Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "RAP/Mobile Browser"
< RAP
| Line 9: | Line 9: | ||
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 | + | *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> |
*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. | ||
Revision as of 07:10, 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 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.
- 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.