Now it was time to store the data locally and with `Jetpack Room` it must be child’s play right?

Oh yeah, but before the implementation of any database table, we must make sure the kind of data we want to store and query operations we need to perform. Let’s briefly discuss `Jetpack room` first.

“The Room persistence library provides an abstraction layer over SQLite to allow fluent database access while harnessing the full power of SQLite.” —

In simpler terms, the room makes it easier to create a local database to provide the same experience even when the device is offline. It uses SQLite as a database language making it more robust, efficient, and easy to use. As the Wikimedia Commons handles non-trivial amounts of data, caching data locally can greatly benefit the apps.

The application used the room database to store and retrieve information for the bookmarks and the leaderboard, therefore I just had to include a table to the persisting database. The crucial part was to decide what entities to use and declare the methods to interact with the data in the table.

As they say “There are only two hard problems in computer science: cache invalidation and naming things.”

After a lot of discussion over the cache invalidation, we settled over a 7-day cache invalidation period. That means if the result of an image in the database is false, then we re-query the image from the API only if the database entry is more than a week old. As opposed to when the result is true we need not re-query at all.

You might ask, what if we upload a recently queried image through the app, then the custom selector will show the image as not uploaded.

Yes, that’s correct. I’ll discuss the solution in a moment, hold tight.

After declaring the table entities and creating the access object, storing and using the data to make changes to the UI was the next thing to be done. With the help of Coroutines, asynchronous data fetch and UI update was a cakewalk.

Now to answer the question, as suggested by the mentors, the solution was to update the database entry as soon as an upload is successful from the application. As I could access the database table in any part of the application now, thanks to room, I updated the entry as soon as an upload was completed from the upload wizard of the app.

As a result, the local caching drastically reduced the loading time and API requests to the server, thus improving the overall user experience. Now the user could differentiate uploaded images within no time.

At the end of this two weeks period, I read about unit testing in android, the frameworks available, and the best practices to be followed. The next goal was to write the unit tests for all the functionalities in the custom selector.

To be continued after the first evaluations (Wish me luck) ….



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store