I am developing an iPhone applciation in which I am applying UIView Animation, but when multitasking occurs like user answers a call or a skype call, my animation is disturbed.
Is there any way to avoid this?
EDIT
Suppose a scenario Skype call is running, in the meanwhile i started my application that has some UIView Animation, while skype call is running its behaviour turns strange? Any comment on that ??
You can't avoid disturbance from incoming calls and other things like that. What you can do is to save the state of you animation in the moment when interruption happens and restore this exact state to continue your animation when app is back in foreground.
What usually happens is that the animation jumps to the "end point" instantly. In case you have cascading animations it's best to make sure you are not in multitasking when starting the new one.
Related
My app can be launched via UIApplicationLaunchOptionsLocalNotificationKey in the background. In that case the usual flow to setup initail view controller and some animations on the app's landing-page/first-page of the app take place.
My question is, Is this a good practice, If I leave these animations like this even when my app is launched via OS in background? Three things I am concerned about:
Some animations are continuous, like a circular-dot(UIImage) expanding and shrinking, using CAAnimation.
Some views are added and removed as subviews to the keyWindow, based on user location.
When user taps the home button, do I need to stop the animations and subview additions then also?
Making the animation stop and resume via applicationDidEnterBackground and applicationWillEnterForeground seems tedious.
Background
When the app is backgrounded I want to have a lock screen that forces the user to log in again. I have implemented this in the OnResignActivation method in AppDelegate.
Functionally this works fine, however, when backgrounded the lock screen tries to slide in but doesn't have time to complete. When the app opens again this animation completes.
Question
How can I get the animation to complete or not use the animation at all so that when ever the app is opened again the lock screen is there and not half way across?
Solution
The solution was in fact in implement the lock screen logic in DidEnterBackground instead of OnResignActivation in AppDelegate.
As the code was running to soon in the life cycle I was getting half an animation behaviour. Putting it in DidEnterBackground resolves this.
These SO answers helped me arrive at this solution.
https://stackoverflow.com/a/12416131/1593273
https://stackoverflow.com/a/25985478/1593273
I want to have some information drop down from the top of a view, stay on the screen for a second or two, and then go back up out of the view. I have search for displaying notifications and/or banners. All I get is either push notifications (which I don't need to use) or iAds banners.
I'm working on a barcode scanning app and I want to briefly show the value of the barcode shown without requiring the user to tap on anything. How can I accomplish this?
Don't use notifications and banners, because that might not work: the user can turn them off. In any case this is not a notification of anything, so it's a misuse of notifications.
Just do what you described, yourself: animate a view onto the screen, and then (in the animation's completion handler) use delayed performance to animate the view right back off the screen after a short delay.
You should use a view which manages its own state (INCOMING, STAY PUT, OUTGOING). This way you can reduce the memory footprint and many other bugs in the process. I coded something for a similar process. Check it out
How can I be notified when the iOS Control Center is being opened?
UIApplicationWillResignActiveNotification isn't good enough since this notification is sent also when the Notifications Center is opened, alert view appeared and other possible scenarios.
I was sure this is not possible, but QuizUp app is notified when the user open the Control Center while the user is on middle of a gameplay to prevent cheating the game.
Thanks
Hey there I did a lot of trial and error investigation and came up with a solution that turns out being very reliable. It works in all orientations and both in fullscreen (no statusbar) and in regular mode. AAWindow is a subclass of UIWindow and you can find it on GitHub.
The way I accomplished this is by overriding sendEvent in UIWindow, separating out TouchEvents from the other events and checking whether touches occur in the bottom 10 percent of the screen (which is the part that can open Control Center). If there are touches and applicationWillResignActive is called within a timespan of .5 seconds (with statusbar) or 3 seconds (without statusbar) you can be very sure that this is because of Control Center being opened. Then a NSNotification is being fired and you can react to that anywhere in the application.
I tested a UIPanGestureRecognizer approach (with and without the status bar visible—changes if the little pull tab comes up instead of control center) along with watching for the applicationWillResignActive notification, and I couldn't reliably know if control center was opened. If the pan was slow enough the gesture recognizer would trigger first, but it's definitely easy to swipe up fast enough to trigger control center and bypass the gesture recognizer firing at all.
Attempting to check if the app goes from applicationWillResignActive and then to applicationDidBecomeActive would be a pretty reliable way to know if the app entered and exited one of a couple states (control center, notification center, answering a phone call, etc), but telling the difference between say notification and control center is impossible this way.
TL;DR: I don't think there is a reliable or accurate way to tell if control center was opened, but QuizUp may be doing something interesting to fake it, and I am open to being wrong!
When Control centre is opened the cycle isn't completed. Means only the method
applicationDidResignActivity will be called but applicationDidEnterBackground won't be called. When app is minimized both methods will be called. Here you can differentiate.
I have a timer in my app, and I want it to appear to be running while my app is on the background. I'd like that if the user presses the home button when the timer shows, for instant "01:11:11" and then goes back to the app and it becomes visible to him 10 minutes later, to see the timer as "01:01:11", however I get a split second where it shows the last state when the app went to the background ("01:11:11") before it starts updating from the correct time.
I assumed that I could correct this by updating the state of my timer in "applicationDidBecomeActive" and it did work on my simulator in Xcode but not on my Ipad.
I'm using cocos2d for my drawing and this is what I'm doing in my applicationDidBecomeActive:
CCScene *s=[director_ runningScene];
GameLayer *l=[(GameLayer*)[s getChildByTag:GAME_LAYER_TAG];
if (l!=nil) [l myUpdate];
I don't think it's relevant to the problem though because myUpdate does get called but I still have that split second glitch on my Ipad, as if it starts back from its last state no matter what.
In apples clock app, in applicationDidEnterBackground it hides the timer text, so that when the app comes into the foreground you see a blank UI for the split second where your app is loading the new timer data in the UI. Also, you may want to call some of your applicationDidBecomeActive code in applicationWillEnterForeground, which is called first. But keep in mind, applicationWillEnterForeground is not called when the app first launches.
There will always be a delay between when your app comes into the foreground, and when the UI updates. Theres no way to fix that, so you might as well use what apple uses to get around the issue.
Well I tried to hide my UI in both applicationWillResignActive and applicationDidEnterBackground. Since applicationWillResignActive is called first and before going into preview (double click on HOME) it causes a "not so pretty" preview but I thought at least it would solve my original problem. It didn't (not, on my IPad). It looks like the system takes the screen shot even before applicationWillResignActive.
I checked the timer in the official clock app and I see the clock is updating even when the app is in the background (in preview), so they "cheat" anyway...