On ViewControllers

[westnordost]

So, I have lately been thinking about how to make user interfaces (found in quest forms) more reusable.

Currently, most of the UI form logic is situated in the *Form classes associated with each quest. This makes the code not really reusable because other quests may need other answer options or answer type, want a different style, different pictures etc etc.

Inheritance

The first solution (and in code: the oldest solution) that comes to mind for code reuse is to use inheritance. Examples of this approach are AImageListQuestAnswerFragment, AListQuestAnswerFragment or the new AStreetSideSelectFragment.

• However, inheritance can get messy quick. After all, the classes all inherit the whole package of all its parents.
• since all *Form classes already inherit from AbstractQuestAnswerFragment, the UI code is only reusable for other quest answer forms

Compound Views

So another solution could be to encapsulate the view logic into custom (compound) views. Examples of this approach are StreetSideSelectPuzzle, LanesSelectPuzzle, AutoCorrectAbbreviationsEditText or LengthInput. This is better than the inheritance approach because

• it avoids the mentioned inheritance
• no dealing with view lifecycle if not needed for that view (it seldomly is)
• functionality can be composed, so there can be a hierarchy of widgets from generic to specific. E.g. there could be a TimeInput class that allows to input a time and the TimeRangeInput class would be just a view that consists of two TimeInput and some extra logic. The TimeRangeInput itself could then be part of another view, e.g. OpeningHoursView

But I found that this, too, has some issues. Minor issues:

• saving the state of a view is a huge overhead, so better leave that part to Fragments (Or, if we ever migrate to it, use ViewModels)
• adding the ability to set the custom view's properties in XML adds quite a bit of overhead. So, better leave that out and do it programmatically
• there is actually inheritance - on the View that is used as the view's parent. This exposes a lot of functionality unintentionally that may break the internal logic of the custom view. E.g. AutoCorrectAbbreviationsEditText inherits from EditText and internally registers a OnEditorActionListener to do stuff. Now, an EditText only allows one OnEditorActionListener at a time and the method to set it is public, so a user of this class could break some functionality by re-setting that listener.

However, like a Fragment, a View(Group) does not only manage the view but also creates and contains the view it manages:

• Coordinating views in different view groups can only be done by the parent (fragment or view) of both these views. This can sometimes be awkward
• Since the compound view creates its view itself (usually by inflating a XML layout), the view will be difficult to style / customize because each and every possibility to change properties of any of subview needs to be deliberately implemented on the compound views interface. E.g. LengthInput allows to input a length in meters or feet+inches. It is however currently only used for the AR Measure quests and not for the AddMaxHeight quest because the input in the latter has a different styling and arrangement of the involved views

ViewController

So, to deal with the mentioned shortcomings, we could have a class that is not a View itself, does not contain or create the view, but just manages it. E.g. a LengthInputViewController would look pretty much the same as the current LengthInput class with all its interface, except that the view(s) it should manage are passed in at the constructor.
So, the view can be injected by the containing custom view or containing fragment and it can be styled and arranged differently, the *ViewController does not care. I.e., LengthInput could still exist but the only thing it would do is to create the (default) view and delegate everything else to LengthInputViewController.

This solves most of the remaining issues with custom views. So, it seems kind of obvious that this pattern is desirable for reusing UI logic independent of styling.

I am lacking really good naming for it though. Other candidates for names are/were:

• *ViewController because it controls view(s). The name is used in iOS programming for something that would be very similar to a Fragment or Activity on Android. So, not perfect. But on Android, this name is not used for anything.
• *ViewManager because it manages view(s). But manager, to me, sounds like something bigger.
• *Widget. The name is used for those apps you have on your home screen, however

Also, I didn't find any source that wrote about this pattern. So, I am kind of unsure if I maybe forgot to consider something. What's your take on this?
(FYI in MVC, MVP and MVVM, all of this here is clearly still 100% in the View layer)

[FloEdelmann]

For reference: implementation in #3885