I would like to perform a different action when my app moves to the background depending upon if its moving to that state because there is an incoming phone call, or if its moving to that state because the user has hit the home button.
In both cases the app delegate receives a willResignActive:, then a didEnterBackground: call. Therefore from the app delegate calls alone it would appear its not possible to determine the difference.
Is there some way?
UIApplicationDelegate Protocol has a variety of methods for Monitoring Application State Changes.
Unfortunately (for you), going into the background is going into the background, there is no differentiation as to why. Given Apple's app design of walling everything off (for security reasons) I don't see them providing you details about what's going on on the phone outside your application.
I would certainly question the need for different behavior in those two cases, but I don't know the details of your app.
Related
In iOS 14 you can now accept phone calls that do not take up the entire screen (the new non-intrusive phone call UI looks like a push notification). If you accept the call, but do not open up the full screen call UI, the app remains open. This is true even if you pick up the phone and put it to your ear the app remains active.
What would the best way be to detect an incoming call, or that the user began the call?
You can’t detect it. If the user just takes the call direct from the banner, your app remains active and there is nothing to detect. That is the whole point of this feature: a call need not interrupt your app in any way.
I have a push notification with rich content.
Can I make it in such way that it is not tappable, i.e., a single tap will not open the application. It must be dragged down to rich content or 3D touched, or deleted from the notification center by swiping.
How should I indicate to the user to drag down (3D touch) in order to reveal rich content on notification?
No, a tap on a push notification will always open the notification in the app, and as far as I know there is no way in public API to override this behavior. It does appear there is a private API to get the behavior you’re looking for, as some iOS-generated (local, not push) notifications appear to do exactly what you’re asking. If you can manage to uncover that, use at your own risk should Apple find out.
Now, as for possible solutions: I would consider implementing code on your app’s delegate to respond appropriately when the notification is opened. For example, send the user to an appropriate location in the app when the app is launched from a notification…perhaps a view controller that shows the same content that would be shown as the rich notification content. I don’t know the exact use case, but the wording implies to me that if the app launches to its main interface, it could be confusing to a user.
It’s impossible for me to tell you how exactly you wish to respond to notifications, so for more on responding appropriately when the app was launched from a push notification, see the following documentation from Apple:
Determine Why Your App Was Launched
UIApplicationDelegate.application(_:willFinishLaunchingWithOptions:)
UIApplicationDelegate.application(_:didFinishLaunchingWithOptions:)
UIApplication.LaunchOptionsKey
UIApplication.LaunchOptionsKey.remoteNotification
Hopefully from that you can find a suitable solution. But if that isn’t an option, consider directly telling the user at some point to press firmly (or tap and hold, as many devices do not support 3D Touch) to view the content. You could do this during some onboarding process or, as an absolute last resort, in the notification itself.
Before proceeding down that route, though, understand that not all users know 3D Touch and/or this rich-content functionality even exists — even fewer use it regularly — and if they become confused, they may decide to clear the notification or outright disable your app’s notifications. In general, it’s also a bad idea to “teach” your user unfamiliar ways of using their device. If a user is used to tapping on notifications, as many are, they will most likely tap on your notifications. It can be tough to break that muscle memory.
I have an app when a specific action fires I close the app and ask the user to reopen it again.
The problem is when the app executes exit(0) the app stays in the apps stack (when I click the home button twice). I want it to be killed completely so that viewDidLoad() will be executed again when the app opens.
You cannot terminate an app on it's own.
From Apple's Human User Guidelines...
Don’t Quit Programmatically
Never quit an iOS application programmatically because people tend to
interpret this as a crash. However, if external circumstances prevent
your application from functioning as intended, you need to tell your
users about the situation and explain what they can do about it.
Depending on how severe the application malfunction is, you have two
choices.
Display an attractive screen that describes the problem and suggests a
correction. A screen provides feedback that reassures users that
there’s nothing wrong with your application. It puts users in control,
letting them decide whether they want to take corrective action and
continue using your application or press the Home button and open a
different application
If only some of your application's features are not working, display
either a screen or an alert when people activate the feature. Display
the alert only when people try to access the feature that isn’t
functioning.
Have a look at this answer: https://stackoverflow.com/a/8491688/742298
I'm currently working on a change request for our iPad app that requires that I handle the resuming of the app in two different ways depending on whether the app returned from multitasking (the user was active in another app or on the homescreen and came back to the app) and standby (the iPad was switched to standby either through the standby button on top or by closing the Smart Cover)
In both cases the following methods are called in my AppDelegate:
applicationWillResignActive followed by applicationDidEnterBackground when I hit the homebutton to get tot he home screen or close the Smart Cover
applicationWillEnterForeground and applicationDidBecomeActive when I come back.
As the same methods are called I am a bit lost on how to detect where I come from on resume. All four methods have a single parameter passing in the UIApplication. I looked at its interface, but didn't find any useful clues.
Is there a way to differentiate between resuming from multitasking or standby?
There is no public api method to define why application did become active
I have a state-transition problem with NSTimer, of which I find difficult to keep track of during applicationWillResignActive / applicationDidEnterBackground, according to the context of my app.
I was wondering if it might not be a better idea to utilise UILocalNotification, especially given it's background/inactive firing. However, I wanted to know whether we have the ability to provide a custom method to UILocalNotification, of which does not present a dialog box (would damage the whole point of my app). In effect, i'd like to only make use of the timer-fire capabilities of UILocalNotification, and handle the fire event with my own method which does something very "undialog-friendly"
Have checked the ADC docs and it alludes to the dialog being presented every time.
Any advice you can give on this would be appreciated.
thanks
sc.
The dialog box is presented when your app is in the background. But it is not presented when your app is running - instead your app is free to deal with the notification however it sees fit. So it would be perfectly possible to hook it up to a custom method of your own making.
The main reason for this behaviour is a user may not want to go into your app if it's in the background. Of course, with iOS 5 the notification may not be a dialog box - it could be one of the new notification styles.