Challenges and lessons learned - Evolve for iPad? offline mode
Date posted
10 December 2014
Reading time
11 Minutes
Challenges and lessons learned - Evolve for iPad? offline mode
A little background
I joined Kainos just over a year ago, and started on the Evolve for iPad project. The team were working on making a transition from an app that was an online only Electronic Medical Record (EMR) to one that not only allowed clinicians to view content when offline, but also allowed them to create content using eForms when offline. To be able to provide this functionality without an internet connection, we needed to re-engineer significant parts of the app that were designed for online use only. I think our biggest challenge was to invent a stable and secure architecture for keeping all the data locally on an iPad. This software architecture is combined with a high quality internal mechanism for the best user experience.
Challenges
Offline App Architecture
It was a challenge to re-engineer the existing architecture to support offline mode, while still honouring our core design principles of security, usability and performance. The picture below shows a high level architecture overview.
As shown in the diagram, the offline capability is integrated with the architecture; there is no separate module to handle offline mode.
Our networking module is responsible for sending HTTP requests, handling the responses and also for determining connection state. The tasks management module is responsible for creating online or offline tasks and manages them in terms of priority and connection state in the tasks queue. The last module that's worth mentioning in our offline architecture is storage. This module is responsible for persisting all the needed data that server side returned. CoreData is an iOS local database per application, it persists all the context data, while the file repository is maintaining the files kept on local disk. The encryption part is used to decrypt stored data when needed. It's decoded into the memory in real time.
Web API
To be able to store all the data locally on iPad we needed to refine and add some functionalities to our REST based Web API. We needed to think about how the data flow would look. It was also one of our challenges, because we had to reinvent the way the app communicates with the server side. After a few iterations, we found a clear way to pass all the information needed for offline mode.
Storage
Storing data on iPad is a rather simple thing to do, but is more difficult when data needs to be well organised and available for fast access. We developed a way to organise files in conjunction with the CoreData database. The queries to read or write the files are sent to the File Repository. This then reads the file and sends it to the Encryption mechanism. This data flow model is very stable, reliable and fast.
Security
One of our most important requirements was to secure and prevent data stored within the app from being compromised. We had to consider every scenario of how data could be compromised, from an IT specialist trying to get information from the iPad to a user that leaves a logged-in session unsecured.
We did some research on available technologies and found a way to secure the downloaded content. All the data is fully encrypted, and when needed, it is decrypted in real time. In our app's physical layer the encryption was a necessary thing to do. We also used native platform security features such as keychain and device content encryption. As for downloading the data, we decided to encrypt the data that is transferred using SSL encryption. Also, if the user is away from the iPad, we implemented a Pin Lock mechanism to prevent unauthorised access. After a few (configurable) minutes of inactivity the application will lock itself, showing the user a PIN screen. To unlock the app, the user has to enter their private PIN.
Manage eForms and Workflows
Another crucial thing was to make eForms and workflows available for clinicians while offline. Our challenge was to make them available but also to be stable and reliable processes. We found a solution for this problem - we decided to make a special type of eForms that can not only be used in online mode but are optimised for offline mode. These eForms are downloaded as soon as the user logs in and are cached allowing the user to interact freely with them regardless of their connection. Once the eForm is submitted by the clinician it is added to the queue and seamlessly sync'd back to Evolve when a connection is established.
Lessons Learned
I believe that after each iteration, after each completed project there are always some things that we learn to make it better in the future. Before we released our first Evolve for iPad app with offline mode and the tests were successful, we asked ourselves as a team what were the things to consider to work better in future:
Offline first
The biggest lesson we have learned is that it is really hard to add an offline capability to an existing app that is already designed for online only mode. Any future apps we build we follow an offline first design principle to ensure offline is built into the app from day one and everything else is built around this.
Optimisations
We have robust test processes in place within Evolve including extensive stress testing across our product stack. We soon learned this same test approach was equally important when building an iPad app. During the implementation it was clear that only a wide range of high stress tests can identify areas for improvement within our app. Our test engineers look for these during every test stage. If one shows up in the test stage we can implement a quick fix for it. This agile approach to continuous improvement and optimisation is a key part of our development process.
Conclusion
The offline feature for the iPad app was a very good move. It allows clinicians to continue their work even if they are not connected to the network. I'm very glad that I have joined Kainos and jumped in to a very exciting project - Evolve for iPad. Every day in our project is an interesting challenge.
As shown in the diagram, the offline capability is integrated with the architecture; there is no separate module to handle offline mode.
Our networking module is responsible for sending HTTP requests, handling the responses and also for determining connection state. The tasks management module is responsible for creating online or offline tasks and manages them in terms of priority and connection state in the tasks queue. The last module that's worth mentioning in our offline architecture is storage. This module is responsible for persisting all the needed data that server side returned. CoreData is an iOS local database per application, it persists all the context data, while the file repository is maintaining the files kept on local disk. The encryption part is used to decrypt stored data when needed. It's decoded into the memory in real time.
Web API
To be able to store all the data locally on iPad we needed to refine and add some functionalities to our REST based Web API. We needed to think about how the data flow would look. It was also one of our challenges, because we had to reinvent the way the app communicates with the server side. After a few iterations, we found a clear way to pass all the information needed for offline mode.
Storage
Storing data on iPad is a rather simple thing to do, but is more difficult when data needs to be well organised and available for fast access. We developed a way to organise files in conjunction with the CoreData database. The queries to read or write the files are sent to the File Repository. This then reads the file and sends it to the Encryption mechanism. This data flow model is very stable, reliable and fast.
Security
One of our most important requirements was to secure and prevent data stored within the app from being compromised. We had to consider every scenario of how data could be compromised, from an IT specialist trying to get information from the iPad to a user that leaves a logged-in session unsecured.
We did some research on available technologies and found a way to secure the downloaded content. All the data is fully encrypted, and when needed, it is decrypted in real time. In our app's physical layer the encryption was a necessary thing to do. We also used native platform security features such as keychain and device content encryption. As for downloading the data, we decided to encrypt the data that is transferred using SSL encryption. Also, if the user is away from the iPad, we implemented a Pin Lock mechanism to prevent unauthorised access. After a few (configurable) minutes of inactivity the application will lock itself, showing the user a PIN screen. To unlock the app, the user has to enter their private PIN.
Manage eForms and Workflows
Another crucial thing was to make eForms and workflows available for clinicians while offline. Our challenge was to make them available but also to be stable and reliable processes. We found a solution for this problem - we decided to make a special type of eForms that can not only be used in online mode but are optimised for offline mode. These eForms are downloaded as soon as the user logs in and are cached allowing the user to interact freely with them regardless of their connection. Once the eForm is submitted by the clinician it is added to the queue and seamlessly sync'd back to Evolve when a connection is established.
Lessons Learned
I believe that after each iteration, after each completed project there are always some things that we learn to make it better in the future. Before we released our first Evolve for iPad app with offline mode and the tests were successful, we asked ourselves as a team what were the things to consider to work better in future:
Offline first
The biggest lesson we have learned is that it is really hard to add an offline capability to an existing app that is already designed for online only mode. Any future apps we build we follow an offline first design principle to ensure offline is built into the app from day one and everything else is built around this.
Optimisations
We have robust test processes in place within Evolve including extensive stress testing across our product stack. We soon learned this same test approach was equally important when building an iPad app. During the implementation it was clear that only a wide range of high stress tests can identify areas for improvement within our app. Our test engineers look for these during every test stage. If one shows up in the test stage we can implement a quick fix for it. This agile approach to continuous improvement and optimisation is a key part of our development process.
Conclusion
The offline feature for the iPad app was a very good move. It allows clinicians to continue their work even if they are not connected to the network. I'm very glad that I have joined Kainos and jumped in to a very exciting project - Evolve for iPad. Every day in our project is an interesting challenge.