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.
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.
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.
I am editing some thing in an iPhone editor application. That time, I am getting a call. How can I identify an incoming call by coding ?
If any one having idea about this, just share with us.
You can't. This is actually a FAQ already :-) All you can do is implement the applicationWillResignActive method in your application delegate (or listen to the corresponding notification). However, you also get this event when some alerts are shown or when the screen gets locked and you can't distinguish why you are getting the event.
Take a look at following URL
Could be helpful for you
Core Telephony
Hey, I am about to start working on an app. I am a beginner, so I am starting out with a pretty basic concept. But, I was wondering if it was possible to send texts from an app. For example, if the person using my app sets a new high score, could they hit a publish button and my app could then send a text to his buddy bragging about the new high score.
Also, what if someone is using my app and they receive a text, does the OS take over, or do I have to handle the reception of text/calls. Is it possible to alter the way the phone behaves when my app is disrupted by calls/texts.
Thanks for any advice you can give. Have a good Monday everyone!
Apple's iOS documentation has a section that roughly covers how to incorporate in-app SMS.
Basically, your application displays an MFMessageComposeViewController as a modal view controller. It won't cause your app to terminate or background — it just lets your user send a text message, and when done, return to your app and continue.
When a phone call, text message or another notification comes in, your application delegate's applicationWillResignActive: method is called. It's up to you what you want your app to do while the user is dealing with the call, message or notification. If the call is declined or the alert dismissed, your application delegate's applicationDidBecomeActive: method is called and your application can resume as if nothing happened. Otherwise, the app either exits or backgrounds (depending on whether you want it to support multitasking), and you'll also have to handle it from there.
Also bear in mind what Toastor says about
Controlling whether messages can display to your user or not
Bills related to texting plans
There is no way to change the way the phone responds to calls. The only way to prevent your app from being interrupted by an incoming call is by activating the airplane mode on the device - which you cannot enforce from within the app.
Same goes for incoming texts - there is no way to notify your app if a message has been received. How would the system know if the message is meant for your app anyway?
The only thing you can actually do is send a text message from within your app. But if I were you I'd go either with established leaderboards or the new GameKit (have not checked this out yet myself, though).
Or, at least, use mail instead of text messages, since texts are not free in every country.
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