I know quite a few questions have been asked around this topic; however, am penning this as they don't seem to specifically answer my question, & some don't have any correct answer listed.
What I want to do in my iPhone App
Fetch some data when the App is not running (basically, it's a prefetch, so as to quicken it when the user uses the App the next time). What's the best way to do this?
Some Potential Solutions
Those that I could think of & some from Stackoverflow & such resources:
Possibility 1 : Fetch the data at a specific time of the day (maybe after midnight ?). Am not seeing 'clearly' how to do this if this this possible in the first place. Some suggest using a NSTimer -> but the timer is put off when the application is suspended, right?
Possibility 2 : Using local notification (?) But I see that Apple's documentation specifically mentioning that notification is to be used to convey something to the user & so this would defy Apple's doc then, right?
Possibility 3 : Through applicationDidEnterBackground -> beginBackgroundTaskWithExpirationHandler . This wouldn't run the fetch at a specific time of the day though. However, it might serve its purpose of 'pre'-fetching. Is this better than the other two?
Any thoughts please?
as you already know that none of the option you have presented are not going to work with ios and user can always close the background applications anyway so I would suggest that it'd be a good idea to fetch the data for next calendar day whenever the app is running.
As samfisher is saying none of your specs. fit with the Apple active background requirements. The only thing that I can suggest you is to use the beginBackgroundTaskWithExpirationHandler I understand that is a "post fetching" instead of prefetching but I guess is the only way.
The other way, but is a little bit trickier, is masquerade your prefetching with some sort of geolocation, in this way you could opt for an active background. This involve a lot of aspects such as:
Appstore rejection
Battery consumption
There are plenty of app on the appstore that use this trick, I can remember one that calculate data traffic.
Related
I've been doing some tests recently with an app switching between networks (Wi-fi, 3G, LTE, offline). I've been using Reachability when detecting this switches, but I'm not currently happy with the implementation when the app goes in an "offline state" for example.
I'm basically just throwing NSLogs currently when the no-network kicks in, but I've seen it go off in between switches. So my question... how do you best manage these things? Do you give it a delay in after no-network of a few seconds before going into "offline state"? Or are there other ways to improve this?
Big issue when streaming audio.. I wouldn't want to go into this offline state when is just a simple network switch or small connection loss. One of the things I would do is to wait for the buffer to be empty before changing states.
Yes, just check twice. Using your example, when you get the "offline" notification, you flip a flag (BOOL claimingOffline). Then when your buffer empties you check the status. If back online, you unflip the afore mentioned flag. If still offline, you flip the flag and go into "offline mode". This technique allows you to wait until the moment you really need to know (when the buffer empties). Otherwise you could use a timer, but it's suboptimal and not nearly as elegant...
I'm developing a navigation app which uses the UIBackgroundModes=location setting and receives CLLocationManager updates via didUpdateToLocation. That works fine.
The problem is that the intervals between location updates are very hard to predict and I need to make sure the app is called something like once every few seconds to do some other (tiny) amounts of work even if the location did not change significantly.
Can I do that? Am I allowed to do that? And how can I do that?
I found a blog post, but I'm not sure if this is really the way to proceed.
Permissible background operations are pretty limited in scope. You cannot, for example, just leave an NSTimer running to perform some arbitrary code while your application is in the background - so the simple answer to your question is no, you cannot. Definitely read the Apple documentation regarding what is and isn't allowed (most of what's allowed pertains to apps that "need" specific ongoing services, like the ability to play music, or respond to location changes (GPS type apps...). You may be able to construct a viable solution by responding to location or significant location change notifications...
I would like for my iOS app when it is in background mode to execute at specific intervals some functions
(What I precisely want to do is to check a URL, and indicate its (int) content as a badge.)
However, I don't know how to have the function executed in the background.
Thanks.
Read about Executing Code in the Background. There is a limited set of things you can do in the background, what you describe not among them unfortunately.
I think you have two options to solve this problem each of them has pros and cons.
First, one is background refresh check the link. Have in mind that it is different for ios 13 and above. You need to define background tasks check here. It takes me some time to understand the background tasks but it seems more logical and easy to manage if you have several tasks. Still, you don't have the full control of when this task will be executed. It depends on how much battery, network and so on your task will use every time. The system will choose what is the best time to run it.
There is one more option, to implement a silent push notification check here.
Here you can implement a good push mechanism for updates but you will depend on network and permission for notifications. Also, you will need a backend for this solution.
You need to define what works best for you.
I think the best option is to use the voip background mode. Here you can find all the required information: how to run background process on the iOS using private APIs to sync email items without jailbreaking the phone
https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app
To update the content frequently when the app is in the background might be difficult, Instead, you can wake the app by pushing a silent notification from backend at regular intervals.
For more information check this article also
https://medium.com/#m.imadali10/ios-silent-push-notifications-84009d57794c
I've decided to integrate OpenFeint into my new game to have achievements and leaderboards.
The game is dynamic and I would like user to be rewarded immediately for some successful results, but as it seems for me, OpenFeint's achievements are a bit sluggish and it shows visual notification only when it receives confirmation from the server.
Is it possible to change something in settings or hack it a little bit to show notification immediately as soon as it checks only local database if the achievement has not been unlocked it?
Not sure if this relates to the Android version of the SDK (which seems even slower), but we couldn't figure out how to make it faster. It was so unacceptably slow that we started developing our own framework that fixes most of open feint's shortcomings and then some. Check out Swarm, it might fit your needs better.
There are several things you can do to more tightly control the timing of these notifications. I'll explain one approach and you can use this as a starting point to explore further on your own. These suggestions apply specifically to iOS apps. One caveat is that these suggestions refer to internal APIs in OFSDK 2.8 for iOS and not ordinarily recommended for high level use and subject to change in future versions.
The first thing I recommend is that you build the sample app with your own product key. Use the standard sample app to experiment before applying the result to your own code.
You are going to get the snappiest response by separating the notification pop-up UI from the process of submitting the achievement. This way you don't have to worry about getting wrapped up in the logic for deciding whether the submission is going just to the local db or is doing the full confirmation on an async network transaction.
See the declaration of "showAchievementNotice" in "OFNotification.h". Performing a search in the sample app, you will see that this is the internal API used for displaying the achievement pop-up when an achievement is earned. It does not actually submit the achievement. You can call this method directly as it is called from "OFAchievementService.mm" to directly control when the message appears. You can then use the following article to disable the pop-up from being called when the actual submission occurs:
http://support.openfeint.com/dev/notification-pop-ups-in-ios/
This gives you complete freedom to call the submission at a later time provided you keep track of the need to do so. For example, you could locally serialize a flag to take care of the actual submission either after the level is done or the next time the app starts up. Don't forget that the user could quit out of a game without cleanly finishing a level.
To be clear, this is for a normal iPhone application, and not a game.
I've read around the web a few times some developers mentioning that they were working hard to improve/reduce the startup time of their applications, but never with any good background information on how to do so.
So the question is simple: how can you reduce the startup of iPhone applications?
Same as any other performance issue: Use Shark and/or Instruments to identify bottlenecks in your code, and then focus on how you can speed things up there. Each tool will give you a picture of how much time was spent in what parts of your code, so the general scheme would be to run the tool while you start the app and then pore over the data to see where the performance hits occur.
At app startup time, the most likely candidates for improvement will be deferring data loading until later on when it's actually needed, variously described as "on demand" or "lazy" loading. Essentially, don't load any data at app startup unless it's actually needed right away when the app loads. In practice, lots of stuff that may be needed at some point doesn't have to be immediately available when the app starts. For example, if you have a database of N records but only one is visible at a time, don't load all N into memory at app startup time. Load whatever the current record is and then load the others when you actually need them.
James Thomson did a nice blog post documenting his efforts to make PCalc launch faster.
Of particular interest is his use of image with screenshot from last app run, to pull the same trick Default.png does, while loading rest of the app.