Jump to: navigation, search

Difference between revisions of "RAP/Mobile Browser"

< RAP
m (RAP on Mobile Devices)
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
| [[RAP|RAP wiki home]] | [http://eclipse.org/rap RAP project home] |
+
With the increasing popularity of smartphones and tablet-PCs it's also important for RAP to support and adapt to these platforms. RAP can offer powerful solutions for such scenarios, allowing to write complex business-applications for modern mobile devices, provided a appropriately fast internet-connection is constantly available.
  
== RAP on Mobile Device Browsers  ==
+
There is a common '''look and feel''', as well as certain features, that most mobile applications have in common, even across different platforms. The RAP web client can conform to those within limits, but it is mostly up to the application developer to imitate these patterns. It is also recommended to create a custom theme or theme-contribution when targeting a mobile platform to accommodate to for the smaller screens and less precise aiming. This also allows hiding the rap-scrollbars (by setting width to 0), which are uncommon on mobile UIs. On the other hand they may be useful for scrolling across larger areas, but should then be wide enough to hit with a finger.
  
=== General Information  ===
+
As of RAP 1.5, '''support for iOs is mostly solid, while Android still has some more severe issues'''. This is partially due to some bugs of its default browser that are hard to work around. Most significantly, [https://bugs.eclipse.org/bugs/show_bug.cgi?id=378360 touch-scrolling is not enabled]. It is recommended to avoid using ScrolledComposite when targeting Android and use a paging pattern instead. Touch-scrolling for Tree and Table will be added in 2.0 (Kepler).
  
With the increasing popularity of smartphones and tablet-PCs it's also important for RAP to support and adapt to these platforms. Since modern web-standards like HTML5 are well supported by modern mobile devices, they offer a possible solution to write cross-platform applications. However, writing cross-platform conforming javascript and HTML is complicated and not very comfortable, especially for developers used to powerful IDEs and debugging-tools. RAP can offer an easy solution for such scenarios, allowing to write complex, HTML5-based business-applications for modern mobile devices, provided a fast internet-connection is constantly available.  
+
'''Other devices have not been tested.'''
  
There is a common look and feel, as well as certain features, that most mobile applications have in common, even across different platforms. RAP should, within its capabilities, aim to conform to those. As of RAP 1.4M6, support and features for mobile devices are still somewhat limited. See [https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=323031&hide_resolved=1 this bug] for a complete overview of planned improvements. General future topics (they are '''not''' fixed planning-items) include:
+
''Due to emerging [http://developer.eclipsesource.com/tabris/ alternatives], further improving the default clients support for mobile browser is currently not a main focus of RAP development.''
  
*Providing a new custom-theme that looks less alien on mobile devices. All existing themes (default/fancy/classic) are designed to look similar to SWT on desktop operating systems, especially MS-Windows. This new theme would be more "inspired" by the look of MacOS and iOS. An special version of this theme could also increase paddings and dimensions for widgets to be more touch-friendly.<br>
+
An overview of mobile-related bugs can be found in [https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=323031&hide_resolved=1 bugzilla].
 
+
*Providing touch-features. Currently all interactions on touchscreens are translated into mouse-events. However, this approach is somewhat limiting since there are severe differences between an touch interface and a mouse/keyboard interface. Events like mousemove and mouseover have no generally counterpart in a touch-interface, and features like multitouch are not possible to translate into mouse-events. Since SWT now has a Touch-API, one possible solution would be to implement this, other would require custom-widgets specifically designed for mobile devices.
+
 
+
*Improving general performance. Mobile devices are less powerful than current desktop-PCs, and RAP applications are very demanding for a web-application. Startup-time, render-time and animations could be better. However, with the current client, which aims towards to bring the full SWT feature-set to desktop-browser, there is limited room for improvement. See next point.
+
 
+
*Create alternative, feature-limited rap-client(s) for mobile devices. With the introduction of the RAP-protocol, its theoretically possible to replace the current javascript client with other clients. In cases where a mobile platform is the main target (and not just an additional platform), a platform-specific client could be superior. Possible candidates would be a [http://jqtouch.com/ jQTouch]-based client, or clients based on platform-native widgets. This client could only support a very limited subset of RAP, but would in exchange be more lightweight and could support more platform-specific features.
+
 
+
=== iOS-Devices (iPad/iPhone/iPod)  ===
+
 
+
TODO
+
 
+
=== Android  ===
+
 
+
TODO
+

Revision as of 07:57, 24 October 2012

With the increasing popularity of smartphones and tablet-PCs it's also important for RAP to support and adapt to these platforms. RAP can offer powerful solutions for such scenarios, allowing to write complex business-applications for modern mobile devices, provided a appropriately fast internet-connection is constantly available.

There is a common look and feel, as well as certain features, that most mobile applications have in common, even across different platforms. The RAP web client can conform to those within limits, but it is mostly up to the application developer to imitate these patterns. It is also recommended to create a custom theme or theme-contribution when targeting a mobile platform to accommodate to for the smaller screens and less precise aiming. This also allows hiding the rap-scrollbars (by setting width to 0), which are uncommon on mobile UIs. On the other hand they may be useful for scrolling across larger areas, but should then be wide enough to hit with a finger.

As of RAP 1.5, support for iOs is mostly solid, while Android still has some more severe issues. This is partially due to some bugs of its default browser that are hard to work around. Most significantly, touch-scrolling is not enabled. It is recommended to avoid using ScrolledComposite when targeting Android and use a paging pattern instead. Touch-scrolling for Tree and Table will be added in 2.0 (Kepler).

Other devices have not been tested.

Due to emerging alternatives, further improving the default clients support for mobile browser is currently not a main focus of RAP development.

An overview of mobile-related bugs can be found in bugzilla.