UI consistency seems to be a big requirement when designing your App - all the UI elements should have a consistent style throughout the entire App. This is especially true for Apps with different kinds of
alert views or
alert controllers. Well,
UIKit itself comes with two different styles of
UIAlertControllerStyleAlert. Using them is absolutely convenient, but the drawback is that they don’t allow you to have much customization.
For the App which we are currently developing, I have been doing some experiments with the alert view mechanism of the App - making this module as independent as possible and, at the same time, as convenient to use as possible.
When designing alert views for the entire App, a few things have to be considered before you actually start to get your hands dirty:
- How will the public interfaces be like so that an object of
UIViewController (or its subclass)can easily present an alert view to the user
- How to keep the presented alert views (or alert controllers) separated from the rest of your view hierarchy?
- How the user experience be defined when there are multiple instances of your designed alert view presented?
- How the presentation and dismissal animations be like?
Well, the first question would be easy to answer. To alleviate the pain when using your customized alert view (or alert controller) in one of your view controllers, you could have a category of
UIViewController, for example,
UIViewController+CustomizedAlerViewPresentation.h. And in this category, public interfaces can be implemented to present your customized alert views (or alert controllers).
However, this solution might be somewhat not so convenient, sometimes. To be frank, this inconvenience is trivial and if this happens, your project might not strictly follow the
MVC pattern strongly recommended by Apple. But, anyhow, it’s an inconvenience that can be discussed here, which is what if you want to also present alert views (or alert controllers) from one of your customized views or some of your manger objects, especially the latter? For the former, delegating the presentation action to a view controller is a much elegant solution.
So, this brings us to another solution: using a singleton to manage all your alert views’ (or alert controllers’) presentation. Although, too many unnecessary singletons is always something I oppose to. This is why I insist to use the first solution in my App, but using singleton in this case is able to solve the problem.
//[Demo Code Link](https://github.com/Alex1989Wang/Demos/blob/master/DemoProjects/JWAlertController/JWAlertController/Alert%20Module/Controllers/UIViewController%2BJWAlertPresentation.m)
You definitely don’t want to instantiate an object of your
alert views or
alert controllers and then refer to it in your views or view controllers. Like the behavior of
UIAlertController, it always floats above any of your views and when you click any of its buttons it dismisses from the window. So, the idea here is that your
alert views or
alert controllers should behave very much like Apple’s default
UIAlertController and keep themselves away from the rest of your view hierarchy. So, how can we achieve this? The recipe is
using a customized window.
Your App can have one
key window and another
alert window to hold your
alert views or
alert controllers. Because the
key window which has all your visible contents and
alert window are siblings, the
alert window is guaranteed to be above all your view elements.
Demo code snippets:
- (void)presentAlertController:(JWAlertViewController *)alertController
This question should be considered in terms of how you want to customize queued behavior of multiple
alert views. So, it will be queued, that’s for sure. But, will the second alert view replace the already-displayed alert view and when this second alert view disappears the former-displayed alert view can reappear again? Or, the second will be cached and begin to be presented until the already-displayed one disappears?
The first kind of behavior is actually the apples’ default way of presentation. But, in my App, we want the second.
The queuing logic is simple. When the first alert view is dismissed, you check whether there are more to be presented. If so, present the first one in the queue.
This is very much up to the taste of your designer. You could have a alert view appearing with size of zero then animated to its actual size. Or, you could make the alert view flying from the top of screen to the middle.
So, choose whatever you like. But, there is one thing worthy of mentioning: the disappearing animation should be better a reversal of its appearing animation for the sake of consistency.
The github demo link