Mobile RIA and Competibility

Transcription

1 How rich are mobile Rich Internet Applications? Piotr Andruszkiewicz 1, Henryk Rybiński 1, Grzegorz Protaziuk 1, and Marcin Gajda 2 1 Institute of Computer Science Warsaw University of Technology Warsaw, Poland {P.Andruszkiewicz, H.Rybinski, G.Protaziuk}@ii.pw.edu.pl 2 Samsung Electronics Polska Warsaw, Poland m.gajda@samsung.com Abstract. Nowadays, mobile devices become more and more powerful and they offer continuously growing capability in terms of computing capability, size of screen, available memory, etc. It causes that delivering applications on mobile devices is even more attractive and draws attention of many software producers. However, variety of mobile devices and incompatibility of their operating systems makes very difficult and costly to implement an application with rich functionality which may be installed and used on different types of mobile devices. The solution to this problem can be Rich Internet Applications (RIAs) which are accessible via Internet browsers enhanced by the standardized functionality supporting RIAs. In this paper we characterize required properties of Rich Internet Applications and present the important factors which should be taken into consideration during development of RIAs on mobile devices. We describe Gears platform, which is a good example of RIA platform enhancing functionality of Internet browsers, and present Mobile Wikipedia Application - the example of Rich Internet Application on mobile devices. 1 Introduction Mobile Internet applications become more complicated everyday. Increasing users needs and various mobile computing platforms make development of applications even harder. The solution to this problem is the creation of an application delivery and execution platform, closely coupled with the browser, but having also access to entire local computer infrastructure (and thus being able to store files locally, access the GPU and sound hardware, etc.). Such platform, called Rich Internet Applications (RIA) platform becomes the important Internet application SDK, augmenting browsers (or to be more precise - a Javascript interpreter) with new functionality, such as object serialization and offline storage. We may describe RIAs as web applications that resemble as much as possible native operating system applications - and indeed such a definition can be found, e.g., on Wikipedia [1]. It is, however, quite imprecise, as it is especially difficult

2 to say what is the minimum degree of similarity to a desktop application, that allows us to classify a given web application as rich. Therefore, we shall define the set of properties that should be exhibited by a RIA, as follows: Browser deployment - it seems quite obvious that RIA should be a web application. Note, however, that it is not easy to define what actually a web application is, as this actually depends on technology that was used to create and deploy such an application (and which might be a script, a Java applet, a Flash applet, and so forth). The two main factors differentiating these applications from native applications from end user s point of view are: Reliance on web browser as an operating environment - meaning, that a web browser must be active together with an application, which usually also means that an application uses a browser infrastructure in order to execute its own code, No installation procedure - a web application is immediately available to use after opening a webpage hosting it, no further actions are required before it could be used (such as downloading an installer, etc.) Note also that this means that the application code is downloaded from Internet every time when the application is launched - so there is no software update process inherent to the desktop applications (code and data caching might, however, invalidate this statement to a certain extent). User interaction - Rich Internet Application should be highly interactive. Specifically it should perform data transfers in asynchronous and transparent manner (so that the browser reload button should not be used by the user) and it should react immediately to user actions such as mouse clicks or keystrokes. Obviously visually rich interface elements - such as animations - are also preferred for RIA GUI design, however, their presence does not seem to be mandatory. Session or data persistence - it is assumed that RIA is used for data processing or creation. Therefore it needs an online storage that would be used for data preservation. It is also desirable that the application state would be automatically preserved, making some operations, such as, e.g., explicit file saving, largely redundant. Browser independence - RIAs should not rely on proprietary functionality of specific web browsers or plug-ins. Ideally, a RIA should work equally well on all operating systems and all web browsers, in practice the application functionality might be slightly different depending on the operating environment or depending on availability of certain extensions and plug-ins. 1.1 RIA for mobile devices Mobile connected devices, such as mobile phones, represent an especially interesting target for RIAs. The reason is twofold. First, their usage pattern (ad hoc data access, collaboration, device volatility, etc.) makes RIAs especially compelling to end users. Second, the current level of fragmentation in mobile IT industry means, that the web applications seem to be one of the few technologies allowing creation of cross platform applications, working on most popular handsets -

3 without maintaining several completely incompatible codebases (such as would be the case in creating native applications for iphone, Android and Windows Mobile devices). The mobile platform specific features make RIA implementations substantially more difficult than in the case of desktop computers. The most important differences, relevant for RIA development, between a typical modern mobile device and a desktop computer are: Form factor - mobile devices are by the definition small. In terms of the user interaction this translates to the small screen size (currently typical screen sizes for mobile devices range from 320 x 240 pixels to 800 x 480 pixels with physical screen dimensions around 5 x 10 cm) and lack of typical hardware input controls, such as keyboard or (traditional) mouse, which functionality is usually provided by a touch screen or a mini trackball. This means that the user interface of mobile RIA needs to be specifically tailored to such device. Note, however, that the small screen size does not necessarily have to be a disadvantage for a GUI design. With such limited space it is easier for a designer to avoid visual clutter, especially as users usually expect that mobile applications would be always full screen and thus in locus of attention. Universal availability of touch screen, or voice recording capability also gives us an opportunity to explore innovative concepts in human computer interaction. Performance - while device manufacturers recognize the need for raw processing power, required for applications such as mobile gaming and video playback, the power and heat dissipation constraints still limit the clock speed of mobile CPUs. Currently most of the devices on the market are equipped with ARM compatibles processors clocked at around 1 GHz, which means that mobile devices are around 5-7 years behind desktop systems, as far as Moore s law [2] is concerned. This also means that some CPU intensive operations that can be easily done on desktop computers (such as software 3D rendering) are difficult to perform on mobile devices, especially when RIA uses an interpreted language such as Javascript. Memory restrictions - on a typical mobile device, as opposed to a contemporary desktop computer, the memory available to the operating system is measured in megabytes, instead of gigabytes. Therefore, while designing applications, a popular developer s assumption that the memory is a cheap resource - does not apply. One expects that a mobile application can consume on average MB of memory. Secondary storage space is fortunately usually less of a problem, especially with raising popularity of miniature SSD. Network bandwidth - mobile devices are naturally using wireless networking to transfer data. Such connections are usually slower than attainable with wired network, and additionally the data transfer speed can vary significantly, e.g., while switching from WiFi to HSDPS/UMTS and then to EDGE or even GPRS cellular data transfer. A device network interface might even be switched off completely, either because of the coverage problems, or be-

4 cause the user is trying to minimize the connection costs. Therefore mobile RIA developer cannot assume ubiquitous availability of the Internet data, and they should also implement some provisions (such as data caching, compression, etc.) to maximize utilization of the network bandwidth. Mobility - mobile devices are equipped with much more user context and location awareness data than a desktop workstation. An average contemporary mobile device should know its geographical location (via GPS or BTS triangulation), and should have direct access to various user s personal data, such as contacts, recent conversations, etc. (being much more private and intimate appliance than those on a computer, which might be shared with other people or which might be just a work tool). All that kind of data is practically unavailable to the desktop applications (both RIAs and native software), though at the same time usually it turns out to be highly useful, especially for social networking. Summing up, the properties of mobile devices influence the design of applications both in positive and negative ways. Thus, there is a need to create versions of RIAs tailored specifically to quirks of handsets, both in order to overcome technical limitations such as connectivity problems, but also tapping into wealth of mobile data allowing creation of new breed of social, networked applications. To do it, developers must have access to a mobile API, allowing communication between RIA and mobile hardware (phone, GPS, etc.). During the joint project of the Institute of Computer Science of the Warsaw University of Technology and Samsung Electronics Polska we compared the available RIA platforms in the context of the creation of mobile Rich Internet Applications. Moreover, the design and development of the own framework for RIA platform was also considered. As the targeted RIA framework was to be running on the Samsung mobile device with ARM architecture, Linux operating system and installed browser (provided by Samsung) based on WebKit, we especially focused on the described above mobile aspects of RIA framework. At the time of starting the project, of the existing RIA platforms, only Gears [3] seemed to be advanced enough to provide mobile application developers with API powerful enough to create good quality applications. Other platforms were either not universal enough or not mature. Creating the own framework would require significantly bigger effort than implementing Gears for the given device, because all the APIs would have to be designed and implemented. And the biggest disadvantage of creating the framework from scratch would be its incompatibility with the existing solutions, and thus would force developers to create yet another series of if s to handle yet another platform. Hence, Gears was chosen as a RIA platform for mobile devices. To show possible to obtain functionality of RIA applications, we created the example Mobile Wikipedia Application based on Gears. The application, as an advantage of the RIA framework usage, depends less on the available communication. Local storage enables users to work with the application even when there is no connection to the network and synchronization procedure let them both update information from the server and upload their changes made

5 locally. Usually, RIA applications are supported by the server-side. We created the application without the adjustments of the server-side, to show that this type of applications is also possible, especially for mobile RIAs. The remaining of this paper is organized as follows. The description of Gears in the context of mobile Internet Applications and more details about the implementation can be found in Section 2. Section 3 shows functionality of RIA based on the example of Mobile Wikipedia Application. Section 4 presents experience gained during the RIA application creation. 2 RIA solution based on Gears for mobile devices Gears form the web browser enhancement, installed as an external plug-in, or are delivered with the browser. Gears supports offline mode and acts as an interface between a webpage and the end-users system. The Gears API is accessed through the Javascript objects. A website using Gears is created using same web technologies as an ordinary website. No new tools or technologies are needed. 2.1 Gears Features The solution consists of the following features: LocalServer - the component allows webpages to be loaded from the cache in offline mode. All the resources (html, js, jpg files) forming a website are listed in the manifest file. They are automatically downloaded when in online mode and served from the cache when offline. LocalServer periodically check if the manifest file version has been changed to update the local cache if needed. Database - the local SQLite database and Javascript API to access to the local storage in online and offline mode. The database includes the fts2 extension allowing full-text queries over the TEXT data. WorkerPool - the mechanism allowing websites to run the Javascript code outside of the main page script execution. It enables websites to run the performance intensive calculation (so called workers) in the background without blocking the user interface. The main execution script and workers do not share any execution state and can only communicate by sending message objects. One website can have several workers. Since workers do not operate within a context of a browser window, they do not have access to the DOM. HttpRequest and Timer classes have been introduced to overcome part of this limitation. Desktop - allows the website to interact with the end-user system. It enables a Desktop shortcut creation, as well as displaying an Open File dialog which can be used to pass the contest of the file to the website, without giving the full access to the file system. Geolocation - an API allowing the website to get the end-user s location. It uses several methods of determining the position, depending of the nature

6 and modules available on the end-users system. On desktop PC s it can an IP-based or WiFi-based. On mobile devices it can leverage an embedded GPS module, GSM network based or WiFi-based localization. 2.2 Security model of Gears Gears uses the highly accepted the same origin policy as its underlying security model. The website can only access resources coming from the same schema, host and port. The model has been extended to the Gears offline capabilities and allows websites to cache file coming from same origin and access local database created for the same origin. A customized permission dialog is shown when a particular website tries to use Gears for the first time. After the end-user s acceptance, the choice is remembered. It can be later changed using the Gears Settings dialog. 2.3 Solution for Linux mobile device As there was no Gears implementation provided by Google for Linux, browser (provided by Samsung) based on WebKit and Samsung mobile device with ARM architecture, Gears was ported on Samsung device. To this end, some parts of Gears have been modified and (re)implemented during the project carried out by the Institute of Computer Science of the Warsaw University of Technology and sponsored by Samsung Electronics Polska. Most browsers communicate with the Gears plugin through the NPAPI interface. However, Gears for Linux only existed for Firefox and this implementation was not based on NPAPI but on Firefox s own API. On the other hand, all Gears NPAPI implementations involved browsers for other platforms than Linux. Porting to the Linux + NPAPI + WebKit environment was partly possible by adapting the implementations of Firefox for Linux, Chrome for Windows and the Android browser. 3 RIA functionality on the example of Mobile Wikipedia Application We show Rich Internet Application platform functionality on the example of Mobile Wikipedia Application developed during the project. Mobile Wikipedia Application (MWA) is an application designed to work on a Samsung smartphone with Linux operating system and WebKit based browser. The application communicates with Wikipedia web service. It is capable of downloading information from the Wikipedia, storing them locally on a user device and synchronize with Wikipedia. All information downloaded is stored locally in a database. No alterations of the server-side were conducted and all functionality of RIA was implemented on the client-side. Thus, the example application shows that RIA applications can be created even the server-side does not support RIA functionality. The application is written in JavaScript and GUI is created using XHTML.

7 3.1 Wikipedia article representation from DB new page not DB not Wiki synchronizing saving in DB from DB saving into DB saved in DB not Wiki saving into DB modified in DB not Wiki editing from Wiki from Wiki from DB synchronizing saving into DB from Wiki saved in DB synch Wiki synchronizing from Wiki editing synchronizing saving in DB saved in DB on Wiki saving into DB editing modified in DB on Wiki saving into DB from DB downloaded not DB synch Wiki editing from DB changed not DB on Wiki from Wiki synchronizing saving in DB Fig. 1. State diagram of AppPage object In MWA all needed information about articles downloaded from Wikipedia or created by a user is kept in one object, namely an instance of the AppPage class. The information includes: article data: title, content, time of creation in WMA, time of the last modification and synchronization, id of a page set by Wikipedia, a table of images added to a page, language, attributes used for synchronizations: whether an article has been modified in MWA, the last revision id generated by Wikipedia and the state of an article with respect to the corresponding article on Wikipedia, information used for controlling behaviour of MWA: whether an article has been saved into MWA DB, whether a html view of the code of page should be refreshed. The state of an article is determined based on values of two attributes: db- Status and wikistatus. The former attribute refers to DB and it has one of the following values: DB STATUS SAVED an article stored in DB is the same as in MWA,

8 DB STATUS NOT IN DB an article is new and it has not be added to DB yet, DB STATUS MODIFIED an article stored in DB is out-of-date (modification introduced to the article has not been saved into DB yet). The wikistatus attribute refers to Wikipedia and it takes the following values: WIKI STATUS SYNCH an article is synchronized with the corresponding article on Wikipedia, WIKI STATUS NOT IN WIKI an article has been created in MWA and it has not been added to Wikipedia, WIKI STATUS CHANGED an article has been modified after the last synchronization with the corresponding article on Wikipedia. The article state diagram resulting from values of these two attributes is presented in Figure 1. The figure does not contain the state, in which an article is synchronized with Wikipedia and not updated in DB, because the synchronization with Wikipedia forces saving an article into DB. 3.2 MWA database Fig. 2. ER diagram of the MWA database MWA uses Gears database that is accessed through Gears API. The underlying database management system is a browser-local relational open source SQLite DBMS. Application database ER diagram is shown in Figure 2. It depicts two entities storing information about wikipedia pages and images that are associated with some of the pages. One page can include several images, but there are also pages that do not contain any images. One image can be associated with many wikipedia pages, thus a many-to-many relationship between the entities is mandatory on the side of the Pages entity and optional on the side of the Images entity. Information stored in the Pages entity include: pageid (identifier of the entity), (page) title, content (of the page text of the wikipedia article), creationtime (date and time the page was saved in the database), modificationtime (if the article has been locally modified this field contains date and

9 time of the modification), wikistatus (possible values: synchronized, not in Wikipedia, changed locally ), synchtime (date and time of synchronization with Wikipedia), revisionid, wikiid and lang (language of the article: English, Polish or Korean). The Images entity stores data concerning images, i.e., imagename name that identifies an image and the actual image (field image). Figure 3 shows logical schema of the MWA database. Here we have 3 relations: Pages, Images and PageImage and the fields have data types used by the SQLite database system. Fig. 3. Logical schema of the MWA database As mentioned above database is accessed with the gears API. Some of the API methods that were utilized here include: open() (opens the database for processing). execute() (executes a given SQL statement), close() (closes the database connection), isvalidrow() (returns true if data extraction methods can be called), next() (advances to the next row of the results). 3.3 Synchronization The WMA provides functionality for synchronizing articles stored locally with corresponding articles available on Wikipedia. The four situations that may occur during the synchronization process are described in Table 1. In the case of the last listed situation the user must decided how to solve the conflict, as automatic synchronization cannot be done. In the remaining situations automatic synchronization is possible. The state of an article is determined by using the attribute indicating whether the article has been edited in MWA (true) or not (false) and a property named lastrevid provided by Wikipedia.

10 Article Article stored Description Synchronization on Wikipedia in MWA unchanged unchanged Articles are equal Not needed - articles are synchronized modified unchanged An article on Wikipedia is An article stored locally is more recent than a page replaced by a page stored locally downloaded from Wikipedia unchanged modified An article stored locally is An article stored locally is more recent than an article uploaded onto Wikpedia on Wikipedia modified modified There is a conflict. Both User should decided how articles (the local one and to resolve the conflict the one on Wikipedia) have been modified since the last synchronization Table 1. States of pages in the synchronization process. The sequence of messages sent between MWA and Wikipedia during the synchronization process is shown in Figure 4. The sequences concern situation in which a new content of an article is uploaded onto Wikipedia. In MWA automatic synchronization is done as a background process. It is implemented by using gears objects: workerpool which provides communication between foreground and background processes, timer for setting intervals in a background process, httprequest for sending and retrieving data to and from Wikipedia. 3.4 Communication with Wikpedia The communication between WMA and Wikipedia is done by using MediaWiki API [4]. In the most cases the JSON format is used as the format of Wikipedia response. The communication is synchronous, i.e., after sending a message the application waits for an answer from Wikipedia. Several techniques have been applied to implement this functionality: Technique based on XMLHttpRequest object. The object is provided by Internet browser and in the MWA one global object is created. In general, the technique allows retrieving data in any format. The function sendpostmethod is used for sending messages by using HTTP POST method. Technique based on the HTML script element. A script element is created dynamically and then added to the header of the main HTML page of MWA. Such technique may be used only for retrieving data in JSON format. After executing a JAVASCRIPT code associated with a script element the element is removed from the application HTML page.

11 Fig. 4. Sequences of messages in synchronization process Technique based on the HTML form element. The form element is used only for sending login information and it is created dynamically and placed in a iframe element. The login data sent by Wikipedia are retrieving by parsing the inner HTML code of the iframe element. Technique based on Google httprequest object. The object is used during the automatic synchronization done in background. The object is similar to XMLHttpRequest object, but it provides only asynchronous way of sending of messages. The synchronous way of synchronization is forced in the application code by using SetInterval method. There are two timers: one waiting for finishing of synchronization of all pages, and another waiting for completing action resulting from the synchronization process of single page. Figure 5 shows the results of the example search. The results contain only the articles that have Polska in the title and were modified before Lessons learned Designing Rich Internet Applications, we can use several different approaches. An application can be created with a server support or all RIA functionality can be implemented on a client-side, as in the example application. Moreover, an application can use RIA functionality to a different extent, e.g., only download

12 Fig. 5. The results of the example search. data from a sever and store locally or download, store, modify and synchronize local data with a server. Mobile Rich Internet Applications are even harder to design and develop than desktop RIAs because their should be resistant to communication loses, lower network bandwidth than in wired connections and conformed to smaller displays. Moreover, additional restrictions, as lower memory and performance, should be considered. However, functionality used in the example application shows that Rich Internet Applications can take into account mobile aspects of Internet Applications, e.g., limited network bandwidth and the possible loss of connectivity (data can be downloaded and stored locally on a device), the connection costs reduction (the synchronization procedure enable users to reduce data transfer). Furthermore, the RIA platform can be used to enhance functionality of the application, when server-side does not support the RIA platform. Functionality of the RIA framework presented in this paper is mature enough and desirable for web application developers and users, so it is going to be included in HTML5 standard [5]. Google also works on bringing all Gears functionality into HTML standard. However, RIA functionality will be evolving. Nowadays the specification of HTML5 standard enable users to continue interacting with Web applications and documents even when their network connection is unavailable, so called Offline Web applications. HTML5 also defines an API for persistent data storage of key-value pair data in Web clients (called

13 Web Storage in the specification). Web Workers in HTML5 enable developers to spawn background workers running scripts in parallel to their main page. Geolocation mechanizm was also included in HTML5 specification. Implementations of HTML5 standard which consider limitations of mobile devices will popularize mobile RIA applications in the near future. References 1. RIA: Rich internet application internet application (2011) 2. Mollick, E.: Establishing moore s law. IEEE Annals of the History of Computing 28 (2006) Gears: (2011) 4. API: Mediawiki (2011) 5. HTML5: specification (2011)