Table of Contents Executive Summary 2
Download 471.88 Kb.
|
- Navigate this page:
- 2.4.1 Web Based Browsing Vs. Application Development
2.4 Android DevelopmentThe Android mobile operating system was developed by Android, Inc., a small company that was acquired by Google in 2005. Since its release of its official build in February of 2009 it has gained steady momentum in the smart phone market, recently ranking first in Unit sales of smart phone OS handsets sold in the U.S. at nearly 44%. Android has a large community of developers writing applications that extend the functionality of the devices. There are currently over 100,000 apps available for Android in the Android Market, the online app store run by Google. Developers write in the object-oriented Java Language, controlling the device via Google-developed Java libraries. The Android software development kit (hereafter referred to as the SDK) includes a comprehensive set of development tools including a debugger, libraries, a handset emulator, sample code, and tutorials. The most convenient development environment for Android is the Eclipse IDE, for which Android provides a plug-in called Android Development Tools (hereafter referred to as ADT) to create, build and debug Android applications as well as control attached android devices. Since the Android operating system runs on top of Java libraries and virtual machines, the first step involved in android development is downloading and installing the Java Development Kit from Sun Microsystems. This installs fundamental Java libraries and the Java Virtual Machine onto a user’s computer and allows for development in the user’s IDE of choice. Once the JDK is installed, the Android SDK must also be downloaded from http://developer.android.com. Upon the Initial execution of the SDK, all of the currently available versions of the Android OS in addition to drivers that allow for the debugging of Android projects on a remote device rather than in the included simulator will be downloaded and loaded into the SDK. Once the initial setup is complete, virtual android devices and can created from the “Virtual Devices” interface shown in 2.4 Figure 1 below. 
2.4 Figure 1: a screenshot of the Android SDK Manager, and the virtual device selection screen Once the Android SDK has been set up and the IDE of choice, Eclipse Classic 3.6.1, has been downloaded from http://www.eclipse.org/, the ADT must be downloaded through Eclipse’s “Install New Software” feature. Having done all of the above, the user is provided with several tools that aid in easily and intuitively creating and programming their own Android applications. From the most basic things such as creating a new android project through the provided wizard shown in 2.4 Figure 2 below, which allows the developer to easily specify several important features for a newly created project that are not provided initially in the Android SDK, to the automatic creation and updating of several important UI and value files, the Eclipse ADT is by far the most featured IDE for Android development. Since Android applications require several classes of the built in frame work to pass information and flow between different classes that the designer has created, it can be difficult to trace through an android project line by line like may be normally done with programming a typical java project. For this reason, the ADT provides a debugging tool called the log cat, which can be used to easily debug android applications. The logcat can be used similarly to System.out.print when trying to trace the evolution of a particular variable, to present the developer with system information on how the device is responding to other stimuli (such as a user’s touch), and also to present the user with any fatal bugs and memory leaks in addition to where they occur in the code similarly to how the stack trace does when exceptions are thrown in normal Java code. 
2.4 Figure 2: The Eclipse ADT’s “Create New Android Project” wizard, that automatically sets up initial files such as the android manifest and initial xml documents. An application in the Android operating system hinges on classes called Activities, which are single, focused things that the user can do. Activities account for every single user interface screen that any application will use to display information to the user and are joined together with a different structure called an intent. Intents are what allow the users to flow from activity to activity in addition to what allows information to pass between user interface screens. Since Android application need to be able to deal with the typical hazards of the mobile platform (being interrupted and stashed away when a phone call is received by the device, needing to open/close nearly instantaneously, etc.), Activities have a few built in methods that a developer may utilize to minimize the headaches that the mobile platform may throw their way. The flow chart in 2.4 Figure 3 below shows the typical life cycle of an Android application using the aforementioned built in methods. 
2.4 Figure 3: The typical life cycle of an android application. Android is designed to run on a variety of devices that offer a range of screen sizes and resolutions. For applications, the platform provides a consistent environment across devices and handles much of the complexity of adapting an application's UI to the screen on which it is being displayed. Due to this built in scalability, applications developed for tablet devices do not require a separate framework to properly display, but simply must be supply properly scaled graphics objects to be properly be displayed on the desire device. Since this system utilizes the android platform a tablet device with a screen larger than the typical Android smart phone, it will need to have these graphics supplied to it in addition to using a custom screen size in one of the built in android emulators. 2.4.1 Web Based Browsing Vs. Application DevelopmentThe means by which the clients access the program can be solved in a few days. The two most fluent ways of doing this, are through a mobile web-based server, and an application run directly on the mobile device used by the client (iPhone, iPad, etc). Since both approaches present distinctive benefits and shortfalls, its best to analyze each design to determine which best suits our needs for the program. Each design strategy poses certain limitations and challenges which must be analyzed to determine which is most beneficial for our implementation. Given the limitations of mobile web browsing, a web-based application would require more bandwidth, and simultaneously be less user-friendly, since all data must be transmitted through the internet, and we would be restricted by the capabilities of mobile web-software. Device application support would be much more fluid, user-friendly, and significantly less bandwidth. However, the application itself would be stored on each individual client; any updates or changes must be initialized and downloaded to the clients. Given the unique display and operating system properties of modern mobile devices, the application approach would allow for more immediate access, and in a more organized manner, since the devices have more ways to display and sort data within the applications. The unique benefits from each design approach are what set the two implementations apart from each other. While the web approach would be slower and more bandwidth-intense, the nature of web development allows the application to be changed and controlled on the fly, since the structure of the program itself is stored on a web server, independent of the client’s access device. This and a few other trade-offs can be seen below in 2.4.1 Table 1. More specifically, the web-based approach would allow more server-side control of the application, and support immediate changes and updates to what the clients can see and access at any time.
2.4.1 Table 1: A chart of trade-offs between web and local application development. Developing an application for the device itself presents new problems, as it requires more hardware testing and it some cases a new programming language. The benefits of the software application are too good to ignore, so it is the most logical approach. For this design, we’ve chosen to focus on Apple products exclusively (iPad and iPhone) as they have the largest market share, and the largest appeal. Converting the software to run on other devices is possible, with some effort in converting the code. Directory: seniordesign -> fa2010sp2011 seniordesign -> Hvac control and Feedback System 0 Group 2 Steve Jones Mathew Arcuri Elroy Ashtian, Jr seniordesign -> Group 5 Spr-Sum 2011 seniordesign -> Senior Design II paper seniordesign -> Remote Touchscreen-Controlled Defense Turret Senior Design Documentation Courtney Mann, Brad Clymer, Szu-yu Huang Group 11 seniordesign -> Flight Performance Data Logging System seniordesign -> Amphibious vehicle seniordesign -> T-100 Watch Dog (Autonomous Security Vehicle) seniordesign -> Ehvac: Wireless Modular Multi-Zone hvac controller Group b javier Arias Ryan Kastovich Genaro Moore Michael Trampler Download 471.88 Kb. Share with your friends:
|