It may very well be a design issue but i am trying to build a watchOs 2 app that is essence a specialised timer that counts down to a specific time according to some parameters that user dials in.
Then I start a NSTimer to count down to this specified time the problem is that when the watch goes dark the timer suspends is there any way to stop this from happening or is there an alternative method.
Regards Christian
Use a local notification on the phone.
Related
I read in many places that if user swipes up and kills an app, that app will not be able to receive location updates. I get didEnterRegion and didExitRegion callbacks are received when my app is not killed and is in background. But if I swipe kill app, app doesn't get those callbacks. My question here is,
Is it that app will stop getting callbacks ever? i.e., even if the app is launched again and is in background it does not get the callbacks
I read about startMonitoringSignificantLocationChanges and background app refresh when used together, I can get callback even when app is killed by swipe. I tried this and could not get it working. Is this the expected behavior?
Will startMonitoringSignificantLocationChanges and background app refresh together when used, I get region entry/exit callbacks after rebooting device?
This is not expected behavior. You are supposed to get didEnterRegion and didExitRegion callbacks even after killing an app in the task switcher. If you are not seeing this, something may be wrong with your app or testing methodology. Posting code may be helpful.
A few caveats and tips:
Make sure your app has obtained backround permission with locationManager.requestAlwaysAuthorization(). Without it, it cannot detect at all in the background.
Detection in the killed state did not work on iOS 7.0.x. It started working as of 7.1+.
Make sure you wait long enough to get detections. In some app states, it can take up to 15 minutes.
Before killing your app in testing, check logs to ensure you know what CoreLocation thinks is your current region state. If you turn off a beacon then kill your app, CoreLocation may not have had time to realize the beacon disappeared, thinking it is still inside the region. If you then turn on the beacon, you will not get a new entry event because it thinks you are already inside.
In my app, I have performed the following listed below and have added counter to the app fetch routine to highlight the number of times fetch is called by iOS 8.1.
Turned on Background Modes and enabled background fetch.
Wrote code for “performFetchWithCompletionHandler”. NSLog message indicate the start and end of the fetch process. Counters are between these messages.
Added code in “didFinishLaunchingWithOptions”. However, instead of using “setMinimumBackgroundFetchInterval” I am using double of 60 assuming seconds.
When I test the code in Debug by setting “Simulate Background Fetch” all works perfectly as expected with absolutely no problems. Counters work and show expected values.
However, when I go live on the iPhone, launch the app, then hit the home button to put in background, wait one or two hours or overnight. Nothing happens, no fetch, no downloads and all counters remain at zero.
If I cannot get this to work, I will need to create my own background thread and manage it directly, which I would prefer not to do.
Any input or ideas are deeply appreciated.
As of iOS 8, I started having this same problem with both of my apps. In iOS 7, background refresh triggered pretty reliably. In iOS 8, it just stopped. If I launch either app from xcode into the background fetch mode, everything works like it should. Background refreshes themselves just stopped triggering on their own in iOS. I have a hopeful theory that I'm trying out right now. Here's my thinking...
iOS will exclude your app from background refresh if the user force kills it from the multi-tasking screen. How might Apple have implemented this behavior? One way would be to just set your minimum fetch interval to UIApplicationBackgroundFetchIntervalNever. Easy peasy. Let's assume that's how they do it. Does your app set the minimum fetch interval every time it launches, or does it only set it on the initial launch?
In my case, I was only setting the minimum fetch interval as part of the initial setup of my app. If the user force killed the app, and iOS is in fact setting the minimum fetch interval to UIApplicationBackgroundFetchIntervalNever, then my apps are stuck in the state of never. I made a minor change in one of my apps, so that it sets the minimum fetch interval on every launch. So far so good.
Update:
All is well in my background fetch land.
Both my app that's currently in development and my app that's in the app store are once again triggering background fetches reliably.
The code for doing this can be pretty simple...
[[UIApplication sharedApplication] setMinimumBackgroundFetchInterval:minimumBackgroundFetchInterval];
Calling that every time your application launches will do the trick, however, you'll want to consider whether setting that value is appropriate to the current state of your app. In my case, one of my apps is a concert listings app. There's no point in setting a minimum background fetch interval if the user hasn't selected a location for concerts yet. I have an NSUserDefault to track whether a location has been set. Here's an approximation of my code for setting the fetch interval ...
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
if ([INCUserDefaults isLocationConfigured]) {
[[UIApplication sharedApplication] setMinimumBackgroundFetchInterval:kSecondsIntervalForUpcomingShowsBackgroundFetch];
}
return YES;
}
Prior to the bug fix that I issued, I was only setting the minimum background fetch interval as part of the setup process. Now I set it during the setup process, and on application startup if the setup process was previously completed.
Apple uses a secret algorithm to determine the frequency of fetch events. This algorithm is presumably based upon app usage patterns (ie: how frequently and when the user users the app). It can take several days before fetch events begin to arrive consistently.
If fetch event works in simulator, that proves that everything is correctly set up. There's nothing you can do but wait.
iOS does the background fetch in certain way. It wakes up apps it believes the user uses often. Try opening the app after you wake the phone for a few times.
As kkarayannis wrote, iOS will learn how often to call your app. I've seen the same behaviour as I wrote my first background fetch. I believe, that you should not only open your app manually, but also trigger a manual refresh then. IOS will learn that the user wants to load data regularly and will start to do it on it's own.
Have you also tried to use "setMinimumBackgroundFetchInterval" instead of 120sec? Maybe it's a too short intervall. However you could also past your code for better understanding.
I need to play sound at specific hours like alarm clock app, for example at 17:30, 18:00, 20:00, etc. I'm tried with UILocalNotifications but don't have sufficient options to customize all of I need.
Any idea?
Thanks!
Unfortunately, this is not possible — the only way to trigger a user stimulus when your application is not the firstresponder is to register a notification.
Check this out for more information on Push and Local Notifications.
What customizations are you trying to make? iOS notifications are not terribly versatile, but it is possible to customize the message and sound, among a few other things.
I'm building a Windows Store app and it pops up toast notifications from time to time. I also have an animation that plays to show when something has updated. Both of these happen at the same time.
What I would like is to not show the toast when the app is running.
So, is there a nice easy way to determine this or do I have to manually track the state via the suspending/resuming events?
Edited info:
The solution has a background task project which goes off, gets the data, then decides if anything has changed that the user needs to know about.
If so, it creates a toast, updates the tile badge, and plays an animation to fade in the new data.
The issue is that I don't want to show the toast and update the tile badge if the user has the app full screen. Similarly, playing the animation isn't needed until the app is resumed (that's the easy part though).
I realize I could solve it by having one timer that works when the app is running, and a separate background task for when it's suspended but that seems like overkill in this case.
The simple answer here is that if your app is suspended, your code won't be running.
If you want to pop up toasts when your app is suspended, you'll either need to use the WPNS or a background task to track changes.
I am building a small app that I can use to do Interval Training,
it schedules a series of UILocalNotifications, all scheduled at the same
time and all fired within a few minutes of each other.
The idea is that you put in your headphones and start a workout,
when you hear one kind of sound you rest and another kind of
sound you workout. I do this with localnotifications, it works
just fine. The reason for doing it like this and not just
having the app run with a timer is that I would like for
the Nike +iPod app to run in the foreground at the same time.
The notifications are just an alert and an OK button:
[notif setHasAction:NO];
So the idea is: Pop in the headphones, start my app, it schedules a series of notification - then start the Nike +iPod workout. When you hear the Notification sound, change from rest to workout or vice versa.
Ok, when the workout is over there are 15+ notifications on the screen and they need to be manually dismissed, this is a bit annoying and not at all user friendly.
My question is now if there is a way to post only sound notifications? OR make sure earlier notifications are removed as new ones pop up OR is there a different/better way of going about achieving the functionality of getting a "sound indicator" while the app is in the background?
Hope someone can lend a bit of experience or a good idea for an alternative:)
Thanks in advance.
I can't confirm how well this would actually work, but if you set the alertBody property on your UILocalNotification object to nil (this is the default value) when you create them, it should prevent an alert from appearing on screen as you fire them.
In addition, you might also want to set the hasAction property to NO, which prevents the user from seeing the action buttons (if you had an alert), or the slider (if they had the device locked).
But as for the actual stacked notification alerts - I don't believe there's any way to prevent them getting stacked. That's something which might be worth raising a Radar for, so Apple could consider allowing that to happen in future iOS versions.