When the user successfully log into my app, session starts, after X period of inactivity the session will time out.
Now how do you detect, the user to see if his active using the application or not using it?
1) Check every on button?
2) check on screen load?
The most elegant way I've found to do this is to use a category on UIApplication that provides a sendEvent: method that resets an NSTimer (after calling its superclass implementation of course). If the timer goes off, post a notification. Listen for the notification everywhere you want to react to the timeout. Doing it this way means that you don't have to add code all through your app to reset the timer on every interaction.
Having said that, I agree with Shaggy Frog, this isn't typical behaviour for an iOS application, so it's not usually a good idea from a HCI perspective.
If you're asking "How do I define activity", you could always reset a timer after a touch event is received, whose callback triggers the "user is inactive event".
I can't speak much for your overall design choice here, as I don't think most iOS users expect their apps to behave in this manner. Think of your users and proceed with caution.
You can also check for applicationwillresignactive callback for this.
Related
Sometimes, when the app I'm working on comes out of suspended mode, I need to make sure it does not respond to the notifications iOS has saved for it while the app was suspended. Where's the right place to perform this cancellation where I can be sure my response code won't run?
I'm hoping that putting removeObserver is applicationWillEnterForeground would do the trick, but I couldn't find anything about this in the NSNotification doc.
Edit:
Let me add the details of the scenario:
The app I'm working on checks for changes to calendar events for the range of the next 7 days. It refreshes it's data (requeries eventStore) at two times:
1. When an NSNotification comes from the iPhone calendar about changes.
2. The first time the app is able to on a new day, because the 7 day range has changed.
The design challenge I'm having is the case where both scenarios are true at the same time (the app returns from being suspended and it's a new day, and calendar events were modified while the app was suspended ). I only want to requery the event store one time in that case. My thought is to, in applicationWillEnterForeground, on the case that it's the first launch of the day, tell the app to ignore or drop any notifications.
I'm getting the impression my assumptions about how NSNotifications would work in this case might be off. Any guidance would be great!
Why not remove the observer from the notification centre in -applicationDidEnterBackground:?
Then you can start observing again in -applicationWillEnterForeground:.
What NSNotifications come in while you’re suspended? Are you running a background task?
I can’t really think of a case where not responding to an NSNotification would be a good idea. They are effectively messages like any other, just with a different routing mechanism.
UILocalNotification would be a different issue.
I have a Video Chat application that I want to disconnect from a call when the device is locked, but stay connected when an SMS, calendar, low battery or any other type of notification is received. The problem is, I cannot figure out for the life of me how to determine what causes my app delegate's applicationWillResignActive selector to be called.
I have thought about implementing some kind of timeout where if applicationDidBecomeActive was not called within a certain number of seconds I would disconnect but that falsely assumes that a user will ignore or accept a received notification within that number of seconds.
Can anyone help me figure out a way to determine what caused the applicationWillResignActive selector to be called?
Many Thanks,
Mason
I think the short answer may be, that you can't really determine specifically what causes the resign call, however you can only plan according to if it actually goes in the background or not.
Check this link out where it details the steps multitasking takes.
http://www.cocoanetics.com/2010/07/understanding-ios-4-backgrounding-and-delegate-messaging/
Good luck, you seem like an awesome guy!
In my case I was stopping the video capturing on NSNotification.Name.UIApplicationWillResignActive
Now, I'm using the:
NSNotification.Name.UIApplicationDidEnterBackground
It isn't triggered when a message comes, or in case someone is calling to the capturing device.
I have an idea for a pretty unusual alarm clock fir the iPhone. But as of now I have some thoughts on how to actually implement this. First off: forgetting about background services for now, how would I do the actual timer that fires the alarm etc? A separate thread? Or does the SDK include any nice alarm features I missed? Of cause I need to be as battery efficient as possible. But for now I do no background process.
Please advise me on this as it is a crucial concept of this app, if it will work or not.
I would create a local notification. Compared to NSTimer, local notifications have the advantage that they work regardless of whether your app is running or not.
You must create a UILocalNotification object and schedule it with scheduleLocalNotification, it is quite simple but there are strong limitations. You app may or may not be notified that the alarm occurred. When the alarm is presented, it will be in form of a AlertView. If the user taps "Close" you do not get a notification. If he taps "View Details", then you get the event didReceiveLocalNotification, your app moves to the foreground and can do whatever you want.
You can also register with iOS4 to receive updates on location change. The parsing of XML can be done but again there are limitations as to how much time you have to run methods in the background.
All information along with sample code can be found here: http://developer.apple.com/iphone/library/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/IPhoneOSClientImp/IPhoneOSClientImp.html
I'm developing an application that needs to take action on completed phone calls, preferably right after the call ends but minimally once per day.
I've read up on the new CoreTelphony framework, and it seems I can get call events if my app is active, but I don't see how to launch/wake my app when a call ends if my app is not the foreground app. I also don't see how any of the new pseudo-background "modes" would allow my app to listen for these events in the background. Do any of you know how this might be done?
If post-call processing isn't possible, then I'd like to figure out a way to automatically wake my app up once per day, pull all of the call events since the last wakeup, and process them. I know how I might do this with Push or Local notifications, but my understanding is that those require user action to continue; in this case, I just want the processing to happen automatically. Is there a mechanism that would enable this?
Thanks,
Dan
You can't launch your app without user interaction.
Push / Local notifications aren't for this kind of thing, they're for letting the user know about event.
On a non-jailbroken device there is no way to do what you want to do.
This question seems to be the essence of several others on this forum. I believe that it is possible for the active iPhone application to continue running, and specifically, to continue receiving timer call-backs, after it has entered the inactive state (either through the idle timer kicking in the screen lock, or through the user pressing the hardware lock button).
The documentation specifically says that while an application is inactive, it is executing, but not dispatching incoming events (I'm not giving a link because I'm jumpy about NDA - should I relax about that? Is this whole post a breach? sigh).
Also, two answers by user "Ambr Str" directly state that it is possible to continue receiving timer call-backs, and he supplies a snip of code to achieve it (I can't link to this because I'm a new user, sorry - search for the question: "What happens to an iPhone app when iPhone goes into stand-by mode?" to find his answer).
I've tried to create my call-backs as he suggests, but once my application becomes inactive, the call-backs cease firing.
I've just noticed that while the iPhone is plugged in, if the application becomes inactive (due to idle time out or me pressing the sleep button), call-backs do continue to occur - perhaps I should get my users to carry a battery pack with them ;-)
There is a good answer to this question on Apple's forums. Search for "Timer" and "Eskimo" (the helpful chap who provides the answers).
In brief, shortly after the application becomes inactive, the phone really does go to sleep. The only way to prevent this is to be playing some audio (or for some audio to be playing in a background application). While audio is playing the phone will not sleep, and your application continues to be run.
It is suggested that playing stay awake audio is a hack, and that you shouldn't do it if at all possible. I think in my application (which performs audio playback interspersed with silent periods), the approach is valid, if not ideal!
I have an app. which includes an embedded webserver. I'm planning to offer an option of disabling auto-sleep IFF the server is turned on, AND the device is on power. So you might consider checking the batteryState property of UIDevice. So if batteryState != UIDeviceBatteryStateUnplugged, go ahead and disable idle timer. (note: the docs say that UIDeviceBatteryStateUnknown will be returned when in simulator.)
You'll also want to listen for UIDeviceBatteryStateUnplugged notifications and set batteryMonitoringEnabled appropriately.