public interface MobileDevelopment
In general, a Smart GWT application written with complete ignorance of mobile development will still be highly usable on tablet or handset-sized touch devices. This topic explains all the automatic behaviors that make this possible, and the few areas developers need to consider in order to optimize the mobile experience, the most important being:
accessibility reasons), this section discusses
 options for
       controlling drag scrolling vs dragging of data
  
If you would like to check whether a specific device falls under normal Support, or would like a quote for a Support plan that would include a specific device or platform, contact Isomorphic here.
Many Smart GWT components automatically change their behavior and/or appearance when used with touch devices in general, or tablets and handsets specifically. There are too many adaptations to comprehensively list, but some of the more obvious behaviors are listed below:
SelectItem and ComboBoxItem controls automatically fill the entire
 screen
       or a major portion of the screen when activated, and add a control to dismiss the
 full-screen interface.  See ComboBoxItem.pickListPlacement for details
 Menu components likewise fill the entire screen
 or a major portion, and offer
       submenu navigation via a slide-in animation and back button instead of displaying the
       origin menu and submenu simultaneously
 Calendar eliminates the
 tabs normally used to switch between
       Day, Week and Month view, instead using device pivot to switch between Day and Week
       views and offering a compact link to Month view
  Slider thumb, Window.headerControls,
 edge-based resizing, and many other
 controls.
 SpinnerItem switches to side-by-side +/-
 controls instead of the very small,
       vertically stacked +/- control typical of desktop interfaces
 AdaptiveMenu can either display menu items
 inline, or in a drop-down,
         or mix the two modes according to available space.
  
 In addition to automatic behavior, Smart GWT offers Adaptive Layout whereby a Layout
  member may be designed to render itself at multiple possible sizes, in order to fit
  into the amount of space available in the Layout.  Unlike simply indicating a flexible size
  on a member, setting an adaptive width or height indicates that the member has two (or more)
  different ways of rendering itself with different discrete sizes, but does not
  have the ability to use every additional available pixel.
  
 For more guidance, see the documentation under Canvas.canAdaptWidth and the
 Inlined Menu Mobile and 
 Adaptive Menu samples.
  
Mobile and touch devices support "touch events" that correspond to finger actions on the screen. By default, Smart GWT simply sends touch events to UI components as normal mouse events. Specifically:
Components that normally show scrollbars on desktop browsers will, by default, hide scrollbars and allow scrolling via finger dragging instead.
 If you are using drag and drop features such as ListGrid.canReorderRecords,
 this
  obviously conflicts with using finger drags for scrolling.  There are two options:
  
Canvas.alwaysShowScrollbars to true.
 useTouchScrolling to
 false on the component.
       Scrollbars will be shown, and finger drags will no longer cause scrolling, so that
       finger drags can now be used for the drag and drop operation configured on the
       component
  Accessibility violation if drag and drop is the sole way to
 trigger an
  operation (keyboard-only users cannot use drag and drop), and also because scrollbars are
  not usually found in touch interfaces.
  
  If your application is not required to be keyboard accessible, and you prefer to show
  scrollbars and use finger drags for normal drag operations, you can use
 Canvas.disableTouchScrollingForDrag to make this choice system-wide or on a
  per-component-type basis.
  
If you have designed a screen for desktop use and it is too wide to fit on a handset or tablet-sized screen, there are several possible strategies:
SplitPane: any time you have two or
 more panes where a choice in one
       pane decides what is displayed in the other.  See the "SplitPane" section further down
       for details
 DynamicForm
       that has 3 columns of input fields, as long as the form itself or some parent has
 overflow:"auto" set, horizontal touch
 scrolling will be
       available to reach fields that initially render offscreen.  Most of the time, there is
       already an overflow:"auto" parent component as a result of default
       framework behaviors or application settings that also make sense for desktop mode,
       so nothing needs to be done.
       However, consider whether scrolling is already in use for other purposes: if you have a grid plus an adjacent component to the right, if the adjacent component is entirely offscreen, attempting touch scrollng on the grid will just scroll the grid as such and won't reveal the adjacent component. In this kind of situation, you can:
SplitPane as described above, a grid
 with something adjacent is
         frequently a good candidate for conversion to SplitPane
    flexible size.
    useTouchScrolling to false. 
 This is another way to
         give the user a place they can touch in order to scroll the both the grid and
         adjacent component together
    FlowLayout: a
 FlowLayout can automatically take two
       side-by-side elements and switch them to vertical stacking when the screen is narrow
  
 The SplitPane component implements the common
 pattern of rendering
  two or three panes simultaneously on desktop machines and on tablets in landscape
  orientation, while switching to showing a single pane for handset-sized devices or tablets
  in portrait orientation.
  
  Use SplitPane anywhere you have two or more panes in your application where a
  choice in one pane decides what is displayed in the other pane.  For example, you may have a
  list of Records where details of a single selected Record are shown next to the list.  A
  SplitPane is well-suited to this interface since it provides automatic "Back"
  navigation and a place to show the title of the selected record when only the detail view is
  showing.
  
  Note that you do not need to use a SplitPane as your top-level component
  containing the whole application, and it does makes sense to use multiple
  SplitPane components in a single application.  For example, your top-level
 container component might be a TabSet, and a SplitPane would be used to manage
  components in tabs which normally show 2 panes side-by-side on desktop browsers.
  
  In most cases Smart GWT will correctly detect the device running your application, and set
 the flags isTouch, isHandset, isTablet and
  isDesktop appropriately.
  
  For any uncommon device for which these variables are not set correctly, you can use
 Browser.setIsTablet(), Browser.setIsHandset() and Browser.setIsTouch()
  to override the auto-detected settings.  If you use these APIs, call them before
  creating or drawing any Smart GWT components or using any other Smart GWT APIs.
  
 Note that the various automatic behaviors triggered by flags on the Browser class can
  be overriden at a fine-grained level on individual components.  For example,
 SplitPane will use 2-pane display when a tablet is
 detected, however, for a
  particularly large, high-resolution tablet device, you could instead use 3-pane display by
 setting SplitPane.deviceMode
 to "desktop".
  
We recommend using either the Tahoe, Twilight, Stratus or Obsidian skins for applications that support mobile (or a custom skin based on one of these skins). These skins make maximum use of CSS3 to minimize the number of images that need to be loaded and the number of DOM elements used to create components.
We also do not recommend attempting to mimic the native UI of each particular mobile platform, because:
Safari in iOS 7.0 will automatically hide and show browser toolbars as the user scrolls around a normal web page, pivots, or touches near edges of the screen. This creates serious problems for web applications, partly because notifications are not reliably fired when toolbars are shown and hidden, and partly because it introduces "dead zones" where an application cannot place interactive controls, since touching there shows browser toolbars instead.
  iOS 7.1 introduces a "minimal-ui" setting on the viewport meta tag which
  eliminates most of these problems, by requiring that the user specifically touch the 
  URL bar to reveal browser toolbars.  Even with this setting, the top 20px of space in
  landscape orientation only is still a "dead zone".
  
  Smart GWT automatically uses the minimal-ui setting whenever iOS is detected, and also
 sets defaultPageSpace to 20px in
 landscape orientation to avoid components
  being placed in the dead zone.  These default behaviors can be disabled by defining the
  isc_useMinimalUI global variable with the value false before the
  framework is loaded: 
  
<script type="text/javascript"> window.isc_useMinimalUI = false; </script>
  Whether minimal-ui is used or not, it is recommend to place some kind of non-interactive
 widget or content in the dead zones created by browser toolbars, for example, a Label
 showing your company name or application name.  When using defaultPageSpace to have
  all components avoid a dead zone at the top of the page, you can set
 leavePageSpace:0 to allow
 individual components to place
  themselves in a dead zone.
  
  When a Smart GWT application loads, by default a viewport <meta> tag is added to the
  page which, on touch devices, fixes the page zoom to 100% and disables the pinch-zoom gesture.
  This is usually the expected behavior of a touch-enabled web application because it makes
  the application look and feel more like a native app. This default setting can be disabled
  by defining the isc_useDefaultViewport global variable with the value
  false before the framework is loaded:
  
<script type="text/javascript"> window.isc_useDefaultViewport = false; </script>For more information on the mobile device viewport, see:
When orientation changes, this is treated identically to resizing the browser on a desktop machine. If you've already created a UI that fills the browser and makes good use of available screen space for desktop browsers, the same behaviors will automatically apply when your application runs on mobile devices and the device is pivoted.
  If you want to build specialized interfaces that respond to device orientation, the
 Page.getOrientation() API may be used to
 determine the current orientation of the
 application, and the page orientationChange event
 will fire whenever the
  user rotates the screen allowing applications or components to directly respond to the user
  pivoting their device.
  
  Generally, all that's required to launch native mobile apps is to create an ordinary HTML
  hyperlink (<a> tag) with a special prefix for the URL specified in the
  href attribute.  For example, the following HTML link will place a call when
  the user finger-taps it:
  
    <a href="tel:8675309">Call Jenny</a>
 You can provide HTML like this as HTMLFlow.contents.  Or use a field of
  type:"link" to cause various
 DataBoundComponents to render a
 DataSourceField value as a
  clickable URL.
  The URL prefixes that are valid for iOS are documented at Apple.com. Typically, the same prefixes also work for Android, Windows Phone and others.
 TextItem.browserInputType can be set to various values such as "email" or "tel"
  (telephone number) to hint to mobile devices to use a different software keyboard with
  specialized keys appropriate for entering certain types of data values.
  
When the first modern smartphones were released, it was necessary to use tiny, mobile-specific frameworks to get adequate performance for mobile web applications.
The situation is now completely different: through a combination of hardware improvements, optimizations in mobile browsers and vastly improved network speeds, typical mobile devices are easily able to run applications built with full-featured web platforms like Smart GWT. For an application that supports both desktop and mobile interfaces, the worst case scenario for platform performance is often not a mobile phone, but an older desktop machine running Internet Explorer.
Unfortunately, there is a lot of out-of-date advice on the web about mobile web development that still advises using ultra-light, feature-poor frameworks for performance reasons. Carefully consider the source and recency of any such advice - the reality is that using such feature-poor frameworks means you will under-deliver with both your desktop and mobile interfaces.
For more background on choosing the right technologies for mobile and desktop web applications, see the Mobile Strategy Page at smartclient.com.
Smart GWT applications support "offline" operation (continuing to work without network access).
Permanent caching of resources such as .js, .css files and images are handled via the standard HTML5 Manifest - just list all the static files your application needs in a manifest file and mobile browsers will cache those resources.
 Dynamic data is handled via the Offline APIs as well as
 special DataSource support
 enabled by DataSource.useOfflineStorage.
  
The end result is that you can bookmark a Smart GWT application to a phone's home screen and use it offline with cached data, much like an installed native application.
Via "packaging" technologies such as PhoneGap/Cordova and Titanium, a Smart GWT web application can be packaged as an installable native application that can be delivered via the "App Store" for the target mobile platform. Applications packaged in this way have access to phone-specific data and services such as contacts stored on the phone, or the ability to invoke the device's camera.
Both Titanium and PhoneGap provide access to the underlying native device APIs such as the accelerometer, geolocation, and UI. Both frameworks enable application development using only JavaScript, CSS and HTML. Additionally they provide development environments that work across a wide variety of devices.
 PhoneGap has good support for native device APIs as noted here.
  Titanium has similar support. There are differences between the two environments and how they
 expose their APIs, though both provide Xcode-compatible projects that can be compiled and run
 from the Xcode IDE.
 See Integration with Titanium and Integration with PhoneGap
  for more information.