Concept, Design, Coding
There is one design pattern that mobile has that would be simply awesome on the web: Navigation Control. You know, the simple pattern of a single “view” at a time showing up in a stack. When a new view is added the others slide over and there’s a back button. Simple user pattern, and thanks to Apple: well-established. Just as easy as it is to use, it can be to implement. Apple’s implementation is a great example of power under ease. And it’s this reason so many have used it.
I looked around to see what was out there and sadly there was nothing. The attempts I found dealt with the styling portions of a navigation stack, not the view lifecycle and stack management.
I could do something about this!
I started with a strong design pattern that would allow for the broadest use, with the least implementation details. I wanted a standard UI but for that to be entirely style-able, replaceable, or even removable. Then the advanced communications that occur in a stack of views needed a place to go. For that I designed an optional protocol object that, if included in the current view on the stack, would serve as the standard delegate to all of the deep details.
The awesome stroke here was that any view from anywhere could be dropped into a NavController with no knowledge of the control itself. This way views can be designed and coded as they have always been, and the NavController can be an over-the-top addition to the lifecycle. In fact, some of my best uses have been adding a NavController to an already existing product without changing the current product at all.
There are deep options, however. NavController supports:
The final component is incredibly simple to use, but also deeply powerful. I’ve used it in several different types of implementations and it has worked flawlessly. It can act as the standard sliding stack of views as seen in the demo on this page, or with no animations and no navigation bars at all. This way the NavController can manage the views and the program can choose the display. This has been extremely useful in multi-step process flows, where you would typically manage a set of “views” as the user moves through a process.