To what extent is it necessary to use a DB and ContentProvider in an Android REST application?

Question

Android

Hello!
I looked at the well-known Virgil Dobjanschi patterns for implementing Android REST applications. Looked at some more descriptions on habré and in other places. Everywhere it is strongly recommended to use a database and, accordingly, a content provider to access it. Those. in short, the algorithm is as follows:
1. request to the server
2. getting the result and updating the database
3. Notifying subscribers that a record has been made in the database
4. Updating the UI from the database
The arguments in favor of using a database are not entirely clear.... For example, we are making an application for a restaurant, the functionality is limited to authorization, viewing and ordering dishes. Well, respectively, the main requests to the server are immediately visible: authorization, getting a list of dishes, getting details of dishes, creating orders, viewing old invoices, and a few more insignificant requests. Here is a question about this example. What is the point in saving dishes in the database if information about dishes can change on the server at any time and anyway, every time you load the list of dishes and their details, you will need to make a call to the server, because infa could change since the last time.
Such cases as "during the request for a list of restaurants, the user minimized the application and the list did not load into the UI" and similar cases are treated with the button "

Answer 1

It just seems to you that there is no need to cache. In fact, caching solves a lot of problems:
Examples:
When developing an application, you should always keep in mind that a lot of users have very weak devices with a slow Internet connection or no connection at all.