For this sprint cycle my team and I focused on how we could implement offline capability for the ng2-amrs project. We came up with some designs using balsamiq and researched what tools we could use for the backend and storing data offline. One of the contributors form AMPATH suggested that we look into a tool called PouchDB which is an open-source JavaScript database. What makes PouchDB so useful is that it can be used to store data locally so users have access to application data even when they are offline. After doing some reading and completing the tutorial provided on the PouchDB site, my team members and I decided it would be best to move forward working on the backend of the offline module using PouchDB to store important data which could be accessed offline.

Shane and I worked together last week in doing the PouchDB tutorial. We first had to download the PouchDB codebase which actually proved to be pretty simple. PouchDB can be installed through npm with either of the following commands:

npm install --save pouchdb

npm install --save pouchdb-browser

The second npm install command will only install the browser components of PouchDB. This is probably what my team and I will be focussing on since the ng2-arms application runs in the browser. One possible concern I have moving forward is that in order to keep the data up-to-date, we will have to make sure that our PouchDB database can easily sync-up with AMPATH’s servers when a wifi connection is reestablished. In the documentation, PouchDB mentions that in order implement syncing, the server needs to be compatible with PouchDB. We will need to reach out to AMPATH to ensure their production servers will be able to sync with our PouchDB database.

One of the key features of PouchDB is that it provides an “asynchronous” API. When I first read this I had no idea what it meant as I’m not all that familiar with web-developemt or the DOM design patter. However, after a little reading I started to get the idea. Essentially, the benefit of being asynchronous is that it ensures the user’s experience is not interrupted when calls are being made to the PouchDB database. If this were not the case, database calls in the browser could cause the application to stutter due to the DOM logic being blocked by those calls. The way this works is by utilizing “promise objects” to call database functions. This link provides a really useful reference for how asynchronous code works.

Along with discussing how the backend of our offline module will work, my team and I also tried to figure out how the front end UI should behave when there is no internet connection. Some of the questions we needed to answer were:

• What type of information should be stored and displayed for individual patients?
  • For this question we want to try and store the least amount of data as possible to optimize storage.
• What should the UI look like when the user is offline?
• Should the UI display some sort of notification to the user when they lose their internet connection?
• Should the user have the option to turn the application to “offline mode” in which they can chose which patients’ data should be stored while the user is offline?

We were able to gain some insight into the first question by referencing the google doc provided by AMPATH. The user stories and requirements describe which data is most important and should therefore be stored locally. For the second question, Fuverion was able to make a couple designs in balsamiq of what the UI might display when there is no intern connection.  As for the last two questions, they are still a work in progress and we will need to consult with the AMPATH developers to determine the best course of action. We will most likely do this in the beginning of our next Sprint Cycle.

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.