I want to make some switches on a view controller dependant on whether a user has allowed / not to register for notifications. The very first time this view loads and
appDelegate.registerForNotifications(UIApplication.sharedApplication())
is called in ViewDidLoad the AlertController is shown and the viewController completes its layout as expected, hence missing any dependency on if the user allows / not the notifications.
I know I could present the register alert as soon as the app launches, but I want to wait to ask for permission in this view controller as it is only relevant in this view and not others before it.
Is there any way of capturing the UIAlertAction before viewWillAppear is called?
Is there any way of capturing the UIAlertAction before viewWillAppear is called?
No, nor should there be. You do not do things before viewDidLoad, viewWillAppear, and so forth. Your job in these methods is to respond as needed (for example, by doing initializations) and then get out of the way, just as fast as possible. You must not delay the appearance of the view controller in any way.
Instead, rethink your architecture.
The view controller's view is going to appear. So just let it! If you are concerned that, say, a button should not be enabled if the user disallows registration, then start out with the button disabled and only enable it after you know (or learn in the alert action's handler) that it is now allowed.
Or, if this view controller depends entirely on the user allowing registration, move registration to an earlier phase of your app, and don't even allow the user to come here without it!
Related
I am trying to implement a way for a user to logout of my app through a custom tabBarController. I have 5 tabBarItems, and I want the first one to be a logout tabBarItem - so when a user taps on it, an alertview pops up asking "are you sure you want to logout?". Is this possible - and if so what would be the best way about implementing this feature?
thanks!
-Matt
That seems like an unintuitive UI. I would consider redesigning so that there is a logout button somewhere within a view controller, toolbar or navigation bar.
With that said, if you really, really insist on making a "logout" tab bar item, you can create a UIViewController that presents a UIAlertView in viewDidAppear: and implements the UIAlertViewDelegate protocol. Then in alertView:clickedButtonAtIndex: you can update your global state to handle a logout (i.e. broadcast a notification through NSNotificationCenter, make a custom AppDelegate call, etc.).
I have the need for an activity indicator view in my app when different views are loading and when data is being retrieved. The problem is the mainVC (where I would place the indicator) is not always aware of when processing is happening so it can start the indicator but it cannot stop it.
e.g. the mainVC loads and then programatically adds a new VC - this VC in turn asks a model to retrieve - it displays data etc. So this newly added VC actually knows when processing is finished and it does not have access to the indicator view (although the indicator is visible at the top).
I was thinking of using notifications - is this the best way of handling this situation?
I'd recommend looking at the brilliant MBProgressHUD library:
https://github.com/matej/MBProgressHUD
It's a very simple set of classes you can use to display loading and progress views that can be accessed by all view controllers in your app. Basically, you can set it up in your app delegate and add it to your app window.
Every view controller can then access the progress view from the delegate and show/hide it when required. It comes with an example project and code - it's very easy to use and customise.
Notifications are one half of the solution. You have to combine them with a persistent object so that you can also get the current state at all times. E.g., when a view controller is about to appear, it needs to read the initial "downloading" state from somewhere, because the VC might have been created after the "start" or "end" notification was sent.
Then, while the VC is alive, it can simply respond to notifications to update the indicator.
This design is particulary important for views, which run the risk of getting unloaded/reloaded all the time.
In my previous question on UIView animations I mentioned that I have to simulate the modal behavior for some view. Here I'll explain why and ask about some better solution.
The first view a user should see in my app is the login screen. Upon successful authentication the program checks if the user is a parent or a child (in a family). For each of these roles the app must provide different functionality.
So I designed the app like this:
Declare outlets for the login view controller and a tab bar controller (for the main part of the interface) in my AppDelegate.
In the application:didFinishLaunchingWithOptions: method
Set the rootViewController of the main window to the login view controller.
Make AppDelegate the delegate for the login controller, so it can send notification when it's done its job.
When AppDelegate receives the message on successful login, it determines whether the user is a parent or a child, instantiates the set of view controllers that provide corresponding functionality and passes them to the tab bar controller.
At last AppDelegate switches the rootViewController of the main window to the tab bar controller.
Certainly the user can logout, then the rootViewController is switched back again to the login controller.
I would like to present and dismiss the login screen as if it is a modal view, but AppDelegate only has a bare window, thus I don't have an object to send presentModalViewController: to. This brings up a question:
First of all, is it a good design?
And if it is, how do I simulate a modal behavior correctly?
I think you're on the right track.
However, I always try to get out of the app delegate as soon as I can, leaving it only to do application-level things (like respond to notifications, go in and out of background). In this case, doing so will help you.
In the appDelegate, create a new UIViewController class, something like "startUpController".
Add it's view to the app window.
Then in your startUpController, do everything that you used to do in the app delegate (login, tab bar setup, etc.).
And now, since you're in a view controller, you can presentModalViewController to your hearts content.
Hii,
you should refer this
http://code.google.com/p/tweetero/
https://github.com/jbrien/WordPress-iPhone
Hope this helps!
I have a page-curl modal working. But I need to be able to track when the user hits the page curl to close the page so I can see some vars. Is there an event I can listen for or some delegate where I will get a call to tell me of this event?
Many Thanks
-Code
You'll see a lot of advice around here advocating the use of performSelector:withObject:afterDelay: with a small delay to take action after the dismissal of modal views, but I think there may be a better approach.
Generate the notification yourself. If you control the view that's being presented modally, use the viewDidDisappear: method in its controller to generate an "I was dismissed" notification which you then subscribe to in your main view controller (or somewhere else). viewDidDisappear: is called after the page uncurl animation completes upon dismissal of the modal view.
In the worst case, where the view may be presented modally or otherwise, you can keep state on the presenting view controller to ensure that the notification actually corresponds to a modal view dismissal.
For completeness' sake, viewWillDisappear: is generated when the page decurl transition starts.
I am experimenting with the splitViewController, introduced for iPads and am stuck at a point. I have a button on my detail view of the splitViewController, clicking on which a modal view opens. Now I want to change the positoning of UI controls on the detail view when the modal view gets dissmissed.
A pretty obvious way of doing this would be to catch the view transition in the ViewWillAppear method of the detailView. But it's not being called in this case. I remember facing the same problem in tabBarController where [tabBarController viewWillAppear:animated] was needed to be set before viewWillAppear of views in each tab item got called. I tried doing this with the splitViewController as well, but this doesn't seem to to work.
Any Ideas??
If the positioning is required due to an action that occurred in the modal view, you should use an explicit delegate callback. That will allow you to clearly specify the control flow and resulting behaviour of your app.
You should then define a protocol that has specific methods that carry pertinent information about the action taken. When the action occurs in the modal, perform the protocol method on the delegate, and it can react to that event (for you it seems to be a re-layout of button positioning).
To get an idea of the methods that are abstract enough to handle generic modal behaviour, look at UIAlertViewDelegate protocol. Here the delegate will get an alertViewCancel: message when the user decides to take no action, or alertView:didDismissWithButtonIndex: when they selected one of the options presented to them.
That is a good start for how to define the protocol.
If you need a many view controllers to react to the action taken in the modal, say a Sign In modal, then a better mechanism is notifications.