I have created a web-service app and i want to populate my view controllers according to the response i fetch(via GET) in main thread. But i want to create a scheduled timer which will go and control my server, if there becomes any difference(let's say if the count of an array has changed) i will create a local notification. As far as i read from here and some google results, i cant run my app in background more then ten minutes expect from some special situations(Audio, Vo-IP, GPS).. But i need to control the server at least one per minute.. Can anyone offer some idea-or link please?
EDIT
I will not sell the app in store, just for a local area network. Let's say, from the server i will send some text messages to the users and if a new message comes, the count of messages array will increment, in this situation i will create a notification. I need to keep this 'controlling' routing alive forever, whether in foreground or background. Does GCD give such a solution do anyone have any idea?
Just simply play a mute audio file in loop in the background, OR, ping the user's location in the background. Yes, that will drain the battery a bit, but it's a simple hack for in-home applications. Just remember to enable the background types in your Info.plist!
Note: "[...] I fetch (via GET) in main thread." This is not a good approach. You should never fetch any network resources on the main thread. Why? Because your GUI, which is maintained by the main thread, will become unresponsive whenever a fetch isn't instantaneous. Any lag spike on the network results in a less than desirable user experience.
Answer: Aside from the listed special situations, you can't run background apps. The way I see it:
Don't put the app in the background. (crappy solution)
Try putting another "entity" between the app and the "server". I don't know why you "need to control the server at least one per minute" but perhaps you can delegate this "control" to another process outside the device?
.
iOS app -> some form of proxy server -> server which requires
"babysitting" every minute.
Related
I have an application where I need to create local notifications via polling without doing push - primarily due to client infrastructure limitations and their security model.
I've read: http://www.objc.io/issue-5/multitasking.html, I've seen David Chan's WWDC presentation - where single push messages kick off download tasks - but what I truly need is background fetch - on a regular basis - like every ten minutes - in iOS 7.
I've seen the VOIP hacks. No. What non-hack way is there to do this without user interaction or push messages? Any examples you can point me to?
Here's what I know:
Background data tasks will work in the debugger but if you can get a console on an IPA, you'll quickly find out they really are prohibited (thereby invalidated many examples).
Background URL tasks require custom delegates - but fetch completion handlers are iffy. This too I found with an IPA and console.
I would love to avoid using the AFNetworking lib - for something quite simple.
Background fetch is not a reliable solution - you are at the mercy of the OS, and it is not very merciful. Abusing iOS background modes is not a reliable solution - Apple is known to reject applications that enable background modes, such as location, VOIP and music playback, without a legitimate reason. Background URL tasks are not something you can rely upon to wake your app; they will wake it, but the app will not be awake enough in the background to enqueue a background URL task.
Your best and most intended method is still background fetch, but be prepared to be disappointed. Your app will not be woken app in the interval you need. Also, the user can kill the app in the app switcher screen, causing your app to never wake up until opened.
No real reliable method other than push. You need to insist with your client for the sake of user experience.
Unfortunately there is no "reliable" way to do that on iOS. With the background fetch API you are not guaranteed to have process run when you would like it run. As you've said, you've already looked at the API so i'm probably telling you something that you already know. A local notification wouldn't solve your issue either as this isn't a way that you can wake your application up and kick off network events. This is behavior that Apple doesn't want as this would negate the whole purpose of their background task coalescing.
You really need to have a push mechanism in place for something like this, so if this is something that is needed, then you may have to stress that to the client.
I am working on a Win8-UI-App (previously called Metro...) and trying to implement Periodic (Documentation for different methods) Tile Updates (Live Tiles) for the first time.
I found a couple of very good resources on the internet and was able to do it. Unfortunately the question of where I should register for the notifications remained unsolved:
Do I have to register for Notifications every time the app starts (e.g. in the App.xaml.cs OnLaunched() Method)? - Or is there an other, more professional way to do so? (I could imagine to save if I already registered for the service or is there a variable I can access to see whether notifications are registered?)
thank you!
PS: For everyone who is also new to this see this StackOverflow post, this example, the tile template types and the Dev Center for quick starting :)
Periodic updates will continue until they are explicitly stopped or your app is uninstalled. Technically, you only have to do that once. But, the Guidelines and checklist for periodic updates states
Call the StartPeriodicUpdate or StartPeriodicUpdateBatch method each
time your app is launched or brought into focus. This ensures that the
tile content will be updated each time the user launches or switches
to the app.
According to that, App launch and App resume are good candidates for a call to StartPeriodicUpdate.
My app uses iCloud (key-value store) to sync an unique id between multiple devices. This works accept at the point were it really has to work, at the first launch of the app. It looks like the device isn't yet familiar with the values from iCloud at first launch, only after the app is installed and has been running for a while.
I check for the iCloud value in the viewDidLoad function on main view of the app.
So, my questions:
Is this the expected behavior?
If yes, is there another solution?
Could it be the case this is only a problem when running from Xcode, not the shipping version? If so, how to test?
Thanks!
Jasper
I had a similar issue where the NSUbiquitousKeyValueStoreDidChangeExternallyNotification wasn't triggering on the first launch after install, no matter how long I waited. Setting an initial key in the NSUBiquitousKeyValueStore seemed to solve this.
Immediately after adding the observer to the default store, I call:
[[NSUbiquitousKeyValueStore defaultStore] setString:#"testValue" forKey:#"testKey"];
[[NSUbiquitousKeyValueStore defaultStore] synchronize];
I use different keys (i.e. not testKey) for the actual data I want to sync.
When you first run an iCloud enabled App it has to pull all the data from Apple servers. The time it takes to do so depends on many things like what kind of network you're currently on (Edge, 3G, GPRS, WLAN). It also depends on how much traffic the iCloud server currently has to handle so the request to the iCloud server may take a few more seconds, no matter what type of network connectivity you have.
To sum it up: Yes, it sounds absolutely normal.
If running your App depends on those settings consider implementing a "Wait" or "Loading" view that stays on the screen as long as it takes for the App to perform a initial synch and load all needed data from the cloud. To not block the UI forever also implement a timeout for this view (if iCloud data not loaded within X seconds, dismiss the view and notify user).
You have no guarantee NSUbiquitousKeyValueStore would have finished its first synchronization as your app is launched for the first time. (In fact, on iOS 5, it's often starting to sync as you launch your app for the first time).
There is no way to know if the first initial sync has already happened, is ongoing or has finished. You can (in fact should) subscribe to NSUbiquitousKeyValueStoreDidChangeExternallyNotification. The trick is that if your store is empty on the iCloud server, you won't get any notification after the initial sync (since your local store is empty and the cloud store is empty as well, nothing really changed "externally" after the initial sync…)
Normally, you should not rely on the initial sync being done.
Be optimist at launch, even if your store is empty, push your values (e.g. your unique id) right away. If the initial sync happens concurrently or after and there is already some value on the server, your local values will be reset to the server values and you will get the NSUbiquitousKeyValueStoreDidChangeExternallyNotification notification with the NSUbiquitousKeyValueStoreInitialSyncChange reason.
Finally, if you really think knowing about the initial sync being completed or not, please file a bug to bugreport.apple.com and explain why you really need that.
I have a Web-Service application, i need to send scheduled GET methods to my server and if a change has happened with my incoming data i have to inform my user about the changes. When my app is in the foreground(in min thread) i fetch some data and pıpulate my tableview, my problem is, i can't realize how to create a scheduled method to the same data source(mean server) and if a new thing has been added, either my app is on bacground or not, inform user(alert) about the changes. Can anyone please share any idea-link.. Thanks in advance
This is exactly what push notifications were designed for, and are, technically the best way to solve the problem.
It does mean the task of 'checking' for new data is shifted to your server but the user is better suited as a push notification will happen, even if your app is not running.
I recommend using a system like Urban Airship.
When my application loads, using the didFinishLaunchingWithOptionsi parse data from the internet to nsarrays. My question is, when the user exists the application by using the 'home' button, and then loads the application again how can the data be re-loaded? (because if the data does not reload - if there are any updates on websites, the new updates will not be seen).
Add an applicationWillEnterForeground method to your app delegate. Load the data there, or start a thread to load it if you like.
You should probably also periodically check for new data even while the app remains open, because the user could go idle for a long time.
As an aside, you shouldn't do anything which might block in applicationDidFinishLaunchingWithOptions. If you are using synchronous NSURLConnection APIs there is a danger the OS might kill your app for taking too long to launch. Best to either use the asynchronous/NSURLConnectionDelegate APIs or do the networking on a background thread and call back to the main thread when you need to update UI (UIKit does NOT like being called from background threads, as it is not thread safe. It might appear to work sometimes, but it will come back to bite you sooner or later).