The Rhodes framework includes stylesheets customized for each device to give your applications a native look and feel. These stylesheets are included by default in all generated Rhodes applications (public/css/), and are included in the application layout file (app/layout.erb).
The default styles will automatically be applied to all supported content found in the “header”, “footer”, and “content” divs. If you prefer using different names for any of these divs, you will need to update your stylesheets to reflect the new names in order to retain native styling. Conversely, if you prefer not to use any of the customized styles in your applications, you can either delete the links to the default stylesheets from your application, or simply place any content you wish to create custom styles for in a div that does not descend from “header”, “footer”, or “content”.
As with any cross-platform development effort, significant differences exist between the browsers found on devices supported by the Rhodes platform. Additionally, the native look-and-feel of each device varies greatly. For this reason, each device supported by Rhodes requires a custom css framework for visual design.
While there are enough similarities between most browsers to facilitate the use of a single view file across platforms, you may encounter some differences which may necessitate the use of custom view files for specific devices. Rhodes supports such differences in several ways:
To render content in some browsers but not others, you can include conditional statements within your views. For example, this code can be used to conditionally display the name of the phone’s operating system in your model views.
<% if platform == 'APPLE' %> iPhone <% elsif platform == 'ANDROID' %> Android <% else %> Windows Mobile <% end %>
To see the appropriate conditional logic for determining the current platform in the application index (or other page outside a model), refer to the generated application layout.erb - this file contains conditional logic for loading the appropriate automatically-generated stylesheets.
If you use more complex conditionals on a regular basis, you can also create custom helper methods in /app/helpers/browser_helper.rb. The following helper method can be used to
a) determine if a browser is webkit based
def is_webkit? platform == "APPLE" || platform == "ANDROID" end
b) and if it is, include a custom webkit stylesheet in the html header in the application layout file.
<%= '<link href="/public/css/my_custom_webkit.css" type="text/css" rel="stylesheet"/>' if is_webkit? %>
For more significant differences between browsers, Rhodes supports platform-specific loading of view files. At runtime, the application detects the current platform, and checks first for a platform-specific file before loading the default view file.
To create a platform-specific view file, simply name the file using the following convention [action_name].[platform_abbreviation].erb (e.g., index.bb.erb, show.wm.erb)
| Android: | android | index.android.erb |
| BlackBerry: | bb | index.bb.erb |
| iPhone: | iphone | index.iphone.erb |
| Windows Mobile: | wm | index.wm.erb |
As an example, the BlackBerry browser has severely limited support for modern css. In order to take full advantage of the capabilities of the more advanced browsers found on iPhone, Android and Windows Mobile devices.
Keep in mind that any changes made to the standard view files are not incorporated into the custom views, so if you’re developing custom views for a specific platform, ensure that any necessary changes are applied to all relevant view files.
Many of the custom styles required on one platform have no corresponding counterpart on other platforms. For example, while the iphone supports several toolbar button styles, there are no corresponding styles in the Android or Windows Mobile platforms. As a result, the iPhone stylesheet provides custom styles for each of these button types, while the remaining devices apply the same style definition to all four button styles. Refer to the rest of this document for additional information on which styles to apply for your specific use case.
With the exception of the header div, the following sections describe the styles available on iPhone, Android and Windows Mobile devices, which will generally be referred to as standard smartphones.
Please refer to Standard Smartphone CSS/HTML Architecture for a discussion of the html markup and styles available for standard smartphones.
If you prefer to generate your own custom styles for your application, you can do so in several ways:
Locate content outside of the header, footer and content divs.
With the exception of some styles applied to the body, h1 and a tags, the platform-specific stylesheets only apply style to content inside the header, footer and content divs. This option provides the most flexibility in the event you wish to eventually use some of the pre-defined styles.Create custom stylesheets
You can create custom stylesheets for your application which override some or all of the predefined styles in the generated stylesheets. Make sure these stylesheets are included in the layout after the generated stylesheets to ensure that they fall last in the chain of inheritance.Modify the generated stylesheets.
To retain maximum flexibility in your applications, this is ''not'' recommended.You might find the following tips useful if you are developing your own styles for use in a Rhodes application.
When creating navigation elements using links, you may not want them to look like standard links.
display:block
text-decoration:none
Windows Mobile has limited support for floated elements. All floated elements and their parent containers must be assigned a fixed height to properly display, making them difficult to use for dynamically generated content. Additionally, Windows Mobile does not support the overflow:hidden method, so text that flows over the boundaries of its parent container will not be hidden.
Placeholder text is only used in textfields on native iPhone applications, however, you may want to note that placeholders will not be displayed on Windows Mobile, and should not be relied upon as the sole user-facing description of a textfield.
Webkit-based browsers are particularly flexible, as they currently implement many of the advanced features available in css3 and html5.
-webkit-appearance
In Webkit-based browsers, the -webkit-appearance property allows you access advanced browser-specific styles for user interface elements. However, in order to customize the appearance of these UI elements, you may need to turn off the default webkit appearance by including
in your style definitions for input elements, buttons, etc.
You can see an example of this in the generated stylesheets for Android and iPhone, where -webkit-appearance is overridden for all form elements so that form elements can be styled to resemble native applications components rather than those used in the browser.
You can find more information about -webkit-appearance at http://developer.apple.com/safari/articles/cssrecipes.html
Viewports vs postion:fixed
The position:fixed attribute does not exhibit the expected behavior in webkit-based mobile browsers. To ensure that the view is rendered at the appropriate resolution, mobile webkit-based browsers use a viewport to determine which content is displayed.
To understand how scrolling in a viewport differs from scrolling in a desktop browser, imagine a newspaper laid out on a desk. Take a large piece of paper, and cut a 480mm x320mm rectangle out of the center of the construction paper. When you lay the construction paper on top of the newspaper, you can only view a small portion of the content at any given time, and you must move the paper around to see additional content. Similarly, mobile webkit-based browsers render the entire page, and allow the user to move their 480x320px window over the top of the page, in contrast to dynamically rendering of pages found in desktop browsers. Since the entire page is rendered once, the browser is unable to regenerate the toolbar in the appropriate location. As a result, items with position:fixed are interpreted as being fixed relative to the page body, rather than the viewport, and from the user’s perspective, the position of the toolbar is not fixed.