Download Android Development

Developing for Android
Erik Nykl
Abstract
The relatively new smart phone market has grown exponentially over the past few years with
new operating systems from Apple, Google (Android), Palm (WebOS), RIM (BlackberryOS),
and Nokia (Symbian). Google’s Android OS has easily been the fastest growing (~3% market
share in 2009 to 29% today) and is expected to maintain explosive growth for the foreseeable
future.
Developing applications for the Android OS could be a very worthwhile economic decision. Not
only has Google made the fastest growing OS but they also have the fastest growing App Store
(Android Market). Google has provided first class APIs and a great framework for developers to
get started. This paper will give the listener a solid introduction to developing for Android
platform.
History of Mobile Computing
Mobile computing has been around for many more years than one would realize. The first truly
mobile phone was released back in 1983 by Motorola. Someone holding a brick sized phone
with eight seven segment displays as the display could hardly see the potential of future devices.
Fast forwarding ten years we see mobile phones nearly half-size of the original, and the first
tablet computer is released. The Apple Newton was a pretty revolutionary idea, at least in
concept. In reality it was a terrible product. The battery life was poor, it came with only three
applications (Notes, Names, Dates), and had no support for other applications. It also had one
interesting feature that worked so poorly many people think Apple shouldn't even have added it:
hand writing recognition.
Throughout the 90's there was steady improvement in mobile phones and near the end of the
decade there was a big push for tablet computing. Bill Gates even said "within five years I
predict it (tablets) will be the most popular form of PC sold in America." In a small way he was
right, with smart phones exponentially increasing in sales each year since 2007. However it took
until the Apple iPad to propel tablets to success.
In the early 2000s there were some pretty big leaps made in mobile technology. In 2000 Nokia
released Symbian, currently the most popular cell phone OS in the world (not just limited to
[Type text]
[Type text]
2
smart phones). Of course with Bill Gates pushing Microsoft they released Windows CE Pocket
PC OS in 2001. Research in Motion (RIM) released the first BlackBerry in 2002, and during the
same year Palm released their Treo OS, which was the first mobile phone OS to allow third-party
applications.
Probably the biggest year in mobile history was 2007. In addition to huge technological
advances allowing phones like the Nokia N95, the first phone with WIFI, GPS, 3G, TV-Out, and
a 5MP camera, the Apple iPhone and the Open Handset Alliance were formed. The Apple
iPhone exploded on the mobile scene in 2007. It was the first touch-only phone and had a web
browser that could compete with desktop versions. Unfortunately iOS 1.0 didn't allow for third
party apps and developers had to wait another year.
Many companies saw the success of the iPhone and wanted to capitalize on the fast growing
smart phone market. Google got together with many other companies and developed an open
hardware and software platform for mobile computing. The OHA announced the Android OS,
an open source OS based upon the 2.6 Linux kernel.
Why Develop for Android?
The question arises "Why should I develop for Android versus a more established platform like
iOS?" Well, not only is Android the fastest growing mobile OS but it now holds the largest
market share of any smart phone OS. During the summer of 2010 nearly 200,000 Android
devices were activated every day. I predict in the long run Android will be the dominant smart
phone OS. The benefits of Android (like open source and open platform) are very appealing to
manufacturers. So much attention has been placed on Android and its platform that the
development cycle for new mobile CPUs and hardware is down to nearly six months.
[Type text]
[Type text]
3
Figure 1: Smart Phone OS market share; Android highlighted [2]
Furthermore development of Android applications can be done in nearly any desktop
environment, and cross platform development is encouraged. Android development is done in
the Java programming language. Google maintains an Eclipse plug-in (called ADT), but plugins are available for Netbeans as well. The Android SDK is available for Windows, Mac, and
Linux and it even allows development to be done without an IDE.
When comparing Android with iPhone development some clear advantages appear. Android has
a minimal $25 developer fee (required only if the developer wants to submit apps on the Android
Market; they can sell through their own means otherwise) versus a $99 fee for Apple (who only
allows apps to be sold through their app store). Android has a much less hostile attitude towards
developers than Apple as well. Apple takes a "guilty until proven innocent" methodology and
screens each app before allowing it on the store. Apple also has a very strict policy on
applications and application content and apps are quickly pulled for violations. Apple has also
been known to blacklist developers and engage in shady business practices such as blocking a
popular app from the store then releasing their own version integrated with the OS (Amazon
kindle e-reader and iBook). Furthermore, in order to properly do development for the iPhone a
Mac computer is basically required.
Android on the other hand is much easier on the developers. Google hasn't of yet removed any
apps so they could implement their own proprietary ones, and in fact they have spent a lot of
time recently decoupling their own apps from the OS (Ex. Google Maps). They also rely on
users to screen apps. Basically the developer sets a maturity level for the app and if someone
[Type text]
[Type text]
4
disagrees with it they can flag it for review. Unfortunately for developers in both worlds Apple
and Google take 30% of the sale price of each app sold on their stores.
Mobile Software Development Process
When we approach a new platform for software development we need to ask a couple tough
questions. How can we effectively and efficiently develop applications in this domain? Will our
traditional methods and processes work or will we have to invent new ones? Following this, we
need to take a look at whether the more traditional processes like Waterfall, RAD, Spiral, or
Incremental will work. Also the agile methods will need to be evaluated.
A few requirements that I think must be reinforced further in mobile development much more so
than a desktop environment are:
1) The application shall be easy to use
2) The application shall be responsive to the user and operating system
3) The application shall be delivered quickly to market
On a typical Android phone there are 4 hardware buttons. This is a far cry from a 106 key
keyboard or a seven button mouse. Furthermore the touch screen resolution is far less than what
can be achieved from a mouse. These factors must be taken into account for the design and
having a well laid out GUI will make or break your app.
The average person feels something is not responsive after 1-200 ms [3]. Even if your code has
award-winning efficiency the user can still think the app is garbage if it isn't very responsive. In
addition to making the app responsive for the user, the Android OS keeps an eye on your app as
well. If a hardware button press isn't handled within five seconds, a dialog asking the user to kill
the task or continue waiting will pop up. Nine out of ten times, as a user, I will kill the task and
I'm sure that is how most people operate also. In addition to the hardware button press event
there is another event called a broadcast that your app must respond to within ten seconds or face
the kill dialogue box [3].
Most mobile applications have a different purpose than traditional desktop applications. There
are new domains that most applications will fall into like content-based services and locationbased services [5]. There are also some new issues to deal with. Developers have dealt with
wireless communication like WiFi but the OS does a great job abstracting it away from the
program. On an Android phone however there is usually a WiFi and a 3G connection. 3G is
great because it allows super long range communications and users (at least Verizon users) can
have internet basically anywhere in the country. However, 3G is way slower than WiFi and the
user also has a limited amount of monthly data usage.
Another issue could be losing GPS signal for a location-dependent app. How can the app
recover? How about portability to a new OS version every year with significant updates every
three to six months? Google guarantees forward compatibility in their API so this is alleviated
[Type text]
[Type text]
5
somewhat, but by picking a higher API level you are restricting the user-base of your app. Apps
only show up in the market if the user's phone meets the API level of the app [3]. In addition to
new software updates every six months the hardware gets refreshed at nearly the same rate. Also
since Android has pretty loose specifications one phone might not have all the hardware that
another one does.
Possibly the biggest issue facing mobile applications is privacy. A GPS-enabled phone knows
more about you than just your credit card number. It knows your web browsing habits, where
you drive, where you sleep, and in the future the phone itself can be used to pay for items. Near
field communication is what is used in similar devices to quick-pay fobs you may have seen at a
gas station (wave the fob above the scanner to pay for the goods), and this is already being
integrated into phones. Google's Nexus S already has this implemented.
Vahid Rahimian and Raman Ramsin took a look at the mobile platform and tried to tackle some
of these problems by engineering a new software process for mobile development. While the
process itself (Figure 2: The iterations of "A hybrid method engineering approach") isn't that
ground-breaking it does lay a good fundamental structure down for mobile application
development.
[Type text]
[Type text]
6
Figure 2: The iterations of "A hybrid method engineering approach"
Writing Android Applications
Since Android apps are written in Java many developers are already ready to start producing
apps. There are a few differences between normal Java and Android's version. Dalvik is a
custom written JVM for Android with tons of optimizations for the Android environment [3].
Dalvik was originally written by Dan Bornstein and is now managed by Google. It uses its own
byte code that is different from Java byte code. It also uses its own library so no AWT or Swing
can be used in your applications. Dalvik is constantly being improved upon and as of Android
2.2 a JIT Compiler was added resulting in speed increases of up to 450%.
[Type text]
[Type text]
7
Laying down the Fundamentals
What is all needed to actually make an Android application? The Android SDK is actually all
you really need. The SDK itself can generate the correct files and folders framework so no IDE
is actually needed (that would be the non-recommended method of development). I tried to get
Eclipse to work but failed after two weeks of messing around with it, but fortunately the plug-in
for Netbeans worked the first try and that is what I used to do all my testing.
Android apps are compiled into a .apk file by the SDK and one apk file is considered one
application by Android.
"The Android operating system is a multi-user Linux system in which each
application is a different user. By default, the system assigns each application a
unique Linux user ID (the ID is used only by the system and is unknown to the
application). The system sets permissions for all the files in an application so that
only the user ID assigned to that application can access them. Each process has
its own virtual machine (VM), so an application's code runs in isolation from
other applications. By default, every application runs in its own Linux process.
Android starts the process when any of the application's components need to be
executed, then shuts down the process when it's no longer needed or when the
system must recover memory for other applications." [3]
Each application can contain a number of the four application components: Activities, Services,
Content providers, and Broadcast receivers. Activities can be thought of as a single user
interface. An app can have multiple activities but it will always have one main activity.
Services are what can be thought of as a Linux daemon or something that runs for long periods
without much user interaction. Content providers are things that provide data storage. A sqlite
database, the SD card file system, or some other "persistent storage location your application can
access" [3]. Broadcast receivers are components that respond to a system-wide broadcast such as
the screen turning off. Components are started by issuing Intents. An intent object is basically a
message defined to activate a specific component.
The AndroidManifest.xml file in the Android project specifies everything your app does. It
contains intents and application components your application will use. It also declares the
permissions, the libraries, and what the API level of the app is. Unfortunately this will definitely
need to be modified manually by the developer throughout the software's development cycle.
A good practice for Android apps is to spawn threads for things that will take a long time to load.
If initially loading your app takes a significant amount of time spawn a thread to load it and show
a splash screen until it is done. Another situation where threading should be used is pulling from
a database or downloading content off the internet. All the threading must be in place to keep
the user happy and the app responsive.
[Type text]
[Type text]
8
Android SDK
A developer must have a good idea of what is in the SDK. In addition to the normal Java
standard library type of things, there are many functions like ArrayCopy(...) that work much,
much faster than hand-rolled implementations. Furthermore, browsing the SDK libraries can
show you all the hardware that is accessible at the current API level.
The Android SDK also allows you to manage all the installed platforms and API versions
available for use. Pictured below is the SDK API manager.
Figure 3: Android SDK manager shown with all API revisions
Furthermore the SDK also allows you to create Android virtual devices (AVD) to test your apps
on. Pictured above shows two virtual devices available to test apps on. Below is the dialog to
create a new virtual device. Notice the resolution, SD card size, and what hardware is available
must all be set. This allows for a very customizable platform to test your apps on.
References
[1] (n.d.) Retrieved March 2011, from Android Development Community | Android Tutorials:
www.anddev.org
[Type text]
[Type text]
9
[2] Canalys. (2011, January 31). Press and Research Releases. Retrieved March 2011, from
Canalys - Expert analysis for the high-tech industry:
http://www.canalys.com/pr/2011/r2011013.html
[3] Google. (n.d.). Dev Guide. Retrieved March 2011, from Android Developers:
http://developer.android.com/index.html
[4] Murphy, M. L. (2010). Beginning Android 2. New York: Apress.
[5] "Designing an agile methodology for mobile software development: A hybrid method
engineering approach," Research Challenges in Information Science, 2008. RCIS 2008. Second
International Conference on , vol., no., pp.337-342, 3-6 June 2008
doi: 10.1109/RCIS.2008.4632123
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4632123&isnumber=4632084