Just wondering on how frequently I should sync data from Game Center to the device? The first time the app is run, every time the app is run or once every x number of days?
I am trying to ensure that a user has the same achievements and high scores if he/she gets a new phone or deletes the app and re-installs it.
Any insight would be great!
If you want to guarantee the latest data, then you should try to update the data every time the app is run.
If your sync process is scheduled to run in the background, you can even sync every time the data changes in addition to every time the app is launched.
If you are syncing just the deltas this should not be very expensive to do
my two cents ;)
Related
I'm developing Windows Metro App and in my App I need to download some information(about 60Mb, every time) from server in background. Download should occur regularly, for example every 8 hours. So I tried to use Background Task, but there are some CPU and network quotas(https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh977051.aspx), and I can't do this. Could somebody help me with advice in this problem?
Instead of attempting to do the entire transfer in the background task itself, have the background task start a background transfer, which runs independent of the task and independent of the app as well. See the topic, Transferring Data in the Background, https://msdn.microsoft.com/en-us/library/windows/apps/hh452979.aspx. You can run the background task periodically according to the schedule you need, and it will easily stay under CPU and networking quotas because the background transfer doesn't count against that.
I am using iCloud to store sync user preferences between devices. On the device, these are stored in an array of 'Favorite Teams' in NSUserDefaults, and I am using MKiCloudSync to mirror them to the NSUbiquitousKeyValueStore. Changes on one device are propagating to the second device well.
But I am not sure how to prevent the cloud data from being wiped on the first launch after a new install. Here is what's happening:
Device A launches for the first time. App finds nothing in the cloud. User adds multiple items to the array in NSUserDefaults. Changes are synced immediately to cloud.
Device B launches for the first time, but is offline. User adds a single item to the NSUserDefaults array, then remembers the app supports iCloud, so finds some wifi instead.
Device B pushes its version of the defaults to the cloud (with only one item). Device A pulls it, effectively wiping out all of the teams added on Device A.
Is this a limitation of iCloud or is my implementation naive? The docs address a similar issue where a 'highest level' is synced, and adds application logic to never overwrite this value with a smaller value. That's fine when there is some clear business logic to adhere to (higher level is always the one to keep), but when data is more arbitrary, I don't see how I can determine what to do.
Or is it because I am using an array in NSUserDefaults for 'Favorite Teams' and replacing it wholesale? If I used separate keys for each team, perhaps they will be synced independently, based on time code?
Any time you sync a value for a specific key, you run the risk that it will be changed by a different device using the same account. The iCloud service chooses the winning value for you, makes updates, and notifies you when it's done. This is a limitation of iCloud and of your app, and is a simple example of why syncing is hard. What if your step 2 above looked like this:
Device B launches for the first time, and iCloud is available. The app downloads the current data from device A. The user changes their mind and deletes all the data they created on device A. Then they a single new item.
Well, what then? Step 3 still happens exactly as you describe it, except that this time the incoming data is what the user wants. You could refactor your data but the same kind of situation will still be possible.
One option is to keep a non-syncing local copy of the data, so that you can compare incoming changes with the previous local state. What to do when they're different is up to you. Just don't forget that even dramatic changes might well be exactly what the user wants, and not a syncing issue that needs to be fixed. Or, they might be something that would lose data the user wants to keep. Resolving this conflict is your job.
I'm syncing a list of table view items via iCloud. When would be best to perform the sync. Here is my understanding of the various options.
didFinishLaunchingWithOptions - this will only get called when the app is launched. As most users send the app to background, rather than quit, it is likely this method won't be called very often.
applicationWillEnterForeground - this will happend every time the app is opened from a background state, if the internet connection is slow, this could cause a pause is the UI displaying?
applicationDidEnterBackground - I believe we only have 5 seconds to perform any actions, so a slow connection might mean we can't sync.
What are your thoughts best time to sync?
Well, besides the fact that a document saves every so odd amount of seconds, the best time to sync with iCloud is very dependent on the circumstance.
For example, if you have created a brand-new object that would be lost if not stored to iCloud, it's probably a good idea to do a sync with iCloud right away.
On the contrary, if you have created a brand-new object that wouldn't be lost if not stored to iCloud due to it being saved within Core Data, then maybe you can combine the save into one elsewhere given that you're concerned about the speed and CPU that the sync will take up.
Microsoft's documentation states:
Background tasks are meant to be short-lived tasks that do not consume a lot of resources.
It also says:
Each app on the lock screen receives 2 seconds of CPU time every 15 minutes, which can be used by all of the background tasks of the app. At the end of 15 minutes, each app on the lock screen receives another 2 seconds of CPU time for use by its background tasks.
I need to run a background task every two minutes to update my live-tile.
My app is a lock-screen-app.
Computation is within the CPU and network usage constraints
Can I create a permanent background task (e.g. something which polls a web service and pulls information, waits and loops) to create a OneShot TimeTrigger every two minutes or is there a better way of doing this?
My concern with the background task option is whether the runtime would deem the task inactive while it was sleeping and close it or something else like there's a limit on the number of times a live tile can be updated within 15 minutes...
Yes, if by long lived you mean under 25 minutes.
Time triggers cannot execute more frequent than 15 minutes. Creating a OneShot trigger that executes in 2 minutes is, that's an interesting idea and should work. Yes, background tasks can register other background tasks to keep this chain going. Should the user's machine be off when it execs it will queue later.
Having said that, updating your tile that frequently & using a background task is not a wise solution. Because, it is unreliable. Background tasks can be disabled, for one. But every 15 minutes, you are going to exceed your quota. Try using a Scheduled tile instead.
There is an app in Windows Store called "The Time" which shows current time (every minute) on its Tile. The app can do this without registering any Background Task.
How can it do this?
UPDATE: it seems that it schedules lots and lots of tiles!
Because if you draw back the computer time, it will stop working.
However, I don't know how many tiles it schedules and how many tiles it is possible to schedule?
From the author himself:
Live tile updates may be scheduled
Applications may be given slices of time via the background task infrastructure
So, simply, when The Time’s background tasks are executed by the OS they queue up a number of live tile updates.
As far as I know this is not possible in Windows 8 - the background task for updating tiles can run every 15 minutes, but not more frequently.
Being productive in the background – background tasks