Support for rows that push view controller
I was thinking whether Formulary should support rows that open a second screen.
For example selecting an item from a longer list or a multi-line text input.
Currently FormViewController is a direct descendant of UIViewController. I think that would've to change to UINavigationController in order to push new VCs.
Or maybe I am thinking "old-school" here and it would be better to allow inline rows to show a lot of content and possible manage the whole screen?
Anyway I think this affects the API design and should be discussed before any restructuring.
Here are some initial thoughts:
I think there can be a form row type that accepts a view controller among its parameters. And have a presentation type
enum PresentationType {
case Push
case Modal
}
I think it's fair to leave the responsibility of embedding the form in a navigation controller to the consumer of the library. If the form isn't in a navigation stack, the .Push option may simply not work.
I definitely want to implement some initial version of this soon. It's interesting to note that this can open up a large can of worms :bug: if we wanted to start supporting presentation controllers and transition delegates. But I'm happy to ignore that for now and get back to those issues later.
I agree with you, that some row types should probably come with presentation parameters or different class "versions" that behave differently, since for specific use-cases different presentations might be best (the user knows best whether an options list is long and should have it's own screen or is shorter and should show inline as to not hide the context).
I don't think that the user should supply their own VC in the general case with option lists and text fields, since they then have to do a lot of the work they picked Formulary for themselves and it would probably also need a lifetime-management API for bigger forms as to not load all secondary VCs into memory at the start etc.
We should probably try to implement some row types that warrant a second / fullscreen and see what kind of API helps most.
My ideas are: long options list, text view, photo picker.
This would also be interesting if child forms or nesting are ever allowed.
I think this can be broken down into three distinct goals. Each approach shows a view controller that serves as input to the selected form row, but in semantically different ways.
- [ ] Push a canned (owned by Formulary) view controller. e.g.:
- [ ] long options list
- [ ] text view
- [ ] photo picker
- [ ] Push a nested Form from a row (I don't think this would be hard, and makes sense for nested models)
- [x] Push an arbitrary view controller provided to the API -- maybe conforms to a protocol:
- return its value
- optionally provide a view that serves to represent that value in the context of the parent form
Formulary can now push an arbitrary view controller from a row.
This covers the use-cases for both other kinds of pushed view controllers. But it would be nice to eventually cover those cases with specific APIs