Mobile application data management

Question

My question surrounds one point - data management in a mobile application . I created a mobile application in which data comes from the server. Data includes both text and images. Below are the steps that I am doing for this:

First start:
1. Get server data.
2. Save the server data in the Sqlite database.
3. Show Sqlite data.

The following launches:
1. Show Sqlite data.
2. Get server data in the background.
3. Delete previous Sqlite data.
4. Save the new server data in the Sqlite database.
5. Show Sqlite data.

I have a few questions on these steps:
1. Is this right? . Another way can display data every time from the server, but it does not display data on the screen right away (depending on Internet speed).
2. I also thought about comparing Sqlite data with the new server data. But ran into a big problem. New server data may have new records or deleted records. In addition, I could not find a suitable approach for comparing each field of the database with JSON data.
So, what is best for comparing local Sqlite data with the data of the new server?
3. Each time I delete Sqlite data and insert new data and then Sqlite screen (which has a UITableView ), it flashes instantly, which is obvious. How to avoid this problem if steps 3, 4, 5 are followed?
4. How can I continue updating data if I return to the screen every time or when the application becomes active? I know NSOperationQueues very well or using GCD . But what if I am crazy and go back and forth to show the screen over and over again. The queue will be the number of NSOperations .

Answer 1

This is a server data synchronization problem, I did it before, and if you can spend time on it, I would say that this is the best solution.

You may need to create and modify dates on the server and local objects to compare them - this will allow you to decide which objects need to be added, updated and deleted. If the server sends you only recently updated objects, you can save a lot of traffic and improve performance (but deleted objects will be more difficult to detect).

If the data is only changed on the server, it is easier when the application can change the data, it becomes more complex (but it seems that this is not your case). It also depends on how complex the database is, of course.

If you don't want to invest some time in this, just collect all the data every time too, even if it's not perfect! Instead of showing old data and blinking, you can simply make the user wait 2-3 seconds at login while you receive new data. Or instead, you can only retrieve data when the application starts, and therefore, when you get to this view controller, it will be ready already.

This is a difficult problem that everyone faces at some point, so I am interested to know what other people will tell :)

Answer 2

This is a good question.

I personally think that downloading data, storing locally and then attempting to sync is a dangerous scenario. It is easy to enter errors, leading and subordinate problems (which data should be the main, if you use multiple devices, etc.)

I think something like this might be working:

1 .. I would try to look at the possibilities of lazy loading data from the server on demand. That is, when the user has a view that should display data, load that specific data with the creation of that particular view. This ensures that data is always in sync.

2. The problem of reloading data from the server from each view can be solved by simply storing the downloaded data as objects in memory (without using SqlLite). The view will try to load the necessary data through your cache manager, and it will serve it from memory, if available. If not in memory, just get the data from your server and add it to your memory cache. The memory cache can be a home data manager that wraps the Dictionary stored on you by AppDelegate , or some kind of global "Singelton" for transferring cache management, storing and loading data.

3 .. When using lazy loaded data and memory caches, you need to make sure that any updates (changes, new records, deleted records) update your memory data model and push these changes to the servers as soon as possible. Depending on the size of the data, etc. You can make the user wait or do it directly as a background process.

4. To synchronize data, you must be sure that you periodically invalid (delete) the local memory entries in the cache and thereby forcibly update data from the server. A better approach would probably be to have the latest updated timestamp for each entry in the memory cache. Thus, a periodic invalidator will only delete “old records” from the memory cache (again not from the server).

To keep the server from unnecessarily loading data, data should still be loaded on demand when the user needs it in the view, and not as part of a “cache invalidation”.

5. Depending on the size of the data, you may need a "cache invalidation". It may be as simple as when xx records are stored, start deleting old objects from the memory cache (not a server, only locally on the device).

6. If data synchronization is absolutely important, you may need to update the memory cache for writing as soon as you allow the user to modify the data. For example. when the user clicks "Change" or similar, you take the latest data from the server for this entry. This is just to make sure that the user is not going to update the record using outdated data and thereby inadvertently undo any made remote changes on another device, etc.

-

I accept it. I do not believe that there is a “perfect right path” for this. But that would be what I would like to do.

Hope this helps some ideas and inspiration.

Answer 3

How about this:

• If data exists in SqlLite, download a copy of "in-memory" and show it
• In the background, new server data is being loaded
• delete old sqlite data if it exists (note that a copy is kept in memory)
• save new server data in sqlite
• load the new sqlite data into the in-memory copy and show it.

If no data was found in step 1, display the loading screen for the user during step 2.

I make the assumption that the data from SqlLite is small enough to save a copy in memory for display in your UITable view (the UITable view will always display data from memory).

It may be possible to combine steps 4 and 5 if the data is small enough to hold two copies in memory at the same time (you must create a new copy in memory and change it with the visible copy at the end).

Note: I'm not talking about error handling here, but I would suggest that you do not delete sqlite data until you have new data to replace it.

This approach also eliminates the need to determine if this is the first run or not. The logic always remains the same, which should make it a little easier to implement.

Hope this is helpful.

Answer 4

You can do the same thing more efficiently with MultiVersion Concurrency Control (MVCC), which uses a counter (like a very simple timestamp) for each data record that is updated whenever the record changes, which means you need to get that data which are updated after the last synchronization call, which reduces the amount of redundant data and bandwidth.

Source: MultiVersion Concurrency Control