Difference between revisions of "RAP/Mobile Browser"

From Eclipsepedia

< RAP
Jump to: navigation, search
(General Information)
Line 1: Line 1:
 
| [[RAP|RAP wiki home]] | [http://eclipse.org/rap RAP project home] |  
 
| [[RAP|RAP wiki home]] | [http://eclipse.org/rap RAP project home] |  
  
== RAP on Mobile Devices ==
+
== RAP on Mobile Devices ==
  
 
=== General Information  ===
 
=== General Information  ===
Line 7: Line 7:
 
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.  
 
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.  
  
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:
+
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:  
  
* Providing a new custom-theme that emulates the look of 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.
+
*Providing a new custom-theme that emulates the look of 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.
  
* 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.  
+
*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.
+
*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 [jQTouch http://jqtouch.com/]-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.
+
*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) ===
+
=== iOS-Devices (iPad/iPhone/iPod) ===
  
 
=== Android ===
 
=== Android ===

Revision as of 07:07, 1 April 2011

| RAP wiki home | RAP project home |

Contents

RAP on Mobile Devices

General Information

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.

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 this bug for a complete overview of planned improvements. General future topics (they are not fixed planning-items) include:

  • Providing a new custom-theme that emulates the look of 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.
  • 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 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)

Android