I'm using PayPal MPL iOS lib. When ever I press the cancel button an alert message is displayed. How do I prevent UiAlert from coming up?
It appears as if the Paypal library itself is putting the alertview up. So unless there is something in the paypal library to disable that feature then you probably can't directly disable it. There might be a couple of workarounds, here are my thoughts:
Listen to the notifications when a new UIWindow is displayed via NSNotification center. The notifications are listed at the bottom of the document.
https://developer.apple.com/library/ios/documentation/uikit/reference/UIWindow_Class/UIWindowClassReference/UIWindowClassReference.html
Heres another post that deals with listening to the notification.
Is there a notification on iOS if a UIAlertView is shown?
My thought is maybe you can catch when the alertview is being shown the you can undo it by calling makeKeyAndVisible on your AppDelegates window object
[[UIApplication sharedApplication].delegate.window makeKeyAndVisible];
The other thought that to me seems like a total hack so I'm not going to advocate for or justify is to use method swizzling. If you swizzled the [show] function of UIAlertView then you could inject a simple if statement to decide wether or not to call the real show method effectively deciding wether or not the alert is really shown or not. There may be unforeseen consequences going this route. If your not familiar with the technique NSHipster has a writeup http://nshipster.com/method-swizzling/. Before going this route I would consider how necessary disabling the alert really is.
Related
Question:
Is there a way to detect if you get a system notification and you swipe away the notification banner (e.g. the alarm that triggers a system notification)?
More practical example:
In your app, you are doing some stuff and suddenly you get a notification from another app. Instead of tapping on the notification, you swipe up the notification (you dismiss it that way). After doing that, I want to capture that in the app.
Why:
Currently, I have a bug in the app, so if I can capture this action, I would be able to fix this bug.
Thanks in advance!
When notification appears, the willResignActiveNotification won't get called, therefore willEnterForegroundNotification won't get called, too.
The best solution here is to catch incoming notification and show the custom view describing this notification instead of system one. Thus, you can detect all actions/timings you need.
For example, I have a Notification that occurs when there is an "unauthorized" error returned from the api server that should bring the user back to the login screen. This event could appear anywhere in the program.
Do I create a new viewless controller to manage states and have it monitor for this notification and then present the login view controller?
I'm thinking about push notifications too, received by the app delegate. Some of these may cause the data model to get updated and then the screen to change. Who should make the screen change? In the past I put all this in the AppDelegate. But there must be a more elegant way!
I also found out about FlowControllers. But they don't play nicely with Interface Builder, at least according to this solution.
Please let me know if you need more specific information about my project.
Is there any way to call action on home button ?
I need something like "are you sure to quit app" and wait for yes or no.
I don't need any code or so. I just need to make sure it is possible.
Thanks
In short, no. you can't block the home button action, neither the user is expecting this to happen.
If you have to perform any kind of saving, you can do it in the application delegate object in the method applicationDidEnterBackground:
Apple documentation here
As far as I know, Apple does not allow you to do this, as it would make the overall user experience of iOS horrible. Can you imagine if every developer added this functionality to their app?
You could attempt to implement applicationDidEnterBackground, then set up a local notification that instantly notifies the user with an alert, with a button that opens the app and one that does nothing. But you cannot intercept the home button press like you would with shouldPerformSegueWithIdentifier
I've decided to make a class that emulates the functionality of UIAlertView so that I can have a better API for callbacks and theme the alerts better. I add another window to the iOS main window to show the alert.
The problem is with voiceover. With the standard UIAlertView voiceover makes a special sound to indicate that there is an alert view on the screen.
I can get the standard voiceover screen change chirp by posting UIAccessibilityScreenChangedNotification but this is different from the Alert view's chirp.
I want this to feel like a UIAlertView for voiceover users. To do this i need to be able to programatically replicate its special chirp.
It's not ideal (you'd lose the theming for instance), but you could have your custom implementation detect if voiceover is enabled using UIAccessibilityIsVoiceOverRunning() and fall back to using a standard UIAlertView if it is.
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.