Developing for Android Erik Nykl Abstract
Download 27.91 Kb.
|
- Navigate this page:
- History of Mobile Computing
- Why Develop for Android
- Mobile Software Development Process
- Writing Android Applications
- Laying down the Fundamentals
- Android SDK
| 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 ComputingMobile 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 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. 
Figure : 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 plug-ins 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 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 ProcessWhen 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 location-based 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 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 : 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. 
Figure : The iterations of "A hybrid method engineering approach" Writing Android ApplicationsSince 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%. Laying down the FundamentalsWhat 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.
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 : 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 [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 Directory: ~yangq -> CSSE411 -> csse411-materials csse411-materials -> Monte Carlo Tree Search in Board Game ai csse411-materials -> Multi-Core Software Development with Examples in C++ csse411-materials -> Web Security a Programmer’s Perspective csse411-materials -> Emotional Annotation of Text David Gallagher csse411-materials -> Christopher Pinski Department of Computer Science and Software Engineering csse411-materials -> Computer Science / Software Engineering uw-platteville csse411-materials -> Security of Mobile Devices Lon Kastenson Abstract csse411-materials -> Spyware, Malware, and Viruses Anthony Bosnak Department of Computer Science & Software Engineering University of Wisconsin – Platteville csse411-materials -> Personal Computing: Past, Present, and Future Michael Wills csse411-materials -> Virtual Reality (VR) Kyle Maitland Department of Computer Science University of Wisconsin Platteville Download 27.91 Kb. Share with your friends:
|