Reputation: 1091
I am working with an iOS app that connects to a backend server using REST APIs to retrieve configuration data. The configuration data is recieved as JSON and eventually persisted locally using NSUserDefaults. The general flow for a piece of configuration data is as follows:
The configuration data is fairly static (it doesn't change much over time), but the app does need to refresh it every so often (i.e., 30 minutes). The approach thus far has been to just dump and replace the local data each time rather than trying to implement incremental updates which would require a complete re-design.
This approach seems to work fine as long as the configuration data is fairly small. However, recently we have seen pieces of configuration data that are >20MB of JSON. In those cases, the approach outlined above is not working as it appears to require too much memory to process end-to-end. In the xcode performance tab, the app's memory spikes to over 500MB and the process typically crashes, at least on older devices (i.e., iPhone 6).
Before I start redesigning the whole process, I am wondering if there is more optimized that would still allow dump and replace but with a smaller memory footprint. Is there a more efficient way to go from an HTTP response to some sort of persisted storage if mapping is required? Would core data be well suited to the dump and replace approach? I am thinking not.
Upvotes: 0
Views: 100
Reputation: 2315
I think saving data to CoreData or SQLight is a better idea instead of saving to userdefaults. This may solve your problem, as all data are not loaded in memory to access to one.
Upvotes: 0
Reputation: 10591
If memory is your main concern, you might have a look at https://github.com/stig/json-framework, which lets you parse in a "chunked" fashion so you don't need to have the entire JSON document in memory at any time.
Upvotes: 0