Cross-platform mobile development using Web Technologies

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO Cross-platform mobile development using Web Technologies Diogo Costa Mestrado Integrado em Engenharia Informática e Computação Supervisor: Rui Maranhão (PhD) July 10, 2013 Cross-platform mobile development using Web Technologies Diogo Costa Mestrado Integrado em Engenharia Informática e Computação Approved in oral examination by the committee: Chair: António Miguel Pontes Pimenta Monteiro (PhD) External Examiner: José Maria Amaral Fernandes (PhD) Supervisor: Rui Filipe Lima Maranhão de Abreu (PhD) July 10, 2013 Abstract There are many different mobile platforms nowadays that share the same applications, at least their name and brand. The differences between each of these mobile platforms make it very hard to build a single code base that runs in all platforms. However, efforts are being made to turn this into a possible scenario. Since almost all major platforms provide a web engine that supports HTML5, CSS3 and Javascript, these technologies have become the base for most cross-platform development framework efforts. Using HTML5, Javascript and an application wrapper, such as PhoneGap, it is possible to make a web application that runs just like a native one. One of the major drawbacks of this approach is developing the user interface. Each platform has its user interface guidelines and designing an interface for each platform can be time consuming. This dissertation addresses the implementation of framework that aims to simplify the development of cross-platform applications using HTML5, CSS3 and Javascript, including a library that auto-adjusts to the look and feel of the platform the application is running on. A demo application will also be described, showcasing the developed framework. Keywords: Mobile, HTML5, CSS3, Javascript, cross-platform, PhoneGap, Meems i ii Resumo Atualmente existem diferentes plataformas móveis que partilham as mesmas aplicações, ou pelo menos o mesmo nome e marca. As diferenças entre estas plataformas móveis tornam muito difícil a utilização do mesmo código fonte para a geração de executáveis para cada uma das plataformas. Contudo, estão a ser feitos esforços no sentido de tornar este cenário uma realidade. Visto que as grandes plataformas móveis disponíveis atualmente suportam HTML5, CSS3 e Javascript, estas tecnologias tem vindo a tornar-se a base da maior parte dos esforços para criar uma framework para desenvolvimento de aplicações móveis multiplataforma. Através da utilização de HTML5, Javascript e um wrapper como o PhoneGap é possível criar uma aplicação web que se assemelha e se comporta como uma aplicação nativa. No entanto, um dos grandes entraves neste momento a este tipo de solução é o desenvolvimento da interface gráfica do utilizador. Cada plataforma tem os seus próprios “guidelines” gráficos e desenvolver uma interface por plataforma é uma tarefa que consome bastante tempo. Esta dissertação endereça a implementação de uma framework que tem por objetivo a simplificação do desenvolvimento de aplicações móveis multiplataforma, recorrendo para isso às tecnologias HTML5, CSS3 e Javascript. A framework inclui uma biblioteca para desenvolvimento de interfaces gráficas do utilizador que ajustam a sua aparência e comportamento consoante a plataforma em que a aplicação está a ser executada. É descrita também uma aplicação de demonstração, cujo objetivo é mostrar como utilizar a framework desenvolvida e mostrar do que é capaz. Keywords: aplicações, móveis, HTML5, CSS3, Javascript, multiplataforma, PhoneGap, Meems iii iv Acknowledgements I would like to say thank you to my family, particularly my grandparents, for supporting me during the past year, when I worked and studied at the same time. Their contribute was crucial for me to be able to finish this dissertation. I would also like to thank my parents, for believing in me and their unconditional support, and my girlfriend Marisa for fighting so that we can both have a good life in the future. At last, but by no means least, I would like to thank my supervisor Rui Maranhão, for accepting to guide me throughout this dissertation and providing his support and expertise, and my colleagues at Novabase for their friendship and support. Thank you all. v CONTENTS xii List of Figures 2.1 KendoUI ...................................... 12 2.2 Kendo UI on iPhone, Android and BlackBerry . . . . . . . . . . . . . . . . . . . 13 2.3 jqMobi........................................ 13 3.1 Native Android Facebook application (left) and Fastbook (right). Credit: Sencha 18 3.2 Earlier version of LinkedIn mobile. Credit: LinkedIn . . . . . . . . . . . . . . . 18 3.3 Exfm iPhone application (hybrid). Credit: Exfm . . . . . . . . . . . . . . . . . . 20 3.4 Exfm Android application (native). Credit: Exfm . . . . . . . . . . . . . . . . . 20 5.1 TheMeemsFrameworklogo............................ 31 5.2 Model-View-ViewModel design pattern . . . . . . . . . . . . . . . . . . . . . . 33 5.3 Dependencies between the libraries that constitute the Meems framework . . . . 36 5.4 Pagestructure.................................... 47 5.5 PageinAndroid................................... 47 5.6 PageiniOS ..................................... 47 5.7 Menuclosed..................................... 48 5.8 Menuopen ..................................... 48 5.9 Menualwaysvisible ................................ 48 5.10 A button group in Android (left) and iOS (right) . . . . . . . . . . . . . . . . . . 48 5.11 A form example in Android (left) and iOS (right) . . . . . . . . . . . . . . . . . 49 5.12 A simple list (left) and a list with ordering and multiple selection (right) . . . . . 50 5.13 Example of switches, sliders and text fields in Android (left) and iOS (right) . . . 51 6.1 Simplified use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.2 Low fidelity mockup. From top-left to bottom right: login screen, empty news screen, feeds screen, manage feeds screen, news screen, news detail screen . . . . 61 6.3 Flowbetweenthescreens.............................. 62 6.4 Architectureoverview................................ 64 6.5 RSS Reader running on Android 4.2.2 . . . . . . . . . . . . . . . . . . . . . . . 70 6.6 RSS Reader running on iOS Simulator, in Safari browser . . . . . . . . . . . . . 71 xiii LIST OF FIGURES xiv Abbreviations ADT Android Developer Tools API Application Programming Interface CSS Cascading Style Sheets GPS Global Positioning System HTML HyperText Markup Language IDE Integrated Development Environment NDK Native Development Kit SDK Software Development Kit SPA Single Page Application UI User Interface W3C World Wide Web Consortium WHATWG Web Hypertext Application Technology Working Group xv Chapter 1 Introduction Smartphones are changing the way we live our lives. Checking emails, listening to music, sending texts, video chatting, GPS navigation, watching movies or taking notes are just a small subset of the tasks most smartphone owners perform. The practicality of these small but powerful devices that fit in a pocket is attracting more people every day. In 2007 and 2008, the two major mobile operating systems were released to the market: Apple’s iOS and Google’s Android. Together they power the largest group of smartphones, making them the most popular mobile operating systems. Others have appeared meanwhile, like Windows Phone, BlackBerry OS or Bada, each with relative success. The success of smartphones has been also directly related to its application ecosystem. The ability to download third party applications allows users to power up their phones with new functionalities without being tied to the operating system’s provider. This also created opportunities for companies and developers to profit by developing new applications. Many have taken this opportunity and today there are thousands of mobile applications available for download. Developing for a mobile platform, however, has brought new challenges compared to the traditional development of desktop applications. Smartphones have different specifications and capabilities than desktop computers and require good planning and implementation to build an application that is easy to use and useful for the final users. Some guidelines and general coherence is therefore necessary to reduce fragmentation and provide users with an excellent user experience on their usually small-sized-screen smartphones. Every mobile operating system has its own development, graphics and user interface guidelines. Following these guidelines ensures that third-party applications integrate well with the rest of the platform. However, this fragmentation also means that in order to build applications for several platforms, one must develop different applications, one per platform. The advent of HTML5 and its growing support in mobile browsers has put the development of cross-platform web applications as an alternative to native development. Web applications do have limitations, but with the increasing popularity of this approach, people have been turning to hybrid applications, mixing web and native code to produce cross-platform applications. 1 Introduction 1.1 Context and Motivation This dissertation was born from my personal necessity to build mobile applications that look native as fast as possible and without spending too much money. After a quick survey of the available tools in market, I wasn’t satisfied with the fact that no good free/open-source solutions were available. PhoneGap looked like a great starting point, enabling the packaging of web applications for six different platforms, but, although there are many frameworks and libraries for the development of mobile web applications, none would provide a native look and feel according with the platform it was running on. Developing mobile applications for different platforms requires different programming languages and tools. Using web technologies, one can use HTML5, CSS3 and Javascript to build applications that run across all major operating systems, thus saving time and money while producing more. This only applies to certain types of applications, of course. There are cases when a native application is not only desirable but required, like those that need to interface directly with the phone’s hardware. With this dissertation, I intend to develop a framework that help developers build their mobile applications faster and cheaper, but still looking good on each mobile operating system, focusing on Android and iOS at first. 1.2 Goals The main goal of this project is to produce a framework that enables developers to build mobile web applications that look native on Android and iOS platforms using web technologies, namely HTML5, CSS3 and Javascript. The developed framework will use open-source and will also be available entirely as open-source, as a contribution to the community that has offered, and continues to offer, me so much, in terms of knowledge, support and free technology. This will also enable other people to contribute to the project, allowing it to grow and be useful to other people. But first, a study over the existing and most popular technologies must be performed in order to identify their most attractive aspects and those they are lacking, so that they can be included in the framework. The necessities of the market and developers is also to be taken into account, so a survey must also take place. The definition of the user interface must be extensible, allowing the developer to create its own component when necessary, and must adapt itself to the look&feel of the platform it is running on, allowing, however, the developer to override the default behaviour if needed. The framework must use existing, approved and popular libraries and tools, like PhoneGap and require.js, to be built over good practices and to appeal to as much developers as possible. After developing the base framework, a demonstration application will also be developed. This application, being for demonstration purposes only, will showcase the framework and how to use it. The application must run on Android, iOS and the most common web browsers. A server-side 2 Introduction component must also be developed in order to demonstrate how to build an application end-to-end using Javascript as the base programming language. 1.3 Dissertation’s Structure This dissertation has 5 main chapters: “State of the Art” (chapter 2), “Case Studies” (chapter 3), “Market Study and Analysis” (chapter 4), “The Meems Framework” (chapter 5) and “RSS Reader: Demo Application” (chapter 6). After the introductory chapter (chapter 1), different approaches when developing for mobile devices will be shown in chapter 2, along with general information on the mobile operating systems available nowadays and how to web applications can be published in the stores of the vendors of the platform. Then, the main web technologies this dissertation focus on are presented, namely HTML5, CSS3 and Javascript. In this chapter, a subset of the existing frameworks, tools and libraries that enable developers to build web mobile applications will also be presented, along with a comparison between them. In chapter 3, some interesting and famous mobile web applications are exposed, along with a short analysis of the patterns used in the user interface and general trivia about the development of each application. Some conclusions about developing for mobile and the advantages of using web technologies for such task are drawn. Chapter 4reveals the main results of a survey that was conducted in the context of this dissertation are presented and interpreted. Chapter 5describes the development of the main framework that was born from this dissertation. The goals and main concepts of the framework are discussed first, followed by a description of the architecture and functionalities developed. The difficulties and challenges in developing this solution are presented at the end of the chapter, together with conclusions about the development. Besides the main framework, a demonstration application was also developed, as described in chapter 6. The requirements of the application, its user interface and architecture of both mobile client and back-end are described in this chapter. Some conclusions about the development experience are drawn. Finally, chapter 7closes this dissertation, with overall conclusions about the work developed and its goals, a personal opinion about the future of the world of mobile development and some ideas about what work could be developed in the future to improve the Meems framework. 3 Introduction 4 Chapter 2 State of the Art The development of mobile applications is a recent field and has been growing in the past few years. The appearance of more powerful smartphones and operating systems is causing this field to evolve and grow exponentially. In this chapter, a brief history of recent mobile operating systems is presented, along with a description of the common approaches taken to develop third-party software to these platforms, with special focus on web technologies, particularly the HTML5 standard. Some mobile web application development frameworks and libraries are also presented and analyzed. Finally, the results of the survey performed in the context of this dissertation are presented and interpreted, closing off this chapter with a few conclusions about the gaps this dissertation intends to fill. 2.1 Mobile Operating Systems Smartphones have become an important tool in our life. They’ve become practical, powerful and extensible. The evolution in hardware and software is intertwined, better hardware enables better software, and better software makes the user want more, leading to better hardware. In the past few years, a revolution in the mobile fields has took place. The advent of modern operating systems like Android and iOS has changed the way people use smartphones. 2007 and 2008 were the years Google’s Android and Apple’s iOS were presented to the world. The iPhone, by Apple, was first revealed in January 2007, running the “iPhone OS”, re-branded in 2010 to iOS. Later, in September 2008, the first phone running Google’s Android operating system was presented: the T-Mobile G1. The iPhone started this revolution, bringing to users a powerful phone designed to do more than just communicate. It included multitasking and graphics capabilities and sported a multitouch screen, accelerometers, camera and other hardware components that contributed to a rich user experience. People were very receptive to this device, as sales have proven: 6.1 million 1st generation iPhones were sold over five quarters.[App09] 5 State of the Art 2.4.4 Sencha Touch Sencha Touch5is a high-performance HTML5 mobile application framework that enables developers to build cross-platform applications using Javascript that work on iOS, Android, BlackBerry, Kindle Fire and other devices. It features smooth scrolling and animations, more than 50 widgets, fast adaptive layout engine, native packaging, advanced lists and much more. The designing of the user interface is done via Javascript, using the provided API. The generated UI can be themed, but it does not adapt itself to the look&feel of the platform. It is well documented, has a large community and many demo and real-world applications to learn from, making it one of the most successful frameworks for web mobile development. 2.4.5 Wink toolkit The Wink toolkit6is also a Javascript framework for developing mobile web applications. It is lightweight, provides touch events handling, DOM manipulation, CSS transforms and several UI components. The interfaces are designed using Javascript to invoke their API. Available for free, it currently supports iOS, Android, BlackBerry, Bada and Windows Phone 7. Like other frameworks described above, the generated user interface can be customized using CSS or by using one of the provided themes. And once again, it does not adapt the interface to the platform’s look&feel. It is highly modular and the existing demo applications, tutorials and community are good starting point for starting to use this toolkit. 2.4.6 Jo Jo7is another framework that allows a developer to build mobile applications using Javascript and CSS. The generated UI is supposed to look native, but only on iOS. It takes full advantage of CSS3 to style the screens making it easy to customize. The documentation is good and there are a few demos, but it does not seem to be used by many applications so far. 2.4.7 Kendo UI Figure 2.1: Kendo UI Kendo UI Mobile8is a complete framework for developing cross-platform web applications that look native in Android, iOS and BlackBerry devices. Differences between platforms are 5http://www.sencha.com/products/touch/ 6http://www.winktoolkit.org 7http://joapp.com/ 8http://www.kendoui.com/ 12 State of the Art automatically dealt with by the framework, adapting the user interface to comply with the platform standards. The framework promotes the separation between the application’s logic and the user interface. Three central concepts define an app: application logic, which is written in Javascript, layouts and views, both written with HTML. The application logic layer manages all navigation, application history, loading views and other essential mobile app tasks, besides the logic associated with the app’s business logic. Layouts define reusable portions of the application, similar to templates. Its often used to promote maintainability by defining common view areas used across multiple views. Finally, views are individual pages of the app. Most applications will have at least one view. Currently, Kendo UI only supports iOS, Android and BlackBerry OS. Besides the nativelike theming and layout system, it is also a complete mobile application framework, handling navigation, views, templates, animations and history. It can be downloaded for a 30-day trial, after which a license must be bought. Figure 2.2: Kendo UI on iPhone, Android and BlackBerry 2.4.8 jqMobi and jqUI Figure 2.3: jqMobi JqMobi9is a small Javascript library for mobile HTML5 application development that can 9http://www.jqmobi.com/ 13 State of the Art replace jQuery in mobile devices. JqUI is a UI toolkit for building user interfaces for mobile applications using HTML5. Using HTML5 elements such as header,nav and footer and some custom dataattributes, jqUI allows a developer to specify the user interface of a whole application and customize it through CSS and Javascript. It targets mobile WebKit browsers, so it works on iOS and Android platforms. It has a small footprint of only 22kb when gzipped and supports plugins for extending functionality. The generated user interface can be styled using themes, but, unlike Kendo UI, it does not adapt itself to the platform’s look and feel. It does provide an overall design that works nicely on mobile devices, which consists of a fixed header and footer, a content area in the middle and a menu on the side that collapses and expands on user command on small screens or is always visible in larger screens. Through the use of plugins, the developer can extend the framework with new functionalities like sub-panels, internationalization, advertisement or maps. JqMobi and jqUI are both open-source projects. 2.4.9 Comparison between frameworks Despite not being a listing of all available frameworks, the list above includes enough frameworks to analyze the current state of the art. HTML5 is still under development and the difference between platforms and their different implementations of HTML5 caused many frameworks to appear, each with its way of tackling the problem, trying to provide developers with the tools for developing better applications that run on as many devices as possible, are cost effective and user friendly. Although all these frameworks leverage the power of HTML5, there are clearly two different approaches as to how the developer designs the applications. JQuery Mobile, jQTouch, Kendo UI and jqMobi try to extend HTML, allowing the user to write the application’s screens in HTML and then applying custom identifiers, CSS classes or dataattributes to provide context and meaning to a specific part of the HTML so that the framework can than transform it into a part of the final application. On the other hand, Sencha Touch, Wink and Jo force the developer to design all the screens in Javascript through the use of their own API. Each approach has its advantages and disadvantages. In the first approach, the traditional HTML file and structure is maintained, the developer just has to make sure that it is structured the correct way so that the framework can interpret the file correctly. However, it is less flexible when compared with Javascript and there is the initial overhead of processing the file to prepare the user interface each time the application is loaded. In the second approach, although it is much more flexible, it requires the user to learn a whole new API. Also, the design of the screens is not as well structured as in the first approach, making it harder to be maintained by a designer that doesn’t know Javascript. As far as look&feel goes, all frameworks provide a consistent user experience across several platforms, mostly because its design and behaviour is the same on every platform. Most frameworks do support theming, but this is not enough to emulate the native look&feel of a platform. 14 State of the Art Name Type HTML5-based UI JS-based UI Cost Native looks jQuery Mobile Library Yes No Free No jQTouch Library Yes No Free No Sencha Touch Framework No Yes Free/Paid No Wink Framework No Yes Free No Jo Framework No Yes Free No Kendo UI Framework Yes No Paid Yes jqMobi Library Yes Yes Free No Table 2.1: Comparison between frameworks The exception to this is Kendo UI. Of all the frameworks above, it is the only one that tries to adapt the user interface to the platform’s look&feel, for instance, tabs will be placed on top in Android phones, on the bottom with labels in iOS or on bottom without labels in BlackBerry. Also, the theme color and images are automatically changed to themes specific for each platform. Although it still cannot pose as a real native application, it does a better job than any other framework. 2.5 Conclusions The smartphone world continues to evolve at an accelerated pace and developers are constantly looking for new ways to speed up the development process of their applications. Web technologies have a good support on recent mobile platforms, making them a good investment for crossplatform development, depending on the kind of application that is being developed. And combined with products like PhoneGap, web applications can pose as native applications and gain access to hardware features that otherwise they wouldn’t have. This enables developers to build powerful applications using only HTML5, CSS3 and Javascript. There are already many frameworks and libraries that aim to make it easier for the developer to build mobile web applications. However, most of these frameworks and libraries don’t provide a native look&feel, rather providing themes that stay consistent across platforms. If a web application wishes to truly integrate with the platform it is running on, then the user interface should look native. However, this should be achieved without requiring the user to define multiple interfaces, one per platform. As so, there is an opportunity and necessity in creating a tool that builds user interfaces that are automatically adjusted to the look&feel of the platform the application is running on, and it is precisely this that I propose to do in this dissertation. 15 State of the Art 16 Chapter 3 Case Studies In this chapter, some known hybrid applications are analyzed to better understand the type of applications that employ web technologies and the design patterns that were used. 3.1 Facebook The Facebook mobile application is very popular, with around 470 million mobile users, where 140 million people use the iPhone app and 176 million use the Android app.[Eva13]. Until the end of 2012, beginning of 2013, Facebook’s mobile application was powered by HTML5. However, Facebook decided to change to native development, saying that betting too much on HTML5 was a mistake.[Ola12] The developers of Sencha Touch, however, did not believe that the problem was HTML5, but rather the techniques used by the developers of Facebook, so they developed Fastbook, a proofof-concept web application that implements the basic features of Facebook, implemented using the Sencha Touch framework. The Fastbook application even managed to beat Facebook’s native Android application in terms of performance.[JA12] In terms of user interface (see figure 3.1), both applications use a top bar with action buttons and the rest of the screen is filled with a list component, which contains the posts. A navigation drawer is also present on both applications. Swiping from the left edge or clicking on the topleft button reveals the navigation drawer, allowing the user to explore through other parts of the application. Both the native applications (iOS, Android) and the Fastbook application use their own appearance, without adjusting to the looks of the platform, therefore looking the same on iOS, Android and even Windows Phone.[Thu13] 3.2 LinkedIn LinkedIn is a social networking website, used mainly for professional networking, with more than 200 million members as the beginning of 2013.[Nis13] 17 Case Studies Figure 3.1: Native Android Facebook application (left) and Fastbook (right). Credit: Sencha In mid 2011, LinkedIn launched its mobile application for Android and iOS. This application was actually a hybrid application, leveraging the power of HTML5 for 95% of the graphical interface. Later, in May 2012, they also launched an iPad application, again also powered by HTML5. Both applications were well received, for its performance and design, which was pleasant and a great improvement when compared to the web site version, which was the only interface available to mobile users before the launch of the applications. It’s also worth noting that the company migrated their back-end code from Ruby on Rails to node.js, which led to an increase of performance and scalability. [O’D11,O’D12] Figure 3.2: Earlier version of LinkedIn mobile. Credit: LinkedIn 18 Case Studies Figure 3.2 shows the first mobile application that LinkedIn launched for Android and iOS. It shows a slick design, which seems like a variant of the native design of iOS, a top bar with a centered title and action buttons on each side, with a few quirks, like the arrow beneath the title of the screen indicating that it is possible to interact with the title to navigate through the application. In terms of content, lists and tiles are common across the application, similar to many other mobile applications. However, the interface of the application doesn’t adapt itself to the native look of the platform, looking the same regardless of where it runs. Later, in April 2013, LinkedIn announced new versions of their mobile applications. The novelty in these new versions is that they are completely native. LinkedIn stopped using HTML5 for building the user interface, because their users were spending more time inside of the application, leading the application to be out of memory eventually. Another major reason invoked by Kiran Prasad, LinkedIn’s senior director for mobile engineering, was the HTML5 ecosystem and its lack of good developer and operations tools.[O’D13] 3.3 Exfm Exfm is a social music discovery platform that was founded in 2010. It is powered by many music sites and, besides a web site, provides iPhone and Android applications. Recently, the CEO of Exfm, Dan Kantor, wrote an article documenting the team’s experience porting their native iPhone application to a hybrid application, using HTML5 and PhoneGap.[Kan13b] In this article, Kantor describes the key factors that led to this transformation and then presents a few technical details and their implementations. Before changing to a hybrid application, Exfm existed in three flavors: iPhone application, Android application, web application for mobile and desktop. The Exfm team is very small, consisting of only six people, which do most of the development. However, it contracted out a lot of the native mobile application work, which has costs evidently. Discussing Exfm’s future with Lucas Hrabovsky, the Chief Technical Officer (CTO) of Exfm, together they analyzed the products current state (mobile applications, Python back-end and Javascript front-end) and their hiring needs for the future. Since the six members of the team are well familiarized with Javascript, they decided to use it for everything. So, they ported the back-end to node.js and used PhoneGap for the mobile applications. As a result of this transformation, their iOS application, which was initially rated 4 stars, went up to 4.5 stars and has more daily installs than the former native application. It also allowed the company to reduce costs by not having to hire work out. At the moment of writing, the hybrid version was only released for iPhone. The iPad and Android versions are still native applications, but the new versions are expect to be out soon. In terms of user interface, the new iPhone application (figure 3.3) shows a different design from the Android application (figure 3.4), but also different from the native look of iOS applications. Overall, it shows a top bar with a title and action buttons on the side. The button on the left side of the title takes the user to a menu screen, allowing him to quickly navigate throughout the 19 Case Studies Figure 3.3: Exfm iPhone application (hybrid). Credit: Exfm Figure 3.4: Exfm Android application (native). Credit: Exfm application. This menu screen shows tabs that reveal lists of songs, people, sites and genres. When playing music, a footer with player controls is shown. Since the Android is native, one can notice the use of native components, like the tab host that contains the applications primary screens and allows the user to quickly change between them, or the lists with the native arrows on the right side. Only when the Android version of the new hybrid application is released will it be possible to see if it maintains the native look of the native application or if it will look the same as the iPhone application. 3.4 Conclusion There are many more mobile applications available, but from these three examples some conclusions can be drawn. First, it is very interesting to see how companies and small teams bet on new technologies as HTML5. Facebook and LinkedIn are both big companies and both initially betted in HTML5 for developing their mobile applications, later migrating to native applications due to complications encountered. On the other hand, the small team behind Exfm initially betted in developing native 20 Case Studies mobile applications, beside their main web application, and later migrated to HTML5, since they had to contract work out for developing the major part of the mobile applications. This was solution because all members of the team knew Javascript. And as result of this migration, the number of downloads increased and they managed to reduce costs. Also, the major reason for abandoning HTML5 was the lack of experience with it, memory issues and the lack of good developer tools, all factors that are expected to improve in a near future as browsers perfect their implementation of the HTML5 standard. Another interesting and relevant fact is that these applications use basically the same look on every platform, even native ones, like Facebook’s. This makes the applications stand out from an user’s point of view, because the user is not familiarized with the interface components. This can be either good or bad. It can help the application distinguish itself from its competitors by promoting a different and consistent look across platforms, but it can also cause the user to look for another application that integrates better with his phone. For instance, earlier versions of Facebook for Windows Phone 8 showed a native look and feel. But when a new beta version with the same look and feel as the iOS and Android applications was released, users complained about the lack of integration with the operating system, because they are accustomed to have a native rich experience.[Thu13] Finally, the applications share a common design pattern: top bar with title and action buttons, a menu with options that is opened when the button on the left of the title is pressed and content presented using lists and tiles. These characteristics seem to be popular with most iOS and Android applications and are a basis for the framework that was developed in this thesis. 21 Market Study and Analysis 4.3.9 Internationalization (I18n) Internationalization, sometimes abbreviated to i18n, refers to the ability to translate the textual content of the application to a predefined set of languages and switching between them according a setting. 37% of the 75 participants that answered this question consider support for internationalization to be useful, 31% consider it to be a must and 16% consider it to be a deal breaker. Although the developed framework doesn’t support internalization directly, Require.js, one of the core components of the framework, can be extended with a plugin1that allows the developer to load language bundles and use them in the application. 4.3.10 Extensions Extensions allow the user to add a certain functionality to the framework if it is missing. Of the 75 people that answered this question, 51% consider it to be useful, 16% and 3% consider it to a must and a deal breaker, respectively. Since the developed framework uses Require.js, the developer can inject custom modules when necessary. The main factory method of creating widgets also allows the definition of custom widgets. 4.3.11 Monetization Monetization is the method through which developers gain profits from their applications. One of the most common ways of monetization is through the use of advertising, embedded in the application. Of the 71 people that answered this question, 46% consider it to be useful, 15% and 4% consider it to be a must and a deal breaker, respectively. The developed framework has currently no standard way to show advertising or support for other monetization techniques. However, using the Html widget, developers can inject custom HTML, thus making it possible to inject code that shows ads. 4.4 Conclusion The purpose of this survey was to see if the goals for this dissertation are aligned with the necessities and desires of its intended target audience. Although the number of participants was low, the responses that were obtained showed that most of the goals and proposed features where well accepted by the participants. Most of the feedback received was taken into account when developing the framework. Decisions to drop some of the functionalities were made, mostly due to time constraints, but also because the core products that the framework can be extended through plugins to include them. 1http://requirejs.org/docs/api.html#i18n 28 Market Study and Analysis This was the case for internationalization, analytics, monetization and providing a full SDK. Another decision that was taken is to support only the use of Javascript to define the user interface. Since the Javascript layer is a necessity, it was decided to leave out the support of HTML5 interfaces. However, in the future, a translator of HTML5 or any other specification language to Javascript could be developed atop of the Javascript API. The next chapters describe the framework that was developed and the core functionalities it provides. 29 Market Study and Analysis 30 Chapter 5 The Meems Framework Meems Figure 5.1: The Meems Framework logo As stated before, most of the current mobile web development frameworks don’t really address the cross-platform look&feel of user interfaces in a way that keeps both the user and the developer happy. 5.1 Goals The Meems framework is an attempt at making the life of developers easier, while trying to provide the final user with the best user experience possible, emulating the look&feel of his mobile platform, by using the power of HTML5, CSS3 and Javascript, available in most modern mobile operating systems. Using the Meems framework, developers are able to put together user interfaces fast, without the need to tweak each detail for each mobile platform. A single code base for all platforms, but with a native-like look&feel on each of them. 31 The Meems Framework The main goal was to build a framework for developing mobile user interfaces that is completely independent, has a small footprint, a modular architecture and that is both easy to learn and to use, but also easy to tweak if necessary. As a framework for building user interfaces, it also promotes the separation between the representation of data and the business logic, following the Model-View-ViewModel design pattern. At the moment, together with PhoneGap, Meems allows developers to target the Android and iOS platforms, with native-like look&feel on each platform. It is possible to target other platforms, but since Meems only supports these two platforms at the moment, the developer would have to choose between one look&feel or the other. 5.2 Concepts The Meems framework is based on a few key concepts that are essential for understanding it and how to use it. 5.2.1 Widgets A widget is an element that influences directly the user interface, be it a control or a layout manager, it is something that users will notice and possibly interact with. Meems possesses a set of basic widgets and allows the final user to use custom widgets. When a widget is initiated, it’ll create DOM objects that will be the visual representation of the widget. These objects are usually assigned CSS classes that can be used to style the widget. The widgets are themed differently for each mobile platform supported. The widget itself can also detect the platform and behave differently in each platform. Take, for instance, the tab group widget. This widgets aggregates several named pages, showing one at once together with a navigation bar with the name of each page (called tabs). Depending on the platform, the navigation bar can either be on top of the page or on the bottom. Although configurable by the user, the default position of the bar will be different according to the platform, for instance, it will be on top on Android devices and on the bottom for iOS devices. Widgets are also responsible for handling DOM events and mapping them to Meems internal events, converting them to meaningful events in the context of the widget. The user can then use the event handling capabilities of Meems to capture those events and process them. Taking the previous example, a tab group widget must capture the event that is triggered by the browser when the user presses a tab, change to the selected page and fire an internal event notifying the application that the tab has changed. Widgets are the core of Meems framework. They are what allows the programmer to define the user interface in a generic way, without worrying on how it will look on each platform. If a platform is not yet supported, the widgets are the only thing that need to be updated to support it. 32 The Meems Framework View Data Binding ViewModel Model Figure 5.2: Model-View-ViewModel design pattern 5.2.2 Model-View-ViewModel While Meems only provides the "View" part of an application, its API is oriented towards the separation of data representation and the application logic according with the Model-View-ViewModel (MVVM) design pattern. The MVVM design pattern promotes the separation of the application’s logic from the user interface. The transfer of data between the two is done through data bindings and commands. Three base concepts are introduced: •Model, a domain object, representing the data that is to be user or manipulated somehow. It is free of business and representation logic. •View, the user interface where the data is presented and/or collected. The view can contain behaviours, events and data-bindings and does not maintain state. •ViewModel, acts as a translator between the model and the view layers, performing all the necessary translations of the data. It exposes methods, commands, helpers to maintain the state of the view and events. It can manipulate the view in response to changes in the model and update the model when the view changes. The MVVM pattern was first mentioned to the public by Microsoft’s John Gossman in a blog post titled “Introduction to Model/View/ViewModel pattern for building WPF apps”. As the title suggests, this pattern is an adaptation of the Model-View-Controller design pattern for Windows Presentation Foundation (then codenamed Avalon). In his post, Glossman explains that the purpose of this design pattern is to allow designers and programmers to collaborate, making the View a sole responsibility of the designer, instead of the developer having to translate mock-ups 33 The Meems Framework and designs to code. This scenario fitted Microsoft’s new markup language for interface design, called XAML, that can be generated by tools designed to simplify the job of designers, most notable Microsoft’s Expression. Using declarative data-bindings, the developer could bind the application’s data to the user interface the designer built. So, data-binding is another base concept for the MVVM pattern. Data-binding is a mechanism that allows the View to notify the ViewModel whenever the user changes the data and also allows the View to be notified when the Model has suffered changes, normally triggered by an action of the user. This is particularly useful in complex user interfaces, specially when the same data is used in several components. Meems also aims to help both the developer and the designer. However, since it is in an early stage, the specification of the user interface is done using Javascript. At later stages of development, and probably outside of the context of this thesis, a mechanism of translation from HTML5, or some other markup language, to Javascript will be developed. After the user interface is built, the developer can bind data objects to the controls through the use of observables. 5.2.3 Observables Observables are data containers enhanced with a mechanism for notifying all the interested parties when its contents have been modified. Following the Observer design pattern, each observable stores a list of interested observers, that will be notified whenever the content of the observable changes. Observables possess methods for subscribing and unsubscribing observers at runtime. Observables are the main mechanism for exchanging data between the user interface (View) and view models in the Meems framework. Most properties of the available widgets support observables and will be automatically updated when a change occurs. Likewise, whenever the user changes the data through the user interface, the view model will be notified of the change so that it can update itself. Observables are used for listening for changes in specific properties, instead of entire objects. The example code below shows how to use observables in the Meems framework. 1/ / D e f i n i n g t h e model , each p r o p e r t y must be an o b s e r v a b l e . 2var person = { 3name : Meems . Observable . obs ervable ( " John Smith " ) , 4age : Meems . Observable . ob ser vab le (18) , 5 6/ / Ar rays must be d e c l a r e d w i t h o b s e r v a b l e A r r a y . 7c h i l d r e n : Meems . Observable . o bs er va bl eA rr ay ( [ ] ) 8}; 9 10 / / R e g i s t e r an o bs e r v e r . 11 var onNameChanged = fu nc ti on ( oldValue , newValue ) { 34 The Meems Framework 12 console . log ( "name changed from " + oldValue + " to " + newValue + " ! " ) ; 13 }) ; 14 15 person . name . s ub sc ri be ( onNameChanged ) ; 16 17 /∗To chang e t h e v a l u e o f an o b s e r v a b l e , i n v o k e i t as a 18 f u n c t i o n w i t h t he new v a l ue as argument . ∗/ 19 person . name ( " John Adams Smith " ) ; 20 person . age (20) ; 21 22 /∗To r e t r i e v e i t s c u r r e n t value , in vo k e as a f u n c t i o n 23 w i t h no a rg umen ts . ∗/ 24 console . log ( "My name is " + person . name ( ) + " and I ’m " + 25 person . age ( ) ) ; 26 27 / / Remove t h e o b s e r v e r . 28 person . name . unsub scribe ( onNameChanged ) ; Listing 5.1: Observables in Meems 5.3 Architecture In order to maintain the code clean and modular, the Meems framework is separated in four libraries: •meems-events, a library for manipulating DOM and custom events, providing an easy API and cross-platform support; •meems-utils, a library with multiple utilities, divided by domain. Includes methods for manipulating arrays, maps, functions and others; •meems-scroll, emulates fixed div scrolling, since older devices don’t allow div’s to scroll when they are positioned absolutely; •meems-ui, the core library that contains the UI widgets and methods to build the user interface. The first two modules are independent and can be used separately. Meems-scroll depends on meems-events and meems-utils and meems-ui depends on the other three. Besides these dependencies, there is only one more, which all of them rely on: require.js1. Require.js is a Javascript file and module loader that implements the Asynchronous Module Definition proposal2. It enables the separation of the code in modules. A module can depend 1http://requirejs.org/ 2https://github.com/amdjs/amdjs-api/wiki/AMD 35 The Meems Framework meems-events meems-scroll meems-utils meems-ui requires requires requires requires requires Figure 5.3: Dependencies between the libraries that constitute the Meems framework on other modules. Given a main module, require.js will dynamically load it and all its dependencies. This enables the programmer to keep the code modular, easier to maintain and to debug. Another advantage of having the code modular and using require.js is the usage of its optimizer tool. This optimizer tool, called r.js, can run on top of Node.js or Rhino and will take as input Javascript modules and produce a single Javascript file, minified to the smallest size possible. This will reduce the number of files that the client must download and also its total size. This is a very powerful step when preparing the code for production. It can also optimize CSS, but the Meems framework does not use this, yet. 5.3.1 AMD - Asynchronous Module Definition The Asynchronous Module Definition API, also known as AMD, “specifies a mechanism for defining modules such that the module and its dependencies can be asynchronously loaded. This is particularly well suited for the browser environment where synchronous loading of modules incurs performance, usability, debugging, and cross-domain access problems.”[ao13] Using the AMD API to describe a module, dependencies are declared using strings, therefore reducing the use of global variables. The API also allows to map a module name to different paths, which makes it easy to swapping implementations. This can be useful for creating mock objects for testing purposes. A module and its dependencies are declared using the define method. The first argument is usually an array of strings containing the dependencies of the module. These dependencies are then passed as arguments to the module constructor, which is a function passed as second argument. 1de fin e ( f un ct io n ( ) { 2return { 3sayHello : fu nc ti on ( ) { 4/ / Do s o m et h i ng . 5} 6}; 7}) ; Listing 5.2: Defining a module without dependencies in AMD (modA.js) 36 The Meems Framework 1de fin e ( f un ct io n ( ) { 2f un ct io n ModB( ) { 3return t h i s ; 4} 5 6ModB. p ro to ty pe . doSomething = f u nc ti on ( ) { 7/ / Do s o m et h i ng . 8}; 9 10 return ModB; 11 }) ; Listing 5.3: Defining a module without dependencies in AMD (modB.js) 1de fin e ( [ "modA" , "modB" ] , fu nc ti on (ModA, ModB) { 2return { 3i n i t : fu nc t io n ( ) { 4ModA. sayHello ( ) ; 5var b = new ModB( ) ; 6b . doSomething ( ) ; 7} 8}; 9}) ; Listing 5.4: Defining modules in AMD (modC.js) 5.3.2 Meems-events Event processing is a must when programming for the Web. The DOM triggers events in response to the actions of the user (for instance, when he moves the mouse, presses a key, touches the screen, scrolls the page, etc.) and also to notify the pages of some internal events, such as timers or when loading ends. Applications can bind listeners to events in order to be notified when such event is triggered. This is how the application can react to the user actions. However, registering this listeners is not standardized among all browsers. There are two major event registration models: W3C’s and Microsoft’s. The first model is supported by Mozilla, Safari, Chrome, Konqueror and other WebKit-based browsers. The second model is supported by Internet Explorer. Opera supports both models. They both offer the two basic functions of event registration (add and remove a listener), but with a different syntax. W3C’s model provides the addEventListener function for registering listeners and removeEventListener to remove them.Microsoft’s model provides the attachEvent function for registration and the detachEvent for removal of listeners. Other differences between this models do exist, but being outside of the scope of this dissertation, 37 The Meems Framework 6/ / O btai n t h e e l e m e n t t h a t w i l l be s c r o l l e d . 7var elm = document . getElementById ( " elmToScroll " ) ; 8/ / Create a s c r o l l e r . 9scroller = new S c r o l l ( elm , { 10 paging : false , 11 snap : 0 , 12 scrollX: false , 13 scrollY: t r u e 14 }) ; 15 } , 16 17 de str oy : f un ct io n ( ) { 18 i f (scroller) { 19 /∗De s t roy t h e s c r o l l e r when 20 i t ’ s no l o n g e r nee ded . ∗/ 21 s c r o l l e r . d est roy ( ) ; 22 scroller = n u l l ; 23 } 24 } 25 }; 26 }) ; Listing 5.6: Using meems-scroll 5.3.4.1 Implementation When associating a scroller with an object, meems-scroll calculates the dimensions of the container (the element which contents will scroll) and the dimensions of the contents inside the container. This information is stored in the container’s DOM element as custom properties. Then, additional DOM elements representing the scrollbars are attached to the container, one for the horizontal axis and another for the vertical axis, depending of the scroller’s configuration. Scroller will manage this elements, showing and hiding them when needed and destroying them when their no longer necessary. Also, events handlers are attached to the element so that meems-scroll can process the events that are triggered when the user presses the container, drags it and releases it and simulate the scrolling of the contents. To know which events to listen for, meems-scroll will first detect if the touchstart event is supported. If it is, this means the platform supports touch events (probably it’s a mobile device with a touch screen), so it will listen for the touchstart, touchmove and touchend events. If touch events aren’t supported, it’ll listen for normal mouse events: mousedown,mousemove and mouseup. When the user starts pressing the container to initiate a scrolling motion, the scroller catches this event and performs the following actions: obtains and stores the position of the cursor or touch point, calculates the size of the contents of the container, updates a flag indicating that the container is scrolling and prevents the event from being processed by the browser. This last step 44 The Meems Framework is very important to overcome a defect6in the Android platform (2.0, 2.1). When the user moves the finger or the cursor while the container is in scrolling motion, the cursor position is grabbed and subtracted from its initial position, stored when the user started pressing the container. The result of this difference will dictate how many pixels the content is moved and in which direction. The position of the content is updated by using the transform property together with the translate3d value. This enables the browser to use hardware acceleration when rendering the content, providing a smoother scrolling experience. The scrollbars are also updated to reflect the current position of the content relative to the container: the size of the bar will be equal to min(containerSize,contentSize) contentSize ×containerSize and its position will be equal to −contentPosition contentSize ×containerSize. These will be calculated for each of the axis, being each dimension chosen according to the axis: size will be the height for the Y axis and the width for the X axis, position will be top for the Y axis and left for the X axis. When the dragging motion is released, the content will be animated, continuing to scroll for a small period of time at a velocity that depends on the movement performed by the user when dragging the content. To perform the animation, the CSS3 property transition is used. To use it it is necessary to know the final position of the content and how long should it take until it reaches the final position. To calculate this, meems-scroll uses as input the duration of the dragging motion (time) and how many pixels the content was moved (o f f set). From this, the average velocity in pixels per second is calculated (velocity =o f f set time ). A first estimate of the animations total time is then calculated by taking the absolute value of the average velocity and dividing it by a constant value (totalTime =abs(velocity f riction )). Having an estimate for the time, an estimate for the final position is calculated: f inalPos =currentPos −velocity ×totalTime. The estimate of the final position must be adjusted according to the constraints imposed by the scroller’s configuration, for instance, paging, snapping and the minimum and maximum possible value. If paging is enabled, the final position will be adjusted to round(currentPos±containerSize containerSize )×containerSize, depending on the direction of the movement. If snapping is enabled, the final position will be adjusted to round(f inalPos con fig.snap )×con fig.snap. Then, the final position is adjusted according the its limit values. It will always be zero or a negative value. If the size of the content is smaller than the size of the container, the final position will always be zero, since there is nothing to show beyond the container’s boundary. If the content surpasses the container in size, then the maximum absolute value for the position of the content is contentSize −containerSize. The final position is truncated, if necessary, to be inside this boundaries. After the final position is calculated, the animation’s duration is adjusted as well by taking into account the difference between the final position before and after being adjusted: totalTime = min(totalTime ×abs(startPos−newFinalPos startPos−f inalPos ),con fig.totalMaxTime). This calculations are performed for each axis and the highest time will be used as the duration of the animation. 6http://code.google.com/p/android/issues/detail?id=5491 45 The Meems Framework Finally, the content properties transition and transform are updated: 1co nte nt . s t y l e . t r a n s i t i o n = " a l l " + to talTime + " s " + conf ig . timingFunction ; 2co nt ent . s t y l e . tr ansf orm = " t r a n s l a t e 3 d ( " + finalPosX + "px , " + finalPosY + 3"px , 0 ) " ; During the animation of the content, the position of the scrollbars still needs to be updated. To do this, an asynchronous cycle of duration equal to that of the animation of content is performed using the requestAnimationFrame method. In each iteration of this cycle, the current position of the content is retrieved using the getComputedStyle function and the scrollbars’ positions are updated accordingly. 5.3.5 Meems-ui The meems-ui module is the main module of the Meems framework. It contains the widgets that will be the building blocks developers use to construct the user interface of a mobile application. It follows an object-oriented approach, based around the Widget class. Every widget must extend this class and override at least the update method. Widgets must also be registered in the Meems.UI factory class, through the registerWidget(name, class) method. After this, to instantiate a widget, the create factory method of the Meems.UI namespace can be used. It takes the name of the type of widget to create as argument and returns an instance of that type of widget. The base widgets provided with the framework can be separated in three categories: navigation and organization, layout and user interface controls. 5.3.5.1 Navigation and organization The widgets in this category are used to specify the high-level structure of the application’s user interface. Mobile applications are usually composed of multiple screens which transition from one to another. In the context of the Meems framework, an application can have one or more Pages, where only one is visible at a time. To store and transition between pages a PageHolder is used. One common user interface pattern in mobile applications nowadays is a lateral menu that slides from the side. This allows the user to easily access other options of the application without leaving the current screen. In Meems, this is called an Aside. PageHolder is a widget that can store multiple pages and transition between them. It should be the top-level widget in an application. Pages can be set using the pages function and transitions can be accomplished by invoking the currentPage function with the desired page as the first argument. It imposes no restrictions regarding what pages can transition to others, it’s up to the 46 The Meems Framework application itself to decide this. Transitions between pages can be animated using CSS3. A default transition animation is provided in the effects.css file. Page represents a screen of the application. It exposes three facets: header, content and footer, as this structure is the most common in mobile applications. Although each facet can contain any widget, it is best to use the Header and Footer widgets for the header and footer, respectively. For the content facet, usually a group or list widget is used, the most common would be the List, Form and TabGroup widgets. Header Content Footer Figure 5.4: Page structure Figure 5.5: Page in Android Figure 5.6: Page in iOS Aside enables the use of one page as a lateral menu that can be toggled when on a small screen and that will be always visible on large screens. The purpose of this is to provide the user with easy access to all the major pages of the application. 5.3.5.2 Layout Some widgets are meant to organize other widgets, placing them in the correct positions with the correct dimensions. The layout of a screen can be achieved by using these widgets. Button Group is a widget that organizes buttons in an horizontal manner. Using the maxButtons attribute, its possible to limit the number of buttons visible at a time. If more buttons than those allowed exist, an overflow button will be made visible. Clicking this button pops up a menu with items representing the extra buttons. Footer is a widget meant to be used with the Page widget. This widget adds a footer to the screen, where a button group can be placed with the buttons facet. 47 The Meems Framework Figure 5.7: Menu closed Figure 5.8: Menu open Figure 5.9: Menu always visible Figure 5.10: A button group in Android (left) and iOS (right) Form stores fields that accept user input and organizes them vertically. A form can also have a title, which will be placed above the first field. Group is a widget that merely groups other widgets vertically. 48 The Meems Framework Figure 5.11: A form example in Android (left) and iOS (right) Header like the Footer widget, is meant to be used with the Page widget. It adds a header bar to the screen, which contains a title and two facets, buttonsleft and buttonsright, to place buttons in left and right side of the title, respectively. These facets expect ButtonGroup widgets. The title can be set through the title attribute. List is a representation of an array. Each item of the array will be converted to a graphical representation using a Mustache template, that can be set using the template attribute. Header items are also supported. An element will be converted to a header if its header property is true. Header elements are converted using the template defined by the headerTemplate attribute. Besides representing a list of items, this widget also provides mechanisms that allow the user to manipulate the items, namely, sort them manually and selecting several items before an operation through the use of checkboxes. To enable sorting, the sortable attribute must be set to true. To enable multiple selection, the selectionMode attribute must be set to multiple. Tab Group allows to separate content in categories, through several partial pages, called Tabs. Only one tab is visible at a time and each one is associated with a named button that allows navigating between tabs. The tabs method can be used to associate an array of Tabs. Tab is a widget meant to be used with the Tab Group widget. The contents of the tab can be set through the content facet. The title attribute is used to set the text that will appear in the tab button. 5.3.5.3 UI controls The following widgets are basic units usually used to present a single piece of information or collect information from the user. 49 The Meems Framework Figure 5.12: A simple list (left) and a list with ordering and multiple selection (right) Button allows the user to trigger a single action. Is characterized with a text and an icon, set through the title and icon attributes, respectively. The context in which the button is used will d:etermine the visibility of the button’s text and icon. The platform will also influence this. For instance, in the Android platform, buttons inside a Header will appear as an icon only, while on the iOS platform they’ll show only as text. See figure 5.10 for an example of buttons in a header and figure 5.12 for an example of a button inside a form. Slider allows a user to select a value from a fixed range by sliding its finger/cursor over a bar. The widget exposes two attributes to manipulate the range of valid values: minimum and maximum. To read or write the value of the slider, the value method must be used. The value can either be a numeric value or an observable. Switch is usually used to represent or collect a boolean value. Like the Slider widget, its value can be read or written using the value method, which also supports observables, besides boolean values. Text Field allows to capture textual information from the user. The value method can be used to read or write the contents of the field. A string or an observable can be used. A text field also exposes the type attribute, which allows to specify the type of data that is meant to be collected according with the HTML5 standard for input controls. This includes types like: text, number, date, tel (for phone numbers), email and search. Setting the appropriate type allows the platform to adjust how it collects the data. For instance, if the type is date, a date picker will be presented to the user instead of a keyboard. If it is email, the keyboard layout will be adjusted to place the symbol in a more handy place. 50 The Meems Framework Figure 5.13: Example of switches, sliders and text fields in Android (left) and iOS (right) Html is widget that allows the developer to use Mustache templates for generating HTML elements, making it ideal to present information to the user. Mustache7is a logic-less template language that uses double braces to denote a placeholder. The placeholders of the template are then replaced with values corresponding to the values of the properties of an object named after the placeholders. For example, given the template This is a {{expName}}. and the object {"expName":"test"}, the final result would be This is a test.. The template can be set using the html attribute. The object to be bound to the template can be set using the data attribute. 5.3.6 Building user interfaces The Meems Framework is meant be used as a presentation layer for mobile applications. Following the Single Page Application (SPA) pattern, all the screens of the application are present in a single page and made visible or hidden to transition between screens, therefore avoiding the need to refresh the page to present new information, providing the user with a more fluid experience and emulating the behaviour of a native application. Since all the application’s screens are present in the same page, it’s necessary to use a mechanism to manage those pages. The PageHolder widget is responsible for storing all pages and transition between them upon command. It must, therefore, be the root widget of an application. Pages can then be added to this widget. To create all the necessary widgets, the factory method create must be used. Passing it a widget type, it’ll return an instance of that type that can be immediately modified using its chainable methods. Meems provides this chainable API so that it is possible to chain several method invocations, reducing the amount of code that needs to be written. 7http://mustache.github.io/ 51 The Meems Framework After creating all the necessary widgets, the HTML DOM elements that will represent the widgets must be created and added to the page. The creation of the elements is achieved by invoking the update method of the root widget. This will trigger the update method of itself and all its children, ensuring that all the widgets associated with it have DOM elements ready to be added to the DOM tree. To give the developer more flexibility, the developer must manually insert the root DOM element as child of the element he sees fit as parent. Most of the times, it will be the body of the page (document.body). Invoking the el method of the root widget returns the DOM element that must be added to the page. See the example below for how to create a simple user interface and how to insert it in the DOM tree. 1/ / Cr eate a page w it h a s i m p l e l i s t . 2var page1 = 3UI . c r e a t e ( " page " ) 4. f a c e t ( " header " , UI . c r e a t e ( " header " ) . a t t r ( " t i t l e " , " Page 1" ) ) 5. f a c e t ( " c on te nt " , 6UI . c r e a t e ( " l i s t " ) 7. items ( [ 8{ t e x t : " Item 1" } , 9{ t e x t : " Item 2" } , 10 { t e x t : " Item 3" } , 11 { t e x t : " Item 4" } 12 ] ) ) ; 13 14 / / C reate a sec ond page w i t h a n o t h e r s i m p l e l i s t . 15 var page2 = 16 UI . c r e a t e ( " page " ) 17 . f a c e t ( " header " , UI . c r e a t e ( " header " ) . a t t r ( " t i t l e " , " Page 2" ) ) 18 . f a c e t ( " c on te nt " , 19 UI . c r e a t e ( " l i s t " ) 20 . items ( [ 21 { t e x t : " Item 5" } , 22 { t e x t : " Item 6" } , 23 { t e x t : " Item 7" } , 24 { t e x t : " Item 8" } 25 ] ) ) ; 26 27 / / Crea te t h e r o o t w i d get and add t h e pa ges . 28 / / By d e f a u l t , t h e v i s i b l e page i s t h e f i r s t one . 29 var r oo t = UI . c r e a t e ( " pa geho lde r " ) 30 . pages ( [ page1 , page2 ] ) ; 31 32 / / Create a l l ele m ent s , add them to t h e page and a p ply a l l changes . 33 ro ot . update ( ) ; 34 document . body . appendChild ( ro ot . e l ( ) ) ; 35 U t i l s .Dom. applyChanges ( ) ; Listing 5.7: Creating a simple user interface 52 The Meems Framework Besides defining the interface in Javascript, it is also necessary to add the CSS files corresponding to the current platform. These can added dynamically through Javascript or can be added manually when there is a main HTML file per platform. Each platform has three CSS files that must be imported: •ui.css - Contains all the CSS necessary to render the widgets correctly; •effects.css - Contains CSS for animating widgets; •icons.css - Contains icon graphics in Base64 format. 1f un cti on loadCss ( u r l s ) { 2" use s t r i c t " ; 3 4var link , 5head = document . getElementsByTagName ( " head " ) [ 0] , 6f i r s t S i b l i n g = head . childNodes [ 0 ] ; 7 8fo r ( var i = 0 , ln = u r l s . l en gt h ; i < ln ; ++ i ) { 9l i n k = document . c re at eE lement ( " l i n k " ) ; 10 l in k . type = " t e x t / css " ; 11 l in k . r e l = " s t y l e s h e e t " ; 12 l in k . h re f = u r l s [ i ] ; 13 head . i n s e r t B e f o r e ( link , f i r s t S i b l i n g ) ; 14 } 15 } 16 17 var p la tf or m = U t i l s .Dom. userAgent ( ) ; 18 loadCss ([ 19 " css / meems / " + pla tf orm + " / ui . css " , 20 " css / meems / " + pla tf orm + " / icons . css " , 21 " css / meems / " + platf orm + " / e f f e c t s . css " 22 ] ) ; Listing 5.8: Dynamically insert CSS files However, the creation of the user interface is not enough to create a mobile application. When the user interacts with the interface, the logic layer must be invoked and update the interface properly. To detect the interactions of the user with the interface, events are triggered. The logic layer can listen for those events and respond appropriately. To update the information on the user interface and also passing information to the logic layer, it is recommended to use observables. Changing the value of the observables will cause the widgets associated with the observable to be updated. Likewise, the logic layer can attach observers to observables and react whenever their values change. 53 RSS Reader: Demo Application Figure 6.1: Simplified use case diagram 6.1.1.2 Feeds The application must load from the back-end server the list of feeds the user has subscribed. This list will be presented to the user, so that he can choose which feed to open. Upon clicking on a feed, the application will load from cache all the news of the feed. If the news in cache are too old (around 30 minutes), the application will ask the back-end server for an updated list of news and store them in cache. The user will also have the possibility to manage feeds. This includes adding a new feed, removing existing feeds and manually ordering the feeds. All changes can then be saved and sent to the backend server for storage, or can be discarded by returning to the previous screen without saving. When adding a new feed, the user must provide the URL, which will be sent to the back-end server. The server then tries to read the feed and obtain its name, stores it in the user’s account and returns the name of the feed to the application so that it can show it to the user. 6.1.1.3 News After the user selects a feed, its news are listed. Each news has a title, an author, a publishing date and a small description. These should be visible in the main listing. The user will be able to scroll through the list to view more news. When the user clicks on a news article, its full contents will be shown in a separate screen, by loading the page of the original website that provided the feed. 6.1.2 Non-functional Requirements The project must be separated in two major parts: a mobile application and a back-end server. This separation allows for future improvement and scalability. The mobile application must run on Android (2.3+) and iOS (5+) platforms, with a look and feel as closest to native applications as possible. 60 RSS Reader: Demo Application All user information, which includes email, password and feed subscriptions, must be stored in a database. 6.2 User Interface Figure 6.2: Low fidelity mockup. From top-left to bottom right: login screen, empty news screen, feeds screen, manage feeds screen, news screen, news detail screen The user interface of the mobile applications must look and behave like a native application. Since the target platforms are Android and iOS, the same basic UI design patterns apply. The applications will have a header with button actions and a title. In iOS, buttons will be used, while in Android an action bar will be used instead. A footer will also be present when managing the feeds. Lists will be used for presenting the list of feeds and news and a form will be used for the login screen and the subscription of a new feed. The most important design pattern used is the navigation drawer. The user will be able to click a “Feeds” button which reveals a side pane, the drawer. This drawer will contain the list of feeds, 61 RSS Reader: Demo Application Figure 6.3: Flow between the screens that allow the user to navigate through his subscriptions, and also more actions related with the feeds, such as the “Manage” action. 6.2.1 Login Screen The login screen will have two input text fields, one for the email and another for the password. The user must fill in both fields and press the “Login” button. If the authentication fails, a pop-up alert will warn the user about the error. After correcting his credentials, the user can try again. If the authentication succeeds, the news screen will be shown. 6.2.2 News Screen This screen will show the list of news, which is initially empty until the user selects a feed to read. To choose a feed, the user has the button “Feeds” on the top of the screen, which, following the navigation drawer design pattern, will reveal a side pane with the list of feeds. If the resolution of the device is big enough (width larger that 650 pixels), this side pane will always be visible. Clicking on a feed will close the drawer, update the page title and show the list of news of that feed. When the user clicks on a news, the news detail screen is shown. Besides showing the list of feeds, the navigation drawer also exposes an action relative to the feeds: the “Manage” action. Clicking on this button, the manage feeds screen will be shown in the side pane. 6.2.3 Manage Feeds Screen This screen enables the user to subscribe to new feeds, by entering (probably pasting) the URL of the feed and pressing the “Add” button. The URL will be appended to the bottom of the list of feeds. The list of feeds will allow the user to select multiple feeds by pressing the checkboxes on the left of each item. When one or more feeds are selected, a footer will appear with the option to delete the selected feeds. 62 RSS Reader: Demo Application On the right side of each item, an order button is present. Pressing and dragging this button, will cause the item to be moved in list according to the movements of the user. Releasing the button will effectively place the item in its new place in the list. All these operations are applied to a copy of the user’s feed list. If the user presses the “Back” button on the top-left corner of the page, the copy is discarded and all modifications are lost. However, if the user clicks on the “Save” button, the modifications are sent to the back-end server and are applied locally, after a successful reply from the server. After saving, the user be taken back to be previous screen. 6.2.4 News Detail Screen This screen will allow the user to view all the details of a news article, by embedding directly (through an iframe) the website the news originates from. The link for the article necessary for this operation is provided by the back-end server, which provides it together with the list of news. When the user is done, clicking on the “Back” button will bring him back to the news screen. 6.3 Architecture The project is divided in two parts: a mobile application that uses the Meems Framework and require.js and a back-end server implemented using Node.js as the runtime, the Express framework and MongoDB as the storage engine. 6.3.1 Back-end Server Node.js1is a server-side Javascript platform, based on Google Chrome’s Javascript runtime, that uses an event-driven non-blocking I/O model, providing a lightweight environment for scalable real-time applications. And since it runs Javascript, it was possible to implement the server and the client using a single programming language. The simplify and accelerate the building process of the back-end server, the Express framework was used. This framework purpose is to facilitate the development of web applications using node.js, by providing a simple API to deal with request routing, middleware and response building. For storing the information of all users, MongoDB is used. MongoDB is a powerful document database and is the leading NoSQL database.2The paradigm behind MongoDB is different from that of relational database management systems (RDMS). Instead of schemas and tables, MongoDB has collections and documents. Collections have a name and store several documents. No schema or structure is imposed to documents, which are normally represented using the JSON notation. Since JSON, which stands for “JavaScript Object Notation”, can easily be parsed in Javascript and both the server and the client are implemented in Javascript, it is easy to load and use the data directly from the database. 1http://nodejs.org/ 2http://www.10gen.com/leading-nosql-database 63 RSS Reader: Demo Application Figure 6.4: Architecture overview 6.3.1.1 Data model The information related to each user is divided in two collections: users and feeds. The users collection contains a document per user. The documents contain the following fields: •email - The email of the user, is used as his identifier and must be unique. •password - A SHA1 hash of the user’s password. Is used for authenticating the user. The feeds collection contains all the feeds that the users have subscribed, one per feed. Each document stores the following fields: •owner - The email of the user that owns the feed. 64 RSS Reader: Demo Application •name - The title of the feed. •url - The URL of the feed. 6.3.1.2 Web Services To expose to the mobile application the functionality provided by the server, a REST-based API is made available, exposing two web services: users and feeds. The API goes as follows: Method Path Description GET /user Get user account information of the currently logged user POST /user Create a new user account. Expects JSON object with the email,password and name of the user PUT /user Update a user account. Expects JSON object with the email,password and name of the user POST /user/login Login a user. Expects JSON object with the email, password GET /feeds Returns all the feed subscriptions of the logged user GET /feeds/:id Returns the latest news of the feed subscription identified by :id POST /feeds Logged user subscribes to a new feed. Expects JSON object with the url of the feed. PUT /feeds Updates feed subscriptions in bulk. Expects a JSON array with feed objects inside. PUT /feeds/:id Update a single feed subscription, identified by :id. Expects a JSON object with name,url and order (for changing the order). DELETE /feeds Removes feed subscriptions in bulk. Expects a JSON array of feed id’s. DELETE /feeds/:id Removes a single feed subscription, identified by :id Table 6.1: Back-end server API overview Each entry point is protected and requires the user to first authenticate using the /user/login service. This service returns a session id in the format of a cookie that must be present in all future requests. Otherwise, the server will refuse to complete the request with a 403 Forbidden response. 6.3.2 Mobile Application To develop the mobile application, the Meems Framework was used for the View layer and require.js and pure Javascript together with a few helper methods from the meems-utils package were used for the ViewModel and Model layers. 65 RSS Reader: Demo Application In order to simplify the development phase, models are simple Javascript objects, so these are not represented directly by a file or module. The downside of this simplification is that the communication with the web services has to be made from the ViewModel layer. While this is not the standard way, this application is for demonstration purposes only. Require.js was used to separate all code units into modules, one per file, and to automatically manage dependencies. The application code is structured in the following way: •css Contains all the CSS files, including Meems themes •js Contains all the Javascript files – lib External libraries: Meems and require.js – view Contains the Javascript files that build the views ∗feeds.js Implements the screen “Feeds” ∗login.js Implements the screen “Login” ∗news.js Implements the screen “News” ∗newsdetail.js Implements the screen “News Detail” ∗phone.js Implements the overall application view, acts as glue for the other views and is the main view that instantiates and controls all others – viewmodel Contains the Javascript files with the application logic. These files implement the ViewModels that form the bridge between the views and the web services. ∗feeds.js Implements the code for managing feeds ∗login.js Implements the code for authenticating the user ∗news.js Implements the code for listing and presenting news of a feed ∗newsdetail.js Implements the code to view a news detail information ∗phone.js Implements the code that initialize other ViewModels and manages navigation between screens – index.js Main module of the project, it’s the file imported by require.js. Contains all the initialization code: imports the necessary CSS files according to the platform, initializes the main ViewModel and install the main view’s root element •index.html The application’s entry point. Imports require.js, telling it where to locate the main module, index.js The view modules use Meems UI to build each page and then expose it to the view model by exporting a Javascript object with the ui property set to the root widget of the page, usually a Page or Aside widget. When creating the view, the module will also instantiate all the necessary observables, bind them to the widgets and expose them through the same object as the ui, so that the view model can update the view in response to some event. It is also common for the view to capture low-level events from Meems UI and translate them to higher-level events. For instance, 66 RSS Reader: Demo Application capturing a button:pressed event triggered by a ButtonGroup, detecting which button was pressed, for example the “Manage” button, and triggering a feeds:manage event that can be captured and processed by the view model. The view model modules have its corresponding view module as a dependency, so Require.js will inject the view modules at runtime. All modules have an init method that initializes all that is necessary. Views create the interface and view models call the views’ init method, install event handlers and update observables to their initial value. 6.3.2.1 Login View The login view is the page where the user must authenticate himself. The root widget is a Page with a Header, which contains a submit button, and a Form as content. The form contains two input fields: email and password. When the user presses the submit button, a login event is triggered. The view model then captures this event and attempts to login. 6.3.2.2 Feeds View This view builds the page that shows the list of feeds the user has subscribed to and also the page that allows the user to manage them. This view will be presented as a side pane, so the root widget is a PageHolder that holds two pages: feeds and manage feeds. The “Feeds” page is where the feeds the user subscribed are listed, so that he can choose one to see its news. The root widget is a Page widget, with a Header and a List for content. In the header, there is a button to enter the “Manage Feeds” screen. The “Manage Feeds” view allows the user to manage its feeds. The root widget is a Page with a Header, which contains a back and a save button, and, as content, a Form and a List. The form is for subscribing to a new feed. It has a URL input field and an “Add” button. The list is multiple selection, sortable list with the feeds of the user. Whenever more than one feed is selected, a Footer with a delete button is shown. If the user presses the back button, all changes are lost and the user is taken back to the “Feeds View”. The user must therefore click the save button in the header for the changes to apply. 6.3.2.3 News View The “News” view is where all the news of the currently selected feed are presented. The root widget is a Page with a Header and a List as content. The header has a “Feeds” button that toggles the side pane which contains the “Feeds” view. The list contains all the news of a feed and when one of its items is selected by the user, the news:clicked event is triggered, so that the view model can show its details. To show all the necessary details of each news item, the item template of the list had to adjusted, as shown below. 1var itemTemplate = 2"<div c l a s s =\" news \" > " + 67 RSS Reader: Demo Application 3"<div c l a s s =\" t i t l e \" >{{ t i t l e }} </ div >" + 4"<div c l a s s =\" d ate \" >{{ formatt edDate }} </ div >" + 5"<div c l a s s =\" a ut ho r \" >{{ a ut hor }} </ div >" + 6"<div c l a s s =\" summary\" >{{&summary }} </ div >" + 7"<div c l a s s =\" c l e a r \" > </ div >" + 8" </ div >" ; 9 10 var l i s t = UI . c r e a t e ( " l i s t " ) 11 . items ( news ) / / Bind t o an o b s e r v a b l e a r ray . 12 . templat e ( itemTemplate ) / / Change t h e i tem t e m p l a t e . 13 . a t t r ( ’ empty ’ , ’<b>No news . </ b><br > ’ + / / Change t h e empty message . 14 ’<br > Please s e l e c t a feed from the menu . ’ ) 15 . a t t r ( ’ s t y l e ’ , ’ normal ’ ) 16 . a t t r ( ’ s o r t a b l e ’ , false ) 17 . on ( " item : c li c ke d " , f un ct io n ( eventName , item ) { 18 pageNews . f i r e ( " news : c li ck ed " , item ) ; 19 return true ; 20 }) Listing 6.1: Changing a list’s item template 6.3.2.4 News Detail View The “News Detail” view appears after the user selects a news article. The view model will obtain the original link for that news and show this view. The root widget is a Page, with a Header, which contains a back button, and a Html for content. The header’s title will be the news’ title. The html widget has a template and a data object binded to it. The template is an iframe whose source is the link property of the data object. So, when the news item is binded to the html widget as the data object, it’s link will be used as the source of the iframe. The user will then be able to view the original news article. 1var pageTemplate = "< iframe c l a s s =\" news−d e t a i l s \ " s rc =\"{{ l i nk }}\" > </ iframe >" ; 2var c o nte nt = UI . c r e a t e ( " html " ) 3. a t t r ( " customClass " , " ui−f i l l " ) / / Makes t h e i f r a m e f i l l i t s p a r e n t 4. a t t r ( " html " , pageTemplate ) / / Change t h e t e m p l a t e 5. a t t r ( " data " , news ) / / Bind t h e news data o b j e c t ( an o b s e r v a b l e ) Listing 6.2: Creating an iframe using an Html widget 6.3.2.5 Phone View This is the main view of the application. Its root widget is an Aside, which will be used for placing the “Feeds” view as a side pane. As the main content, a PageHolder that contains the “News” and “News Detail” views is used. 68 RSS Reader: Demo Application 6.3.2.6 Login View Model The login view model initializes the “Login” view and deals with communicating with the backend server when the user presses the submit button. When initializing, the view model checks if it has the credentials of the user stored in the localStorage and, if it has, it attempts to login automatically using those credentials. Otherwise, the user will have to fill in his email and password and press the submit button. When the user presses the submit button, the login event is captured and the view model collects the email and password the user wrote using the observables binded to those fields and submits an AJAX request to the back-end server, to the /user/login endpoint. If the user is successfully authenticated, the credentials are stored for automatic authentication the next time the user opens the application and the “Feeds” view is shown. However, if the authentication fails, the user is warned by ways of an alert and remains in the same page so that he can try again. 6.3.2.7 Feeds View Model This view model initializes the “Feeds” view and handles the events generated by it. The feeds:clicked event is triggered when the user clicks on a feed. The view model will check its cache (which is stored in localStorage) and collects the list of news from there. If the cache is outdated, it’ll ask the back-end server for new news. After collecting the array of news to show, it passes them to the “News” view model, invoking its showNews method. This method updates the observables that set the title and the list content of the “News” view. After that, it’ll show the “News” When the user presses the manage button in “Feeds” view, the event feeds:manage is triggered and captured by this view model. It creates a copy of the current feeds of the user, that will be used as target of all the user’s modifications when on the manage screen, and makes a transition to the manage screen. The feeds:add event is triggered when the user is in the “Manage feeds” view, inserts an URL and presses the “Add” button. When this happens, the view model reads the value of the observable associated with the URL field and adds a new Javascript object to the temporary feeds array. This object contains the properties name and url, both with the new URL. The feeds:cancel event is triggered when the user presses the back button. It causes the view model to clear the temporary feeds list and return to the “Feeds” screen. The feeds:save event if triggered when the user presses the save button. The view model captures this event and merges the temporary list and the present list, identifying which feeds to add, edit or delete. Then, for each of these operations, it’ll communicate the changes to the back-end server using the API described before. 69 Conclusions As new platforms appear, the mobile market evolves, along with how applications are developed. The future is still uncertain, but web applications will definitely play an important role in it. 7.1 Future Work The Meems Framework provides a working basic framework, but it is far from complete. A project of this dimension would never be ended within the time frame of this dissertation, so its scope was reduced. But there is still much work to be done to turn it into a really useful and productionready platform: more widgets, support for more platforms, better performance, integration with other tools, better user documentation with examples, tutorials and a community. Since the framework is extensible, implementing new widgets and supporting new platforms is simple. Possible new widgets include: progress bar, picture gallery, comboboxes, dialogs and pop-ups. Existing widgets should also be improved and extended. For example, the Aside widget could be extended to be able to appear from either sides of the screen, instead of appearing only from the left. The List widget can also be further optimized, as it is certainly one of the most important widgets in mobile applications. Its performance varies according with the size of the list, which means that long lists degrade the performance of the whole application. The support for other platforms, like Windows Phone, BlackBerryOS, FirefoxOS or Ubuntu Touch, will also be critical, as multiple platform support is one of the key features of frameworks of this kind. As the frameworks evolves, the user documentation will also be made better and users are expected to collaborate in writing and translating it. A good solid documentation is an important step for any software that wants to be used properly and prosper. Providing the final user with the best experience is the goal, but the Meems framework is also about making the life of developers easier. All the improvements above are certainly a step in this direction. 76 References [ao13] amdjs organization. AMD. https://github.com/amdjs/amdjs-api, 2013. [Online; accessed 16-February-2013]. [App09] Apple. Apple Reports First Quarter Results, January 2009. http: //www.apple.com/pr/library/2009/01/21Apple-Reports-FirstQuarter-Results.html [Online; accessed 10-June-2013]. [App13] Apple. Start Developing iOS Apps Today: Set Up. https://developer.apple. com/library/ios/#referencelibrary/GettingStarted/RoadMapiOS/ chapters/GetToolsandInstall.html, 2013. [Online; accessed 16-February2013]. [Eva13] Benedict Evans. Facebook’s 470m mobile app users. http://ben-evans.com/ benedictevans/2013/1/2/facebooks-545m-mobile-app-users, January 2013. [Online; accessed 02-June-2013]. [Goo13a] Google. Android NDK | Android Developers. http://developer.android. com/tools/sdk/ndk/index.html, 2013. [Online; accessed 16-February-2013]. [Goo13b] Google. Android SDK | Android Developers. http://developer.android.com/ tools/sdk/index.html, 2013. [Online; accessed 16-February-2013]. [Goo13c] Google. Policy and Best Practices - Android Developer Help. http://support. google.com/googleplay/android-developer/topic/2364761?hl=en, 2013. [Online; accessed 16-February-2013]. [Hen12] KeeKim Heng. Speeding up JavaScript: Working with the DOM. https:// developers.google.com/speed/articles/javascript-dom, March 2012. [Online; accessed 04-May-2013]. [IDC13] IDC. Android and iOS Combine for 92.3Shipments in the First Quarter While Windows Phone Leapfrogs BlackBerry, According to IDC, May 2013. http://www.idc.com/ getdoc.jsp?containerId=prUS24108913 [Online; accessed 10-June-2013]. [JA12] Jacky Nguyen Jamie Avins. The Making of Fastbook: An HTML5 Love Story. http://www.sencha.com/blog/the-making-of-fastbook-anhtml5-love-story, December 2012. [Online; accessed 04-May-2013]. [jF+12] jQuery Foundation et al. jQuery Mobile Docs - Intro, 2012. http://jquerymobile. com/demos/1.2.0/docs/about/intro.html [Online; accessed 10-June-2013]. [Kan13a] David Kaneda. jQT (formerly jQTouch) — Zepto/jQuery plugin for mobile web development, 2013. http://jqtjs.com/ [Online; accessed 10-June-2013]. 77 REFERENCES [Kan13b] Dan Kantor. The Story behind Exfm, April 2013. http://phonegap.com/blog/ 2013/04/23/story-behind-exfm/ [Online; accessed 05-June-2013]. [Mah13] Michael Mahemoff. Client Side Storage - HTML5 Rocks, 2013. http://www. html5rocks.com/en/tutorials/offline/storage/#web-storage [Online; acessed 10-June-2013]. [Nis13] Deep Nishar. 200 million members!, January 2013. http://blog.linkedin.com/ 2013/01/09/linkedin-200-million/ [Online; accessed 05-June 2013]. [O’D11] Jolie O’Dell. LinkedIn’s new mobile app is so gorgeous, you’ll actually want to use it, August 2011. http://venturebeat.com/2011/08/16/linkedin-mobileapp/ [Online; accessed 05-June-2013]. [O’D12] Jolie O’Dell. You’ll never believe how LinkedIn built its new iPad app (exclusive), May 2012. http://venturebeat.com/2012/05/02/linkedin-ipad-appengineering/#vb-gallery:1:421650 [Online; accessed 05-June-2013]. [O’D13] Jolie O’Dell. Why LinkedIn dumped HTML5 & went native for its mobile apps, April 2013. http://venturebeat.com/2013/04/17/linkedin-mobileweb-breakup/ [Online; accessed 05-June-2013]. [Ola12] Drew Olanoff. Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5. http://techcrunch.com/2012/09/11/mark-zuckerberg-ourbiggest-mistake-with-mobile-was-betting-too-much-on-html5/, September 2012. [Online; accessed 02-Jun-2013]. [Sen13] Sencha. Sencha Touch - Build Mobile Web Apps with HTML5, 2013. http://www. sencha.com/products/touch/ [Online; accessed 10-June-2013]. [Thu13] Paul Thurrott. Why is the Facebook Beta App for Windows Phone 8 identical to the Android and iOs apps?, May 2013. http://winsupersite.com/windowsphone/why-facebook-beta-app-windows-phone-8-identicalandroid-and-ios-apps [Online; accessed 05-June-2013]. [Ton10] Tony Wasserman. Software Engineering Issues for Mobile Application Development. FoSER, 2010. http://works.bepress.com/tony_wasserman/4 [Online; accessed 23-February-2013]. [Wik12] Wikipedia. Approval of iOS apps — Wikipedia, The Free Encyclopedia. http: //en.wikipedia.org/wiki/Approval_of_iOS_apps, 2012. [Online; accessed 16-February-2013]. 78 Appendix A Survey Results The results of the performed survey are shown below. A.1 Experience A.1.1 How many years of experience in software development do you have? The language and the platform don’t matter. 026 27% 166% 233% 366% 410 10% 514 14% 612 12% 766% 833% 922% 10 10 10% This section’s purpose it to collect the amount of experience you have developing software. A.1.2 How many years of experience in software development do you have? The platform doesn’t matter. 79 Survey Results 036 38% 128 29% 221 22% 311 11% 400% 500% 600% 700% 800% 900% 10 00% A.1.3 What platforms have you developed native applications for? Choose all that apply. JavaME 55% Symbian 22% iOS 88% Android 56 59% BlackBerryOS 00% Bada 11% Windows Phone / Mobile 18 19% Other 55% A.1.4 What kind of mobile apps do you develop? Do you use the platform’s provided SDK’s (native), tools like PhoneGap or appMobi (hybrid) or do you develop web applications oriented towards mobile? Native 46 53% Hybrid 13 15% Web App 28 32% 80 Survey Results A.1.5 Do you target one platform at a time, or do you have a team per platform? One platform at a time 35 54% A team per platform 46% I only target one platform 26 40% A.2 HTML5, Javascript and CSS3 A.2.1 What’s your skill level in Javascript? 023 23% 118 18% 223 23% 314 14% 417 17% 544% A.2.2 What’s your skill level in HTML5 and CSS3? 023 23% 113 13% 219 19% 314 14% 422 22% 588% A.2.3 Do you prefer HTML5 or Javascript for implementing user interfaces? For implementing the views of your application, you prefer a library that enables you to use solely HTML5 (like KendoUI) to specify it or a library where you use Javascript to specify the GUI (like Sencha Touch)? HTML5 25 35% Javascript 710% I like to mix HTML5 and Javascript 39 55% 81 Survey Results A.3 Features A.3.1 Classify the functionalities/characteristics below according to their importance to you A.3.1.1 Analytics Not important 45% Nice to have 21 28% Useful 27 36% A must 21 28% Deal breaker 23% A.3.1.2 Hardware acceleration Not important 34% Nice to have 17 22% Useful 28 37% A must 22 29% Deal breaker 68% A.3.1.3 Configurable effects Not important 23% Nice to have 26 34% Useful 32 42% A must 14 18% Deal breaker 23% A.3.1.4 Fixed scrolling emulation Not important 811% Nice to have 19 26% Useful 33 46% A must 11 15% Deal breaker 11% 82 Survey Results A.3.1.5 UI Widgets Not important 45% Nice to have 15 20% Useful 29 39% A must 20 27% Deal breaker 68% A.3.1.6 Data bindings betweens views and models Not important 34% Nice to have 12 16% Useful 31 41% A must 23 31% Deal breaker 68% A.3.1.7 Cross-platform support Not important 23% Nice to have 912% Useful 24 32% A must 24 32% Deal breaker 16 21% A.3.1.8 Full SDK Not important 57% Nice to have 811% Useful 25 35% A must 21 29% Deal breaker 13 18% 83 Survey Results A.3.1.9 Documentation Not important 34% Nice to have 12 16% Useful 16 22% A must 26 35% Deal breaker 17 23% A.3.1.10 Internationalization (i18n) Not important 11% Nice to have 11 15% Useful 28 37% A must 23 31% Deal breaker 12 16% A.3.1.11 Extensions Not important 34% Nice to have 20 27% Useful 38 51% A must 12 16% Deal breaker 23% A.3.1.12 Monetization Not important 913% Nice to have 15 21% Useful 33 46% A must 11 15% Deal breaker 34% 84