saelyria / corduroy Goto Github PK

NavigationValidator - some kind of object that can be passed to a coordinator object that, given the view controllers involved in a navigation, decides if that navigation should go through. The main use cases for this would probably be for authentication walls or paid-version feature restrictions. It would also allow common, more complex 'should-I-navigate?' decisions to be wrapped up in a reusable component. They would likely be one-off objects you create at the point of making the decision; shouldn't need to be passed around.

This could be implemented by having a 'flags' array on 'NavigationCoordinatorManageable' view controllers that are defined by the app that, when writing a new NavigationCoordinatorManageable, would be a static get-only computed property. The 'flags' could be defined by the NavigationValidator as constants or something, don't know yet.

Undecided yet as well is whether NavigationValidators should handle their 'don't-navigate' cases themselves or delegate that back to the navigation coordinator that employed their use. The use case would likely be common - for example, if it's an authentication wall, navigating the user to a login screen - so could be handled by the validator along with additional 'on-validate' or 'on-deny' closures passed in or something, would need to be fleshed out.

The gist of the feature idea is an app-defined 'base context' that gets passed around with every navigation done by a coordinator. It's meant to be a replacement for static app state dumping grounds that's inspired by functional programming allowing for state changes (and bugs introduced by state changes) to be easier to find.

The main complications are where/how you would change the context objects and how you would define it in a way that's compile-time constant. One idea would be having a BaseAppContext class included in the framework that the framework consumer would subclass and add all the other main app state properties to. This 'app context' object could be the handler for its own properties (i.e. changes to its properties would be done in the form of a 'change request' where maybe credentials need to be passed in or something) to avoid some static 'manager'.

The app context would then be an object created early in the app's lifetime (in the app delegate or the first coordinator or something) and could be setup initially with either default states or serialized data to allow apps to quickly pick up where they left off from a close. Really, they could become fully serializable themselves as a built-in (though optional) feature.