I Did lots of BG tasks in the past, But Trying to get data when app is killed (Even when user is giving Always permission) seems not to work.
I wonder if there is a solution for that.
To make things clear, I am not talking at the moment when app change from Active or Background even to suspended mode. I'm talking about if the user is using the app and set permissions but then kills the app and after that i need every hour to get data from the user and send data to them.
Is there a way to do that?
Can a Today widget help me with that? Does a Today widget "lives" all the time and i can get that from it 24/7?
Whet is working is CLLocation manager. This is working even when the app is killed. But only when the user is changing a location.
I need that to work when the user is in the same place also.
Non of the other methods work. Not BGTask (I need every hour on the hour and not when apple decide to do things), Nor Silent Push Notification for some reason (Regular ones work, but i Don't want to bother the user with a push every hour just for getting and sending data).
Sorry there is no code to show as this is a very general question. But i think that is very important one to many people and can't find an answer for that.
Related
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 am looking for a good way how to make my app "upToDate". These are my requirements:
I have an RESTful Webservice, with tasks for different users. Every user has an iOS App, which should get automatically updated when the Server/Service assigned a task to that User.
So first ill created a manuall "Sync" Button, which checks for new Tasks. Fetches the data with Alamofire, and updated the UI.
But, my goal is automatically sync if there are new tasks.
So, ill guess there are 2 different ways to solve that:
1. Make a Background Fetch (with a NStimer?) every xx Minutes and check if there are new tasks.
After checking that tutorial here:
http://www.raywenderlich.com/92428/background-modes-ios-swift-tutorial i am not sure if a background fetch is a good way to solve that. In that case the App uses an scheduler, to check once for new updates, and not every xx minutes.
So in my case i would create an NStimer in the AppDelegate (maybe in applicationDidEnterBackground) and check every xx minutes for new data (but when there are 3 days not any new task, that would be unnecessary battery consumption, or?)
2. Using Push Notifications.
My other idea is to use Push Notifications, so when there is a new task, ill send a Push Notification an manually start the sync. In my opinion that would use less battery, because he will only start the sync when there is a new task available.
Generaly Questions about using Background Services
So ok, if the user finished the task, some data should be automatically uploaded to the server. Normally not a problem, with the manual sync ill check if there is something to upload. But, what if, when there is no internet connection (ill check if before uploading) - and the user do not press on "manual sync".
So i would prefer to check in my "Background Service" if ill got an Internet connection, and if yes - start uploading some data.
Ill know this is not a specific question, but ill think there are lots of users who have the same requirements and it would be great if someone can help me out whats the best way to solve that in the best and practical way.
Thanks in advance!
Background updates sound wonderful until you realise that Apple throttles them heavily: you can ask to be updated as frequently as possible, but iOS decides what that value actually means based on how often users open your app and when they do so. Apple considers background updates the kind of thing that should happen just before a user opens your app so the latest content is right there, rather than something that runs proactively in the background.
Your push notification solution is a better one, particularly if you use CloudKit to subscribe to record change events using CKSubscription and CKNotificationInfo. If you do this you'll automatically get push messages in your app, so you can get what you want with very little work. You can read my tutorial for more information on subscribing to CloudKit to get push messages.
I have a volume control app in the iOS store, but one problem that my users have frequently is that the device kicks it for memory control. Is there any way to either force it to stay active (by permission) or to at least alert the user when its no longer active or in danger?
All the answers are under Background Execution in the iOS Developer Library.
Of course, here's the philosophy:
Always try to avoid doing any background work unless doing so improves
the overall user experience.
See Table 3-1 for the types of background execution. There's a category for audio but it requires audio to be played from the app. It does not sound like your app fits in here. So you'll want to look at notifying the user.
You could send a notification to the user when the app falls to background with applicationDidEnterBackground(), or just before it quits with applicationWillTerminate(), supposedly time-permitting.
Running in the background is permitted. I have an app that does it and while the rules have changed and adapting to it has been gut wrenching at times, it is pretty straightforward. In your case, I would think that you could setup to be notified and then just disappear, no? waking from a notification is part of the state changing protocol and you should be able to do that.
As a point of comparison, in Android, background operations like yours would be implemented as services and would have no fear of being terminated. The strangest thing about the way ios chooses to allow background activity is that you are applying for status one time. In Android, I was able to indicate that a single activity should be kept alive when the app is backgrounded, all others could be terminated. There is no way to do that in ios.
I take it my disappear and wait for notifications is probably not going to work for you because there is no way to be notified of volume changes. You must be polling? In which case, you probably are going to have to ask to be kept alive. Would be nice if you could just piggyback on other services, e.g. keep me alive while music is playing.
To answer your other question, yes you will get notified if/when you really are going to get termed, so you could send a notification at that point.
In my app I'm registering a NSSystemClockDidChangeNotification notification in AppDelegate method application:application didFinishLaunchingWithOptions:options.
Posted whenever the system clock is changed. This can be initiated by
a call to settimeofday() or the user changing values in the Date and
Time Preference panel. The notification object is null. This
notification does not contain a userInfo dictionary.
Month ago it was working fine, but these days every time I suspend my app, lock my iPhone and leave it 2 minutes to pass, when opening the app, the selector method is called, which is weird to me. I didn't change the system or time, I just let the device idle.
Can anyone help me understand this? I just want to execute some code when the user manually change the system time, just in that case (tried with UIApplicationSignificantTimeChangeNotification but that doesn't help).
Like that: Getting iOS system uptime, that doesn't pause when asleep
But remember, this solution will fail sometimes because of out-of-sync when system tries to update time from NTP server when the Internet connection is not reachable.
This answer is a bit late but this is what the apple support team replied when I ask a similar question:
Part of the question I asked:
Could it be possible for the OS posted [this notification] if the
time/timezone has not changed in the device?
The answer I got from them:
Absolutely [1]. It's common for a notification like this to be posted
redundantly. In some cases it's triggered by a state change you can't
see. For example — and I haven't tested this theory, so it's just an
example of how this sort of thing can come about — this notification
might be posted if the system's giant list of time zone info has
changed. So, the time zone state has changed, but it's not something
that affects your app.
But in other cases, a notification might be truly redundant (-: iOS
is a complex system and in some cases this complex machinery generates
redundant notifications, and there's no need to filter them out
because…
Your app should respond to such notifications be refetching the info
it cares about and updating its state based on that. If this update
is expensive, keep your own copy of the previous state, compare the
current system state to that, and only do the update if the stuff you
care about has actually changed.
I'm trying to figure out if there is any permissible way to have my iOS app run periodically (say every 4 hours) and grab a users location. I'm aware of three possible ways this might be accomplished:
Local Notifications (Handling Local and Remote Notifications)
The problem with this solution is that when the app is killed after being in the background a while or the phone restarts, then the local notification will fire and give a UI but not actually start the app so I can't grab the location.
Alarms (Configuring Alarms)
As Apple's documentation says:
Note: An alarm is not intended to serve as a UILocalNotification. An alarm requires you to create an event or reminder that is visible in the user’s Calendar or Reminders app. A UILocalNotification is better suited for general purposes that don’t involve the Calendar database.
Therefore, not only would I be going against Apple's recommendation, but I would then have to ask for access to the user's calendar which won't make any sense to the user.
NSTimer (NSTimer)
I could create a NSTimer, but that solution was already answered here as not viable (That was three and a half years ago but I'm guessing the answer hasn't changed).
Are there any other ways in which this might be accomplished on iOS?
I don't know of any way to grab it periodically every X hours, but the Significant Change Location API might work for your use case. It gives you updates whenever there has been a significant change to the users location.
edit
If you app is not running in the background it will relaunch your app.
/edit
https://developer.apple.com/library/ios/documentation/userexperience/conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html#//apple_ref/doc/uid/TP40009497-CH2-SW10
This stack overflow question has a lot of info about this service also:
Behaviour for significant change location API when terminated/suspended?
See the Getting Location Events in the Background section of Apple's Location and Maps Programming Guide. The other methods mentioned in the question wouldn't actually wake the app up, except for UILocalNotification, and then only when the user tapped in in Notification Center.