Display applicationState iOS - ios

I have a button which when pressed creates an object thing. It then sleeps for ten seconds and then calls thing.go which gets the application state like
UIApplicationState state = [[UIApplication sharedApplication] applicationState];
Then following this question's answer and comments I check if the app is in the background, and if it is, it displays a local notification.
So I press the button and immediately press the home key to go to the main screen (thereby putting the app in the background)
However, I can tell that the if statement is returning false and is therefore not executing any code within (by putting an NSLog inside the if statement).
So my next thought process was to somehow display the date in the console using NSLog(state). Obviously I cannot do this.
So how can I display the applicationState to resolve my issue? Or is there another way I can check to see if the app is running in the background within this class's method?
Here is the go function which is called inside the IBAction when the button is pressed
-(void)go {
if (state == UIApplicationStateBackground) {
NSLog(#"App is in background");
}
}
Here is the IBAction which is linked to the button, i.e. runs when button is pressed
- (IBAction)button_help {
myclass* thingy = [[myclass alloc] init];
sleep(10);
thingy.go;
}

You should pretty much NEVER use sleep. Forget it exists. It locks up your app, and nothing changes, including transitions to the background.
What you want to do is to set a timer for 10 seconds that then invokes thing.go.
However, that's going to be complicated by the fact that normally timers don't run in the background. In fact, unless you take special steps, your app doesn't get any processor time in the background. You get told that you are going to the background, and then the next call you get is the return-to-foregraound.
When your app gets a message that it is being sent to the background, it will need to make the system call that asks for background processing time. (I don't remember the call off the top of my head, and don't have Xcode running at the moment.)
Apple changed the rules for background processing in iOS 7, but you say this is iOS 6, so those changes don't apply.

If I understand correctly, you're checking to see if the app is returning from a local notification or if it was already active?
if (state == UIApplicationStateActive) {
// do something
NSLog(#"application was active ");
} else {
NSLog(#"sent from notification");
}

Related

viewWillTransitionToSize:withTransitionCoordinator: called when app goes into the background or inactive

It appears that the method viewWillTransitionToSize:withTransitionCoordinator: gets called multiple times when the app goes into the background or inactive since iOS 9.
For example, if the app is in the portrait on iPad, pressing the home button will cause the app to receive method call first with size of 1024x768 (landscape) and then with 768x1024 (back to portrait). That leads me to conclude that iOS does this in order to get screenshots for app switcher.
Our application logic depends on the screen size and changes to the screen size trigger tasks that update our model with regard to the new size. We need to do this when user rotates the device or goes into multitasking mode (split view), but we must not do it when user goes into the background.
One idea was to use UIApplicationWillResignActiveNotification notification, but that turned out to be mission impossible because sometimes viewWillTransitionToSize:withTransitionCoordinator: gets called before the notification is sent and othertimes it gets called after the notification is sent :/
Any ideas?
In viewWillTransitionToSize:withTransitionCoordinator you can use the UIViewControllerTransitionCoordinator to tell when the transition is complete. Then, check that your app is not backgrounded and perform your logic.
- (void)viewWillTransitionToSize:(CGSize)size withTransitionCoordinator:(id<UIViewControllerTransitionCoordinator>)coordinator {
[coordinator animateAlongsideTransition:nil completion:^(id<UIViewControllerTransitionCoordinatorContext> _Nonnull context) {
// after transition
if ([UIApplication sharedApplication].applicationState != UIApplicationStateBackground) {
// perform logic
}
}];
}
I currently have the same problem. I do a lot of work when the size changes and can't have it happening when going into the background. One thing that is working for me "most" of time is to check if the app is in the background using [uiapplication sharedApplication] applicationState]. The application state is set to UIApplicationStateBackground before the 2 extra calls to viewWillTransitionToSize are made. This seems to be consistent. I'm having some problems when the app is swiped in using multitasking then goes into the background and then foreground again at full size. The order of calls doesn't seem to be consistent in this case to determine which size changes should be used.
Yup, same problem. You could, instead of using 0.1 seconds, use the coordinator's transitionDuration(). Then, check for background status.

UIApplication's applicationState returns wrong value

My app execute background fetches to update some data. In my initial view controller's viewDidLoad method I want to detect wether my app runs for background fetch or not?
I know that it's very easy to check the app's state using this:
if ([UIApplication sharedApplication].applicationState == UIApplicationStateBackground) {
return; // have a breakpoint here <----
}
But for some reason even when I launch app normally sometimes program can reach this breakpoint. Which means that applicationState returns UIApplicationStateBackground. Maybe app launch happens at the moment when background fetch is running or something like that?
I don't want to execute code that in my viewDidLoad method when app runs in background mode, so I need this if block in viewDidLoad.
By the time your viewDidLoad method is called, it will be in the foreground (with a state either UIApplicationStateInactive or UIApplicationStateActive), so it doesn't make sense to ask for UIApplicationStateBackground in the viewDidLoad, for more info read this link.

Termination of an app running in the background

I am currently developing an app that will need to terminate after running in the background for more than five minutes. In order to do this, I will have to have a timer running in the background after the the Home button has been pressed or in case of an interruptions such as an SMS or a telephone call, then, after five minutes the applicationWillTerminate method will be called. My first question is should I put the applicationWillTerminate in the applicationWillResignActive method or in the applicationDidEnterBackground method? My second question is since this is an app with more that one view, Should I write these things in the AppDelegate class or elsewhere? Thank you for your response.
1) You can't force your app to finish programatically.
2) You should never call these AppDelegate methods by yourself. They're meant to be called only by the system.
Reference: UIApplicationDelegate Protocol Reference.
This is pretty ghetto, but what you can do is make your app crash when you want it to exit, and it will close automatically, granted that's not closing the app, but there's no real harm in it as long as you are in control of how it crashes try to go for a bad access error, aka trying to access something that has been deallocated
as for running a timer in the background, i don't know per say if you can do that, but as an alternative you can save the time when they leave the app aka the app goes into the background and then you can have all the events return to your app of the view controller that is first responder, and each UIEvent has a time stamp, and regardless of which event it is you can compare the time stamps and see if it's greater than 5 minutes
Regardless i don't suggest any of the above, but that is the best answer i can come up with for your question
the code for receiving events out side of your app
[[UIApplication sharedApplication] beginReceivingRemoteControlEvents];
will start the event tracking and the call back is:
- (void)remoteControlReceivedWithEvent:(UIEvent *)event { }
but you have to remember to
[self becomeFirstResponder];
this tells the device which view controller to go to for the event tracking, oh and don't forget to resign first responder, and endReceivingRemotecontrolEvents

Determining if a UILocalNotification was fired from scheduling or user interaction

I'm trying to determine different scenarios of UIApplication didReceiveLocalNotification:. If a user clicks the notification the while app is inactive, I should bring them to the corresponding UI page. Otherwise, if user just opened the app without tapping a notification, I should let them stay in the UI page which they left off from.
However, there is a little problem as the UILocalNotification was scheduled by myself.
[[UIApplication sharedApplication] scheduleLocalNotification:scheduledAlert];
So every time it fired by iOS, it will call the same delegate method as the callback when I manually clicked the notification on the status bar:
- (void)application:(UIApplication *)application didReceiveLocalNotification:(UILocalNotification *)notification { ... }
I tried some tricky hack such as counting the fired times while app is inactive mode, counting 1 means iOS firing, and counting 2 means user clicked, and relative counting management code.
But I don't think this could be the best practice. I checked the iOS Messages application, which has the same functionality. If you put the app into inactive mode, such as scroll down the status bar, then it can determine the UILocalNotification is from your touch (and will open the text editing mode) or just you return back to the app (stay in the previous status).
I would appreciate if you guys could let me know what the best solution is here!
I use a custom key-value pair which I set a NSMutableDictionary, which I then assign to UILocalNotification.userInfo, to tell different scenarios.
I check the app state so that I only handle the notification if I'm coming from the background:
UIApplicationState state = [application applicationState];
if (state == UIApplicationStateInactive) {
// Your Code Here
} else {
}

Can the application know whether the Home button or the Power button was pressed? [duplicate]

I have an app that needs to do something when it’s sent to background using the Home button and something else when the device is locked using the top hardware button. The standard way of solving these requirements are the notifications and delegate methods sent out by UIApplication. On iOS 4 they look like this:
// Pressing the home button
Will resign active.
Did enter background.
// Tapping app icon on Springboard
Will enter foreground.
Did become active.
// Pressing the lock button
Will resign active.
// Unlocking the device
Did become active.
In other words, it’s quite easy to tell between locking and backgrounding. On iOS 5 the behaviour changed:
// Pressing the home button
Will resign active.
Did enter background.
// Tapping app icon on Springboard
Will enter foreground.
Did become active.
// Pressing the lock button
Will resign active.
Did enter background.
// Unlocking the device
Will enter foreground.
Did become active.
Notice that the didEnterBackground and willEnterForeground notifications are now sent out even when (un)locking the device, making it impossible to tell between locking and backgrounding. Is this change documented somewhere? Is it a regression? Do you know another way to distinguish the two cases?
iOS 6
In my preliminary testing via the simulator, checking the application state with
[[UIApplication sharedApplication] applicationState]
in either
- (void)applicationWillEnterForeground:(UIApplication *)application
- (void)applicationDidEnterBackground:(UIApplication *)application
allows you to differentiate between a call to lock the device and just switching back to the homescreen. A lock screen will return 1 (UIApplicationStateInactive), whereas a home button press will register as a 2 (UIApplicationStateBackground).
It seems consistent and should work on an iOS device just as reliably as it does in the simulator.
iOS 7
The iOS 6 method no longer works in iOS 7. In order to do this now, you have to utilize CFNotificationCenter and listen for a darwin notification (labeled: com.apple.springboard.lockcomplete). You can find the github repo with the sample project here: https://github.com/binarydev/ios-home-vs-lock-button
Credit for the iOS 7 fix goes out to wqq
I have looked into this quite a bit so I would love to be wrong here if someone knows something I don't, but technically, there is no documented way to tell the difference between locking the device, and sending to background.
One thing you can check however, is the UIApplicationState during the transition from foreground to background. Locking a device will give UIApplicationStateInactive and moving the App to the background will give UIApplicationStateBackground. But, since this behaviour is not officially documented it may change in the future.
A basic example:
- (void)applicationDidEnterBackground:(UIApplication *)application {
UIApplicationState state = [[UIApplication sharedApplication] applicationState];
NSLog(#"Device state: %#", state);
switch (state) {
case UIApplicationStateActive:
/* ... */
break;
case UIApplicationStateInactive:
/* Device was/is locked */
break;
case UIApplicationStateBackground:
/* User pressed home button or opened another App (from an alert/email/etc) */
break;
}
}
UIApplicationState - The running states of an application
typedef enum {
UIApplicationStateActive,
UIApplicationStateInactive,
UIApplicationStateBackground
}
UIApplicationState
Constants
UIApplicationStateActive - The application
is running in the foreground and currently receiving events. Available
in iOS 4.0 and later.
UIApplicationStateInactive - The application is running in the
foreground but is not receiving events. This might happen as a result
of an interruption or because the application is transitioning to or
from the background.
UIApplicationStateBackground - The application is
running in the background.
According to the UIApplicationDelegate Protocol Reference:
applicationWillResignActive:
didEnterBackground:
// ...
willEnterForeground:
applicationDidBecomeActive:
are the only methods that ever get called in both situations.
According to the iOS 4.3 to iOS 5.0 API Diff, these are the ONLY changes regarding UIApplication or UIApplicationDelegate, so I couldn't find where they documented any of these notification changes:
UIApplication.h
Added -[UIApplication setNewsstandIconImage:]
Added UIApplication.userInterfaceLayoutDirection
Added UIApplicationDelegate.window
Added UIApplication(UINewsstand)
Added UIApplicationLaunchOptionsNewsstandDownloadsKey
Added UIRemoteNotificationTypeNewsstandContentAvailability
Added UIUserInterfaceLayoutDirection
Added UIUserInterfaceLayoutDirectionLeftToRight
Added UIUserInterfaceLayoutDirectionRightToLeft
This is more of a workaround/hack, but according to my experience it's very reliable.
When the device is screen-locked (not just home button-ed, if that's a word :)) - bound network (UDP) sockets are broken.
I was using GCDAsyncUDPSocket (also AsyncUDPSocket before) and they both fire a network/broken pipe error reliably when the device is turned off.
In my case I need the UDP socket anyway, for other apps it might be a bit smelly, however, just binding/listening on a UDP socket without any action is not too terrible if you really need to differentiate here.
This note will [self destruct]; is 5 minutes (so Apple won't find out).
There’s a thread about this issue on Apple Developer Forums (registered developers only, sorry). The gist is that the new behaviour is by design. There are requests for a new API feature to distinguish between the two use cases, but nothing working yet.
Here is what Apple's iOS Programming Guide says:
Pressing the Sleep/Wake button is another type of interruption that
causes your app to be deactivated temporarily. When the user presses
this button, the system disables touch events, moves the app to the
background but sets the value of the app’s applicationState property
to UIApplicationStateInactive (as opposed to
UIApplicationStateBackground), and finally locks the screen.
http://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html
So, you should check the UIApplication's applicationState property in applicationDidEnterBackground:. If it is UIApplicationStateBackground the user pressed the home button. But if it is UIApplicationStateInactive the user locked the device.

Resources