Do you want to cache some data in your app, but you’re unsure how to implement it in your codebase? I’ve been in this situation myself and would like to tell you how I tackled this problem and give a few examples of how you could do this. In one of my previous Android apps, I found a few GET endpoints that were called very frequently. The network calls were initiated by many different places – view models, use cases, repositories, etc. Each caller was making an individual network call, locally using the response, and wasn’t sharing it with the other callers. This was very inefficient. Do you have a similar situation in your codebase? This resulted in unnecessary network calls and battery drain. This was noticeable to the users since we were operating in Emerging Markets where network traffic is costly and phones aren’t the most capable. Also, we were putting a redundant load on the backend, and as our user base kept growing, our requests started to be blocked by the backend rate limiter. To fix this, I cached the data in runtime memory and created a global Single source of truth to read and mutate it. This allowed me to share the data and replace most network calls with a cache read. This was a good start, but there was another problem. The fetching of the data wasn’t synchronized. If multiple callers needed the data at the same time, but the cache was empty, they were still making individual network calls, for example, on login or app launch. To fix this, I added a synchronous fetch to the existing solution. This allowed me to synchronize the calls and share the data when it was simultaneously requested by multiple callers. Finally, there was a problem that this data was needed on app launch, but it wasn’t available in runtime memory after a process restart. I had to make a network call to fetch it and display a loading spinner in the meantime. This slows down the app launch and even makes it fail if the network call fails. To fix this, I added persistence to the existing solution. This allowed me to use a cached version of the data on app launch and unblock it from waiting for a network call. Do you also have data in your app that you can benefit from caching? Impact As a result, the number of requests per second (RPS) to the cached endpoints has decreased by 66%. This was measured on the backend side. Given that these were the most frequently accessed endpoints, this has significantly cut down the cost of running our backend services. Secondly, the app now launches faster and always successfully since it doesn’t depend on a network call. Instead, it now reads from a persistent storage, which is much more reliable. Previously, if the network call failed, an error UI with a retry prompt was displayed. Runtime Cache As the first step, I cached the data in runtime memory and created a global Single source of truth to read and mutate it. This allowed me to share the data and replace most network calls with a cache read. Previously, each caller was making an individual network call and using the data only locally. Now, callers can access the data through a shared repository. Internally, I stored the data in a reactive data holder – MutableStateFlow, which allowed me to make it observable. This turned out to be very handy since my screens were already implemented using MVVM and could react to the data changes. For example, imagine the following scenario. The data is used in Screen A and Screen B, the user navigates forward from Screen A to Screen B, changes the data in Screen B and then returns back to Screen A. In this case, Screen A will have to be manually reloaded unless it can observe the data and react to its changes. https://gist.github.com/vlad-kasprov/ca73e916708493381c33f2aaa6999873?embedable=true Notes All operations are thread-safe because value and update are thread-safe.
In this example, null is the initial and empty value, but you can adjust the code to have other behavior.
observe() emits only distinct values because MutableStateFlow skips values equal to the current one.
If you prefer RxJava, you can use BehaviorSubject instead of MutableStateFlow. Runtime Cache with Synchronous Fetch As the second step, I added the ability to synchronously fetch the data by calling updateAndGet. This is needed when multiple callers try to simultaneously fetch the data. For example, on login or app launch. Previously, if multiple callers tried to fetch data at the same time, this could result in a race condition and multiple network calls. Now, the fetch operation is synchronized, only one network call will happen, and the response will be shared with all the awaiting callers. Furthermore, by passing an update strategy, callers can specify when to fetch fresh data or a cached version can be returned. You can implement other strategies based on your use case. https://gist.github.com/vlad-kasprov/83337787c0026fec59a88e0723fcebef?embedable=true Notes All operations are thread-safe because they are synchronized with Mutex.
You need to write your own implementation of ExampleRemoteDataSource. Runtime & Persistent Cache with Synchronous Fetch Finally, along with caching the data in runtime memory, I persisted it as well. This is needed on app launch when the data isn’t available in runtime memory after a process restart but is required to display the first screen. Previously, on app launch, before showing the first screen UI, I had to make a network call and display a loading spinner until it was completed. If it failed, I had to display an error UI with a retry prompt. This meant that the user couldn’t interact with the app until that network call had been successfully completed. Now, on app launch, I simply load the previously cached data from the persistent storage. This made the app launch faster and always successful. https://gist.github.com/vlad-kasprov/c5e3f0a2efc104f654eb7ebd9856834e?embedable=true Notes All operations are thread-safe because they are synchronized with Mutex.
The initial value is loaded from the persistent storage during ExampleRepository construction. Until the load has been completed, observe delays emissions and get returns null.
It’s up to you how to implement persistence, so write your own implementation of ExampleLocalDataSource. You can store the data in a database using Room or simply serialize it into JSON and use SharedPreferences. Conclusion This three-step refactoring process allowed me to safely and incrementally introduce caching into the existing codebase. Each step delivered measurable value to the company and the users, such as fewer network calls and a faster and more reliable app launch. Can caching benefit your app as well? If the answer is, but you’re unsure where to start, consider my story as a possible guide and example. Do you want to cache some data in your app, but you’re unsure how to implement it in your codebase? I’ve been in this situation myself and would like to tell you how I tackled this problem and give a few examples of how you could do this. Do you want to cache some data in your app, but you’re unsure how to implement it in your codebase? In one of my previous Android apps, I found a few GET endpoints that were called very frequently. The network calls were initiated by many different places – view models, use cases, repositories, etc. Each caller was making an individual network call, locally using the response, and wasn’t sharing it with the other callers. This was very inefficient. Do you have a similar situation in your codebase? Android GET individual locally sharing Do you have a similar situation in your codebase? This resulted in unnecessary network calls and battery drain. This was noticeable to the users since we were operating in Emerging Markets where network traffic is costly and phones aren’t the most capable. Also, we were putting a redundant load on the backend, and as our user base kept growing, our requests started to be blocked by the backend rate limiter . To fix this, I cached the data in runtime memory and created a global Single source of truth to read and mutate it. This allowed me to share the data and replace most network calls with a cache read. rate limiter runtime global Single source of truth share This was a good start, but there was another problem. The fetching of the data wasn’t synchronized. If multiple callers needed the data at the same time, but the cache was empty, they were still making individual network calls, for example, on login or app launch. To fix this, I added a synchronous fetch to the existing solution. This allowed me to synchronize the calls and share the data when it was simultaneously requested by multiple callers. individual synchronous fetch share Finally, there was a problem that this data was needed on app launch, but it wasn’t available in runtime memory after a process restart . I had to make a network call to fetch it and display a loading spinner in the meantime. This slows down the app launch and even makes it fail if the network call fails. To fix this, I added persistence to the existing solution. This allowed me to use a cached version of the data on app launch and unblock it from waiting for a network call. runtime process restart persistence Do you also have data in your app that you can benefit from caching? Do you also have data in your app that you can benefit from caching? Impact As a result, the number of requests per second (RPS) to the cached endpoints has decreased by 66% . This was measured on the backend side. Given that these were the most frequently accessed endpoints, this has significantly cut down the cost of running our backend services. requests per second (RPS) 66% Secondly, the app now launches faster and always successfully since it doesn’t depend on a network call. Instead, it now reads from a persistent storage, which is much more reliable. Previously, if the network call failed, an error UI with a retry prompt was displayed. faster always successfully Runtime Cache As the first step, I cached the data in runtime memory and created a global Single source of truth to read and mutate it. This allowed me to share the data and replace most network calls with a cache read. Previously, each caller was making an individual network call and using the data only locally . Now, callers can access the data through a shared repository. runtime global Single source of truth share individual locally shared Internally, I stored the data in a reactive data holder – MutableStateFlow , which allowed me to make it observable . This turned out to be very handy since my screens were already implemented using MVVM and could react to the data changes. MutableStateFlow observable MVVM For example, imagine the following scenario. The data is used in Screen A and Screen B , the user navigates forward from Screen A to Screen B , changes the data in Screen B and then returns back to Screen A . In this case, Screen A will have to be manually reloaded unless it can observe the data and react to its changes. Screen A Screen B Screen A Screen B Screen B Screen A Screen A https://gist.github.com/vlad-kasprov/ca73e916708493381c33f2aaa6999873?embedable=true https://gist.github.com/vlad-kasprov/ca73e916708493381c33f2aaa6999873?embedable=true Notes All operations are thread-safe because value and update are thread-safe. In this example, null is the initial and empty value, but you can adjust the code to have other behavior. observe() emits only distinct values because MutableStateFlow skips values equal to the current one. If you prefer RxJava, you can use BehaviorSubject instead of MutableStateFlow. All operations are thread-safe because value and update are thread-safe. thread-safe value update In this example, null is the initial and empty value, but you can adjust the code to have other behavior. null initial empty observe() emits only distinct values because MutableStateFlow skips values equal to the current one. observe() MutableStateFlow equal If you prefer RxJava, you can use BehaviorSubject instead of MutableStateFlow . BehaviorSubject MutableStateFlow Runtime Cache with Synchronous Fetch As the second step, I added the ability to synchronously fetch the data by calling updateAndGet . This is needed when multiple callers try to simultaneously fetch the data. For example, on login or app launch. synchronously fetch updateAndGet simultaneously Previously, if multiple callers tried to fetch data at the same time, this could result in a race condition and multiple network calls. Now, the fetch operation is synchronized , only one network call will happen, and the response will be shared with all the awaiting callers. synchronized shared Furthermore, by passing an update strategy, callers can specify when to fetch fresh data or a cached version can be returned. You can implement other strategies based on your use case. https://gist.github.com/vlad-kasprov/83337787c0026fec59a88e0723fcebef?embedable=true https://gist.github.com/vlad-kasprov/83337787c0026fec59a88e0723fcebef?embedable=true Notes All operations are thread-safe because they are synchronized with Mutex. You need to write your own implementation of ExampleRemoteDataSource. All operations are thread-safe because they are synchronized with Mutex . thread-safe Mutex You need to write your own implementation of ExampleRemoteDataSource . ExampleRemoteDataSource Runtime & Persistent Cache with Synchronous Fetch Finally, along with caching the data in runtime memory, I persisted it as well. This is needed on app launch when the data isn’t available in runtime memory after a process restart but is required to display the first screen. runtime persisted runtime process restart Previously, on app launch, before showing the first screen UI , I had to make a network call and display a loading spinner until it was completed. If it failed, I had to display an error UI with a retry prompt. This meant that the user couldn’t interact with the app until that network call had been successfully completed. before showing the first screen UI Now, on app launch, I simply load the previously cached data from the persistent storage. This made the app launch faster and always successful . persistent faster always successful https://gist.github.com/vlad-kasprov/c5e3f0a2efc104f654eb7ebd9856834e?embedable=true https://gist.github.com/vlad-kasprov/c5e3f0a2efc104f654eb7ebd9856834e?embedable=true Notes All operations are thread-safe because they are synchronized with Mutex. The initial value is loaded from the persistent storage during ExampleRepository construction. Until the load has been completed, observe delays emissions and get returns null. It’s up to you how to implement persistence, so write your own implementation of ExampleLocalDataSource. You can store the data in a database using Room or simply serialize it into JSON and use SharedPreferences. All operations are thread-safe because they are synchronized with Mutex . thread-safe Mutex The initial value is loaded from the persistent storage during ExampleRepository construction. Until the load has been completed, observe delays emissions and get returns null . ExampleRepository observe get null It’s up to you how to implement persistence, so write your own implementation of ExampleLocalDataSource . You can store the data in a database using Room or simply serialize it into JSON and use SharedPreferences . ExampleLocalDataSource Room SharedPreferences Conclusion This three-step refactoring process allowed me to safely and incrementally introduce caching into the existing codebase. Each step delivered measurable value to the company and the users, such as fewer network calls and a faster and more reliable app launch. Can caching benefit your app as well? If the answer is, but you’re unsure where to start, consider my story as a possible guide and example. Can caching benefit your app as well?

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Android: An Effective Approach to Building Caches

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

10 good rules for bad App

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

10 good rules for bad App

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps