RFC-7: StackFrame stack lifecycle callbacks

[doridori]

ACTIVITY LIFECYCLE ENUM - register with parent stack? when register observer pass boolean to pass curent state

• ACTIVITY_STARTED
• ACTIVITY_STOPPED (seperate from NOT_STARTED?)

STACK LIFECYCLE (frame overrides)

• FRAME_TOP_OF_STACK called when newly pushed to top or something popped
• FRAME_NO_LONGER_TOP called when something pushed on top, can ignore popped as below will be called
• FRAME_REMOVED_FROM_STACK called when popped on own or part of group

optional Frame callbacks should be

frameStackLifecycleEvent(...) hostActivityLifecycleEvent(...)

When a frame added to stack both these methods need to be called with current state. Then while in the stack they will be called with each state change until FRAME_REMOVED_FROM_STACK or application destroyed.

Lifecycle methods should also be called after a stack has been de-serialised.

ACTIVITY_* and FRAME_ lifecycle states should be gettable also.

---

FINAL FRAME LIFECYCLE

• onAddedToStack (pushed) (called once)
• onVisibleFrameStatusChange(boolean) (only visible if top visible frame of stack regardless of opacity and activity is started - can always query the stack if need any more logic on top of this)
• onRemovedFromStack (popped) (called once)

Need to add this in core docs. Main concepts?

FINAL VIEW LIFECYCLE

A PilotFrame-backed View needs to know when the backing PilotFrame is available and when its updated.

When a PilotFrameLayout extending View is created is will have the corresponding PilotFrame passed to it. See PilotFrame.backingFrameSet

State-change listeners are added inside the PilotFrame backed PilotFrameLayout.onAttached and PilotFrameLayout.onDetached methods and will result in PilotFrame.updated() being called, which is where you should sync up the UI state with the PilotFrame state.

Views have backingFrameSet(ShowPadPresenter backingPilotFrame) and this should be used over onAttached as more explicit and less change of OS re-attaching views messing anything up :)

TODO Currently in 'Quick Start'. Move this to concepts and link

[doridori]

Some interesting thought on lifecycle events in presenters

http://hannesdorfmann.com/android/presenters-dont-need-lifecycle

not sure how much I agree with this as would not want to have to worry about some model objects which need to change behaviour based upon lifecycle events but still persist on lifecycle changes, are managed. Half of the nice thing about pilot is moving as much code away from classes that are transient in respect to the lifecycle. The nice thing about having lifecycle callbacks inside Frame classes is that you can still react to them (forward to a particular respository/model instance) without having to worry your about to lose all object references and callabacks as your about to be torn down and recreated.

Really its about keeping the traditional android lifecycle at arms length so its config change effects are minimised.

Plus when abstracting the back stack its not as easy to pass dependencys in IOC style as the stack should be recreatable from meta data only - much like the intent / activity stack is.

[doridori]

Just needs doc update now

[doridori]

in 0.8.0_SNAPSHOT

[doridori]

In hindsight the current impl is not very clean, as the stack needs a notion of the apps visibility, which is not really its concern.

Will switch to the Frame having a visibility callback, which is called by the PilotManager, which utilises the isOpaque (see #20) method that is already part of the UI type handlers.

• When the handlers add a new view this lifecycle method can be called (on the new and replaced views backing frames)
• When the root activity has onStopped event thenall visible Views Frames can have this method called
• When root activity has onStart all visible Views Frames should have this method called

In the case where a frame needs to start and stop some action based on the corresponding views visibility this will provide a place for this, without Frames or the Stack having to keep track of any visibility meta data.

Can perform this logic in the PilotLifecycleManager using the PilotSyncer for access to all UiTypeHandlers

[doridori]

0.9.0 snapshot

[doridori]

Final impl has a method called between pushed and popped when the frames view gains visibility and when loses visibility.

[doridori]

Im beginning to thing about how the naviagable-stack-stack should be a seperate project entirely as really its a specific type of state-machine. All the states care about are if the containing application code considers it paused or not. We do sort of have this pretty abstract atm with frameViewVisible callbacks. Think it should be a bit more abstract, as some states may not have a view etc?

[doridori]

As above, with a view to splitting the StateStack out as a separate project we should remove all traces of anything android related (conceptually or otherwise).

Current proposal is that the StateStack should have two states, STARTED & STOPPED. This can be passed to a StateFrame in the following manner:

• onPush(...)
• activeStateChanged(...) rename

This would remove the need to the PilotActivityAdaptor methods for lifecycle delegation. We should instead name these for that they actually represent. i.e. instead of onStopDelegate we should have stateMachineStopped or containerStopped etc.

Also the PilotUISyncer hostActivity methods would be changed (if not removed)