Data Startup in Mobile Applications – part I

rsz_sqlitegeneration

In mobile applications, data is a critical matter: It always has to be available and ready to your users. This is even more true for enterprise applications, if data takes a long time to load, sync or is only partially downloaded from the server, it will reflect very poorly on your product quality.

Internet instability can have concerning effects. One such example is if the app stops downloading a payload, you can retry until it is completed. However, that might take a long time, and you might have to start the communication from scratch.

Furthermore, in applications with highly structured data, partial information is useless. For instance, If you download order details which rely on product data, but products have not been downloaded, can we display order details?

Goals

With the previous discussion in mind, we can extract three major goals for our process flow:

  • If internet drops, resume download.
  • Have all your user’s data ready.
  • Fast and reliable.

Proposed Solution

The solution I’m proposing has a simple flow. Once the user is logged in to the app, it will send a request to a Backend API, then it will will check in a file storage if the SQLite database file has been generated recently. If not, the API will create the SQLite file and make it available for the mobile app to download it, simple eh?

  1. The mobile app requests the database from the API and blocks the UI
  2. The API checks if the database exists
    • If the database does not exist, generate and save it
    • Return the database to the client
  3. The mobile app receives the database and allows the user to begin interacting with the app.

SqliteGeneration

If you want to take a peek at the POC code, that covers this workflow end to end, check it out in my Github repo. The demo project was built using:

Reliability

Treating SQLite db as any other type of download task, gives us management power, and if connection drops we can resume downloading. Moreover, we can be sure that all data we need will be available to our user, once the file is downloaded.

Performance

Delegate the heavy work to the backend. Even though our phones are powerful computers, they do not have the processing power and scalability of cloud providers, such as Azure or AWS.

What is next?

I will cover each and every step of the solution that was laid out in this post in a part II and possible part III. I would also like to thank Mr Dylan Berry and Allan Ritchie for all the meetings, code pairing and guidance.

throw new CauserException();

References

One thought on “Data Startup in Mobile Applications – part I

  1. Hi great post looking forward to the future series regarding syncing, etc.

    What was the main advantage of building up the DB server side, vs just downloading the data via endpoints and having the DB build up on the phone? I feel there is overhead in building up the DB, uploading to Blob, then having the client download.

    Also you mentioned your conversion of the MS SQL Data into SQL Lite was in memory, however it looked like in your demo the SQL Lite DB is still built on the API file system then uploaded to Blob. Do you still need to interact with the file system server side?

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s