PHA Android Application Development

Transcription

1 PHA Android Application Development This semester brought about great change to the Android PHA application and frenzied development. It is important to note that Android has a steep learning curve, and it took considerable time to learn the Android SDK and how to create an Android application properly. While Google provides some detailed instructions and tutorials on their developer zone website, complete resources are hard to come by, and Google s documentation can be cryptic at times. I found the book Professional Android 2 Application Development by Reto Meier to be an excellent companion resource. This semester, as described in the various sections in detail below, I was successful in overhauling the existing Android application into a new, modern application completely rewritten from scratch. The new application is much more efficient, compatible, dynamic, and integrated than the previous iteration. The new application also provides integration to Microsoft HealthVault, utilizing Java model and server classes to connect to a.net server application directly using JSON, which then connects us to the HealthVault API. As described below, numerous improvements have been made in the new application in comparison to the existing application, and a number of new features have been added. Future work items have also been identified and described in detail. While working primarily on the Android application development, I did assist with debugging the.net server application numerous times throughout the semester, and did contribute some development time to that application, which is described below. Debugging the.net HealthVault Server Application When the.net server application was first ready for deployment, multiple attempts were made to deploy the program to a virtual machine located on the CDR server in Lab 215. After configuring the virtual machine and installing the necessary software, it was soon discovered that the server application was failing to load URLS correctly, due to the presence of a port number in the URL. HealthVault applications typically run on port 80, but because this was a virtual machine, that port was already in use. Assisting Gordon with troubleshooting this issue, we stumbled upon documentation from Microsoft ( that provided instructions on how to add port numbers to URLs HealthVault generates. Although we tried numerous times to implement these steps, it failed every time. We concluded (along with verification from other users experiencing the same issue) that it must be a bug in the current HealthVault SDK. As such, we elected to deploy the server application on my personal lab computer, which has port 80 freed for use. Recently, we discovered that while the server application deploys correctly in a local instance, it failed to publish correctly to IIS (Microsoft s web server) and would throw back server security warnings each time the HealthVault application was accessed directly via its URL. After much troubleshooting with Gordon, we discovered that the license key that is used by the HealthVault SDK also had to be manually included in the IIS web configuration file. By including this file, the application can now be successfully accessed via its URL in a web browser.

2 Improvements over the Existing Application Code Overhaul The Android PHA application was rewritten from the ground-up this semester after an extensive analysis of the existing code revealed it to be poorly written. In many aspects, the existing code lacked a unified structure and did not always comply with the MVC (Model View Controller) nature of Android. Furthermore, existing code in many areas was overly complex to the point that it was adding more complexity than necessary or simply breaking the code altogether. In fact, when running the existing Android application in an emulator, many areas of the application would crash, resulting in a forced close of the application. This can be seen when trying to view the Reports or Alarms tab in the application. As of the end of this semester, these crashes still exist in the latest version of the existing Android application. Considering all of these issues, it made more sense to start fresh and rewrite the application utilizing best practices and efficient code. As a result, the new application is lighter, more efficient, and less resource intensive. A typical Android Activity will access many of the form elements defined by that activity s layout directly: in the previous application, individual objects were defined for each element, unnecessarily taking up memory and storage space. In the new project, single objects for each type of element are reused, and elements that are required to be stored separately are still given their own object. In addition, many helper functions were created to reduce the amount of code needed to perform certain functions, such as input validation and updating form elements with new property values. Layout Overhaul and Cosmetic Upgrade One of the most noticeable changes to the Android PHA application is its cosmetic makeover. The new application features improved organization, drastically improved layouts that increase usability and user-friendliness, improved graphics and styles. Layouts are constructed in XML files using on the required layout elements to achieve the desired look: in the previous PHA application, many unneeded layout elements were nested together, adding only to the complexity of the layout. Also, unlike the previous PHA application, the graphics included in the new project are included with multiple sizes to support low, medium, and high resolution and density displays. All textual information that is displayed to the user (and will not be overwritten at some point) is saved in the project s strings XML file. This is beneficial as not only allows for multi-lingual implementations in the future, but it also allows for easy modification of text that is present in different screens of the application. Support for Multiple Resolutions and Densities One of the most prominent issues plaguing the previous Android PHA application was its lack of support for multiple screen sizes and screen densities. The first iteration of the PHA application utilized absolute layouts for drawing elements on the screen this was not the best design choice for multiple reasons, as elements are essentially statistically placed at X,Y coordinates and do not conform to device changes. Furthermore, this type of layout has been deprecated by Google. In the screenshot below, we

3 can see a side by side comparison of the Wellness Diary in both the old and new PHA applications, and the layout issues in the old application are heavily prevalent. This issue has been eliminated in the new Android PHA application. Using layouts that adapt to the screen size and density, such as linear or relative layouts, and using scalable size units when customizing elements (such as Android s sp and dp units) instead of pixels, the new PHA application will look consistent across any phone-based screen size. New Features HealthVault Connectivity The most prominent addition to the Android application this semester was the integration of the HealthVault server application functionality into the core application. This integration provides direct connectivity from the PHA application to the HealthVault API, allowing the application to download, upload, delete, and modify user data to and from HealthVault. Various data models, implemented natively in Java, are used to represent the various supported HealthVault data types, such as basic demographic information, height, weight, and medications. Similarly, the Java classes representing the server connection are responsible for interfacing with the methods and objects that are implemented in the.net server application, and this communication interface is established and maintained using JSON. With the.net HealthVault server application running and the Java classes to interface with the server application implemented, it was non-trivial to integrate the Android application s forms with the server. By simply importing the model classes into the activity classes, creating and instantiating objects

4 of those classes, and using the methods defined by those classes directly, direct communication to HealthVault is achieved. For instance, the Wellness Diary is able to create and upload an entry to HealthVault, and retrieve a list of all the wellness entries currently stored in HealthVault. A user can also choose to delete an entry, and this action is also reflected online in HealthVault. Similarly, a user is able to define a new medication (whether it is a prescription or over the counter drug), and upload and save that data to their HealthVault profile. The Android application is able to retrieve the lists of all prescribed and non-prescribed medications and display them to the user in separate screens, and users are able to edit their medication information and save the changes, or delete the medication altogether. Splash Screen One feature missing from the existing Android application that was present in the iphone application was a splash screen. The iphone application utilized a single PNG image to display the application s logo and name, and did not perform any background tasks it simply advanced to the next screen after a set amount of time. This feature was implemented in the Android PHA application this semester and has vastly improved upon its counterpart. The actual splash screen does not utilize an image but uses scalable text to display the application logo, name, and version number. A small, animated loading (progress) indicator is also present on the screen. By implementing this screen using scalable elements, rather than a static image, the screen can adapt to any device resolution or density. However, the main purpose of this screen is to perform any data-intensive tasks while the application loads and before the user can interact with the application. As such, the Android PHA application performs background HealthVault data downloading in a separate thread (apart from the system thread) while the screen is displayed to the user, and the screen automatically advances to the home screen when the download tasks are completed. By loading the data during the initial application start up and in a separate thread, the application s performance is maintained and there is no visible interface lag to the user. Reusable UI Components and Layouts In addition to correcting the erroneous layout structures and inconsistencies of the existing application, further reductions to the size and complexity of the application s layout XML structure was achieved through the notion of layout reuse. As mentioned before, Android utilizes an XML structure to define the layouts that construct the screens that are displayed to the user at runtime. More often than not, many screens share similar (and often identical) features and layouts, such as button bars, styled section headers, and custom styled list items. Rather than implementing these features over and over again in each layout XML file, these reusable components and layouts were defined in their own XML file and where included when needed in other layout XML files. This approach results in the reduction of the performance overhead associated with recreating these elements repeatedly, and the reduction of the overall code size and storage space required implementing these elements. Shown below is an example of this reusable layout approach, in which the custom layout for a list item (used for each item inside a list view) is defined in a single XML file and used in multiple list views, defined elsewhere in the application. In this custom layout, the item text and an arrow image are displayed.

5 <?xml version="1.0" encoding="utf-8"?> <RelativeLayout xmlns:android=" android:layout_width="fill_parent" android:layout_height="wrap_content" > <TextView android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignparentleft="true" android:layout_centervertical="true" android:padding="10dp" android:textsize="16sp" android:text="list Item Text" /> <ImageView android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignparentright="true" android:layout_centervertical="true" /> </RelativeLayout> Using this approach, reusable layout XML files were created for the application s section headers, one column list items, two column list items, buttons (and button bar), and the wellness diary seek bars. Custom and Reusable Form Control Listeners Many screens in the PHA application utilize complex form controls, such as spinners (the Android equivalent to drop down menus), date pickers, seek bars and buttons. These form controls are considerably different from the standard text field in that they require a listener to be defined for each instance of the control. Typically, this involves defining a new on item click listeners for each of these form controls and implementing the logic behind these events. While this is non-trivial task, it can become very cumbersome when a single activity (screen) utilizes a large number of these form controls, especially when the form controls are of the same type. For example, a form with three date pickers will be required to define three listeners (and their respective overloaded methods) for each date picker, and these listeners will be virtually identical in structure. To simplify this process and reduce the amount of code needed to implement these form control listeners, custom listener classes were created for each type of form control and stored in a listeners folder. When initializing one of these complex form controls in an Android Activity, a new instance of the respective form listener was instantiated, and overloaded with the control-specific information. In summary, this approach allows us to initialize multiple complex form controls by reusing a single listener class. Input Validation and Notifications Since the PHA application implements numerous form elements on various screens, it was absolutely essential to implement input validation on these elements, a feature that was severely lacking in the previous implementation. For example, on the Wellness Diary reporting page, a user can select certain ODLS and a timeframe when generating a graph that visualizes their ODL statistics over

6 time. Without input validation, if the user did not select a checkbox or start/end date, the JSON call that would have been executed when the Generate button was clicked would have ultimately failed, resulting in a crash and forced close of the application. To prevent these types of events from happening, input validation was implemented in every applicable area of the application. The error messages were generated and displayed to the user using Android s built-in Toast notification system. The screenshot below provides an example of the input validation and Toast notification in action. Logging Logging was virtually non-existent in the previous Android application. To assist with development and debugging, meaningful Logging statements were inserted throughout the application using Android s built-in logging system. These statements provide information regarding the class the error occurred in, an error message, and the stack trace of the error itself. Future Work Although the work completed on the Android PHA application this semester represents a huge leap forward, there is still much more to be done. The improved code implementation and layout design provides a structural framework that is very simple to learn, understand, and build upon, allowing for simpler and rapid application extension and development by any programmer in the future. With this in mind, implementing the identified application improvements and additions as described below will be non-trivial for those with knowledge and experience with Android development.

7 HealthVault Connectivity Improvements First and foremost, a number of improvements can be made to the underlying code that connects the Android application to Microsoft HealthVault. As discussed earlier, the Android application utilizes a number of server and data model classes to connect to the.net server application and access the user s HealthVault information using JSON. This data access method has worked really well and reliably for us this semester for development and testing, so long as the server application was running locally. In the event that the server application is not running or cannot be reached, the Android application will stall and timeout during initial startup, resulting in a force-close crash. This event should be properly handled in the future, by either implementing a timeout on the JSON call, or providing an offline mode that stores user activity locally on the phone s on-board memory until access to HealthVault could be reestablished. Furthermore, during the application s initial startup, a splash screen is displayed to the user with various application information and a loading (progress) bar. While this screen is displayed to the user, the application creates a new thread in the background and proceeds to connect to the HealthVault server application and download the user s data, which is stored locally for faster access. The thread is constructed in a standard Java implementation and works well for our purposes, as it allows us to download the information in the background while the activity is being displayed (not possible in a nonthreaded execution, as the screen would not be displayed until the data download was complete otherwise). However, Android provides an AsyncTask class which natively implements functionality for downloading information in the background, eliminating the need to construct a thread manually altogether. Going forward, the PHA application should be modified to use this class instead of creating a new thread manually, as it will offer various performance and reliability improvements. Lastly, as we were only developing the PHA application with one HealthVault account, the user credentials were hardcoded into the server application and as such, the application only works for that account. In the future, the PHA application should feature a login screen that allows a user to enter his or her HealthVault account username and password, and the server application should retrieve that information from the Android application and use those credentials to login and validate the user. Including a Remember Me option on the login screen, although not required, will help improve the user experience as well, as the user will not be forced to login each time to use the application. Android Application Improvements A number of improvements can be made to the PHA application directly and many have already been identified during this semester s development and are described below. Although not a major requirement, the inclusion of a global application menu (a menu that pops up when the Menu key on an Android phone is pressed) can be considerably beneficial for the user. This context menu, at a minimum, can offer the user the ability to log out of the Android application and offer the user the ability to perform a manual data refresh, which will force the application to update its data in the background. Similarly, the inclusion of a settings screen can give the user more flexibility in customizing the Android application, such as setting an automatic interval for performing data refreshes, the duration to be

8 logged in for, and how the application should behave in terms of notifications. This could be easily implemented using the SharedPreferences feature of Android, which allows for the saving of application settings on the phone in a very simple key-value pair manner. Naturally, the application will need to be modified to support these new settings. In terms of features, the Home Activity can be further improved to allow a user to edit his or her demographic information directly from the phone, and push those modifications out to HealthVault. Similar code already exists in other parts of the project to accomplish this, and support for this action is already built into the HealthVault server application (it was not finished in this semester due to time/priority constraints). Similarly, allowing the user to change their profile picture be either selecting an image from a URL or by selecting an image stored locally on the phone can be easily implemented. While the Android PHA application features a top-notch Wellness Diary with several preset ODLs, including additional ODLs, such as those featured on the iphone application, would not be difficult to accomplish. The ODL model can be easily extended to include any new information that needs to be stored, and modifying the JSON queries to include these new ODLs are only simple one line modifications. The reporting feature in the Wellness Diary can be further improved by placing the generated graph inside a web view instead of an image view. Android does not support zooming and panning capabilities in an image view, which is what the graph is currently implemented in. By switching to a web view, only the graph s URL will be needed, and these limitations can be overcome. Finally, there are a number of screens that remain to be implemented. These include but are not limited to the Allergies, Herbal Supplements, Nutritional Supplements, and Alarms screens. Since HealthVault only provides support for prescribed and non-prescribed medications, only those two items are currently supported in the Android application. Further research will be required to determine how to save these types of data in HealthVault. One possibility that can be explored is to create custom data types using the HealthVault API. This route was not explored this semester due to time and priority constraints. Also, although prescribed and non-prescribed medications are supported in HealthVault, the information that can be stored about a medication is severely limited to a small set of fields. Further research will be needed as well, although one possibility of overcoming this limitation is storing this data inside the notes section HealthVault provides for medications. The data will need to be keyed with ID s, and while this should work fine, it s important to note that this marked-up data will be visible to a user via their HealthVault profile, and can be edited (and malformed) mistakenly. Availability The code for this Android application is available in the SVN repository located at the following URL: