In my last installment I described what a DIL Environment is and how it can negatively impact a mobile application that relies on web services. When developing a mobile app there are a number of scenarios you may face regarding the amount of control and DIL support you have with the backend web services you are consuming:

  • Custom Purpose-Built Backend: A custom backend that your team designs, controls, and configures to support DIL scenarios specific to your application.
  • Platform As A Service (PAAS): A backend utilizing a platform like Azure, ApiOmat, or Amazon Web Services that may offer some built-in DIL support which can be implemented and configured.
  • Virtual Blackbox Backend: A back-end that you have absolutely no control over and provides no DIL support.

In this article I will be examining the third scenario, a virtual blackbox backend. In order to maintain functionality for the mobile application in a DIL environment in blackbox backend scenario all DIL support must be implemented client-side within the mobile application itself. This is a common situation when it comes to enterprise and and third party application development.


Offline Caching Support- Preserving core application functionality when disconnected

How can a mobile application like this remain functional when it is cut-off from its web service data stream?  The only way is to cache incoming data locally on the mobile device for offline use. The complexity and amount of data consumed by the application would be factors the developer should consider when determining the type of data store and its implementation. One the most common methods would be to leverage an SQLite database within the mobile application to store the incoming data. Xamarin offers excellent support for SQLite database implementation, but there is no framework for resolving an optimal caching strategy.

When creating a local store there is also the need for custom logic to be implemented to manage the data. The storage space on the mobile device is limited. It is unlikely all of the data supplied by the webservice can be cached on the mobile device indefinitely due to the device’s local storage space limitations. Some applications may work best with a FIFO (first-in, first-out) logic applied to the data caching process. This logic could be triggered either when the local data store reaches a predetermined total size on the mobile device’s local hard drive, or the remaining space on the device’s local drive drops below a critical level. At that point old data would be purged to create space for new incoming data. In some cases it might make sense to give users the option to override that logic on specific data objects that may be critical to the user’s purpose.

There must also be custom logic implemented to save and track changes the user makes to the data as they work offline. When the device finally reconnects to the network there needs to be logic to manage the update process. Depending on the amount of data kept in the local store there is a good chance that pushing the entire contents of the local store back to the web service for update would be impractical. Custom logic within the mobile application itself must be implemented to track changes so that only new data is pushed to the web service for update. This strategy would save time and bandwidth, both of which may be critical to the user.

There is no out of the box existing Xamarin framework to support this caching. Each developer must roll their own version and think through all of the use cases.


Security Issues- What is the nature of the data being stored?

Depending on the purpose of the application, especially medical data, it is a possibility that the data being cached on the local store is sensitive or private in nature. The presence of malware on the mobile device where your application is in use is a possibility that should be considered. It may be necessary to encrypt the data being cached by your application in order to prevent malware from mining data out of your application’s local data store. Xamarin does support data encryption, but developers typically have to download 3rd party tools to build effectively.

Another issue to consider is if your application requires secure user login. Typically user authentication is handled by backend web services, so how can a user login to the application when disconnected? A custom offline login process must be created and implemented within the application. Validated login information must also be stored locally on the user’s mobile device for offline authentication process’ utilization. Storing login information locally would require an encrypted local store in order to keep users’ credentials secure.

Additionally, when working in a blackbox backend scenario there is typically no way to obtain validated login information by request from the web service. Seemingly the best (and possibly only way) for the mobile application to capture validated login information is to store usernames and passwords when a successfully validated login to the webservice occurs. This solution is limited and would only store the login information of users that successfully log in on a specific device. Authorized users who have not previously logged in on that specific device would not be able to login on that device while it is disconnected.


Battery Life- Is this a critical issue for your user?

When a device becomes disconnected from the network it begins scanning for a new connection. This scanning can consume a lot of power and drain the device’s battery very quickly. Accelerated battery consumption is potentially a big problem for end-users if they are in a situation where there is no access to electricity. Within your mobile application it may be wise to implement logic that alerts the user when the device becomes disconnected from the network and then offers options to the user for the device’s network scanning behavior. It may be possible to override the device’s default network scanning behavior in order to give the user the ability to change the time interval between scan attempts or stop the device from scanning for a new connection altogether. All of these options would help to extend the battery life of the device. The user should also be given the option to re-enable the network scan when the user is back within range of the network. While the OS of mobile phones do implement battery saving techniques, Xamarin developers don’t have existing tools built into the framework.



In this installment I have taken a look at the challenges presented in attempting to compensate for the limitations of a DIL environment when there is no support for this scenario from the web-services your mobile application consumes. There are many aspects to the problem that must be considered, and the implementations of these solutions will largely depend upon the priorities and purpose of your application. When dealing with a virtual blackbox backend there is a lot of work put upon the application development team to find and create custom solutions and implement them within the mobile application itself.

Xamarin would be a great tool for this scenario when the application being developed is required to be deployed on both Android and iOS platforms. The majority of the custom logic required to implement the DIL solutions I described would be shared in both platform iterations. Sharing that amount of code would reduce development time and allow for faster and less costly deployment across multiple platforms. A DIL environment creates many challenges, but we here at Bytelion relish the opportunity to solve problems and create custom solutions for our clients.

Stay tuned for our next installment as we explore newly created tools and techniques to support DIL using Xamarin!

Leave a Reply