Dividing logic in Scenes

[nhaarman]

Scenes can become huge, causing monoliths. It should be possible to divide logic in these Scenes.
This could be done with Presenters which have the same lifecycle as the Scene.

[nhaarman]

In conjunction with #8, it would only be natural to allow Scenes to have child Scenes. In fact, this can be done already, by manually routing the parent Scene's lifecycle invocations to the child Scenes.

If necessary, a mechanism for this could be designed.

[zoltish]

Building on top of this, Id love to hear your approach and thoughts on rocking child scenes inside a viewpager - where the parent scene controls the whole view (e.g. detail screen showing the title of "A", containing a list of "B"s, and in turn each viewpager page showing details about a particular B). Would you consider the top level scene to be responsible for creating the child scenes in this case?

[nhaarman]

Yeah probably. But if at all possible, don't use child scenes at all but plain data classes.

If there is significant interaction within a page the top level scene would probably pass a bunch of child scenes to the view. You'll have to be careful dealing with the lifecycles of the child scenes though, to ensure they are strictly contained within the parent scene (e.g only started when parent scene is started, destroyed when parent is destroyed).

In the other hand, you might find a compromise between both options to work: have a Scene-like class without the start/stop/destroy lifecycle, and only allow attach/detach.

I guess it eventually comes down to specifics: how much do the child scenes actually need to do, do you really need the full lifecycle, do you even need 'smart classes' at all or do plain data objects suffice?

[nhaarman]

For 'simple' screens with a fixed number of sub scenes we currently do this manually: we have a scene that is built up of ~10 subscenes, and the parent scene just forwards its lifecycle to them.
Since they're all visible at the same time this makes sense.

For lists of subscenes however (e.g. O(100)) in some kind of listview this may not scale at all, and you probably only want to start them when applicable.

[zoltish]

Thanks for getting back to me about it! The sub-screens do indeed have a ton of logic, and theyre really only part of a viewpager in order to make switching between them easy for the user - outside of that Id consider them no different than any other normal screen.

Things get complex quickly when lifecycle differs for child scenes, an approach Ive been experimenting with myself is to have data & behavior someplace else, think of something like a NoteViewModel that has the ui-ready fields for a given note, and various actions - both available to the consumer for showing & using. The viewmodel in turn is provided through the scene, and any number of different viewmodels could be provided really. Furthermore, lazy loading could be acheived quite easily, but in my case I found that with the viewmodels not knowing what creates them, it really isnt as needed since each viewmodels scope is rather small (instead of loading A and retrieving B, the viewmodel is just populated with B).

I hope that makes sense, just thought Id share my own approach to it. Perhaps it can spark up a new idea that will revolutionize the whole thing, I havent found any real quirks with it yet but Ive only been playing around with it since after my post on here. In either case, its a joy to find well thought out libraries like yours where everything has a purpose and place, I look forward to seeing how it continues expanding!

[nhaarman]

So an example of this could be constructed as follows, by delegating the 'main' lifecycles to the sub scenes:

class SubScene1 : Scene<C1> { /* ... */ }
class SubScene2 : Scene<C2> { /* ... */ }

class MyScene(
  scene1: SubScene1,
  scene2: SubScene2
) : Scene<C>, ProvidesView {

  override fun createViewController(parent: ViewGroup): ViewController {
    /* ... */
  }

  override fun onStart() {
    scene1.onStart()
    scene2.onStart()
  }

  override fun attach(c: C) {
    scene1.attach(c.c1)
    scene2.attach(c.c2)
  }

  override fun detach(c: C) { / * ... */ }
  override fun onStop() { / * ... */ }
  override fun onDestroy() { / * ... */ }
}