I have an (old) audio app that is misbehaving on iOS 5.1.1. It records audio and on older iOS versions (don't know precisely where the "break" is) it would stay "in foreground" while recording, without any nudging.
But on 5.1.1 the app is put into background after two minutes, and then things go sour. Currently (will have to change this, I suppose) the app kills recording when it's backgrounded (and it appears to do this successfully), but it still dies with a trap in the above routine.
Unfortunately, the call stack is empty when this occurs, so there's little clue as to why the app's getting killed, but I gather (just from hints here and there on the web) that the trap occurs because a background app cannot use any UI facilities, and the app must somehow be calling something UI-ish. But I haven't a clue what it might be.
I've worked through most of the notifications, to see if a notification might be lurking in a queue somewhere and doing something, but I've not found anything so far that might be triggering a UI opp.
Any ideas on how to track this down?
Aha!! The app uses an Apple freebee widget known as AQLevelMeter. When recording is stopped, the level meter is also stopped, but the stop code inside AQLevelMeter.mm does not invalidate the timer that's driving the UI updates.
Related
My app (OS X 10.10, Xcode 6.1.1) uses an AVPlayerView to show a video resource bundled inside the app. Normally the video runs as expected. Sometimes--and I haven't figured out a way to reliably reproduce this--the video does not start to play, and the screen is all black. At the same time, a warning pops up in the console:
<<<< Boss >>>> figPlaybackBossPrerollCompleted: unexpected preroll-complete notification
How can I programmatically recover from this? I tried Googling parts of the error description but there was only one result (an email to the Apple Mailing List).
Perhaps a notification my view controller can listen for?
Alternatively, if you know a way I can force this state to reproduce, that would help too, as I could then put a breakpoint in.
UPDATE: I still haven't been able to force this problem to reproduce, but I have seen it a couple of times since the first post, and I can say for sure that it's not related to the NSNotifications AVPlayerItemNewErrorLogEntryNotification, AVPlayerItemPlaybackStalledNotification or AVPlayerItemFailedToPlayToEndTimeNotification. My View Controller is listening for those, and didn't hear them when the bug presented.
Thanks!
I am currently trying to find the most efficient way to continue a method in the background of my app.
I am probably adding location/gps to my app soon, so I was considering using that flag to keep the app Active in the background. However, I do not want to add that flag yet because I want to post an App Update before I add the location functionality.
I know the exceptions;
Apps that play audible content to the user while in the background, such as a music player app
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Newsstand apps that need to download and process new content
Apps that receive regular updates from external accessories
Besides asking for a more generic idea then these ^, can someone explain the "external accessory" flag please? I am recording video from an outside device. However, I do not know what constitutes an "external accessory".
I also see that iOS7 has introduced new Multi-tasking functionality but I haven't seen any examples that I understand can someone also explain that? Maybe that is a viable solution?
Thanks in advance!
When a user first opens my app, I need to download and install some content from a server before they can begin using the app. The problem is that this takes around 5 minutes on wifi, during which time the app goes into the background and the download is suspended.
Is there any way to either:
prevent an iOS app from entering the background whilst I perform my download
or continue peforming the task in the background (i.e. perform the task irrespective of whether the app is in the foreground or background)
Thanks
It really doesn't matter, if the user presses the home button it will go to background. Although you can do two things to mitigate the problem:
Use beginBackgroundTaskWithExpirationHandler, to give you a bit more time to download. Which you can read here.
Don't allow the device to become iddle, with [UIApplication sharedApplication].idleTimerDisabled = YES;. You can read more about that here.
Either way, the best thing you can do is to tell the user, that is an important download and he shouldn't quit the application.
Can't you include some or all of the content in your app bundle instead, and just download changes on first run?
I can't imagine this is a good first user experience, and it may not pass App Store review like this.
The only third party apps that are allowed to download in the background are newsstand apps loading issue content, and Apple are pretty strict about what they allow as newsstand apps.
You can't do what you want, in this situation. One way, and I think the best and only, is to resume your download when you app becomes active (returns to foreground state). Also, don't forget to register for connectivity notifications (Reachability class can be used for this purpose from this Apple sample app http://developer.apple.com/library/ios/#samplecode/Reachability/Introduction/Intro.html). Good Luck!
I want to register my app for push notification when my application terminates so i think if i delay my app quitting time it could be possible.Does someone knows how to delay application quitting time? I think this method
[self performSelector:(SEL)aSelector onThread:(NSThread *)thr withObject:(id)arg waitUntilDone:(BOOL)wait];
will do my job but i don't know how to use this method if someone knows please tell.I need to send some data to a server along with registering for Push Notification when my app quits.
I can't imagine why you would want to do this. If it were even possible it would be extremely annoying for a user to tap the home button and the app to take x amount of time to shut down. This time 'x' being dependent on the server connection creates even more user headache.
Apple have the home button exit apps immediately for a reason.
If you want to register the Push Notifications like you suggest, do it while the app is running. If your worrying that they won't be properly set if the user exits prematurely... don't.
As users, we all know there are sometimes consequences of exiting a program without giving it time to save your settings.
For push notification it is better to register when the app first starts and then send the push token to your server in the background. However, if you have a good reason why you need to do the registration just as the app terminates, I believe you can do this if you are using iOS 4. iOS 4 has a new feature called "task finishing" that allows an app to stay running for a few minutes after the user closes it so that it may finish up any tasks it was in the middle of (such as saving data).
I want to develop a screensaver-like app where the only way of getting back to the springboard is entering a code. Therefore I would need the Home Button action to be ignored, that is that when the user presses the button nothing happens..or something custom...instead of going back to the springboard and terminating the app.
Is this possible? does anybody know if apple will approve/reject this kind of app?
The answer to your question is, yes.
The answer to the question you meant to ask--can I ship an app through the iPhone store that has the home button disabled--is no.
If you are only publishing your app to jailbroken phones you can do it, but it will piss everyone off.
Edit 7 years later:
This is actually extremely possible now--there is a standard feature in the iPhone called "Guided Access". It's hidden under that "Accessibility" Link (With some other fairly cool stuff like flashing the LED whenever you get a call and allowing a Bluetooth keyboard to tab between controls)
It's called "Guided Access". You set a passcode, launch the app then triple-click the home button to start guided access.
It disables exit and allows you to designate regions of the screen you can't touch. You can also set a time limit (For kids playing which seems to be the reason a lot of people look up this question).
Tempted to edit the "Accepted answer" and throw this info in there, but that seems rude so I'll just hope people find this answer.
Annoyingly you also seem to be unable to shut off the phone--I suppose this is perfect for people who want their kids to play a game, but might not hit the original asker's problem of restricting access to a single app (I mean it WILL do that but it'll also prevent it from doing ANYTHING else).
Not with public APIS (and hopefully, not with private ones). Even if you manage it somehow, Apple will reject it for breaking UI guidelines. Moreover, even if they didn't, people could always use the iPhone's "Force Quit" equivalent to hard terminate your app.
Apple is not going to approve this type of app, they state pretty explicitly that you're app needs to respond appropriately to springboard telling the app to terminate both when things like phone calls come in and when memory warnings come in.
This is not possible with the current SDK, nor do I suspect it will ever be.
You might be able to get this behaviour via jailbreaking, but you won't be able to sell your app through iTunes, nor will Apple ever approve such an application.
You can do it like this
Install the following mobileconfig file
This will disable the home button once you launch the app
Download
Found the link Here
Apple won't allow it.
What if something emergency happens and you wan to dial an emergency phone number. You are putting the user at risk. The trade-off isn't worth it.