SRP - Break up the PilotManager

[doridori]

PilotManager is currently a bit bloated and has more than one responsibility.

Its two core responsibilities at present are

1) To allow something with an Android lifecycle (i.e. Activity) to interact with something that is purposefully staying away from any lifecycle hassles (PilotStack). This involves listener management and handling delegated lifecycle methods. 2) Maintains a list of View mappings and listens to stack changes - manifesting the top view mapping and setting it to a root view

The above obviously violates the Single Responsibility Principle (SRP) and should be changed. Pulling out the view manifestation logic into a separate class (with corresponding interface) would allow for easy switching for different approaches i.e. using a Fragment creator rather than view creator. This would make the lib more flexible also as not everyone likes View only approaches but most do suffer from (at least one of) the problems the abstracted stack solves.

This may also open the way for master/detail display as the view creator could be composed at runtime based upon device specs (i.e. screen size). https://github.com/doridori/Pilot/issues/15

Also this may make it easier to cope with transparent view representations of frames. https://github.com/doridori/Pilot/issues/5

[doridori]

We should now be working towards

• PilotLifecycleManager - Abstracts away Activity lifecycle difficulties
• ViewCreator - Handles creating View representations of stack frames
• ViewChoreographer - Handles placing of views within the UI (can perform display based logic)
• ViewRebuilder - Handles ensuring the correct amount of stack listener calls are made when an activity is (re)created

We still need to split the above to be able to handle Fragments as well as Views (and even old fashioned Dialogs etc)

[doridori]

Need to update this with final SRP refactor once pushed to master and doced. Maybe should rename as above...