tvOS restricts local storage usage

[tbaggett]

Hi Edwin,

Per the tvOS documentation, local storage is very limited for tvOS apps. I wanted to get your thoughts on disabling local EVCloudData caching on tvOS or forcing it to store the local files in the cache folder instead of the documents directory. I will be happy to implement what is needed once I hear from you. Thanks!

Apple documentation on tvOS storage:

Local Storage for Your App Is Limited

The maximum size of an Apple TV app is limited to 200 MB. Moreover, your app can only access 500 KB of persistent storage that is local to the device (using the NSUserDefaults class). Outside of this limited local storage, all other data must be purgeable by the operating system when space is low. You have a few options for managing these resources:

• Your app can store and retrieve user data in iCloud.
• Your app can download the data it needs into its cache directory. Downloaded data is not deleted while the app is running. However, when space is low and your app is not running, this data may be deleted. Do not use the entire cache space as this can cause unpredictable results.
• Your app can package read-only assets using on-demand resources. Then, at runtime, your app requests the resources it needs, and the operating system automatically downloads and manages those resources. Knowing how and when to load new assets while keeping your users engaged is critical to creating a successful app. For information on on-demand resources, see On-Demand Resources Guide
  This means that every app developed for the new Apple TV must be able to store data in iCloud and retrieve it in a way that provides a great customer experience.

[evermeer]

The directory is currently set to the documents directory in the init method. I thought about what would be the best location for the data files. Since it works like a cache, maybe the CachesDirectory is a better location. At least for the Apple TV we should set it to that. For iOS i'm inclined to think that the CachesDirectory would also be a better location. If the data is gone, it will be downloaded from CloudKit anyway. Don't you think?

This would be the easiest change. Just replacing the .DocumentDirectory on line 173 with .CachesDirectory

[evermeer]

I changed it to ChachesDirectory and pushed that to Github as version 2.13.0 Be aware that if you upgrade an app on a device, that it won't be able to read the old cache data and that all data has to be downloaded again.

[tbaggett]

Great, thanks for taking care of that. I was going to make the change as soon I finish some enhancements that I hope you'll like and merge in. I've added support for optional notifications via NSNotificationManager of all the existing state change events, and a new "Retrieving" event if the data isn't cached locally. It makes it easy to know when a loading display of some sort should be displayed. Both are non-breaking changes. I will send a PR your way once I've finished testing everything.

[evermeer]

Sounds good.

[evermeer]

Hi @tbaggett,

I have let it sink in. Maybe there is an alternative instead of the Retrieving event. You could change the isFinished variable in the callback to status and pass it an enum. The enum would have the following values: FromCache, PartialResult and FinalResult. You would call the FromCache when the data is from the cache, PartialResult if there is a cursor, FinalResult if there is no cursor. I think this would be easier for the situations where you don't care what the status of the request is.

[tbaggett]

Okay sure, that should work just as well, provided that you're okay with it being called with the PartialResult status immediately after the cache check fails. If you prefer the PartialResult status not be returned until the first block of data is received from iCloud, then I would suggest the enum also having a Retrieving state that can be returned as soon as it is determined that the cache doesn't contain the data. That's the point in time that I'm interested in.

Let me know if you prefer the PartialResult or Retrieving state to be returned at that point. I will make the needed changes to the PR I'm working on. Thanks!

[evermeer]

I did not thought about that scenario. I think an extra Retrieving state would be better that a PartialResults state. I wonder if all the different states will be clear to whoever will use the library. I think it's still ok. Maybe you can can think of something that works better? Maybe you get an idea while working on the issue.

[tbaggett]

I believe your suggestion will work well. I will try to document the enumerations clearly so everyone will understand when they are expected and what they mean. You're welcome to make modifications to my PR or I can make further changes once I send it to you.

[tbaggett]

PR created: #30

[evermeer]

Cool, I will have a look at it this evening (about 10 hours from now)