This introduces the MVC model to details fragments. It moves as much
view and control code out of the concrete fragments into the abstract
classes.
* Added UML class and sequence diagrams under doc/diagrams to clarify
the new setup
* Introduces new abstract classes
* AbstractFragment class to hold the DataHolder
* AbstractInfoFragment class to display media information
* AbstractAddtionalInfoFragment class to allow *InfoFragments
to add additional UI elements and propagate refresh requests.
See for an example TVShowInfoFragment which adds
TVShowProgressFragment to display next episodes and season
progression.
* Introduces new RefreshItem class to encapsulate all refresh
functionality from AbstractDetailsFragment
* Introduces new SharedElementTransition utility class to encapsulate
all shared element transition code
* Introduces new CastFragment class to encapsulate all code for
displaying casts reducing code duplication
* Introduces DataHolder class to replace passing the ViewHolder from
the *ListFragment to the *DetailsFragment or *InfoFragment
* Refactored AbstractDetailsFragment into two classes:
o AbstractDetailsFragment: for fragments requiring a tab bar
o AbstractInfoFragment: for fragments showing media information
We used to use <NAME>DetailsFragments for both fragments that show
generic
info about some media item and fragments that hold all details for
some media item.
For example, artist details showed artist info and used tabs to
show artist albums and songs as well. Now Details fragments are
used to show all details, Info fragments only show media item
information like description, title, rating, etc.
* Moved swiperefreshlayout code from AbstractCursorListFragment to
AbstractListFragment
Removed getting details in AddonDetailsFragment as the
AddonListFragment already provides all information required
in the AddonDetailsFragment. Therefore, we do not need to
retrieve the same information in the AddonDetailsFragment as well.
Martijn Brekhof
Synced Synapse