I am working on an app where I would have to implemented at least two background tasks. The scenario becomes like this, I have a web service which tells me when to start the location updates for a user. So, I would need to periodically call this service to check if it's time to start, and/or stop, user's location tracking.
So there are two background tasks, fetch and location tracking. Fetch should run periodically which defies Apple's procedure that it will monitor your app's usage and decide on it's own when to update the content. This has become my first problem, is there any way that I can avoid this? The second problem comes with the multiple tasks, how can I switch between either of them?
What is the best practice here? Dos and Don'ts?
You should use Push notifications through Apple's push servers, or you may find a service like Parse.com easier to work with. You can use the push notification to trigger or create anything in your app delegate (where you handle receiving push notifications). As #Paulw11 's comment states, you can even attach a payload(data) to a push notification and deal with it. So the first part is fire a notification to the user's device when they should start tracking and end tracking.
Most location tracking stuff using an instance of a CLLocationManager can be done via it's delegate methods. However if you want you can use it in a subclass of an NSOperation and manage it in an NSOperationQueue, see here for a tutorial:
http://www.raywenderlich.com/76341/use-nsoperation-nsoperationqueue-swift
And I suggest researching the class documentation.
Related
I need to notify user when a certain condition is met but that condition might or might not meet in months. I need to run condition check in background (even when app terminates) so that I could detect condition is met (even if it happens after 3 months). If condition is met then I need to send notification only to a single user (not all users).
I am not sure what is the best way of doing it. Local Notification or Push Notification? I can not schedule a local notification in advance because I don’t know when it will meet the condition. I think Push notification is not needed because I am sending only one notification to only one user in several days/months.
I also need to constantly run this check in background. I know it can be run infinitely in background by using location update (significant monitoring or background navigation). But my condition checking code doesn’t actually require location updates. As far as I understand, Apple allows only location update or network related task in background (for few minutes). That's why I am thinking of putting my code in background location update code.
In my opinion , I should use local notification and put my code in background location update code so that I could check constantly if certain condition is met. This background check will schedule local notification and show it to the user who is using that device. I don’t think it is possible to schedule a push notification by code running in background.
In summary, I have following 3 questions
Should I put my code in background location update? If not, what is the right approach of running my code infinitely in background without location update?
Will Apple reject application if I put my code in background location update while location update code doesn’t actually send/receive current location?
What kind of notification should I use in this kind of situation where I send notification to a single user after months? Would you use Local Notification? or Push Notification.
Please reply. Any help is truly appreciated.
Thanks in advance.
This is a bit of a tricky problem unfortunately.
Apple won't allow you to create long-running operations in the background. As you mentioned, you can add code in the background with location updates or audio, but neither of those are very good solutions since (1) Apple will likely reject you from the app store and (2) the user will probably close the app if they notice a big locations banner at the top of their phone (or a weird background audio signal), and closing the app will kill your operation. For any truly long-running tasks it's probably best to set up a server and run a cron job or equivalent long-running operation. It's the only way you can know that the task will continue running.
Sorry, I was just answering one at a time, but as I mentioned above, yes, they'll probably reject your code for that. As a rule of thumb: if you think the Apple-created code you're using wasn't meant for what you're using it for, Apple will probably reject your app.
It sounds like you should use a remote notification. If you do use a remote notification, you'll probably want some sort of backend anyway. You could use a local notification to notify a user after a few months, but you would need to know the exact time to send it up front, which it doesn't sound like you would.
In summary: Try to build a simple BE. Maybe use Firebase Functions or something, and also build an APNS system to send pushes. In the app, tell the server to start processing the information and send the push back when it's done. The situation sounds like a perfect use case for server-side logic.
Hope that helps!
I'm making a simple app with a Today Widget extension that logs events.
The user can tap a button in the app or the related Today Widget to log an event. These events are saved with Core Data any time the button is pressed either place.
Whenever a new event is logged in the app, I run a function called updateLocalNotificationsFromCoreData(). It handles the setup of UILocalNotifications based on the most recent event in Core Data after clearing the appropriate existing notifications.
However, when a new event is logged from the Today Widget, I can't use this function because I need to register the Local Notification with UIApplication.sharedApplication().scheduleLocalNotification(), and UIApplication is not available in the Today Widget extension.
I realize I'll probably need do something unconventional or hacky to get this working, so I'm trying to evaluate possible approaches and come up with a relatively robust solution.
Basically, I want to find a way I can call my
updateLocalNotificationsFromCoreData() function right away any time a new event is logged.
If I can't do it every time an event is logged, an alternative would be to trigger the updateLocalNotificationsFromCoreData() function periodically (somewhat frequently) another way. Here are some solutions I was thinking about using, but I don't like any of them:
Do it in AppDelegate when the app is launched (or another state change)
One approach I'm thinking about is running my updateLocalNotificationsFromCoreData()function in AppDelegate somewhere, like didFinishLaunchingWithOptions.
The downside is that it would require the user to open the app periodically. If the user didn't open it much the notification behavior would be inconsistent. I'd prefer a solution where a user could interact with only the Today Widget and reliably get Local Notifications without ever opening the app.
Sync the events to a server and use Push Notifications
I've thought about syncing the data in Core Data to a server, then setting up Push Notifications to the user's phone based on that.
I don't like this, because I want the user to still be able to get notifications without an Internet connection. It also introduces a lot of extra overhead of syncing the data with a server.
Ping a server, and send a content-available Push Notification
When someone logs an event with the widget, I could ping a server. That server could send back a silent content-available push notification to trigger the app to run updateLocalNotificationsFromCoreData() in the background.
I found a similar question (Scheduling local notification from within a Today extension) where one answer proposes a similar solution. Unlike the previous solution, an Internet connection is not needed to receive the notifications, but an Internet connection would be required to make sure the notifications are up to date when a new event is logged.
Background fetch
I thought about using Background Fetch to fetch something arbitrary from a server, then run the updateLocalNotificationsFromCoreData(). This would be a way to trigger the update in the background, although it seems silly to fetch data if that data isn't being used, and seems like something for which an app could be rejected. There also seems to be a risk of the system not calling the background update regularly if the user doesn't open the app much and mostly uses the Today Widget.
Use background location updates
This seems like the dumbest approach, but I thought I would mention it anyway since I thought about it. I could use one of the low accuracy background location update modes to trigger updateLocalNotificationsFromCoreData().
It would require the user to allow location in the background, which would be hard to explain. And, it would require the user to at least move around a few blocks to trigger the function, which could provide an inconsistent user experience. Also, it would increase power consumption of the app for a silly reason.
I'd really appreciate fresh ideas about how I might be able to reliably schedule local notifications when Core Data changes on a device that doesn't have an Internet connection!
Or, if that doesn't seem possible, I'd appreciated feedback on which approach seems to make the most sense.
EDIT: I came up with a new solution. It's not ideal, but I think it's better than these other approaches I was considering. When someone taps the button to log the event, I launch the full app. It's annoying because I have all the data I need at that point to give the user feedback and log the event within the Today Widget without launching the app, but by launching the app I have the opportunity to check and schedule local notifications.
Also, in iOS 9 the annoyance on the user is slightly minimized because the system-wide "back" button will appear and let the user go back to the previous app easily once my app has launched from the Today Widget.
In the future I may try a solution where one of the server-based approaches above is used when an Internet connection is available, and I would then fall back to this system of opening the app only when the network connection is not available and I need to schedule the local notifications within the app.
I'm writing a iOS/Swift application which reads data from a REST service each X minutes and updates the UI accordingly.
Now I would like that when the app is put in the background, a task keeps being invoked at X minutes intervals reading from the REST service and, in case the data just read satisfies a given condition, show a notification prompting the user to bring the app back to the foreground.
In my searches I've read that during applicationDidEnterBackground event, I should start a task with beginBackgroundTaskWithExpirationHandler.
The problem is that, if I've understood correctly, this allows a maximum of 10/15 minutes after which the app is terminated if the task is not stopped with endBackgroundUpdateTask, while I want the task to keep polling the service indefinitely (at least until the user disable it from the app's settings)
My question is:
How is this kind of functionality performed normally? Do some common solutions or best practices exist for the solution of such a problem?
Use iOS Background Fetch feature where you can specify minimum background fetch interval. But actual interval between successive invocation of your code will be determined by iOS framework. For details checkout this link: http://code.tutsplus.com/tutorials/ios-7-sdk-working-with-background-fetch--mobile-20520
I use this approach in my app and I think it is a preferred way of doing.
You can use a local notification that can be presented from the background in case your condition is met.
Correct, iOS will eventually shut down the background process, you can't enforce continuous background activity. Use the backgroundTimeRemaining property to check how much time your application has left and try to handle it as gracefully as possible by calling endBackgroundTask so that iOS does not force kill your app.
As a solution, you could think about using remote notifications with with content-available : YES, which runs the didReceiveRemoteNotification
Have a look at the Parse.com Their local datastore is an abstraction for what you are trying to acheive.
By the way, is it really necessary to refresh in the background. If call is relatively quick, there is no need to refresh until the user open's the app. Background processes like that, using the net can be quite battery consuming when the user are not on a Wifi. So consider the use case carefully!
I'm trying to look for a way as to how I can notify a user of new updates based off of a .Net API that I created. Much like that notification you get on facebook, I just need to alert the user that something has been updated. So I'm thinking I need a function that runs in the background while my user uses the app combined with a NSTimer.
Based on my research (and on this question https://stackoverflow.com/a/14835300/639713) apparently you can only achieve such a thing for VOIP and location services. And that using push notification is the only way. Is it really the only option that I can use for such a need? Or are there any other ways?
Thank you for your time.
You have two options:
While your app is open, poll the server every so often to see if there are any updates to report.
This will work only as long as the user has your app open, and as you note, your app will only be allowed to stay open for a long time if it happens to be a VOIP or navigation app.
Use push notifications to push updates to the user’s device.
The disadvantage here is that you will need to write some server-side code to talk to Apple’s push notification servers (as described in this tutorial). This may or may not be a big deal in your particular situation, but it’s the only way to get data to the user when your app isn’t open.
I Googled around and I can't find many discussions on this. I want to develop an iOS program that would use access a REST service, and I want to get notified of updates so I am thinking of long polling. Does RestKit deal with this?
Another questions is what if I want to run in the background? It seems like the proper way to do is to set up an Push Notification Service and notify the user to open the app to receive the latest message?
Doing a job in background is only possible with special APIs like Music and Location, so you won't even be able to do queries if the user is not using your app.
Instead, you should do all the heavy work on a web service, and setup an APNS server to notify the user when something happens. That way, it won't drain all the battery of your users and use technology in place exactly for that purpose.
There's also a lot of service to send out push notifications, if you don't want all the heavy setup. Take a look at http://parse.com or http://urbanairship.com/.