Exploring a Disconnected Synchronization Architecture Between Android Client and Cloud

nadagoudapv10.it@coep.ac.in

Ishita Mundada

Department of

Computer Engineering

and Information Technology,

College Of Engineering,

Pune, India

mundadair10.it@coep.ac.in

Saurabh Phadnis

phadnisss10.it@coep.ac.in

Sunil Mane

Department of

Computer Engineering

and Information Technology,

College Of Engineering,

Pune, India

sunilbmane.comp@coep.ac.in

The popularity of mobile devices has increased rapidly in the recent years. A report by Gartner states that the worldwide total sales of mobile handsets in 2013 has surpassed 1.8 billion. Out of these, over 750 million were Android based smartphones. Gartner says Android had a 78.4 % market share in 2013, a 3.5% increase from 2012 [1]. It is plain to see that the popularity of Android is due to its ease of use, and consequently, this has made it possible for developers to reach a wider audience with innovative applications.

Medicine is one of the fields in which technology has become common to increase efficiency in application. However, on one hand large hospitals have patient database storage units, online record access, and software for staff usage; and on the other hand it is difficult for small private practitioners to afford such technology. In relation to the vast numbers of private clinics present, there is a dearth of technological facilities available to them. We present an application that will provide the required accessibility to data to help doctors organize and maintain their patient information. The application will synchronize data from the desktop software to the connected mobile device, so that patient and medicine information will be readily available whenever required by the doctor.

Along with the Android platform as the client, we have opted for the use of the Google App Engine(GAE) as the backend server. The datastore service of the GAE provides a free quota for reading and writing data entities [2]. The purpose of the server end is to retrieve the data from the desktop client, store it in the cloud, and send it down to the Android application.

The message format we have chosen for transferral of data is JSON - Java Script Object Notification. For preventing Man-in-the-middle and other types of security threats, the JSON objects will be encrypted before sending and then decrypted at the receiving end. Similarly a session token will determine if the request is received at the server by an authenticated client.
2. Related Work

Patient Records Doctor ON GO [3] is a phone application that has patient management features and is for busy medical professionals. While this existing application can transfer patient files to PC by connecting the device through a hardware port, our application is built to synchronize data between the PC and the phone through the internet. This will save doctor’s time and effort to manually back up the data on the PC.

Patient Tracker [4] is a tablet application used to manage patient details, record their medicine data and prescription information. This data is stored locally in the database of the device. There is no connectivity to a remote server or backup functionality. All data may be lost in case of device failure. To overcome this issue, our application connects to the Google App Engine in which the data is stored. This provides recovery options in case of device failure. Even if the hard drive of the device is formatted, the data remains secure on the Google server and can be downloaded again.

Medical doctors need fast access to patient’s current state and test results along with the patient’s historical data to have accurate diagnostic.  Darabant, Todoran et al. [5] have proposed a paper with a pilot project called MobMed, which is a mobile solution that helps doctors to easily access and edit their patients’ information. Since doctors can meet their patients outside the hospital as well, the app is useful to the doctors to store data about the patients even when they are not in the hospital. Whenever the doctor needs any patient information, the information is fetched from the MobMed server (MMS) and stored temporarily on the device that the doctor is using. The devices were Personal Digital Assistant (PDA). This is similar to our system in which all the data is stored in the cloud from where data can be fetched or inserted by either the computers or the mobile devices. But the difference is that our application is android based. In order to use the MobMed solution, it is a necessity that the hospital as well as the device used by the doctor has internet connection. When the connection is available on the device, the application will be able to exchange information with the MMS.

Any changes made through the device will be synchronized with the MMS. MMS will then synchronize the data with the central warehouse of the hospital. Any changes made at the hospital application will also be synchronized with the device. The central warehouse at the hospital stores information of patients of all the doctors in the hospital and synchronization happens between this warehouse and the PDA; whereas our system synchronizes data between the desktop and mobile app of a particular doctor, even though The App Engine server stores information of patients of all the doctors that use this software.
3. Architecture
3.1 Client Tier

The Android Operating System was released in 2007 under the Open Handset Alliance [13]. Their goal is to create open standards for mobile devices. Android is an open source mobile OS based on the Linux kernel. Android provides access to a wide range of useful libraries and tools that can be used to build rich applications. For example, Android enables developers to obtain the device location, a range of sensor services like Bluetooth and voice control, advanced network capabilities, and near field communication, allowing devices to communicate with one another. It also possesses a customized lightweight SQL database and content provider for persistent storage. In addition, Android includes a full set of tools that have been built from the ground up alongside the platform providing developers with high productivity and deep insight into their applications. The API is constantly evolving and the most recent release (4.4.2 Kitkat) is a giant leap forward in terms of available features from earlier releases [14].

Fig. 1 Overview of System Architecture.

Google App Engine is a service for hosting Web applications. It is an example of a platform-as-a-service (PaaS) cloud computing solution because Web application developers can use it to create and host their applications. In contrast to other cloud services, such as the Amazon Elastic Compute Cloud (EC2), Google App Engine requires that application developers use only a limited set of supported programming languages, currently Python, Java, PHP and GO, together with a small set of APIs and frameworks that are mostly dedicated to Web applications. The applications are executed in a secure hosting environment running on the computing infrastructure that Google provides and manages [15].

Android is a java based platform, and so we used the Google Web Toolkit for Eclipse IDE as the development environment. This provides new project wizard, debug configuration and deployment on to the App Engine [16]. The GAE Datastore is a NoSQL datastore, with features like ACID transactions, no planned downtime, high availability of reads and writes, strong consistency for reads.
4. Technologies

4.1 Data Interchange Format

XML and JSON are the 2 major standards when it comes to data formats [6]. XML has been used for a long time and is remarkably the simplest way to structure data. It makes use of tags and attributes, which are self-descriptive. Data is strictly stored within tags with the labelled index. XML provides serialization of data with good security. XML Schema comes into the picture to ensure that proper norms are followed while structuring the data. Even though it has good specification, the efficiency with which the data can be analysed is low.

JSON stands for JavaScript Object notation. It is a very recent data format option available and has become popular for its use on web pages to dynamically update information without explicit page refresh. JSON stores data in a much smaller size avoiding the use of user defined tags. It is easy for the machines to parse and generate data in JSON. The text format of JSON as compared to the use of tags in XML is independent of the language. The objects of JSON are analysed as String Arrays which makes it comparatively faster. It is small when comes to structuring the data and has many synchronization options.

It is evident that using JSON as the data interchange format is more advantageous than using XML. Hence, we implemented JSON in our mobile application. The device will store data in JSON format and send it to server and the server will do the same.

The problem of network connectivity in a mobile application is a big one. It is possible that the mobile user may not have access to the internet at all times. This should not interrupt his/her application usage. It is essential that any changes made to the data, be stored in the local database, and these changes be reflected at the server when internet connection is present.

There have been several methods researched to do this:

• 
  Enable a Refresh button that will allow the user to upload the data changed locally or download the newest version of files from the Server when the user is guaranteed to have reliable network connectivity.
  
• 
  In the background, automatically refresh the data present at both ends of the network when any changes are made, and internet is available.
  

In that case, for automatic data synchronization, the techniques we have found are:

• 
  Implement batch updates by grouping together multiple small updates. It is profitable to minimize the duration of network usage by decreasing the number of times the network is touched.
  
• 
  Concurrent Versioning Systems Sync [7] implements version numbering and a unique ID for each record. An instance of every object can be looked up by its object ID from the Previous Version table, Latest Version table, or Ready-to-Sync table. Mobile device synchronization through version numbering is possible.
  
• 
  HotSync[8] uses Boolean flags to indicate records that have been modified since the last device synchronization. Whenever a connection is established, transfer of those records takes place which have been flagged. Subsequent to the update, the flags are removed.
  
• 
  The Open Mobile Alliance [9] is a global initiative comprising of hundreds of companies in the mobile domain. The Data Synchronization Protocol used by them is SyncML, which is based on the configuration of XML. This protocol uses synchronization anchors to allow any host to connect to another host.
  

Security in the mobile device is of a major concern as the patient data pertaining to this application is of a sensitive nature. The important aspects of security include mobile database security, device configuration security, application execution security and mobile network security. Parviz, Aytak et al. [10] have proposed in their paper, a solution for mobile security threats. Best security practices that users can implement involve user authentication by password, careful usage of the device so that it does not result in unauthorized penetration. Viruses, trojans, malware can enter the device through Bluetooth connection. Hence our application does not utilize transfer through Bluetooth. Wireless networks like EDGE, 3G, 4G LTE are also vulnerable to external attacks as they are open to the public Internet. Our solution protects end users by implementing AES encryption for network messages.

Obfuscation is a technology used to transform a simple program code into a complex and illegible format of text thus making it difficult for an outsider to understand and tamper the code. The semantic representation of the code and logic remains the same in the process of obfuscation. There are three broad classifications of obfuscation namely Lexical Obfuscation, Data Obfuscation and Control Stream Obfuscation. To overcome drawbacks of these traditional obfuscation Tang, Chen, et al. [11] have proposed four algorithms which concentrate on elimination of the addition of unnecessary symbolic information for the purpose of obfuscation.  Broadly the paper discusses on Identifier Renaming Algorithms which scrambles the names and references in the JAVA byte code.

Desnos in his paper about Statistical Analysis Using Similarity Distance [12] proposes an algorithm to find similarities and differences between two applications efficiently and quickly. This will help us find any tampering done to the application code. The algorithm also provides a huge step towards the major problem of application theft from the Android market by not allowing hackers to download and crack the application.  

Data objects are stored in the GAE Datastore as Entities, with specified properties. It is possible to query on the basis of these properties and retrieve a set of results. Our application, when requesting data from the server during the initial setup synchronization, calls a servlet through an HTTP Post Request, which queries the datastore for the required entity kind and returns a defined number of results. This result set is packed into a JSON object and sent back to the device in the HTTP Post Response method.

Query cursors allow an application to retrieve a query's results in convenient batches without incurring the overhead of a query offset. After performing a retrieval operation, the servlet obtains a cursor, which is an opaque base64-encoded string marking the index position of the last result retrieved. The cursor contains information about the Entity kind, the properties on which sorting takes place, and the location in the list of the last obtained result [17]. In our application we are sending back

Fig. 2 Synchronization Process
the cursor string with the response JSON. The cursor string is then stored in the local mySQL database of the mobile device. When the next request is sent to the GAE, the cursor string is sent along with the message to indicate to the GAE that previous results have already been received. The appropriate servlet uses this cursor string to find the correct location in the entity list to retrieve results. These new results are then sent back to the application along with the new cursor string again.

Fig.3 Application’s Window showing syncing process.
Each entity in the datastore has a timestamp property. This timestamp specifies when the entity was added to the datastore or last modified in the datastore. Each time a query is executed to retrieve results, the entity list is sorted based on timestamp. In this way, the most recently added or modified entities will always be at the end of the list. The entity pointed at by the cursor will show the next new entity and the subsequent entities will also be new. An entity that was before the current position of the cursor, when modified, will update its timestamp and be placed at the end of the list after the cursor’s current position. Hence we have used the query cursor as an efficient method of obtaining updated records for synchronization.

There is a possibility that the cursor is not present when required for use in a query. In that case, the timestamp is used. It is returned along with the cursor as an indicator of the last updated time, and stored in the local database. When only timestamp is sent to the GAE, a search is queried for all entities having their timestamps greater than the provided one. Similarly, when no timestamp is provided, then it is an indicator that this is the first initial synchronization, and so the GAE returns the entities starting from the first in the list.

Fig. 4 Authentication

The encryption/decryption keys obtained by means of the authentication process are used to by the Android client and the GAE servlet. The encryption standard used is AES(Advanced Encryption Standard). Each outgoing JSON object message from either end is encrypted in its entirety using the key and then sent over the HTTP connection. On receiving the message, the receiver first decrypts it using its respective key and then parses the information. Each key pair is unique for each doctor and Android application. This ensures that sensitive information can be read only by the intended recipient.

Since the cursor contains data about the Entity and its properties, it is not safe to send the original


Fig. 5 Application’s Login Window
cursor over the network. There is a possibility of interception and decoding of the cursor to extract the datastore metadata. To avoid this, the cursor is first hashed using a hash function and then the hashed cursor string is sent back with the response. The original cursor is stored in the GAE datastore itself. As hashing is irreversible, it is impossible to retrieve the original cursor from the hashed string. The mobile device stores the hashed cursor in its own local database. A request is sent to the GAE from the device with the hashed cursor. On receiving and authenticating, the GAE compares the hashed string with the original cursors it has stored, and retrieves the appropriate one. Now the query to the datastore can use the actual cursor.
7. Conclusion and Future Work

Our sample application is able to successfully download data from the GAE datastore during both the initial setup synchronization and also latter delta synchronizations. The partial updates retrieve only the data which is not present in the local mobile database of the application at the time. In this way, the doctors can view patient and appointment details when disconnected from the internet, and update the database when internet connection is available.

With regards to data security, the application ensures privacy of sensitive data being transferred over the network as well as the data stored in the mobile device through message encryption and sqlcipher. The server is also protected from external attacks by maintaining confidentiality of the internal working.

In future work we wish to expand the functionalities of the application. This includes reverse synchronization, in which data changes made to the application are seen at the server end and are replicated in the desktop application. Further fine tuning and addition of features must be done before the application is deployed on the Google Play Store. At that time, the entire code base will be obfuscated to prevent reverse engineering of the application.

We would like to thank Catalyze Systems Pvt. Ltd. Pune for their support and guidance in building the Android application and for providing us access to their servers from which we authenticated doctor credentials and retrieved patient information.

[1] Gartner, “Gartner Says Annual Smartphone Sales Surpassed Sales of Feature Phones for the First Time in 2013”, http://www.gartner.com/newsroom/id/2665715

[2] Google App Engine Datastore, https://developers.google.com/appengine/docs/java/datastore/

[3] Siyami Apps, LLC, Doctor on GO

[4] Weblineindia, Patient Tracker

[5] Adrian Sergiu Darabant, Horea Todoran, Mobile Devices and Data Synchronization Assisting Medical Diagnosis, Dept. of Computer Science, Babes-Bolyai University, Romania

[6] Guanhua Wang, Improving Data Transmission in Web Applications via the Translation between XML and  JSON , School of Computer Science & Engineering, Southeast University Nanjing, China

[7] Henry Larkin, Applying Concurrent Versioning to Serverless Mobile Device Synchronisation, University of New South Wales, ADFA, Canberra, Australia

[8] Henry Larkin, Data Representations for Mobile Devices, University of New South Wales, ADFA, Canberra, Australia

[9] Open Mobile Alliance, Data Synchronization Protocol, http://openmobilealliance.org/

[10] Parviz Ghorbanzadeh, Aytak Shaddeli, A Survey of Mobile Database Security Threats and Solutions for It, Urmia University of Technology, Computer Department, Urmia, Iran

[11] Zhanyong Tang, Xiaojiang Chen, Dingyi Fang, Feng Chen, Research on Java Software Protection with the Obfuscation in Identifier Renaming, College of Information Science and Technoligy, Northwest University, Xi’an China

[12] Anthony Desnos, Android : Static Analysis Using Similarity Distance, ESIEA : Operational Cryptology and Virology Laboratory (CVO), Honeynet project, 2012 45th Hawaii International Conference on System Sciences

[13] Open Handset Alliance, http://www.openhandsetalliance.com/

[14] Jarle Hansen, Tor-Morten Grønli, Gheorghita Ghinea, “Cloud to Device Push Messaging on Android: a Case Study” in 26th International Conference on Advanced Information Networking and Applications Workshops, 2012

[15] Maciej Malawski, Maciej Kuz´niar, Piotr Wójcik, and Marian Bubak, “How to Use Google App Engine for Free Computing”, 2013

[16] Weider D. Yu, Hongbin Yuan, “An Approach to Explore Mobile Software Engineering Advances in Cloud Computing Environment” in 35th IEEE Annual Computer Software and Applications Conference Workshops, 2011

[17] Query Cursors, https://developers.google.com/appengine/docs/java/datastore/queries