A historical audio and video guidebook for an Android smartphone/tablet John Reid September 2011 Dissertation submitted in partial fulfilment for the degree
Download 239.28 Kb.
|
- Navigate this page:
- 3.2.2Methodology
- 3.2.3Coding Guidelines
- 3.2.4Mobile Considerations
3.2Approach3.2.1AndroidOne of the first decisions that had to be made was which mobile device operating system (platform) to target the application to run on. The following three common mobile platforms were initially considered: the Android platform from Google [14], Windows Phone from Microsoft [15] and the iOS platform (formally known as iPhone OS before June 2010 [17] ) from Apple [16]. The Android platform was finally chosen for several reasons: this particular platform used a java type language which I already had experience of and so would help to shorten the development time. Additionally, an Android course was being taught in the second semester which would be useful in advancing the project. Although the iOS platform from Apple was a strong contender in the mobile device market [18], it would involve learning the Objective C programming language and it would have required purchasing an Apple Mac for development. The Windows mobile platform was the final platform considered and although it was gaining in popularity and had been receiving positive reviews as an easy platform to write for [21], there were (at the time of writing) currently less devices out there using it than Android or iOS. The Android operating system was developed by Google and the Open Handset Alliance for smartphones and other mobile devices [12], [18]. An interesting and important aspect of its architecture was its Activity class [23] and its associated lifecycle (as shown in Figure 6.). An activity was typically a window that allowed the user to do something. Typically associated with an Activity was a layout file, used to generate and arrange how “views” appeared on the screen1. An Android “View” was a user interface class that handled screen layout and interactions with the user [22] (for example a “TextView” displayed text and an “ImageView” displayed an image on the screen). The activity stack was an important aspect of Android and when the user pressed the “Back” key on an Android device it would remove (pop) the current activity and run the previous activity. As detailed in the Android documentation “An application should be able to restart at any time without loss of user data or state in order to handle events … and then returns to your application” [24]. 
Eight Android activities were used in the application, with each class being extended from the base “Activity” class; Figure 7. describes these activities.
3.2.2MethodologyA “Software Design Notes” (or “Software Maintenance Handbook”) document was created to store all the notes related to the project. This was created in preference to a paper based workbook as it was previously found to be a better format for searching through and for storing images and web addresses in. A prototype of the application was created early in the development process to quickly check the technologies being used and to get early feedback from potential users. This was particularly useful for the design of the guidebook pages to check the swiping of pages and how videos could be played. It was hoped that creating a prototype in this way could save time by reducing the number of potential alterations later in the implementation stage. Since one of the aims of the project was to create a responsive application and to give the user a good experience, a “Now or Nothing” approach was taken: if the user could not access content quickly then the feature was either redesigned or removed from the application. All multimedia data was therefore held locally rather than being streamed from a server. Another approach taken was not to “re-invent the wheel” when there was already something available either from the Android library or from other developers, then consideration was given to using it. A benefit of this approach was (hopefully) a reduced development time and a more reliable application. An example of this was extending (through inheritance) the existing Android Gallery view to handle left to right swiping gestures and using the open source “WheelView” and “Osmdroid” code. A spread sheet was created to contain the list of the places that were going to be used in the guidebook application, together with information about them. Images in the "Lost Edinburgh book" were scanned and processed using Photoshop to correct their colour and to lower their resolution. Sections were then added into the guidebook XML file(s).
To make it easier to maintain the code, relevant comments were added in and links made to the software maintenance handbook were added for larger text descriptions. As the coding progressed and features were finalised, code was occasionally refactored to better name methods and variables. The code was compiled with as few warnings as possible and class methods and variables were made private as much as possible to try to keep the implementation details hidden from the other modules of the code. Logging code was added to help in any debugging issues that could have arisen during testing (through the use of the Android logging methods). As much as possible, clear and descriptive names were chosen for the classes and objects in the source code. Backups of the source code were done frequently. Some consideration was made to make the code as cross platform as possible so if the application needed to be run on a different mobile device (for example, the iOS platform), then it would be easier to port the code (recompile and target it for a different operating system). In practise, this proved quite difficult since the concept of activities in Android is unique. However the parts of the code using technologies such as XML would be more portable.
An option was also added into the settings menu to allow the user to use “High Contrast Text”. If this option was selected, the text in the guidebook pages would be coloured white and placed on top of a black background. This would save battery power (especially when lots of text was being viewed) on mobile devices that used OLED displays since they don’t have a backlight. Instead each pixel is an Organic Light Emitting Diode that makes its own light. Reducing the number of pixels switched on when the device was being used would help to conserve battery power [26]. Other considerations included the small screen size that the application may have to run on: text was sometimes placed on top of other components to save space and so an opacity level was used on the text background (white) so the black text could still be read easily on a dark background. The ability to change font size easily was also important for small screens. Since mobile devices may not have much RAM, avoiding memory leaks and creating a well behaved application was an important consideration. To avoid memory leaks, the practise of creating Android objects and drawable instances as static class members was avoided [27]. Additionally, the DDMS “LogCat” window was often used to check for memory leaks and other coding issues while the application was being tested. Directory: courses -> ITNP99 -> PastDissertations -> 2010-2011 -> Dissertations courses -> Ieor 4600 Mixed-Integer Rounding Inequalities courses -> San José State University Social Science/Psychology Psych 175, Management Psychology, Section 1, Spring 2014 courses -> Kennan's Telegram (Excerpt) courses -> The university of british columbia courses -> A hurricane track density function and empirical orthogonal function approach to predicting seasonal hurricane activity in the Atlantic Basin Elinor Keith April 17, 2007 Abstract courses -> Cover page need figure & title by Proposed Table of Contents courses -> Objectives courses -> Dr. Jeff Masters' WunderBlog Download 239.28 Kb. Share with your friends:
|