Architecting For a Sometimes Connected Application

The modern world is full of options to connect your app to the Internet.  Nevertheless, there are cases where you will have a sometimes connected application.  This situation impacts architecture and needs to be understood before starting.  "Sometimes" is a challenging situation to handle with your architecture.  Thus, it is easier to architect a solution that is always connected.  Better yet, one that is completely stand-alone.

Danger Zones

First, it may help to highlight some of the areas and types of applications that will fall under this umbrella.  Certain building types are often problematic for wireless connections.  These include anything that is mostly concrete, including (in many cases) government buildings, schools, military locations, hospitals, and prisons. Applications that are going to be used by those that travel can also fall into this category.  Some examples are sales applications, insurance or real estate assessors, physical therapists, and athletes.  When in doubt, take a good look at your target user base.

Possible Solutions For A Sometimes Connected Application

The good news is that this is not a new challenge.  There are a lot of people that have gone before you that have found ways to address this.  Also, the solution is generally simple to understand.  It is just the number of situations that need a review.  There is almost a confusing number of options available.

The solution is to provide access to the data when needed.  This option may seem overly simple.  However, it is essential to your approach.  Some applications are ok with being useless in a disconnected state.  In those cases, you can act like the user is always connected and close the app when they are not.  Once you eliminate the "you can't use this unless connected" option, it gets trickier.  You have two main options.  You can cache data or reduce functionality.  Also, these are not mutually exclusive, so you have this choice to decide for almost every piece of functionality.

The Cache Problem

While caching data seems like a simple solution, it is not.  There will come a time when you need to merge data back into the system.  Ask anyone that has had to merge data as to how challenging that can be.  In particular, when both sides of the merge may have changes the same data.  There are usually rules to follow in those cases.  However, getting the comparisons and remediation steps implemented can be grueling.  The process also tends to be full of outliers and other special circumstances.  In these times, remember that slow and steady wins the race.