For example,app was not visible in the background,system need memory for other app and kill the app process,then user restart the app.Will the #Extra annotation restore the data automatically？
No. Extra is for extracting the extras from the Intents coming to your Activity. To save and restore fields you should use #InstanceState. You can annotate the same field which you already has #Extra.
BTW AndroidAnnotations is just a wrapper, so these concepts are coming from core Android.
Related
I found that DJISDK requires:
the app user to agree bluetooth usage
update database and download it
then, the app can be registered (provided DJISDKAppKey is set properly in info.plist and so on).
My question is, why DJISDK need to update database and download it again?
What's the content of database?
It's a "fly safe" database, containing data about areas where one is not allowed to fly.
If the database is not included in the package (to reduce package size), it must be downloaded once the application starts.
The method you mentioned is for monitoring the progress of the download (because the database is not very small, downloading it can take some time).
If my objective is to create a cloud backup that a user can restore if they accidentally delete my app or a bug causes data loss (no need to share data across devices), what's the simplest option to backup user CoreData daily?
(Note: The occasional full iPhone backup isn't sufficient)
When I read about CloudKit I see things like:
You might wonder why you should choose CloudKit over Core Data, other commercial BaaS (Back end as a Service) offerings, or even rolling your own server...
But that's a problem because I would like to continue using CoreData! I do not want the user to depend on the cloud for data. I don't want syncing problems, online/offline issues, etc.
I would also like to avoid having the user login or create an account. According to Ray Wenderlich:
Since CloudKit uses the iCloud credentials entered when the device is set up (or entered after set up via the Settings app), there’s no need to build complicated login screens.
I see some apps use Facebook login but I'd even like to avoid that! So can I use CloudKit to avoid login screens but also still use CoreData?
Although code answers are great, just a general answer on what API/design-pattern is used for this type of functionality would suffice.
Yes you can use CloudKit at the same time as CoreData to do this and it does avoid the login and cost overheads of many other cloud alternatives.
However as the two data models are not related, if your data is complex there will be a significant amount of code necessary to covert between them whenever the user selects to backup or restore.
Are you sure relying on the normal iOS backup functionality is not sufficient?
I created a framework to share my data objects between the App and the extension. This includes the data model and the sqlite file with my Core Data db.
I am concerned of what might happen if both App and Extension try to access this shared sqlite db.
What could go wrong if the App is making some changes to the db in the background while the extension is using it?
What's the best practice in this case?
As #CL notes, SQLite is fine with this. But you're not using SQLite directly, so you may need to do some Core Data-level work to maintain consistency. With an iOS app and an extension, you have two separate processes that can make changes to the data. Your code needs to account for this.
If your app extension only displays data (for example, a "today" extension that only displays data created in the app), you probably don't need to do anything special. If your app is running in the background and creating new data while the extension is visible, it's possible that the extension's data could be slightly out of date. If that's important, you can refresh it. But today extensions typically aren't visible for very long, so it's probably not worthwhile. In this case I'd use NSReadOnlyPersistentStoreOption when setting up the extension's Core Data stack just to be clear about the intention and prevent inadvertent changes.
If your app extension creates new data or modifies existing data, your app needs to be aware of this and respond appropriately. What changes you would make will depend on how exactly the extension handles the shared data. For modified data, your app probably needs to call refreshObject:mergeChanges: on any in-memory managed objects with NO as the second argument. It also probably needs to redo any fetches where the changes might affect a search predicate. That'll ensure you're getting the most recent updates. For new data you would need to re-fetch any data the app is working with to get new additions/deletions. A good time to check would be when the application comes to the foreground (i.e. when UIApplicationWillEnterForegroundNotification is posted).
I am creating an app where data needs to be displayed right away from the local datastore. I fire off a background thread when the app starts to determine if iCloud is available.
I looked everywhere and can't find the solution to this: when iCloud becomes available, can I change the "options" on the persistentStore to start using iCloud transactions?
I'm not sure what the proper approach is in this situation. Everything I try causes the application to crash.
Originally I had it so the iCloud checking wasn't in a background thread and the app worked fine, but occasionally timed out.
You have not to know when iCloud becomes available. You just work with data but you don't send them directly to iCloud. iOS does it instead you. So only it knows when and how it should send data.
No, you can't change the options on an NSPersistentStore object once it exists. You can only specify the options when adding the persistent store to the NSPersistentStoreCoordinator. The closest you could get to changing options would be to tear down the entire Core Data stack and start over with different options.
That wouldn't help, though, because:
Even if you have detected that iCloud is available (I'm guessing using NSFileManager, either via its ubiquityIdentityToken or by calling URLForUbiquityContainerIdentifier:), your call to addPersistentStoreWithType:configuration:URL:options:error: might still block for a while. If there's new data available in iCloud, it doesn't start downloading until you add the persistent store, and that method doesn't return until the download process is finished. And sometimes, iCloud just makes that method block for a while for no readily apparent reason.
If you let the user make any changes to the data while using non-iCloud options, those changes will not get automatically sent to the cloud later. Core Data only sends changes to iCloud when the data changes while iCloud is active-- which makes it generate a transaction. You'd have to load and re-save any changes the user made, or those changes would never make it to the cloud.
You have, unfortunately, hit on one of the major stumbling points when using Core Data with iCloud. You can't make the full data store available until Core Data finishes communicating with iCloud-- because your call to add the persistent store doesn't return until then. And you can't do anything to speed up that process. This is just one of the headaches you'll run into if you continue trying to use iCloud with Core Data.
Depending on the nature of your data you might be able to use two data stores, one purely local and one synced via iCloud. You could make the purely local data store available while the iCloud one tries to get its act together well enough to be useful. If you stick with one data store though, you're stuck with the delay.
What happens to the app when it is killed/terminated from the multitasking tray (i.e double click the home button and delete it from there)? And i relaunch the app again by clicking on it? Consider this scenario. I save some variables (global variables) and i save some values to them. I killed/deleted the app from multitasking tray and relaunched it. I no longer have variable values. How can i store them through the entire process of app life cycle and they can be changed when someone changes within the app life cycle. If you need more information please ask. I have been saving the values to a plist file.I created a settings bundle and saving values to them as global variables..is it the way to go?
To save data even after the app is killed/terminated, you have to use persistent storage. There are a number of different ways to do this. A few of these ways are using NSUserDefaults, plists, or CoreData.
See these links, and try to find out what's best for what you're trying to do.
iOS persistent storage strategy
Use SQLite, plist, or something else?
You should also check out the iOS development lectures, there's two parts and the first part covers persistent storage in great detail. It's called Effective iPhone App Development. I recommend watching both, but the first part of the first one would answer your questions.
https://developer.apple.com/videos/ios/