I'm not sure what causes it, but I and others on my team have found that, for some reason, iOS sometimes decides to completely disable all animations within our app. iOS general animations (parallax, app switching, home button, etc.) are still enabled, so it's restricted to our app.
This wouldn't be so much of an issue if it weren't for the fact that it seems that some things like -[UIResponder becomeFirstResponder] don't work immediately after what would otherwise be an apparition animation (for instance, in a viewDidAppear method, or the block of a -[UIViewController dismissViewControllerAnimated:completion:]).
I've checked our code to ensure this isn't something we do, and indeed we simply pass YESs into the Cocoa Touch framework when it asks if we want things animated, and at no point in our code (or, as far as I know, in our 3rd-party SDKs) is +[UIView setAnimationsEnabled:] ever called. Likewise, I didn't do anything in iOS settings like "Reduce Motion", and simply restarting our app or letting the iOS device sleep will reverse this state.
So, what might cause iOS to disable our app's ability to use system animations? Additionally, Does this affect how/when/if delegate methods and callback blocks are being called?
Also, is there a way to detect, trigger, or reverse iOS's decision to disable animations?
Related
Does anyone have any insights into when/under what conditions applicationWillTerminate is called in iOS 5/6?
I've got some logic i'd like to execute whenever the application terminates (not moves to the background), for example if the user navigates to the application bar at the bottom of the screen by double tapping the home button and force quits the app.
when i try to do this on a test device, applicationWillTerminate does not seem to get called. Is there a reason for this?
My plan B is to tie that logic to some persistent object like a singleton or a static that is automatically destroyed when the app quits.
Any suggestions?
thanks
Have you read the documentation for applicationWillTerminate:,
It says,
For applications that do not support background execution or are linked against iOS 3.x or earlier, this method is always called when the user quits the application. For applications that support background execution, this method is generally not called when the user quits the application because the application simply moves to the background in that case. However, this method may be called in situations where the application is running in the background (not suspended) and the system needs to terminate it for some reason.
There is a "maybe" mentioned there. Probably that answers your question. So it is not necessary that this will get called when you quit the app. Probably you might have to use UIApplicationExitsOnSuspend to disable multitasking and then it might get called while putting in background. But that again depends on your app requirement. If you cannot disable multitasking, you might have consider doing that in applicationDidEnterBackground method or so. I am not sure if there are any other delegate methods which will help in identifying the force quit.
Here is some background information, otherwise skip ahead to the question in bold. I am building an app and I would like it to have access to the remote control/lock screen events. The tricky part is that this app does not play audio itself, it controls the audio of another device nearby. The communication between devices is not a problem when the app is in the foreground. As I just found out, an app does not assume control of the remote controls until it has played audio with a playback audio session, and was the last do so. This presents a problem because like I said, the app controls ANOTHER device's audio and has no need to play its own.
My first inclination is to have the app play a silent clip every time it is opened in order to assume control of the remote controls. The fact that I have to do this makes me wonder if I am even going to be allowed to do it by Apple or if there is another way to achieve this without fooling the system with fake audio clips.
QUESTION(S): Will Apple approve an app that plays a silent audio clip in order to assume control of the remote/lock screen controls for the purpose of controlling another device's audio? Is there any way of assuming control of the remote controls without an audio session?
P.S. I would prefer to have this functionality on iOS 4.0 and up.
P.P.S I have seen this similar question and it has gotten me brainstorming but the answer provided is not specific to what I need to know.
NOTE: As of iOS 7.1, you should be using MPRemoteCommandCenter instead of the answer below.
You create various system-provided subclasses of MPRemoteCommand and assign them to properties of the [MPRemoteCommandCenter sharedCommandCenter].
I'm keeping the rest of this around for historical reference, but the following is not guaranteed to work on recent iOS versions. In fact, it just might not.
You definitely do need an audio player but not necessarily an explicit session to take control of the remote control events. (AVAudioSession is implicit to any app that plays audio.) I spent a decent amount of time playing with this to confirm this.
I've seen a lot of confusion on the internet about where to set up the removeControlEventRecievedWithEvent: method and various approaches to the responder chain. I know this method works on iOS 6 and iOS 7. Other methods have not. Don't waste your time handling remote control events in the app delegate (where they used to work) or in a view controller which may go away during the lifecycle of your app.
I made a demo project to show how to do this.
Here's a quick rundown of what has to happen:
You need to create a subclass of UIApplication. When the documentation says UIResponder, it means UIApplication, since your application class is a subclass of UIResponder. In this subclass, you're going to implement the remoteControlReceivedWithEvent: and canBecomeFirstResponder methods. You want to return YES from canBecomeFirstResponder. In the remote control method, you'll probably want to notify your audio player that something's changed.
You need to tell iOS to use your custom class to run the app, instead of the default UIApplication. To do so, open main.m and change this:
return UIApplicationMain(argc, argv, nil, NSStringFromClass([RCAppDel`egate class]));
to look like this:
return UIApplicationMain(argc, argv, NSStringFromClass([RCApplication class]), NSStringFromClass([RCAppDelegate class]));
In my case RCApplication is the name of my custom class. Use the name of your subclass instead. Don't forget to #import the appropriate header.
OPTIONAL: You should configure an audio session. It's not required, but if you don't, audio won't play if the phone is muted. I do this in the demo app's delegate, but do so where appropriate.
Play something. Until you do, the remote controls will ignore your app. I just took an AVPlayer and gave it the URL of a streaming site that I expect to be up. If you find that it fails, put your own URL in there and play with it to your heart's content.
This example has a little bit more code in there to log out remote events, but it's not all that complicated. I just define and pass around some string constants.
I bet that a silent looping MP3 file would help work towards your goal.
Moshe's solution worked great for me! However one issue I noticed is when you paused the audio, the media controls would go away and you won't be able to play it again without going back into the app. If you set the Media Info on the lock screen when you play the audio then this won't happen:
NSDictionary *mediaInfo = #{MPMediaItemPropertyTitle: #"My Title",
MPMediaItemPropertyAlbumTitle: #"My Album Name",
MPMediaItemPropertyPlaybackDuration: [NSNumber numberWithFloat:0.30f]};
[[MPNowPlayingInfoCenter defaultCenter] setNowPlayingInfo:mediaInfo];
I've got an app that changes the screen brightness with [UIScreen mainScreen].brightness = newBrightness, and I want to restore the brightness to it's previous state when the user finishes using it.
I've tried these two delegate methods:
- (void)applicationDidEnterBackground:(UIApplication *)application
- (void)applicationWillResignActive:(UIApplication *)application
But without much success. I suspect my app must be in the foreground to change the brightness? When I change the brightness in didEnterBackgroundMethod, it has no effect at all. When I use willResignActive it does restore the brightness if I switch to another app, but it has no effect when I press the home button.
Are there any notifications or delegate methods that are executed before the app leaves the foreground?
It seems this happens to others as well: see this S.O. post.
Only way around it seems to be forgetting about setBrightness and simulating it by overlaying a black-semi-transparent on your view...
OLD ANSWER:
willResignActive should also be called when you press the home button before the application enters the background state.
This method is called to let your application know that it is about to move from the active to inactive state. This can occur for certain types of temporary interruptions (such as an incoming phone call or SMS message) or when the user quits the application and it begins the transition to the background state. An application in the inactive state continues to run but does not dispatch incoming events to responders.
This is also the behavior I witness. So, my guess (but it's just a guess) is that your app is not set to support background, so that when pressing the home button it is terminated. In this case applicationDidEnterBackground is not called.
I would suggest to check the info.plist file in your project for the UIApplicationExitsOnSuspend or "Select Application does not run in background" key.
Furthermore, you could try and put some breakpoints (or NSLog traces) in those functions and check whether they are effectively called as expected.
According to Apple´s DevForum it seems to be a bug that Apple don´t want to fix soon.
I want to track four finger touches in my application, but they are cancelled as the iPad uses the four finger swipe to switch applications.
Is there a way to cancel / override this gesture?
I looked into this for a game I worked on and I could not find a way to override it. Even if you found a way, it would probably get you rejected from the app store, since there doesn't seem to be any public API for it.
This be my answer. I'm not sure how you'd go about to actually execute the below as I guess implementions do things differently, but generally it sounds as there is a possibility, because after all these are the words of Apple regarding the multitasking gestures:
"Developers are encouraged to evaluate any existing interactions in
their applications for potential sources of interference. In order to
properly interoperate with multitasking gestures, applications must
properly handle the following methods and notifications:
touchesCancelled:withEvent: (UIResponder) cancelTrackingWithEvent:
(UIControl) applicationDidBecomeActive: and
applicationWillResignActive: (application delegate)
UIApplicationDidBecomeActiveNotification and
UIApplicationWillResignActiveNotification notifications These can be
enabled for development via Xcode so you can update your apps to
interoperate with these new gestures. Test them and give us your
feedback in the Apple Developer Forums."
I really don't think you can because I have watched countless videos on how to override on iPhone/iPod but there are no ones for iPad must be so you can't cheat on games!
My App is a view-based application. At the beginning I show my logo and after a delay of a few seconds it changes into another view. from then on the user can switch to a lot of different views.
Sooooo.. My Problem: The thing is, when I restart my App. [..well closing and reopen by touching the icon..] the app itself doesnt restart in the sence of jumping to the very first view. to the contrary: at restart the user just returns to the last view that was open.
So I dont know why this is.
Is it normal to somehow manually tell the app to return to the very first view after restart? And if so, how do I have to do that?
PS.
I have so no idea what to do.. Maybe my problem has to do with the timer i used in the first view to change after a delay of time?
Please, is there anyone, who can help me?
Your problem is that, as of iPhone 4, returning to the home screen does not terminate your app. It's just made inactive, so opening it again reactivates it. In most cases, this is a good thing. If it doesn't work for your app, you can add the UIApplicationExitsOnSuspend key to your Info.plist with a value of YES.
(As I said, you should only do this if it really helps usability. If it's just about getting your splash screen shown again, most users and possibly Apple will frown upon it.)
iOS 4.0 and greater have a fast-start thing that allows apps to restart back from where they were upon restarting. There are several ways to deal with this:
1.) your App Delegate receives info about being but into the background and resumed. - (void)applicationDidBecomeActive:(UIApplication *)application and - (void)applicationDidEnterBackground:(UIApplication *)application are the relevant functions here. Check the docs.
2.) You can also disable the background, inactive state completely by including UIApplicationExitsOnSuspend in you Info.plist as Chuck already pointed out.
Overall, you should check the application state docs on Apple's Side.