Case study on PhoneGap / Apache Cordova

Transcription

1 Chapter 1 Case study on PhoneGap / Apache Cordova 1.1 Introduction to PhoneGap / Apache Cordova PhoneGap is a free and open source framework that allows you to create mobile applications in a cross platform way by using web technology such as HTML, CSS and JavaScript. PhoneGap makes it possible to access native functionality from within your web application and wraps it within a real native application that you can release in the application stores. With PhoneGap you can access functionality like the camera, the storage system of the device, notifications and many more from within the browser. You might think that some of these things are already possible from within the browser by using the W3C Device API standard. This is true, but these standards were not available yet when PhoneGap was started (2008) and not all the browsers implement the standard at the same time which makes it hard to develop in a cross-platform way. PhoneGap solves this problem by using the existing implementation from the browser or by implementing the standard itself. The ultimate goal of PhoneGap is to cease to exist. PhoneGap was originally created by a Canadian company called Nitobi. In 2011 it got acquired by Adobe and the source code was donated to Apache where it got the name Cordova. The two still live next to each other and they still use the same code base, but Adobe uses PhoneGap as the commercial name for it. 1.2 Creating PhoneGap The development of PhoneGap started in the end of 2008 by some developers at Nitobi. They were developing web applications for clients and noticed that it was hard to develop native smartphone applications for the new operating systems that were popping up. Android had 1

2 CHAPTER 1. CASE STUDY ON PHONEGAP / APACHE CORDOVA 2 released it s first phone a year earlier and the iphone was about two years old. Next to these two platforms a lot of other platforms existed like Windows Mobile, Nokia and Bada. All these platforms have different programming languages or at least different API s, different user interface behavior and some of them have buttons while others don t. Next to the platforms differences there are also differences in the device s performance, screen sizes and resolutions. It s very hard to tackle all these problems in native code since you end up with having a lot of different code bases that your developers have to maintain. If you upgrade your application you have to change it for all these platforms separately. It s especially a problem for smaller companies who would need experts at several languages and platforms. At Nitobi they noticed that all these platforms and devices had one thing in common: a browser. So why not use this browser to create your applications and access the native functionality through this browser? There goal became to create a framework that could make native functions available from within the browser and to have only one code base written in web technology that you could use on every platform. They wanted to create the Adobe AIR for mobile applications, which didn t exist yet at that time. In the IT world it is not only about the development of these products and tools but also about the business model behind it. How are you going to make money with it? At Nitobi they decided to make PhoneGap open source so buying a license on the platform didn t need to be a restriction to start using the platform. They planned to get their money out of training and PhoneGap related things. The development of PhoneGap and its architecture was always closely linked to the business development of the product. You can see three phases in this architecture and business development. During the first phase they were testing things out, trying to create a stable prototype and get feedback on it. In the second phase PhoneGap started to get known in the community and was used a lot for development of applications. In the third and last phase they got acquired by Adobe and had a big boom in users and software quality. The three phases are described in the sections below Phase 1 ( ) Problem definition As said before Nitobi wanted to create a framework that would allow web applications to access native functionality, create native applications out of these web applications and thereby allow cross-platform development.

3 CHAPTER 1. CASE STUDY ON PHONEGAP / APACHE CORDOVA 3 Requirements There most important requirement was that this framework should be cross-platform and allow cross-platform development of applications. This was the problem that they wanted to solve. Next to that it should be possible to access native functionality from within a webkit view, which is actually just a browser class that each platform offers in their API. This is an important requirement since this influences the success of the platform. If you could only use functionality that is already present in the browser itself, why would you use PhoneGap? They chose to support only webkit views because these had the best rendering and most browsers already supported webkit. Their last important requirement was that developers of PhoneGap applications should not need to use native code to create the PhoneGap application. Everything should be possible by using web technology. Quality attributes and tactics These three requirements indicated that portability should be their first quality attribute to focus on. Portability is a variant of modifiability and means that the platform that you develop your solution for is subject to change. This was indeed the case since they wanted their solution to work on ios, Android, Bada and many more. They used several tactics to make sure this quality attribute was met. They used layers to hide information so the upper layer should not be aware of which platform is used in a lower layer. They created an interface that the application developers could use on all platforms and they restricted the communication paths. It is not possible to access the native functionality without going through the PhoneGap layers. Architecture In their architecture we can identify four different layers, as you can see on figure 1.1. The operating system layer. This is the lowest layer of the PhoneGap framework. If you would develop a native application this would be the layer you would work on. It contains the API provided by the manufacturer of the OS. The PhoneGap native layer. To allow the browser to access the native functionality, PhoneGap had to create a bridge between Javascript and the native code, which is partially done in this layer. This layer

4 CHAPTER 1. CASE STUDY ON PHONEGAP / APACHE CORDOVA 4 Figure 1.1: First phase architecture of PhoneGap also contains the webkit view that will run the web application that the developer created. The PhoneGap Javascript layer. This Javascript layer includes parts of the bridge to the native code. It also contains the API that developers will use in their Javascript if they create the PhoneGap application. In case a function from this API was already implemented by the browser view, this layer redirects to this implementation, otherwise it calls one of the native functions in the layer below. The app layer. This upper layer contains the application that an application developer would make. It contains the CSS, HTML and the Javascript that includes the logic. The only layer that is visible for an application developer is the app layer and the interface towards the PhoneGap Javascript layers. All the other layers are hidden for an application developer. This is an implementation of the tactic Hide information. As you can see in figure 1.1 there are different columns in the lowest three layers of this architecture. This is because in these three layers the code is platform specific. The Javascript code for Android for example has a different implementation for certain functions than the

5 CHAPTER 1. CASE STUDY ON PHONEGAP / APACHE CORDOVA 5 JavaScript code for ios. This is because the bridge from Javascript to the native code and the other way around is based on a hack in the browser and this hack is different on each platform. One of the requirements for this phase was that the framework should be crossplatform, which is not totally the case but for a developer it is possible to create applications in a cross-platform way. Business development During this first phase the business development was limited to making the product known to application developers and receiving feedback to test how big the need was. At the beginning of the development of PhoneGap they had some problems with Apple. Although PhoneGap allowed developers to create good quality ios applications, these applications were rejected by the Apple App Store team simply because they were build with PhoneGap and thus they were no native application. The people at Nitobi put a lot of effort in this problem and luckily they were able to convince the people at Apple that they should allow these applications to be released as long as they met the Apple User Interface guidelines. If they shoudn t have been able to solve this problem, it could have killed their whole business. If you claim to be a framework that you can use for cross-platform development, but you can t create applications for one of the largest platforms, your product is worthless. This is a good example of a crucial product factor. Even though PhoneGap was not that big, Nitobi already started with providing some Phone- Gap trainings. Partially to receive feedback about the product but also to make sure that people knew how to use it and created applications with it. It is important that you pamper your early adopters and that you help them as much as you can to create excellent applications with your product. The early adopters are the people that will help you to promote your product with other people and thereby help you to grow quickly. PhoneGap was present at several conferences to make sure developers knew that it was existing. They also participated in some pitch contests and they always had a very good response. They even won the public prize at one of these contests. It really showed that there product was fulfilling an actual need and that they should continue with the development. During this first phase PhoneGap was already available on a lot of platforms including Android, ios, Blackberry and Windows Mobile. This was important since it proved that they were aiming to cover as much platforms as possible. If after one year they had only covered two platforms, people might question there cross-platform abilities which is the main USP (unique selling point) of PhoneGap.

6 CHAPTER 1. CASE STUDY ON PHONEGAP / APACHE CORDOVA Phase 2 ( ) Problem definition During the first phase Nitobi did a lot of work to get PhoneGap known in the developers community. And it worked. A lot of developers started to work with PhoneGap. Since it was only a beta release these developers often found problems that they wanted to solve. This didn t seem to be a problem since the code was open source. Unfortunately, the adaptations to the code made it sometimes impossible to merge this separate and adapted branch with the main branch. After a while there were different versions of the source code circulating. This caused another problem. It was possible that you were working with a specific version and you d discovered a bug. The same bug was fixed in another branch but you couldn t use the fix since your code was different. At that moment you had two options: try to find a fix yourself or port to the different version of PhoneGap. This was not what the people at Nitobi had in mind. They wanted it to be possible to just merge back your code without generating conflicts. If they wanted their product to grow and have a solid contributors base they had to do something about this situation. Requirements It should be possible for developers to add their own extensions to the platform without affecting the PhoneGap platform itself. If this is possible each developer can add the functionality that he wants and share this code with other people that might want the same. Once these extensions are available it should be easy to add them to your application and to upgrade it to a newer version. It should be possible to update a certain part of the internal code of PhoneGap without affecting other code that has nothing to do with it. Quality attributes and tactics PhoneGap needed to include modifiability into their architecture in order to meet these requirements. If they changed their architecture at that moment in a more modifiable one it would be easier to do changes and let other people contribute. To obtain a higher level of modifiability they changed the existing architecture into a more plugin-based architecture. These plugins include the extra functionality an application developer would want to add to some of its applications. They divided the internal architecture in separate components that could be changed without affecting the other ones. For the plugins they used binding at runtime to make it as modifiable as possible.

7 CHAPTER 1. CASE STUDY ON PHONEGAP / APACHE CORDOVA 7 Figure 1.2: First phase architecture of PhoneGap s internal structure Architecture PhoneGap had to change the PhoneGap native and the PhoneGap Javascript layer in order to make the architecture more plugin-based. Especially in the Javascript layer the code was often a mess and there were no strict components as you can see in figure 1.2. They changed this and made separate components with different functionality and responsibilities such as camera, notification and media. On the other hand they made it possible to include the external plugins such as a Facebook or PayPal plugin. This is visualized in figure 1.3. In the general architecture the plugins were added to the PhoneGap Javascript layer as well as to the PhoneGap native layer, as you can see on figure 1.4. This is because a plugin always consists of a native part that executes native code and a Javascript part that provides the interface towards the application and the link to the native code to be executed. This also means that a plugin is not cross-platform and that both parts have to be developed for each platform. Business development During this second phase the first version of PhoneGap was released which included the pluginbased architecture. From now on PhoneGap was out of beta. This of course influenced the amount of downloads which reached over downloads in total with a big increase after the release of PhoneGap 1.0.

8 CHAPTER 1. CASE STUDY ON PHONEGAP / APACHE CORDOVA 8 Figure 1.3: Second phase architecture of PhoneGap s internal structure Figure 1.4: Second phase architecture of PhoneGap

9 CHAPTER 1. CASE STUDY ON PHONEGAP / APACHE CORDOVA 9 Nitobi still organized training for developers but next to that they also organized the first PhoneGap Day. On this day PhoneGap developers could meet the application developers and they gave several sessions about using PhoneGap and how it works. PhoneGap was included in Dreamweaver which made it much easier to develop PhoneGap applications. This also showed that Adobe believed in PhoneGap and that they thought that the community would keep growing Phase 3 ( ) The third phase is dominated by the acquisition of Nitobi (and thus PhoneGap) by Adobe. This didn t only influence the business side of the project, but the architecture as well. Although the actual acquisition happened in October 2011, the negotiations were started before this date and changes were already manifesting them from the beginning of Problem definition PhoneGap kept growing as the 1.X releases offered more and more functionality. This meant that more and more developers were thinking about creating applications with PhoneGap. These could be highly experienced developers who quickly found their way in the PhoneGap community. But there were lots of other developers too, who couldn t find the information they were looking for in the mess of PhoneGap documentation. At the beginning of the third phase, there was not that much documentation. There was a Google group which contained questions and (sometimes) answers on these questions, a wiki page with (often outdated) information and a very minimal page of API documentation (also often outdated). If you wanted to know how a function worked, the best way to look was in the PhoneGap code itself. Documentation was not their first priority and you could clearly see this. This documentation was nevertheless very important, since some API s were not consistent between the different OS platforms. As you could see on figure 1.4, there is no unified API layer towards the application developer, but each platform has its own API. This introduced inconsistencies between the platforms, for example because some platform requested an extra parameter when calling a certain function. Since the documentation was not up to date, it was sometimes very hard to find out which parameter you actually had to add. Because of these problems, developers often had to add extra if conditions to check for the platform in order to keep their code cross-platform. Their last major problem in this phase was the complicated build process, which already started when creating a new project. It was very important that you did this in the right way, which was often not the most obvious one. If you didn t create the project in the right

10 CHAPTER 1. CASE STUDY ON PHONEGAP / APACHE CORDOVA 10 way, you couldn t build your project correctly and you had to create a new one in the right way. The build process itself was not that easy too and was different for each platform. These three problems led to people stopping to use PhoneGap for their development. Besides that, chances existed that their reputation would be affected by these problems, since bad comments travel faster than good ones. They had to tackle this immediately, but therefore they needed extra people who wanted to do this. At first some members of the community started on improving the documentation, but with the acquisition by Adobe they received enough resources to overcome these problems. Requirements In order to fix these problems they had to make the workflow of creating, developing and building a PhoneGap application much easier. They had to lower the learning curve so newbies to PhoneGap could easily get started with it and easily find the right information. Therefore they had to improve the documentation, include tutorials, structure the wiki and integrate with different tools that could make the development of applications easier (for example compatible GUI frameworks). Of course they had to make sure that the API was consistent between the different platforms. Quality attributes and tactics These different requirements indicated that usability was their most important quality attribute for this phase. Usability is only partially related to the architecture. A lot of the usability resides in other things such as documentation, information or workflow. To improve the build process and to create the consistent API, they had to do changes to the architecture. Architecture Before PhoneGap entered this third phase of their architecture, the PhoneGap code looked like figure 1.3. They had internal modules and external plugins. This meant that it was not possible to exclude the camera functionality from your project if you didn t use it. But it also implied that internal components were called in a different way than the plugins, which was sometimes confusing for developers. Therefore the PhoneGap team decided that they would make a plugin out of every functionality that can stand on it s own such as the camera or the accelerometer. There still is a small PhoneGap code base which makes sure that all the plugins can communicate with the developer s application and that crosses the bridge to the native code. You can see the new structure in figure 1.6.

11 CHAPTER 1. CASE STUDY ON PHONEGAP / APACHE CORDOVA 11 Figure 1.5: Third phase architecture of PhoneGap Figure 1.6: Third phase architecture of PhoneGap s internal structure

12 CHAPTER 1. CASE STUDY ON PHONEGAP / APACHE CORDOVA 12 Their architecture changed as well. In the architecture shown in figure 1.4 you still see the different platform specific API s in the PhoneGap Javascript layer. During this third phase the PhoneGap team added a component that includes the API towards the developer and that is not platform specific, as you can see in figure 1.5. The PhoneGap team did a good job at improving the build process. This is not really a part of the architecture, but they had to do some small architectural changes in order to make this possible. They now offer an automated cloud service that packages your HTML, Javascript and CSS code into a native PhoneGap application for all the different platforms. Unfortunately you can only use this service if you use the plugins supported by PhoneGap build and it can not be used when you have your own native parts. Business development As mentioned at the start of this section, the third phase was highly dominated by the acquisition of Nitobi by Adobe. This acquisition was a big step for Nitobi since they are no longer an independent company, but should follow Adobe s wishes now. This is not totally true for the PhoneGap project since the source code was donated to the Apache Cordova project. This allows Cordova to move in another direction of PhoneGap if this should be necessary. In the meantime, Adobe PhoneGap 2.0 was released, which included the new architecture with the unified Javascript layer. With this second release they reached over downloads a month. They also changed the release cycle to a fixed date each month and 10 releases over the year (there is one release missing around New year and one during the summer since a lot of developers are on holiday in these periods). Now it is very clear for developers of applications that they will have to update their applications each month to the newest PhoneGap version. In 2012, there was not only a PhoneGap day in the USA, but also in Europe. This shows the interest of Adobe PhoneGap in the European region. 1.3 Remarks Now that we took a look at the evolution of the PhoneGap architecture, there are some remarks I would like to add Avoid frequent changes of the architecture Of course it is possible that your architecture is subject to change over the years. This doesn t have to be a problem if this is needed to make your product better. But it is important that

13 CHAPTER 1. CASE STUDY ON PHONEGAP / APACHE CORDOVA 13 you limit the amount of changes that affect the developers work, such as API changes. If a developer has to change its code often because your product changed something to the API or to something else, it can be frustrating. PhoneGap changed several times in a way that developers had to refactor their code. The first change was during phase two when they merged the different PhoneGap files in one file to include in your project. This introduced several SVN conflicts, which are always frustrating. When they changed their plugin structure, every plugin had to be rewritten in order to cope with the new plugin API. Sometimes it was not possible to use a plugin since it still used the old plugin API and you already used the new one. The different API changes in general often introduced bugs that were hard to find since Javascript will not give an error when an argument or function is not found. It also worsened the documentation problem since some API s changed so often that is was hard to keep track in the documentation. The last major refactor was when PhoneGap was donated to the Apache Cordova project and the name space was changed from PhoneGap to Cordova Find partners that support you For a product like PhoneGap, it is very important that you find big partners that support you and that help you to integrate their products or services within yours. People from RIM (Blackberry), Google, Intel and IBM are contributing to the Cordova project in order to improve the PhoneGap applications developed for their platforms. PhoneGap also gets help from people at Facebook to improve the quality of the Facebook plugin. The most important partner of PhoneGap is of course Adobe itself, which was already a partner from the beginning There is no silver bullet PhoneGap or Apache Cordova is not a silver bullet every developer should use to create mobile applications. The advantages of using PhoneGap are that you can create an application in no time, you don t need to learn a native language but you can use web languages and you can use PhoneGap build to automatically build an application for all platforms. On the other side Javascript is hard to debug on mobile applications, the performance is not native since you pass an extra layer and you don t have a real native experience (although you can do a really good job at simulating it). For every application you would like to create you should really think about what is important for that application and your company. Is the native experience and the performance more important that a minimal cost? Then go for a native application.