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.
Related
First of all I'd like to say sorry in case my question is dummy, I'm really new to iOS and what to understand how thing are going on. Imagine such a situation - user taps on home button and the app starts to collapse, but immediately after taping on home button user taped on some UI element. So, I'm wondering how the iOS will handle this? I tried to do some tests using breakpoints, but since it just test I can't be 100% sure. It seems that if the UI interaction event will happen before the system will call willResignActive then the event will be fully processed and if the system will call willResignActive first, then the even will be discarded and won't be handled at all. Is this correct, or I missed something? Thanks
First, why do you want to use this in your app? If a user presses a button exactly in this time, it's okay that the action is not handled.
The only thing you have to keep track of is that whenever the button gets pressed and let's say you store a file without a completion handler it could be that you present an alert which is saying that everything went well but you actually not saved the file because the user left the app in this time.
But since you're never doing critical actions without completion handlers, in my opinion, there's no need to make sure that this doesn't happen.
If I got you wrong, just comment!
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 came to know that iOS does't support widgets this is what i have read.But i am making application on Security in iOS, i want the user to perform some action when he is in need of help without opening the application.
I know iOS supports few background modes like play audio,receive location updates,voip etc.
Can anyone suggest me any alternative to fire some methods without opening the application like pressing some button when in dangerous situation to call those methods.
I don't know whether we can do it or not.
But have a look.
You said we can implement background modes like audio, location, voip updates etc.
Let take the example of Audio mode. It has previous, play/pause, and next button in the lockscreen.
What you can do is play an audio when the application is in background mode.
Check whether the any of the music buttons are pressed more than 3 times. If this is the case trigger alert messages for security and send them to appropriate persons or do your own action.
I don't know whether we can do this or not. Even if it is possible, I can't say Apple will allow such false actions for buttons which are meant for some purpose.
Also see whether we can get detect volume button presses when in background mode. If that is possible you can do that. Because even my LG mobile has an SOS mode which is enabled when I press volume buton in lockscreen 4 times. Apple may allow this action if it possible
Is it possible to record set of touch events on iPhone and then playback?
I have searched alot but could not find any answer. if its possible, can anyone explain with an example.
I m not looking for testing purpose. Within my application, instead of creating animation, i just want to record set of events and then want to playback to explain the app flow to the users.
Regards.
Recording is pretty simple. Look at the various "Responding to Touch Events" and "Responding to Motion Events" methods on UIResponder. Just create your own UIView subclass (since UIView inherits from UIResponder) and keep a copy of the events passed into the relevant methods.
Playback is a bit more complicated; there's no way to make UITouch or UIEvent objects (so you can't make a fake event and pass it on to -[UIApplication sendEvent:]). But, there's nothing stopping you from manually parsing an array of Event objects and handling it on your own (aside from it being some kind of ugly code).
There's no built-in macro capability, but you could certainly build that ability into your application. You'll need to do more than just play back events, though. Touches aren't normally visible, but if you're trying to explain how to use your app to the user you'll probably want to have some sort of visual representation for the touches that trigger different responses similar to the way the iOS Simulator uses white dots to represent multiple touches when you hold down the option key.
Assuming that you can solve that problem, two strategies for easily recording user actions come to mind:
Use the Undo Manager: NSUndoManager is already set up to "record" undoable events. If you invest some time into making everything in your app undoable, you could (maybe) perform a set of actions, undo them all to move them to the redo stack, and then save the events in the redo stack as your script.
Use Accessibility: The Accessibility framework sends notifications whenever user interface elements are touched. Your app could use those notifications to create a playback script. You'll still need to write the code to play back the events in the script, though.
You could mirror your application with AirServer and use any screen capture software to make the video.
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.