I have an app that stores data in a coredata db. I save data to the db from a web service when the app is started. The thing is that people can keep their app in the background even for weeks and may see data that is no longer valid. I would like to kind of reinitialize the entire app once it comes from background (a sort of restart, if you will) because i have multiple tabs. Can this be done?
You don't need to restart the app each time it enters foreground. You can disable "multitasking" by adding this to your project's info.plist
Add a new row and select “Application does not run in background” (or type “UIApplicationExitsOnSuspend”) and then toggle the checkbox.
EDIT: (Thanks to Kevin Ballard) It's better if you check if it's been a long time since the last time it downloaded the data and, in that case, re-download the data. You should only disable "multitasking" when you have a really good reason to do that. This is not that case.
Shouldn't you just refresh the UI? Core Data has plenty of notifications for keeping up with the changes in the context, for example NSManagedObjectContextObjectsDidChangeNotification which has all the updates/deletes/inserts with it as well. Just start observing it before you update the DB and you'll see if any changes occur.
No need to restart to reload the UI, all the callbacks are there...
So instead of updating your data in applicationDidFinishLaunchingWithOptions: do it in applicationDidBecomeActive: and use Core Data notifications to update the UI as necessary.
Related
The application I am working on downloads and parses a large xml file to populate UI elements, namely search and a spinner. This is done through an async task. If the user decides to switch out of the application during this, the information is downloaded correctly, but then when the application is resumed, the UI will not be updated.
Is this because the changes can't be made while the application is not active? What is the best way to go about checking whether the UI was not updated on resume? Or instead should I be doing something with the Async task, checking whether the UI thread is available? I'm having a hard time debugging this because it involves leaving the application which ends the debugger.
You can achieve this scenario through the broadcast receive.
Follow the step:
Solution 1:
Step 1;
Register the broadcast receiver before executing the Asyntask.
Step 2:
send Broadcast in onPostExecute method of Asyntask.
step 3:
And then you can able receive your broadcast message in your activity.
and do whatever you want.
Solution 2:
Otherwise you can use Interface Call back for this Scenario.
Hope It will help you.
It should'nt. App being in background means View objects may or may not be there. Actually the entire process may be stopped or just deleted by android.
Use a Service to truly do processing in background. When processing is complete but UI is not there, post a notification to let user know, OR, save the results and provide it to UI the next time it binds to your service and ask for same thing (a.k.a caching).
The application in background may not be live. The O.S may destroy it in case of memory constrains.
The trick is to try an alternate logic.
When the application moves from background to foreground onresume() is called ,you could try saving the data to db and update the content on the resume call.
FYI.onPause() and OnResume() is called when the application goes background and foreground respectively.
I have noticed that for a mobile application, saving on the main thread seems to take a bit when it compares to other applications on the device. Is it recommended to only save Core Data when the application enters the background or when an application closes instead of anytime items are added and sent / received from the api?
That's kind of a broad question, but I've found that saving core data after VewDidAppear statements is better than viewWill statements. Giving the user something to engage with and persisting makes it less noticeable than on a load. However, if a user is used to waiting for something like an activity loop, adding the save to that doesn't tax it too much (IMHO).
Not sure this help, just my experience.
I'm currently working on a new game for iOS using Cocos2D. The game needs to advance states after x amount of time since the first launch. So for example:
State - Time
initial launch
24hrs
48hrs
My first idea was to just get the data and time on first launch and save it to a file. Then I could check it ever now and again to see how much time has passed. The problem with this is I need it to be in realtime so that the changes will take effect immediately once the state is reached. It also needs to continue when the user is not using the app. The functionality I'm looking for is kind of similar to how the iOS strategy games work where you build structures that take x amount of time.
Anyway my question(s) is; is there some sort of library that can accomplish this and how can I get it to continue after the user exits the app?
It can't. There is - apart from kind of misusing video/music playing etc. no way for your app to do work while it is not running.
You have two things you can do to simulate that behavior (and I suppose the strategy games do this, too):
You can calculate at any time while a user is still running your app the points in the future when something should happen (eg a housing structure is finished). When the user leave your app, store these future times as local events - then the user will get notified that something has happened in your game (eg message "The church has been built. Do you want to go to church now?)". Pressing yes will open your app, and you can do whatever is necessary to indeed build the church. So in fact you don't do it at the time when it occurred, but when the user opens your app the next time.
Like 1, but without notification. Just remember when the user leaves the app (eg in your settings, I would use a property list; set it when the app delegate gets the appWillResignActive event), and the next time he starts do whatever would have been done in the meantime - he won't be able to tell the difference :-).
It's all about make believe here :-).
What I'm doing:
I'm pretty new to doing data migrations with Core Data, but I've got everything almost set up and it doesn't seem to be too hard.
When the user opens the updated app for the first time, the database should be upgraded as expected during the app loading. I'm guessing the update won't take more than a few seconds at most, so I won't even let the user know this is happening.
But:
What happens if the user decides to quit the app in the first few seconds while the database is upgrading?
Is this handled nicely? i.e. - does the update continue to finish while the app is shutdown? Or, is the intermediate state of the upgrade saved, and continued flawlessly from where it left off the next time the app is started?
So...
Do I have to worry about this at all (with a large amount of users, I'm sure at least a few users will quit during updating). Or, has Apple taken care of all of this - am I needlessly worrying about it?
Core Data Lightweight Migrations will succeed or fail. When the migration is not committed until the end of the migration process. If the user quits the app at just the right time they would re migrate on relaunch of the app because the transaction did not complete properly.
If the user backgrounds the app and then resumes the execution state of the lightweight migration resumes as well ensuring data integrity.
Information on Core Data Migrations
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmMigrationProcess.html
I have an application that allows you to edit some percentages, however it will only let you commit those changes if the percentages add up to 100. However because the Core Data template includes the save code in the application will terminate. If the user changed something and then exited the application, the item would be of course saved even though it did not add to a 100%.
Therefore I simply decided to comment out the save in the application will terminate. I know the other option would be to use another context for the edit and then merge the changes or setting my context values until the actual save point. However I do not see any harm in commenting out this line, since I save whatever I want in my application when the user clicks the save button, so my question is: is the save on the application will terminate mandatory? what possible consequences could this have?. It is important to note that the application continues to work just fine after commenting this lines (which is what I expected).
Thank you in advance.
-Oscar
You can save whenever you like.
However, you will never know when the app will terminate. Unlike applications on more conventional platforms e.g desktops, the iPhoneOS will terminate your app (from the apps perspective) at random. The only warning you will get will be the applicationWillTerminate message sent to the app delegate. If you don't handle saves there then it is highly likely that at some point, your users will lose data.
I think you should reconsider your design. It sounds like you're putting calculation into the managedobjects that could (1) be handled elsewhere in code or (2) be handled by transient properties. You shouldn't have a condition in which the managedobject can't be saved at the drop of hat. Doing so makes your datamodel utterly dependent on external code for its internal integrity. This causes problem with maintenance, portability and upgrading.
Its not mandatory to save on application will terminate. You can save when ever you feel appropriate for the context of the app.