evaluating!development!frameworks!for! … · 2018-01-22 ·...
TRANSCRIPT
Evaluating Development Frameworks for Hybrid Application Development
CSI 5112
Project Report
Submitted by
Shahzeb Khowaja
Taha Lukmanji
1 EXECUTIVE SUMMARY
Mobile Development has become a very fast paced environment where companies are pushing
its developers to dole out new features and updates as quickly as possible to get ahead of their
competition. Adding to the list of dilemma is the permutation of various platforms (iOS,
Android, Tizen, etc), various screen sizes (from 4 inches to 10 inches) and hardware
components. Looking at the permutations of platforms and hardware differentiators would
make any developer pull their hair!
One method of solving this problem is to provide an API set in language X and after compiling,
building and packaging, the output gives way for multiple applications packages, each for a
platform. This is called Hybrid Application Frameworks. These frameworks attempt to remove
some of the pain, mentioned above, of developing on multiple mobile platforms and attempt to
provide a single look-‐and-‐feel across all platforms.
An e-‐commerce company sells hardware tools (wrenches, hammers, saws, etc) on an open-‐
source web-‐based commerce platform called OpenCart. The version of software they currently
use was released 10 years ago and upgrading to the latest version has been declared to be too
risky. They have contracted us to provide advice on how to proceed with developing a mobile
application that sells hardware tools, which is an outcome of a growth and strategy meeting in
the company.
With the set of requirements provided by the business into consideration, we came up with a
set of criteria to select the most suitable hybrid application framework for the e-‐commerce
company. The criteria primarily focus on the cost of acquiring the hybrid application framework
along with the satisfied intersection of desired features and available features of the various
frameworks. Once the previous criteria are satisfied, we evaluate the ease of doing
development using the platform, considering lines of code to implement a feature, along with
performance numbers of each feature.
After a first pass of filter, we picked two frameworks, PhoneGap, owned by Adobe and
Titanium, owned by Appcelerator. After applying our criteria to these two frameworks, we
selected PhoneGap as the framework of choice for our client. It was a tight race between the
two frameworks. PhoneGap’s solid screen adaptability versus Titanium’s immense hooks and
“cartridges” into iOS and Android platform made it difficult for us to pick our framework.
PhoneGap, overall, used more system resources than Titanium but as overall system
capabilities are increasing, the performance requirement as a percentage of the whole system
will decrease. Moore’s Law is very famous in this scenario; he states that the numbers of
transistors put per square inch of area will double every 18 months.
2 TABLES
2.1 TABLE OF CONTENTS 1 Executive Summary .............................................................................................................................. 2
2 Tables ................................................................................................................................................... 4
2.1 Table of Contents ........................................................................................................................ 4
2.2 Table of figures ........................................................................................................................... 5
3 Glossary ................................................................................................................................................ 6
4 Introduction ......................................................................................................................................... 7
4.1 History of Smartphones .............................................................................................................. 7
4.2 Variation in smartphones ............................................................................................................ 9
4.3 Platforms ................................................................................................................................... 10
4.3.1 Android ................................................................................................................................. 10
4.3.2 Apple iOS .............................................................................................................................. 13
4.4 Hybrid Application Frameworks ................................................................................................ 15
4.4.1 Web-‐based approach ........................................................................................................... 16
4.4.2 Widget toolkit – based approach ......................................................................................... 17
4.4.3 Cross-‐compiler approach ...................................................................................................... 18
5 Business Context ................................................................................................................................ 20
5.1 Requirements ............................................................................................................................ 21
6 Criteria & Evaluation Methodology .................................................................................................... 23
6.1 Criteria ...................................................................................................................................... 23
6.2 Evaluation methodology ........................................................................................................... 25
6.2.1 Filter ...................................................................................................................................... 25
6.2.2 Analyze ................................................................................................................................. 25
7 Initial Research ................................................................................................................................... 27
8 Titanium SDK & PhoneGap SDK .......................................................................................................... 29
8.1 Brief introduction ...................................................................................................................... 29
8.2 System requirements ................................................................................................................ 30
8.2.1 General ................................................................................................................................. 30
8.2.2 PhoneGap ............................................................................................................................. 30
8.2.3 Titanium ................................................................................................................................ 31
8.3 Setup ......................................................................................................................................... 31
8.3.1 PhoneGap ............................................................................................................................. 31
8.3.2 Titanium SDK ........................................................................................................................ 33
9 Evaluation of PhoneGap and Titanium SDK ....................................................................................... 36
9.1 Feature importance ranking ..................................................................................................... 38
9.2 Feature ratings .......................................................................................................................... 40
9.2.1 Location awareness .............................................................................................................. 40
9.2.2 Screen adaptability ............................................................................................................... 41
9.2.3 Local database ...................................................................................................................... 42
9.2.4 Communication support (REST) ............................................................................................ 42
9.2.5 Notification Support ............................................................................................................. 43
9.2.6 Globalization & Localization ................................................................................................. 44
9.3 Decision Making ........................................................................................................................ 45
10 Conclusion ..................................................................................................................................... 47
11 Final remarks ................................................................................................................................. 49
12 References ..................................................................................................................................... 50
2.2 TABLE OF FIGURES Figure 1: Android Architecture ..................................................................................................... 11
Figure 2: Layers of iOS (from Apple Inc) ....................................................................................... 14
Figure 3: Hybrid Application Framework: web-‐based model ....................................................... 16
Figure 4: Hybrid Application Framework -‐ Widget toolkit-‐based model ...................................... 17
Figure 5: Hybrid Application Framework: cross-‐compiler approach ............................................ 18
Figure 6: PhoneGap project structure .......................................................................................... 32
Figure 7: Titanium Studio Preferences Window ........................................................................... 34
Figure 8: Titanium Studio project structure ................................................................................. 35
Figure 9: Performance metrics measurements for iOS application ............................................. 37
Figure 10: Performance metrics measurement for Android application ..................................... 38
Figure 11: Bar chart of feature ratings ......................................................................................... 40
3 GLOSSARY
• OS: Operating System
• API: Application Programming Interface
• IOS: Interactive Operating System
• POS: Point-‐of-‐Sale
• GA: Generally Available
• TSS: Titanium Style Sheet
• UI: User Interface
• OHA: Open Handset Alliance
• HAL: Hardware Abstraction Layer
• SSL: Secure Socket Layer
• OpenGL: Open Graphics Library
• DAL: Device Abstraction Layer
• REST: Representational State Transfer
• CSS: Cascading Style Sheet
• URL: Uniform Resource Locator
• GPS: Global Positioning System
• JSON: JavaScript Object Notation
• XML: Extensible Markup Language
• CPU: Central Processing Unit
• LOC: Lines of Code
• HTML: Hyper Text Markup Language
• SDK: Software Development Kit
• NDK: Native Development Kit
• GB: Gigabyte
• JDK: Java Development Kit
• IDE: Integrated Development Environment
• CDV: Cordova
• RAM: Random Access Memory
4 INTRODUCTION
Today, smartphones have become an important electronic companion for the major of the
population, which can afford it right now. As I type, we are glad that the affordability of
smartphones is increasing exponentially. Many businesses are moving towards catering their
customers by building mobile applications. It may be easy, from a technical standpoint, for the
upper echelons of a business organization or a company to announce intent to cater to their
customers via a mobile application but the technical staff below face many problems when
developing applications for smartphones. There are permutations of different platforms and
different hardware component and variations; engineers strive hard to make sure that all
variations are addressed handled elegantly.
Due to complications in developing mobile applications, an e-‐commerce company has decided
to contract the work to us, providing us with a set of requirements. In the end, we will come up
with a recommendation to the company on how to proceed with the development of the
mobile application. They are constrained in terms of time and money. Therefore, we have
decided to build our application using hybrid application frameworks. But what are hybrid
application frameworks? It’s a bit of a long story. In this section we will set the stage with first
discussing a little bit about the emergence of smartphones, detailing about the progress, and
then discuss the current platforms available today in the market. Then we will discuss about
how hybrid application frameworks work and the different approaches taken.
The next part of the report will establish the business context along with requirements, criteria
and evaluation methodology. We will then do a deep dive into our selected hybrid application
frameworks and analyze them. The report will close off with a conclusion.
4.1 HISTORY OF SMARTPHONES
Availability of smartphones has become commonplace today, so common that people have
started removing their landline phones and tossing them in the garbage, and replacing them
with smartphones which, to be honest, can do much more than the standard landline phone.
But you may wonder how did this revolution start? Let’s put these major events in point form:
1. The first wireless phone call was made in 1973 by Martin Cooper, a Motorola Engineer
was credited to building the first cellphone [1,2].
2. Fast-‐forward 10 years later and the general public started seeing the first cellphones on
the market. It weighed 800 grams and estimated the service cost to be between 60 to
100 dollars a month [1, 2].
3. In 1993, cellphones were finally beginning to pick up in sales. In that same year, IBM and
BellSouth attempted to build a “smartphone”. The cellphone contained pager, email,
and handwriting capabilities [1, 2].
4. Nokia entered this so-‐called niche market later and released the Nokia 9000
communicator. It was a monochrome phone capable of email, web browsing, word
processing and even spreadsheets. Ericsson released the Penelope 88 phone and
officially called it the smartphone [1, 2].
5. In 1999, Research in Motion released 850 and subsequent models became extremely
popular, reaching a market evaluation of 55 billion dollars in its heyday, before being
battered by stiff competition by Apple and Android [1, 2].
6. Between 2000 and 2006, vendors started to innovate in terms of the aesthetics of the
phone. In this duration, different vendors tweaked with the various screen sizes,
touchscreen vs basic, different hard keyboards, screen resolution, etc. but core
hardware specifications and general aesthetics were not vastly different [1, 2].
7. Symbian, Blackberry and Palm OS were the most popular operating systems between
2000 and 2006 [1, 2].
8. In 2007, Apple launched its first release of iPhone, essentially putting multimedia and
the basic applications of work (email, web browsing, etc.) into one platform. The trend
exploded [1, 2].
9. Google entered the market with its own operating system called Android. While Apple
followed a closed-‐model approach to its iOS platform, Google followed an open, free-‐
for-‐all approach with Android. The Android codebase is open-‐source and anyone is
allowed to use their OS [1].
10. Let’s fast forward again -‐ yes again -‐ to 2012. iOS and Android as platforms are
dominating on the smartphone market. The wide adoption of Android by Samsung and
HTC has increased their market share to astounding levels [1].
You may notice at point 9 that the smartphone market has come to be dominated by
software giants, their bread-‐and-‐butter being in software. And what about the companies,
which pioneered smartphones in the 1990s and 2000s? Well, there is an interesting story to
it. Some are battered by the stiff competition from Apple and Google, and some have
become non-‐existent. Blackberry is facing a tough time turning around its business. Nokia
sold its mobile division to Microsoft which itself is facing a shrinking market share of its
Windows Phone platform. The platform leaders today are iOS and Android.
4.2 VARIATION IN SMARTPHONES
If you read the section above, between the lines, you could notice a new emergence of
problems, which software developers have come to face. Between 2000 and 2006, vendors
started tweaking with different screens, keyboards, UI layouts, and the additional components
available on phones like camera, sensors, Bluetooth, etc. There’s one permutation right there.
The other permutation is the plethora of smartphone platforms that are available today; each
platform touting over the competition with its ease of use and development. Even in the
growth stages of smartphones, there were many platforms present: Windows Phone,
Blackberry OS, Symbian, Palm, etc. Now it is iOS, Android, Windows Phone, Tizen, Ubuntu OS,
Firefox OS, variants of Android like Cyanogen and Blackberry.
Tablets have added an interesting twist to the mix. They use the same OS used in smartphones
but do not have the hardware capability of making phone calls (that is changing with wide VoIP
adoption with high WiFi availability). They are much bigger in screen size and some tablets do
not have the same components available on a smartphone.
I am sure as you read this, you are breaking sweat. You may wonder how do I build an
application for all these platforms and maintain the same look-‐and-‐feel on a 10 inch screen
versus a 4 inch screen versus a 7 inch screen and you may also wonder, what if I build an
application that uses component x but it is not available on certain devices? Unfortunately
some of the onus still lies on the software developer but others have done some of the hard
work; developers who write code to abstract the details of hardware differences so other
developers can write and build software, which has the same look-‐and-‐feel across all platforms.
The name given to this idea is Hybrid Application Framework. This will be discussed in further
detail in a later section but first let’s dive into the mobile platforms available today in the
market.
4.3 PLATFORMS
As of end of 2014, Android holds a majority in the smartphone market (at around 80%)
followed by iOS at 14%, followed by Windows at 2.7%, followed by Blackberry at 0.6%
(Windows and Blackberry will not be discussed). Therefore, it makes sense to follow the next
set of discussions in descending order of market share. The sections below will introduce these
platforms [3, 4].
4.3.1 Android
While most people associate Android with Google, which is true as Google is the primary
contributor to the project; however, the Android project was not started by Google as some
people may think it did. In 2003, 4 technology experts started the Android project: Andy Rubin,
Rich Miner, Rick Sears and Chris White. Their intention was have a system run on cameras such
that it could access computer services. They soon realized that there is not enough demand for
computer cameras so they switched their focus to cellphones.
In 2005, Google quietly purchased the company for 50 million dollars, quiet enough such that
people assumed that Google started the Android project. People realized that this is Google’s
entrance into the mobile market and making their strengths -‐ search engines, email, etc. –
available on cellphones. In 2007, Google established the OHA, Open Handset Alliance, an
alliance of 34 companies with a single vision to create an open standard for cellphones.
Growth of Android platform has been exponential since its introduction. Today, it commands a
market share of 80%, running over smartphones of multiple handset manufacturers. An author
claims that we are currently in the Android era, the platform has permeated into every device
imaginable: cameras, washing machines, refrigerators, etc. [5].
Let’s discuss briefly the architecture of Android.
4.3.1.1 Architecture
Figure 1: Android Architecture [6]
At the bottom of the architecture is the Linux kernel. In addition, drivers for various
components like camera, gyroscope, Bluetooth, also reside in this layer. The Linux kernel
version used in Android 5 is 3.4.x [7, 8].
The layer above Linux kernel is the HAL and the Android Runtime layer. The HAL – Hardware
Abstraction Layer -‐ contains data structures, which essentially abstracts the technicalities of the
hardware and provides a clean user interface to the layer above. It, in other words, tells the
hardware what to do. On the same level is the Android runtime. It contains some core libraries
for Java application developers but the component of interest here is the Dalvik Virtual
Machine. It is a Java Virtual Machine specifically built to run Java-‐programmed applications on
Android. The Dalvik virtual machine makes use of memory management capabilities and
concurrency available in core Linux kernel and simplifies the complexities to the application
developer, similar to what is built in core Java [7].
The Native Libraries layer contains libraries, which allow the application developer to write
performance or timing critical code for an application, which cannot be achieved by the Java
libraries. For example, a VoIP applications’ voice streaming part of the application would be
implemented using the native libraries. From the picture shown above, SQLite, SSL, OpenGL and
other interfaces and libraries are present in this layer [7].
The Application Framework layer contains Java classes, which provide higher-‐level services to
the application developer. Some of the popular classes offered in this layer are Notification
Manager and Package Manager [7].
Application Layer contains applications on the smart phone. Application type would include
Clock, Browser, Alarm, Contacts book, etc.
4.3.1.2 Wide adoption
Why is Android so popular? Let’s go back to 1990s. During the personal computer boom of the
1990s, Microsoft allowed any manufacturer to use its operating system, paving way for wide
adoption of the personal computer. This stopped Apple from gaining any significant market
share as Apple believed in selling the operating system and the computer as one unit, and they
still do.
Google adopted a similar strategy to the Android operating system. By establishing the OHA,
they allowed any mobile device manufacturer to pick up the Android operating system and use
on their device for free. The major difference between Google’s strategy and Microsoft’s
strategy with Windows is that Google made the Android source code available for free. This
allows any company to tweak the operating system to run on their device. In addition, Google
has placed their top services like Gmail, Google Now and Google Maps into the Android
platform. What else could a device manufacturer ask for? They just need to focus on building
top notch hardware for their devices and have essentially decoupled themselves from
developing an operating system which many companies do not have the Android platform
other than making sure that the hardware integrates with the software, this being Android.
This strategy has allowed Google and hardware manufacturers to reap huge benefits. The
revenue and profit generator for hardware manufacturer is the sale of their devices while
Google’s revenue generator are the applications -‐ colloquially called “apps” -‐ sold on Google
Play and advertisements shown in applications which uses the Google Ads API.
4.3.2 Apple iOS
When Apple launched iOS in 2007, it wasn’t called iOS. Actually, Apple did not give a name to
the new operating system. When they launched a Software Development Kit later, they
referred to the operating system as iPhone OS. The launch did not contain any third-‐party
applications. In a subsequent launch in 2008, they enabled 3rd party applications to run on
iPhones.
In 2010, Apple used the term iOS to officially name its operating system. They had borrowed
the trademark of the name iOS from Cisco. Subsequent launches of the iOS platform included a
voice-‐activated assistant called Siri – iris read backwards; as well as new applications to
compete with the Google Android ecosystem. Apple also switched their user interface to a
flatter look compared to earlier releases of iOS
Currently iOS runs on iPhone (smartphone) and iPad (tablet) product lines, similar to how
Android runs on smartphones and tablets. The latest release of smartphone is named iPhone 6
and 6S. The iPhone 6 is a smaller screen sized phone while the iPhone 6S boasts a screen size of
5.5 inch [10].
4.3.2.1 Architecture
The architecture of iOS is similar yet different from Android architecture. There are 4 layers to
the iOS platform.
Figure 2: Layers of iOS (from Apple Inc)
The Cocoa Touch layers contains libraries – or in Apple speak, frameworks – which allows you
to design the layout of your application. It also provides for key technologies like concurrency,
touch capability, push notification services as well as other high-‐level system services [11].
The Media layer contains libraries for graphics, video and audio. These libraries work seamlessly
with the Cocoa Touch layer. The audio library encompasses anything related to sound. It
handles built-‐in sound as well as playing audio files in iTunes or any other application. The audio
library supports popular industry standard audio files as well as Apple specific audio file
extensions. Similarly the video library has the ability to play, stop and pause video files. The
video library also supports industry standard and Apple specific file extensions and format. The
graphics library allows an application developer to push out custom images and files on a
standard view or a custom view. The library also bundles OpenGL to provide powerful two and
three-‐dimensional rendering to images [11].
The Core Services layer contains libraries and API to support core backend functionality of the
application. Services including a networking stack, location awareness, iCloud integration, local
database, in-‐app purchases, advertisement support and many more [12].
The language of writing code is Objective-‐C and recently, Swift. Objective-‐C has taken the
standard C-‐language specification added its own syntactic sugar for object-‐oriented
programming. Swift is a new language by Apple and follows a very similar syntax to Objective-‐C
but also embraced some Java conventions into the language to make programming easier as
most developers are comfortable with the Java/C++ style syntax of object period method
argument.
4.3.2.2 iPhone 6 is the best-‐selling smartphone!
In the last quarter of 2014, Apple sold a whopping 74.8 million iPhones making it the top selling
device in the smartphone market and increasing their market share to close to 20%. What is
making iPhone the top selling device? While many people prefer the openness offered by
Android, there is a market segment, which prefers a very tight integration with hardware
components and the software sitting on top of those hardware components. In the end, you
have a seamless integration of services with very little user intervention. When there are so
many iPhones hopping around in public, the platform it runs does deserve equal recognition
along with the stunning hardware specifications; iOS stands as the 2nd most popular platform in
the smartphone market today [13].
4.4 HYBRID APPLICATION FRAMEWORKS
As seen in section 4.2, there are huge variations in the type of devices available on the market.
Developers noticed this and decided to solve this problem. They introduced a device
abstraction layer – we will call it DAL -‐ and provided an interface where the application
developer does not know where the application will run or maybe be unsure of what his
intended target platform is. The developer cooks up a quick application independent of the
platform and tests it. When it is finally time to build the application for the intended platform,
he selects the platform and deploys it. The application looks exactly as what was intended. He
or she then decides to run the application on a friend’s phone, which is on a different platform,
and the look-‐and-‐feel is similar to what he or she had seen on his or her phone. “Wow!” the
developer proclaims and jumps in joy and is excited that a lot of time and money has been
saved.
Hybrid Application Frameworks come in multiple flavors: web-‐based approach, widget toolkit-‐
based approach and 3rd, a cross compiler based approach. The 3rd approach is often
contentious such that some experts prefer to place it in its own class but we have placed this
under hybrid application frameworks partly because it serves the same goal as the web-‐based
approach and the widget-‐toolkit-‐based approach; single development environment but
multiple application output. We would like to create an abbreviation for it; DOOM, develop
once, output many. Below we will explain how each flavor works [14].
4.4.1 Web-‐based approach
In this flavor or model, the application developer writes very web-‐centric code with calls to the
native library using the JavaScript APIs. The developer uses current web languages like CSS,
HTML and JavaScript to build the User Interface. When the application needs to access the
component, it makes a “request” – similar to requests handled by backend servers -‐ to the
native code, done using JavaScript Bridge. The native code processes the request and sends the
result back to the User Interface. The behaviors of these frameworks are very similar to how
REST-‐like applications behave, except that the User Interface part and the native code part
reside in the same application package. See diagram below [14].
Figure 3: Hybrid Application Framework: web-‐based model [14]
The JavaScript block in the diagram makes a request to the native block using the bridge. The
native code block is analogous to a daemon and it accepts requests with URL parameters,
processes them based on the URL passed and send the response back to the User Interface.
Both share some memory and disk for message passing. Since the User Interface is built using
current web technologies, the front end of an application is a thin shell browser, which has the
ability of displaying web pages. This object is known as WebView.
4.4.2 Widget toolkit – based approach
The above model does not give a native feel to the application and could look like a small
website running on the front end. Some developers may not have a warm feeling towards that
approach and prefer that each application have a bit of a native feel to it. Example: an
application running on Android looks like an Android application.
What some developers have decided is to abstract the User Interface and device API from the
application developer. In our previous model, the User Interface was not abstracted and
depended heavily on web. In this model, the framework has a generic User Interface API as well
as a generic Device component API [14].
During compilation, based on the platform you intend to build for, the native libraries for that
platform will be picked along with the proxy-‐like abstraction layer. The front end is still written
in JavaScript. Abstraction Layer has deep knowledge of JavaScript as a language and knows how
to generate source code for the intended platform when required. The application developer
will use the User Interface API, provided in JavaScript to place User Interface objects into its
view. In the previous case of Web-‐based model, the User Interface objects are completely
dependent on HTML, CSS and JavaScript. See diagram below [14].
Figure 4: Hybrid Application Framework -‐ Widget toolkit-‐based model [14]
4.4.3 Cross-‐compiler approach
What if you are a rock star developer but you are just not familiar with the various web
technologies? HTML, CSS and JavaScript is just too mind-‐boggling for you? Well, there is a
solution for that too. In this approach, an application developer chooses a language which she
or he is comfortable with (C#, Java, C++, etc.) and then writes an application using that
language, typically using the language constructs for creating the front and the hardware
component end of the application. There are some frameworks that don’t even use everyday
programming language and have their own language. Essentially, these languages are domain-‐
specific languages, languages that can only apply in that context [14].
The application developer writes his intended model in a domain specific language (depending
on the framework, it could our everyday programming language like C#, Java, etc.). During build
time, a code generator will parse the domain specific language code, and generate source code
for the targeted platform. For Android platforms, code generator will generate Android
compatible Java source code and then the next step of the build process is to call the compiler
and packaging binaries bundled in platform SDKs to compile the generated source code. The
result of this process is an application that looks very native like and it maybe is very difficult for
the end user to recognize that the code used to build the application is generated. See the
diagram below for a detailed insight into the model [14].
Figure 5: Hybrid Application Framework: cross-‐compiler approach [14]
As you can see from the diagram above, there is a “cartridge” for each platform, which hooks
deeply into each platform’s SDK. When the code generator engine is run, based on the
characteristics of each cartridge, the source code is generated for each platform, and then the
generated source code is compiled using the compile tools available with each SDK [14].
5 BUSINESS CONTEXT
The sections discoursed a lot about the history of smartphones, diving into the hardware
variations available with smartphones and then discussed about the popular mobile platforms
of today. In between the lines, we propelled a problem, the problem of developing mobile
applications for all platforms and all hardware specifications available in the market today in a
limited amount of time with significant cost savings. That’s where hybrid application
frameworks fit in, as these frameworks abstract the details of the device to provide the
application developer one API set to develop their application on. Now, you might be scratching
your head about where does all this information fit in context? We hope that you won’t be
scratching your head any further as we will apply this information in a business context.
An e-‐commerce company approached us with a plight. The company’s growth has stalled and
they predict that revenues will shrink if they don’t act immediately. The company currently has
a website built using the OpenCart, an e-‐commerce solution, but they launched the website 10
years ago and haven’t made significant updates the website. Products sold on the website are
mostly hardware tools, for example hammers, wrenches, nuts, bolts, screwdrivers, etc.
Major stakeholders of the company brainstormed in multiple meetings and made those ideas
concrete. One idea proposed was to upgrade the OpenCart server application to the latest
version. After research done by the IT gurus of the company, they deemed the OpenCart
software upgrade as too risky and could shut down their only distribution channel, which is the
bread-‐and-‐butter of the company. The other idea proposed during various brainstorming
sessions is the expansion of channels of distribution of their products since the web solution
has become a bit of a cash cow for the company. On further discussions, they intend to target
active smartphone users which, they hope, will drive sales and bring in much needed new
sources of revenue. The IT gurus of the company are not experienced in the mobile space and
hence recommended to get an external firm to develop a mobile-‐based channel of distribution.
The company approached us with the idea of developing a mobile application for two popular
mobile platforms of today: Apple iOS and Google’s Android as these platforms, combined, claim
to own 96% of the smartphone market. Below is the list of requirements in further detail.
5.1 REQUIREMENTS
The company has the following set of requirements. Each requirement has detailed explanation
of why is it important to the company:
1. Their main purpose is to run the “same” application on Apple iOS and Android. The same
keyword means that when the application run on an iOS or Android-‐based platform, the User
Interface of the application should essentially look very similar. For example, if the iOS
application has 3 tab controllers, then the Android application should also have 3 tab
controllers. If one of the controllers has a table section on the Android application, then the
table should also exist on the iOS application. The company has given us some leeway on the
style of the widgets (button, scroll bars, tables, text fields), which appear on the view of the
application; they do not need to be the same. They do not have a strong preference. Either
the widgets could get a native platform look-‐and-‐feel or inherit the common look-‐and-‐feel
of widgets. The selection of Android and iOS to develop applications is an obvious choice.
These 2 platforms own 96% of the mobile operating system market share as mentioned in
the introduction of the platforms
2. In addition, they want the application to be GA (generally available) on Apple App Store and
Google Play store by the next financial quarter. This is another major requirement set by the
company. As mentioned in the business context section, they have recognized that they need
to act quickly in order to grow their sales and revenue otherwise they will end up being left
behind in an extremely competitive market. The company has provided some flexibility on
the timeframe of the application release. While ideally the company would like to release
the application at the beginning of next quarter, they can tolerate some slack in the release
timeline provided that the reasons for not releasing on time are valid. The company wants
the application to be extremely stable and will implement a multi-‐step procedure from
prototype to GA.
3. The mobile application will sell hardware tools, therefore they want the application to handle
all financial transactions as oppose to a centralized server handling financial transactions.
The reasons for this approach are simple. They do not want to be liable for any major data
breaches if it ever occurs. While security is paramount for any company, they do not have
the security expertise to tackle any data breaches if it ever occurs. In addition, if a hacker
could obtain credit card or debit card information unlawfully; the company may not have the
resources to tackle hackers and increase protection on their nodes. Instead when a third
party like Stripe or Paypal deals with financial transactions, sure they do charge a percentage
for each transactions, but they are also liable for any breaches if it every occurs. Sometimes
it is best to leave the complicated work to the experts of the field.
4. The business is constrained in terms of time and money. As mentioned earlier, revenue has
maxed out and the rate of growth has bottomed out. Other companies are eating away their
market share by the day and the company is in a bit of a panic mode, they haven’t declared
a “state of emergency” yet but are very concerned. They also realize that it may take a few
financial quarters to reap the benefits of their mobile application so they are very keen on
spending as little as possible. They also intend to “hack” and push out new features quickly.
In one conversation, they wanted a major feature in every release of the mobile application.
The selection of the development model and process moving forward is key to the company.
The company has repeatedly stressed that they are constrained in terms of time and money.
Hybrid application frameworks are the way to proceed. Developer needs to learn one set of API
rather than two and the developer needs to develop for one application instead of two. The
savings are immense. Developer will save time in training, implementing and when you save
time, you also save money as external companies work on a per hour basis.
We, as a company, have taken these requirements and now we are set to build criteria for
selecting a development model for the e-‐commerce company.
6 CRITERIA & EVALUATION METHODOLOGY
6.1 CRITERIA
In the section above, we mentioned we would proceed with hybrid application frameworks.
Now let’s build a criteria so we can help our customer can save even more time and money and
pick a hybrid application framework most suitable for the e-‐commerce company using these
criteria
1. Cost to obtain the application framework. The company has hinted that acquiring hybrid
application framework should not incur a significant recurring cost. They have a strong
preference towards freely available platforms.
2. Feature set of each hybrid application framework being evaluated and whether it conforms
to the requirements of the company. The following features will be targeted:
i. Platform support – while iOS and Android platforms are an absolute requirement,
support for other platforms (Windows, Blackberry OS, etc.) is a nice-‐to-‐have feature.
ii. Location awareness – access to the Global Positioning System (GPS) and ease of finding
out the smartphone's current location in addition to integration with leading mapping
systems (Google Maps, Bing Maps, Apple Maps etc.)
iii. Screen adaptability – Android and Apple smartphones have a variety of screen sizes and
if the framework is not adaptable with common screen sizes, it will be disqualified.
iv. Local database access – support for saving client specific data on the phone itself (like
credit card information and order details)
v. Communication support to backend services – RESTful or SOAP with JSON and XML as
payload? This feature will be used to obtain product listings from the backend server
while ordering of those items will be pushed to the backend server
vi. Notifications support – Once the item has been shipped, a notification with shipping
details could be pushed to the buyer's phone and it could also be used for deals on
hardware tools
vii. Globalization and Localization – how easy is it to integrate spoken languages (English,
French, German, etc.) into the app for different regions as well as geographic availability
of the application with the language of choice for that geographic location (French for
France, Belgium, Quebec; German for Germany and English for Commonwealth
countries, etc.)
3. Time and cost of developing an application using the hybrid application:
i. Ease of developing the application – how long does it take for the application to be
developed from scratch to prototype grade and then to as a marketable application. Does
it lie within the requirement of delivering the application to the end customer by next
quarter?
ii. Cost of development environment – numerous devices will have to be at the minimum
leased from sellers. In addition, to develop apps on iOS, they need to purchase a Mac
desktop or a MacBook
4. Performance measurement of the application built using selected framework: We have
deemed this as an important criterion because we do not want the application to be a
performance bottleneck on any of the smartphones available today. We will look at the
following parameters, listed in descending order of priority: memory usage, CPU usage,
network usage and disk usage after installation of the application. The lesser the value of the
parameters mentioned above, the more favorable the framework becomes.
6.2 EVALUATION METHODOLOGY
In the section above we discussed the general set of criteria. Let’s go a little deeper on how we
will evaluate the frameworks available on the market today and satisfy our criteria, which will in
turn satisfy the customer’s requirements.
To evaluate the frameworks in the market today, we will undertake a two-‐step approach: filter
first, analyze second.
6.2.1 Filter
The first step is to filter out “noisy” frameworks from our research pickings. Let’s define our
“noise” factor:
1. The company is tight on money. Therefore we have set the highest priority and tier on the
cost of obtaining the framework. Frameworks, which are open-‐source and free, will be
considered first. If there are no free and open-‐source frameworks, then an open-‐source
framework with developer support fee will be considered. If there are no frameworks in
this tier, then a commercial framework will be selected. This filter is similar to our 1st
criteria mentioned above. In addition, frameworks that have not been updated in the past 3
years will not be selected for next screening process.
2. Once we have obtained frameworks that satisfy the first filter, we will look at the feature
set of the hybrid application frameworks selected. Any framework which satisfies all the
features mentioned in our requirement will be selected go to the next step
6.2.2 Analyze
Now after applying the filter, we have a handful of frameworks. We will evaluate these
frameworks in the following way.
1. We will evaluate each feature for our selected hybrid application framework. Below
are sub points on how we will evaluate the feature as well as the factors that will
influence the score.
1. Each feature API on the hybrid application framework will be given a score
between 1 to 10, 10 being “easy to use” while 1 being “difficult to use”
2. In addition, each feature, independent of the framework, will be given a score of
between 1 to 4, 1 being “not important and 4 being marked as “crucial”.
3. The score from point 2 will be multiplied with the score obtained from point 1.
4. All the multiplied scores will be added for each feature. The hybrid application
framework with the higher score will win the game.
5. The following factors will be considered for evaluating step 1:
1. Lines of code (LOC) – how many lines of code is written to initialize and
activate the feature. The higher the lines of code, the
2. CPU, memory and network usage of each feature on the phone
3. Language variability – how many different languages are involved in
activating this feature. The lesser the language variability, the better.
7 INITIAL RESEARCH
As any company, we started our work by searching online and finding out what is available in
the market today. From our research online, we found these frameworks:
1. Xamarin, A C#-‐based hybrid application framework -‐ (http://www.xamarin.com)
2. PhoneGap, A HTML, CSS and JavaScript open-‐source hybrid application framework –
(http://www.phonegap.com)
3. Titanium, A free JavaScript, model-‐view-‐controller pattern based hybrid application
framework -‐ (http://www.appcelerator.com/titanium/)
4. MoSync, an open-‐source HTML, CSS, JavaScript, C/C++ based framework -‐
(http://www.mosync.com)
5. Emobc XML UI-‐layer only hybrid application framework -‐ (http://www.emobc.com/)
We applied our first filter on these frameworks in evaluation methodology. Recall that our first
filter is to pick frameworks that are freely available. While our hopes were dim and we had
expected to jump up to the next tier in the 1st filter (free to obtain but pay for framework
support). However, we were more pessimistic than we needed to be. We obtained 4 frameworks
from our research that matched the first tier of our first filter: Titanium, Xamarin, Emobc and
PhoneGap. When we did look at MoSync, the framework had not been updated for quite some
time and therefore MoSync was disqualified for the next round/filter.
Then we applied our second filter. All the features mentioned as requirements will have to be
met by the platform. Titanium and PhoneGap met these requirement but Xamarin and Emobc
did not meet it. Xamarin did provide a free version but it does not support all the features
required by the e-‐commerce company. The paid version, available at a cost of 83 dollars a month,
of Xamarin did provide an API set for all the features but since we did find free frameworks in our
previous filter, Xamarin was disqualified. Similarly when we researched about Emobc, the
framework contains a UI-‐only framework and does not provide access to any of the hardware
components (camera, accelerometer) on the phone. The developer would have to write hooks in
order to link the front end User Interface to the back end (native code which has access to these
hardware components).
What is left after applying these two filters: Titanium and PhoneGap. Now that we know our
target framework, a study will be carried and the 2nd, which is more critical, step of our evaluation
methodology will be applied to these frameworks. These frameworks contain all the features we
were looking for: location accessibility, storage, notifications service, network accessibility,
screen adaptability and integration with RESTful APIs
8 TITANIUM SDK & PHONEGAP SDK
In chapter 7, we had picked our two frameworks: Titanium and PhoneGap. Now, we will do a
deep dive into these two frameworks starting with a brief introduction of the two frameworks
followed by setup details
8.1 BRIEF INTRODUCTION
PhoneGap was started by a company called Nitobi, in Vancouver, in 2009 as a way to allow
native access to components through a web interface on the application. With this approach,
they were trying to “kill two birds with one stone”. The first stone being that application
developers do not need to know the inner details of the platform SDKs in order to build an
application. The other stone being is that web development is extremely popular and
leveraging that widely available skill in the market makes it easy for a web developer to build
applications for smartphones [16].
Adobe in 2011 purchased Nitobi. The main aim of this purchase is to extend the capability of
the framework to include Adobe’s flagship AIR and Flash product. Adobe is committed to keep
PhoneGap open source and contribute code to the Apache Software Foundation [16].
PhoneGap is built on Apache Cordova. Cordova provides a simple API to call JavaScript
functions that underneath contains hooks to the native code. Cordova provides a pre-‐built set
of plugins (act as bridge between JavaScript and native code for that component). In addition,
other developers can contribute to the Cordova plugin repository of custom-‐made plugins,
which in turn enhances Cordova and the PhoneGap library. If we refer to earlier sections about
the type of hybrid application framework, it falls under the web-‐based approach. The
mentioned section details how web-‐based hybrid application frameworks work [16].
Adobe is seeing a different future with Cordova. The library may become obsolete in name, as
functionality of camera access, location awareness and access of other hardware components
will be built into all browsers.
Jeff Haynie and Nolan Wright founded Appcelerator in 2006. They initially worked together to
provide business solutions. The SDK was a result of the numerous projects undertaken by
Appcelerator. They released the SDK as open-‐source. Their main revenue generator is: provide
support for its products, training and custom development [17].
Appcelerator has raised, in various venture capital funding rounds, close to 83 million dollars up
to date. The company is releasing new products using the Titanium SDK and entering the
market with data analytic platforms specifically targeting mobile applications.
Aim of Titanium SDK is to provide users with industry standard platform independent language
called TSS, JavaScript and XML. Titanium is built on the widget-‐toolkit based hybrid application
framework. The mentioned section above gives detailed description about how widget toolkit-‐
based hybrid application frameworks work.
8.2 SYSTEM REQUIREMENTS
In this section, we will discuss the system requirements that are common across both platforms
as well as system requirements of each hybrid application framework we selected.
8.2.1 General
In order to develop on the framework, these are the general system requirements:
• Any computer which can run Mac OS X with at least 8 GB
• Apple iPhone
• Any Android smartphone (preferably a popular one)
• Developer accounts on Google Play and Apple App Store
• Android SDK set up on the Mac OS X
• Oracle Java JDK
8.2.2 PhoneGap
In addition, PhoneGap requires Node.js installed on the Mac OS X.
8.2.3 Titanium
Titanium has their own IDE called Titanium Studio, which is built on top of Eclipse. The
installation of Oracle Java JDK should be sufficient in order to run Titanium Studio.
8.3 SETUP
Here, we will look at the setup steps for the 2 frameworks:
8.3.1 PhoneGap
Open a terminal command line application and type the following command: npm install –g
phonegap. This will start Node.js to pull the necessary files from its repository and install
phonegap on the machine. To create a project after installation is easy: phonegap create
<project name> [19].
PhoneGap is useless without plugins and platform selection. Therefore to add a platform, the
following command will set it up: cordova platform add <platform name>. The acceptable
parameterized name of platforms are: wp8 (Windows Phone 8), windows, amazon-‐fireos,
android, blackberry10, firefoxos. To add a plugin: cordova plugin add <reverse domain name of
plugin> [19]
Building a PhoneGap application is as simple as cordova build <platform>. Running the
application is as simple as cordova run <platform> [16].
The project folder structure of PhoneGap is shown in the figure next page. There are essentially
3 main folders in a PhoneGap project: platforms, plugins and www. The platform folder holds
platform specific source code for each platform. The plugin folder holds JavaScript bridge files
as well as the corresponding native code files. The www folder contains the main front-‐end
code. It contains the index.html file, JavaScript files, which have references to the JavaScript
Bridge, provided in PhoneGap as well as CSS file which contains the layout attributes of the
webpage.
Figure 6: PhoneGap project structure
The project contains a config.xml file under the various platforms folder under platform. This
configuration maps the JavaScript objects to Objective-‐C or Java objects. For example:
<feature name="Battery"> <param name="ios-package" value="CDVBattery" />
</feature> <feature name="Camera">
<param name="ios-package" value="CDVCamera" /> </feature>
This XML code will map to the Class names of the platform in the plugins folder. When the
builder will run, it will parse through the file so it knows which class files need to be picked up
before getting a successful build.
If we look at the JavaScript file available under the plugins folder, which is the bridge file, this is
the sample stub
• Open
/cygdrive/c/Users/tlukmanji/Contacts/pgkitchensink/plugins/org.apache.cordova.camer
a/www/Camera.js
• var args = [quality, destinationType, sourceType, targetWidth,
targetHeight, encodingType, mediaType, allowEdit,
correctOrientation, saveToPhotoAlbum, popoverOptions,
cameraDirection];
• exec(successCallback, errorCallback, "Camera", "takePicture",
args);
TakePicture method in CDVCamera is being called above by the exec method. If you see in the
line above, the keyword “Camera” will be mapped to the CDVCamera class in Objective. The
JavaScript bridge interface at CDVCamera.h header file has the following prototype declaration:
-(void)takePicture:(CDVInvokedUrlCommand*)command;
The exec function will send a URL with the arguments passed. The unmarshaller at the backend
of the application will map it to the correct function.
8.3.2 Titanium SDK
As mentioned in the system requirements, Titanium has its own IDE, which is fork of Eclipse
IDE. Since we have recommended getting a computer that can run Mac OS X, we downloaded a
.dmg installer and followed the instruction on the installer.
After the installation of Titanium, Android SDK root path needs to be set. ‘Preferences’ on
Titanium SDK is opened. The marked field below shows where the Android SDK path is set. If
the NDK were downloaded, then the setting the NDK would be helpful.
Figure 7: Titanium Studio Preferences Window
Below is the editor window of Titanium Studio. On the left panel, the "app" folder contains
JavaScript, TSS and some XML files that basically contain the user interface structure of the
application. The platform folder contains platform specific files. The plugins folder contains
code specific to each platform.
While it would have been ideal to go in depth into tying all the pieces of the project structure
into a formidable section, it was very difficult to find concrete information about Titanium SDK.
It is understandable, since Appcelerator, Titanium’s creator, intends to earn money through the
sale of support contracts. However, from a few sources, it is noted that Titanium follows a
model very similar to what is mentioned under section 4.4.2.
Figure 8: Titanium Studio project structure
9 EVALUATION OF PHONEGAP AND TITANIUM SDK
Now that we have covered have skimmed the surface of PhoneGap and Titanium SDK, we will
jump in to analyze and evaluate the code stubs, ease of using API, and the performance of each
feature to provide an evaluation score to our customer and provide them with tools to make
further decision. Let’s recap what features we will be evaluating (which is the customer
requirements of the application).
1. Location awareness
2. Screen adaptability
3. Local database access
4. Communication support to servers (REST)
5. Notification support (push notification)
6. Globalization and Localization
For each of these features, we will evaluate them by counting the lines of code to use the
feature, language variability and performance metrics. Both platforms have elaborate
documentation to allow developers to use their platform with API documentation for each
platform.
The way in which we quantify lines of code (LOC) is to first implement the feature on a sample
project and then count the lines of code required at the bare minimum. Performance metrics
were collected from an Android smartphone for Android applications and we used the iPhone
simulator to obtain performance statistics for each feature on the iOS-‐based application. While
we had intended to obtain performance numbers by running the application on a physical
iPhone but due to heavy restrictions placed by Apple in order to run the application, we were
unable to get obtain statistics from physical hardware. However, we believe that the
performance metrics obtained from the simulator will be a good base to further our reasoning
of the evaluation score we picked for each feature.
The method we obtained performance statistics is by first compiled the iOS application for
PhoneGap and Titanium, and then we ran the application on the iOS simulator. We gave it a
couple of minutes so that the application can settle down, no background task is running and all
components are initialized and ready to use. We then used each feature on both platforms for
about 5 to 8 times and then we noted the average value of CPU, memory, network and disk
usage. See Figure 8 on how performance metrics were recorded.
You may wonder how did we run the application on Xcode? During the application build in
PhoneGap and Titanium, the build process generates the Xcode project files as part of the build.
The Xcode project files were then opened in Xcode.
For the Android application, we were able to deploy the application on physical hardware. The
application was deployed on Google Nexus 4 phone. Using Android Studio’s monitoring tool,
which Google’s official IDE for Android development, we see the current running application on
the monitoring tool. In this case, we just started the application on the phone once it was
deployed. If you see from Figure 9, the performance statistics console popped up below is
marked with a blue box.
Figure 9: Performance metrics measurements for iOS application
Figure 10: Performance metrics measurement for Android application
9.1 FEATURE IMPORTANCE RANKING
In our evaluation methodology, we mentioned that we would use a 4-‐step importance ranking
of our feature. The “very important feature” will get a rank of 4 and the “least important” one
will get a rank of 1. Below is a table of data denoting the feature and the rank or multiplier for
each feature:
Feature name Importance
Rank (1 to 4) Reasoning for rating
Location
awareness 1
It’s a nice-‐to-‐have feature. The location awareness feature
would be beneficial in filtering products based on where the
request was being made but there are also other methods of
doing this (Example: a drop-‐down list for the county and city)
Screen
adaptability 4
We expect customers to run their application on all sorts of
hardware platforms with different screen sizes and different
resolution, therefore screen adaptability of the application is
extremely crucial for a well-‐functioning application
Local storage 3
We may need to save personal financial transactions and
some account details of each customer, therefore the
application will need to save this data locally on the phone as
we believe that it is important.
Communication
support (REST) 4
Most of the product information will lie on a centralized
server. Therefore this is key to a well-‐functioning application
as if there is no REST API or communication to server
availability, we may not be able to retrieve data and our
application will be pointless.
Notification
support 2
Typically the company would use notifications to send deals
to customers about various products. It is not very important
because there are other methods of generating notifications
like sending an email
Globalization &
Localization 2
Currency and language support is not very important
because the application will launch in countries where
English is the official language or it is the language of
business. There is not a hard requirement of providing
application in multiple languages.
To recap again, we will use these values as multipliers to ratings we provide to each feature.
Now that we have completed importance rankings for the features, we will now discuss the
rating for each feature.
9.2 FEATURE RATINGS
The bar chart below shows the rating of features. In section below, we have provided an
illustration of ratings. We will further discuss the ratings we reached in each section
Figure 11: Bar chart of feature ratings
9.2.1 Location awareness
Platform PhoneGap Titanium
Lines of code 191 302
iOS Android iOS Android
CPU usage 6 – 8% 11 – 20% 1 – 2% 11 -‐ 15%
Memory usage 2.8MB 1.6 MB 1.8 MB 2 MB
Disk usage 36 KB 32 KB 43 KB 30 KB
Network usage aggregate 6.3 KB 4.4 KB 2.1 KB 4.3 KB
Rating 7.5 8
0
2
4
6
8
10
12
Location awareness
Screen Adaptability
Local Database Access
Communication Support (REST
API)
Notification Support (Push Notification)
Globalization and Localization
Average rating of features
PhoneGap Titanium SDK
We ended up with a rating of 7 for PhoneGap while Titanium deserved a rating of 8 because the
CPU usage and memory usage in PhoneGap is much higher compared to Titanium. However,
the number of lines of code to write is much less in PhoneGap compared to Titanium. Therefore
you can see that it is a tight race of ratings between Titanium and PhoneGap. As mentioned
earlier, Titanium compiles all code to native platform code and you can see the benefit as it
uses much less CPU and memory compared to PhoneGap. Network bandwidth was used in both
platforms, as it is needed to convert longitude and latitude values to a more meaningful
location (a restaurant or a famous landmark).
9.2.2 Screen adaptability
iOS Platform PhoneGap Titanium
Lines of code 53 77
CPU usage -‐ -‐
Memory usage -‐ -‐
Disk usage -‐ -‐
Network usage aggregate -‐ -‐
Rating 10 6
In Titanium, there are various class methods that have to be called in order to place the
relevant dimensions in the appropriate hardware platform (phablet, phone or tablet). This can
be very cumbersome the application designer.
On the other hand, PhoneGap does not require the same level of fine-‐grain tuning for various
screens as it is already handled by the WebView component of the application. Therefore,
PhoneGap deserves a 10 while Titanium gets a 6.
It is important to note here that there are no performance statistics in the table above. The
reason being the fact that screen adaptability is a very static feature of a smartphone. Most
users will seldom change the orientation of the smartphone and hence it does not require
additional investigation. The key point here is we ran the application on different iPhones, they
all adapted well to the code.
9.2.3 Local database
Platform PhoneGap Titanium
Lines of code 182 209
iOS Android iOS Android
CPU usage 7 – 10% 3 – 7% 1 – 2% 3 – 7%
Memory usage 1.2 MB 0.8 MB 0.8 MB 0.7 MB
Disk usage 0.3 MB 0.3 MB 0.4 MB 0.2 MB
Network usage aggregate -‐ -‐ -‐ -‐
Rating 7.5 8.5
You can see the rating applied to PhoneGap is 7.5. The reason is because even though the lines
of code in PhoneGap are less, the CPU and memory usage is much higher when tables are
created on the phone.
Titanium uses more lines of code but the interesting thing to note is that Titanium on Android
used the same amount of CPU as PhoneGap on Android. This could hint towards a low
performing SQLite database inside Android compared to iOS.
9.2.4 Communication support (REST)
Platform PhoneGap Titanium
Lines of code 239 335
iOS Android iOS Android
CPU usage 2 – 5% 1 – 6% 1 – 4% 1 – 4%
Memory usage 1.5 MB 2.7 MB 2 MB 1.09 MB
Disk usage 2.3 MB 2.3 MB 3 MB 3 MB
Network usage aggregate 0.27 MB 0.26 MB 0.17 MB 0.17 MB
Rating 8.5 7
We tested this functionality by obtaining JSON and XML data from a server and we also tested
by downloading images from a server. PhoneGap requires much less lines of code to implement
the feature while Titanium requires one hundred additional lines of code to implement the
same capability. Titanium gains some points on the reduced network usage by executing the
same test.
However, we believe that the reduced lines of code on PhoneGap will help developers greatly.
Therefore, PhoneGap get 8.5 while Titanium gets 7.
9.2.5 Notification Support
Platform PhoneGap Titanium
Lines of code 162 123
iOS Android iOS Android
CPU usage 1 – 4% 0.9 -‐ 2% 1 – 2% 0.5 – 2%
Memory usage 0.1 MB 0.83 MB 0.13 MB 0.5 MB
Disk usage 76 KB 137 KB 93 KB 77 KB
Network usage aggregate 11 KB 12.2 KB 9.4 KB 8 KB
Rating 4 8
The usage of CPU is more on PhoneGap compared to Titanium for both platforms. The network
usage on PhoneGap is much more than Titanium. The lines of code required for notification
service is also much higher than Titanium. Therefore Titanium gets the higher score compared
to PhoneGap. The notification service provided by PhoneGap is subpar to Titanium. PhoneGap
only supports notifications like beeps and buzzers but Titanium supports a fully-‐fledged
notification service, which is on par of native platforms.
9.2.6 Globalization & Localization
Platform PhoneGap Titanium
Lines of code 173 21
Rating 6 10
To handle strings of different languages required in User Interface in PhoneGap, you have to
specify the files with a path name for each language but in Titanium, you just need to specify
the type of language the strings are for and add to a JavaScript file. It’s extremely easy to use
therefore we have given Titanium a full rating compared to PhoneGap. The additional lines of
code required to setup a proper globalization environment has led to PhoneGap taking a
beating on its rating.
9.3 DECISION MAKING
PhoneGap Titanium PhoneGap Titanium
Feature Importance multiplier Rating Rating Score Score
Location awareness 1 7.5 8 7.5 8
Screen adaptability 4 10 6 40 24
Local storage 3 7.5 8.5 22.5 25.5
Communication support (REST)
4 8.5 7 34 28
Notification support 2 4 8 8 16
Globalization & Localization 2 6 10 12 20
TOTAL 124 121.5
Let’s discuss what we did above. We generated multiplier factors from above along with the
ratings for each feature. We multiplied the importance factor with the rating for each feature
to get a weighted score. The weighted score was then added to a sum value. As we discussed
earlier, the larger sum of the two will win the race.
Therefore, from the table above, we see that PhoneGap has taken lead after going through
various rounds of evaluations. The reason being that PhoneGap is easy to use and its easiness
overcomes some of the performance impacts of the framework. The reason for the higher
performance requirements is due to the fact that PhoneGap is a web-‐based model hybrid
application framework. In the sections discussed earlier, we learnt that PhoneGap does not
compile all its code into a native platform format. Instead, it compiles the Objective-‐C or Java
files into its platform and the front end JavaScript, HTML, CSS files are left as it is. The WebView
object is a thin programmable browser; is bundled with the other native code objects and
hence display the application by parsing the JavaScript, HTML and CSS files. Today’s
smartphones are built with extraordinary amounts of RAM and CPU power such that they are
capable of running games on it. A bit of extra resource usage in exchange of faster development
is always preferred. That’s why languages like Java and scripted languages have become
popular. People were willing to take a bit of hit in resource usage for much better programming
ability or in other words, improvement in G factor. The faith in Moore’s Law that the numbers
of transistors will double every 18 months (this is contentious, some highlight it as one year,
other say it is 2 years) and that has kept the trend upwards towards an easier development
language to use and take acceptable hits in resource usage and performance.
Titanium was not too far behind PhoneGap. It was behind by 3 points, which also shows the
power of its framework. Unfortunately, there is no cross compatibility between the frameworks
as they are built using completely different technologies, but it if did exist, developers could
interchange between Titanium and PhoneGap, maximizing the best of both worlds. Titanium
framework is very strong in its usage of system resources; the SDK compiles all code to native
assembly code for that specific platform as seen in earlier sections about hybrid application
frameworks.
10 CONCLUSION
Developers have been working tirelessly to make other developers’ job much easier. We have found
today that the single most concern of mobile application developer is the permutations of hardware and
mobile platforms is driving them crazy, to the point of pulling their hair. Other developers have partially
solved the problem by developing a device abstraction layer called hybrid application frameworks.
Hybrid application frameworks allow you write an application in one set of languages that may be
completely independent of the platform itself but the resulting compiler, builder and packager will
create multiple applications, each for a platform.
The report first converses about smartphones and the history of it before diving into the details of
today’s mobile platforms of iOS and Android. Both platforms have a similar architecture. Android is a
Linux-‐based platform while iOS is Unix-‐based on OS which they spun off from Mac OS X. Android
provides its SDK in Java and its NDK in C++ and C. The advantage of this approach is to provide a simpler
language (Java) for most applications but time critical applications can also write their application using
the NDK. Android application can also be a hybrid of both; most portions of the application would be
written in Java and then a portion of application code use the Java Native Interface Bridge to hook into
the C++ layer for time sensitive features of the application that cannot be met by the Android SDK.
Apple iOS SDK is primarily in Objective-‐C and their new language called Swift. Since Objective-‐C is
compiled directly to native assembly code, there is no byte code interpreter as oppose to in Android
where the Dalvik Virtual Machine runs the Java byte code interpreter.
Hybrid application frameworks behave like a device abstraction layer – DAL – and use the iOS and
Android SDKs and NDKs and acts like the man-‐in-‐the-‐middle in application development. This results in
the application developer not knowing anything about the underlying platform and just programming
using one common API. There are 3 models: web-‐based, widget toolkit-‐based and cross-‐compiler-‐based.
An e-‐commerce company, with hair on their hands, approached us to advise them on how to proceed
with developing a mobile application. They sell hardware tools like wrenches, nuts and bolts currently
on OpenCart but the OpenCart version they have is 10 years and it is in dire need of an upgrade but they
have deemed it too risky as it could affect the schema of the database and they could lose critical
information. Instead, they have decided to build a mobile application and this is open another channel
of distribution. The company came armed with a small but strong set of requirements. Criteria and
evaluation methodology was built out of the requirements
There were 5 frameworks selected for initial consideration but 3 of them did not pass the “filter” step of
our evaluation methodology. We were left with two frameworks: PhoneGap SDK and Titanium SDK.
PhoneGap was started by a Canadian company called Nitobi and purchased by Adobe in 2011. Its API set
is provided in JavaScript but the user is expected to know HTML and CSS, as the front UI end is very
webpage-‐like. Titanium SDK was created by Appcelerator and born as a result of the numerous projects
they had worked on. The company started in 2006 by two founders.
Both frameworks have very similar system requirements. The primary reason for selecting a computer
that runs Mac OS X operating system is due to the fact that the iOS application has to run on an iOS
based device. PhoneGap does provide a cloud service to build mobile applications but it has a cost of
9.99 dollars per month at the minimum. After analyzing the two frameworks based on location
awareness, globalization and localization, screen adaptability, notifications, communication to REST
servers and local data access, we decided that the “winner” of the evaluation phase is PhoneGap.
PhoneGap wins because of its ease of use and while it does use more system resources, the delta
between PhoneGap resource usage and Titanium SDK resource usage is not vast.
11 FINAL REMARKS
Thank you for offering us, Shahzeb Khowaja and Taha Lukmanji, the opportunity to work on an exciting
project. While researching on hybrid application frameworks, we found that the power these
frameworks harness are immense and the ability to cut time significantly will direct the focus of more
developers to further build the framework and gain even more audience of these frameworks. If we
ever do build a mobile application, this area will be followed very closely and used.
Enjoy your sabbatical!
12 REFERENCES
1. Pocketnow: The evolution of the smartphone, 11th April, 2015
http://pocketnow.com/2014/07/28/the-‐evolution-‐of-‐the-‐smartphone#!prettyPhoto
2. CBC Canada: 5 major moments in cellphone history, 11th April, 2015
http://www.cbc.ca/news/technology/5-‐major-‐moments-‐in-‐cellphone-‐history-‐1.1407352
3. Statista: Global market share held by the leading smartphone operating systems in sales to end
users from 1st quarter 2009 to 4th quarter 2013, 12th April, 2015
http://www.statista.com/statistics/266136/global-‐market-‐share-‐held-‐by-‐smartphone-‐operating-‐
systems/
4. http://www.idc.com/getdoc.jsp?containerId=prUS25450615 [market share]
5. http://www.ipwatchdog.com/2014/11/26/a-‐brief-‐history-‐of-‐googles-‐android-‐operating-‐
system/id=52285/
6. Picture android: http://source.android.com/source/index.html
7. Android Architecture, 12th April 2015,
http://www.tutorialspoint.com/android/android_architecture.htm
8. Redmi 1S updated to Android 5.1 Lollipop with unofficial CyanogenMod 12.1 ROM, 12th April 2015,
http://www.ibtimes.co.uk/redmi-‐1s-‐updated-‐android-‐5-‐1-‐lollipop-‐unofficial-‐cyanogenmod-‐12-‐1-‐
rom-‐how-‐1495905
9. Google's Android has generated just $550m since 2008, figures suggest, 12th April 2015,
http://www.theguardian.com/technology/2012/mar/29/google-‐earns-‐more-‐iphone-‐android
10. Apple iOS: a brief history, 13th April 2015,
http://www.telegraph.co.uk/technology/apple/11068420/Apple-‐iOS-‐a-‐brief-‐history.html
11. About the iOS Technologies, 13th April 2015,
https://developer.apple.com/library/ios/documentation/Miscellaneous/Conceptual/iPhoneOSTech
Overview/Introduction/Introduction.html
12. Core Services Layer, 13th April 2015,
https://developer.apple.com/library/ios/documentation/Miscellaneous/Conceptual/iPhoneOSTech
Overview/CoreServicesLayer/CoreServicesLayer.html#//apple_ref/doc/uid/TP40007898-‐CH10-‐SW5
13. Apples iPhone is back to being the world's top selling smartphone, 13th April 2015,
http://money.cnn.com/2015/03/03/technology/mobile/apple-‐iphone-‐top-‐smartphone/
14. Overview | Cross-‐Platform Mobile Development, 14th April 2015, http://cross-‐
platform.mobi/documents/01-‐overview/01-‐introduction.html
15. The Last Word on Cordova and PhoneGap | The Official Ionic Blog, 14th April 2015,
http://blog.ionic.io/what-‐is-‐cordova-‐phonegap/
16. Adobe Announces Agreement to Acquire Nitobi, Creator of PhoneGap, 15th April 2015,
http://www.adobe.com/aboutadobe/pressroom/pressreleases/201110/AdobeAcquiresNitobi.html
17. Startup Of The Week: Appcelerator Promises Faster RIA Development, 15th April 2015,
http://www.informationweek.com/startup-‐of-‐the-‐week-‐appcelerator-‐promises-‐faster-‐ria-‐
development/d/d-‐id/1063165?
18. Appcelerator | CrunchBase, 15th April 2015,
https://www.crunchbase.com/organization/appcelerator
19. PhoneGap | Install PhoneGap, 16th April 2015, http://phonegap.com/install/