Improve feature loading within an EnvivedFeatureActivity (Ref #4)

[irinagrigorescu]

The current way of loading features is somewhat involved and the implementation leads to a hack for subverting Android’s default way of handling configuration changes (e.g. tilting the screen sideways). Additionally, the wait-for-data spinners are a bit hackish in implementations.

The task is to improve this functionality. One possible idea is to create two types of abstract classes that handle the loading and displaying of wait-for spinners:

• update and use the existing EnvivedFeatureActivity for activities that DO NOT use Fragments
• create an abstract EnvivedFeatureFragment base class or even a custom subclass of the FragmentManager to support our on-demand loading/retrieving of feature data. This will used on feature activities that require Fragments to display the data. Moving the loading/retrieving code to the fragment part is expected to help with the configuration change issue as well.

Ref #4

[asorici]

Another thing to look out for is the way feature initialization is done in Activities not subclassing from EnvivedFeatureActivity (e.g. PresentationDetailsActivity, SpeakerDetailsActivity). The idea would be to separate initialization into parts that do actual "remote retrieval" (happens only on subclasses of EnvivedFeatureActivity) versus those that just do "loading" like the ones mentioned above (the activity flow is such that these classes are never accesible if the EnvivedFeatureActivity subclass can not load the feature class).