Download PHA Android Application Development

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 Appli cation
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
(http://msdn.microsoft.com/en-us/healthvault/cc514196) 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.
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
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
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.
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="wrap_content" >
<TextView
android:id="@+id/list_item_one_arrow_text"
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:id="@+id/list_item_one_arrow_image"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_alignParentRight="true"
android:layout_centerVertical="true"
android:src="@drawable/ic_list_next_white" />
</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
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.
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
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:
https://cdr-dev.engr.uconn.edu:55080/svn/androidv2