I have an app that runs in the background (location services). When the app is in the foreground it vibrates fine when I want it to, however, if its not in the foreground (in the multitasking view), the vibrate does not work anymore. Is this not allowed? Is there some way for my background app to give a vibrate alert? If not that what about a beeping sound?
Right now I am just doing something like this:
AudioServicesPlaySystemSound(kSystemSoundID_Vibrate);
While importing:
#import <AudioToolbox/AudioServices.h>
If you enable background audio modes (as documented by Apple at https://developer.apple.com/library/prerelease/ios//qa/qa1668/_index.html) then vibration will happen when the app is in the background state. I just verified that adding the "App plays audio or streams audio/video using AirPlay" entry under the "Required background modes" property in the target's properties allows the vibration to work when the app is not in the foreground.
I found that checking 'Audio,AirPlay and Picture in Picture' within the 'Background Modes' of your apps Capabilities worked:
If you're trying to provide the user with a notification of something while your app is running in the background, consider delivering that information using a Local Notification (see UILocalNotification.)
Forcing the phone to vibrate is not a great user experience for a few reasons:
Some users (including myself) disable vibrate while in silent mode
iPads and iPod Touches do not vibrate
Users may not know what caused the vibration or sound and may not realize to open your app
Local notifications appear to the user in a manner that they can control and will recognize.
If your intention is something besides notifying the user, add that to your question & I'll try to help.
I'm pretty sure that you aren't able to vibrate the phone while it is in the background state. I've actually never seen an app do this.
Related
I working on swift for Ios App. I want to phone user connect specific wifi. So i open iphone wifi settings by NSURL like this. After then my app go to background and i control ssid every 500ms in background by background task like this. When phone connect the specific wifi i can see this status and i stop background task. But i cant comes my app to foreground. I tried open my app use NSURL metod like this video (i add custom url my info.plist and add application function in my appdelagate) but my app has no return use this metod.
unfortunately bringing an app from background to foreground is not possible. You can however send a notification or a badge for the user to click and open the app. The user should have notifications enabled for this to work.
Happy Coding!
I have a requirement where i need to track the iphone device state like if device is locked or unlocked. I was able to track these events when the app is running in foreground or background. But i also need to track the same when the app is suspended. Something like tracking the user location in background when the app is suspended. But i don't need to track the user location but only the device state.
Please suggest me some steps to solve this issue in objective-c.Thanks in advance.
You can not perform any operations once your app is in suspended state and you can not prevent your app from getting suspended unless you are using one of the background capability mode mentioned in this apple doc
So what you are looking for is not possible if you are not using either of background modes allowed by apple.
EDIT
Even if you go on and enable one of background mode like background audio, your app is likely to be rejected during review process as reviewer will see you do not have a valid reason to use that particular background mode.
One would think it would be essential for a VoIP app to obey the same rules as the stock phone app but it turns out to be almost impossible to implement ringing correctly. Several things I tried:
Local push notifications with ring sound.
Good: obeys both Silent and DND modes.
Bad: the sound can be no longer than 30 seconds, and it only vibrates once when the notification appears. So to achieve the ringing effect the notification has to be re-pushed e.g. every 6 seconds, effectively spamming the notification center. Also push notifications do not sound/vibrate if the app is active so the app has to detect that and ring differently.
AudioServicesPlayAlertSound().
Good: proper API seemingly designed specifically for this task. Obeys silent mode.
Bad: completely ignores Do Not Disturb mode, the sound and vibration come right through.
Use AVFoundation to play the ring sound.
Good the sound plays.
Bad: does not support vibration, does not support silent/DND modes. Essentially not usable as a ringer.
Is there a better way? Or did Apple completely miss this use case?
As you say in your 3 options, only a UILocalNotification actually obeys silent/DND mode.
The problems with it can be solved.
Spamming the notification center: I think that works quite well. You can cancel your previous notification immediately before you fire off a new one, so there will always be only 1 outstanding notification.
[[UIApplication sharedApplication] cancelAllLocalNotifications];
Vibration problem: You should be able to call this: AudioServicesPlaySystemSound(kSystemSoundID_Vibrate); in the same place where you call your local notification over and over again with a timer until the call ends or the users acknowledges the call. With the VOIP background setting on it should work in the background.
As you stated in option 2 the vibrate will not follow DND mode, but it's just vibration. If you spam the notification center that will vibrate once every time the notification comes in so you may not need to explicitly start vibrating if that's enough for you.
Good luck.
In one of my apps I have to detect external sound even if the app is in the background. I have some question on this.
Is it possible to detect external sound continuously even if the app is in background mode or closed? If so then will it have an effect on the device battery?
Does apple allow these kinds of app?
If my first question is not possible then is there any alternate way to achieve this?
It is impossible to detect the external sound when the app is in background.Due to background task time restrictions, iOS Background Task can not be run more than 10 secs.
app is not possible.
You can make notifications while the app running in background. But I dont think any way to achieve this functionality.
This is not possible.But you can make it only for some secs.
With Push Notifications it is possible.
I am creating player application, which is playing audio streams through internet. I want to add alarm functionality in my app - in particular time my player begins to play audio stream, I am trying to use UILocalNotification mechanism. But I've difficulties with it when my application in background mode, I can't call 'play' method, when notification is receiced (can't without user interaction). May be it is impossible?
But I bought this application:
http://itunes.apple.com/us/app/radio-alarm-clock-mp3-radio/id380271167?mt=8
And it seems like radio can start playing when local notification is received. Alarm can start playing radio when my app is in background mode.
Earlier I was trying to use NSTimer for this, but when my app goes to background, timer stops. If I use beginBackgroundTaskWithExpirationHandler: it works only 10 minutes. My app has special flag in plist, what is is audio application, and can playing music in background. In this case timers are working. But if I stop playing and go to background, timer is not working.
When I use \Radio Alarm Clock' application, I hear 'white noise' from dinamic, when music in not playing. May be it is the secret of this application?
Can you help me with my problem? Thanks.
maybe it's too late.
I had a look to the app you've mentioned at http://itunes.apple.com/us/app/radio-alarm-clock-mp3-radio/id380271167?mt=8 and yes, I think you are absolutely right, the only way to achieve that the application remains active while in background is to play a fake sound while it is in the background, which should be prohibited by Apple.
I've also seen that they don't use the remote iPod control, and this was strange at a first look.
At the end my opinion is that they do the following:
Avoid the call to beginReceivingRemoteControlEvents which allows to activate the iPod controls while in background (in fact they don't have it)
In this way, the status bar doesn't show the play icon while
the app plays audio
When the app goes in background, it probably plays a no sound periodically (once every 10 secs for example), in this way the app remains active
I saw that they also avoided to manage interruptions, for example in case another app is in foreground and plays music. Again Apple should have rejected the app for that reason, cos it is against the rules to follow while in background, but maybe they didn't see it during the acceptance tests.
So my interpretation is that they have intentionally missed to activate the iPod controls, just to avoid to show the play icon in the status bar while in background. In this way, the users are unaware that the app is active and is doing something strange after they close it.
In addition you can see that the app doesn't interrupt when another app plays in foreground a sound or audio, because otherwise they risk that the app doesn't restart on time when the alarm shpould fire.
That's just my idea of how they do that, and I think this is the only way for an audio app on iOS to remain active while it is in background and is supposed to be halted (well, in case Apple doesn't see the trick).
Have you tried adding this to appdelegate.m
- (void)application:(UIApplication *)application didReceiveLocalNotification:(UILocalNotification *)notification {
// Call your method in here.
}
if you have can you add code for us to see what your doing.