DroidPlanner/droidplanner — pull request #553 by ne0fhyk (2014-01-06 22:26:52+00:00)
Title: Feature improving backward compatibility

This pull helps improve support for backward compatibility by switching to the android V4 support library as discussed in issue #537.

Quick summary of changes:
* Moved the ```SettingsFragment``` to a new ```com.droidplanner.activitys.SettingsActivity``` class, as ```android.app.PreferenceFragment``` is one of the few remaining without equivalent in the support library.
* Updated all the remaining fragments to extend from ```android.support.v4.app.Fragment```.
* Switched the google map fragment from ```com.google.android.gms.maps.MapFragment``` to ```com.google.android.gms.maps.SupportMapFragment```.
* Updated the activities to extends from ```android.support.v4.app.FragmentActivity``` instead of ```android.app.Activity```.
* Updated all activities, except ```com.droidplanner.activitys.SettingsActivity``` to use ```getSupportFragmentManager()``` instead of ```getFragmentManager()```.
* Updated the support library jar file (v13 -> v4).

Additionally, most of the fragments in the ```com.droidplanner.activitys.ConfigurationActivity``` class had some sort of fragment initialization related bugs, that I resolved:
* Most of the fragments were using ```getFragmentManager()``` to initialize their own fragments, instead of ```getChildFragmentManager()```.
* ```RcSetupFragment``` and ```SetupFragment``` were passing reference of themselves, as well as arguments to their child fragments in an unsafe, error prone way. The recommended way to pass, and retrieve arguments to a fragment is via the ```setArguments(Bundle args)```, and ```getArguments()``` methods. The recommended way to access a parent activity is via the ```getActivity()``` method, and if the fragment is a child fragment, the recommended way to access its parent fragment is via the ```getParentFragment()``` method. So I updated the architecture for the ```RcSetupFragment```, and the ```SetupFragment``` fragments to take care of these issues.
* Child fragments of ```SetupFragment``` were directly accessing and manipulating elements in ```SetupFragment``` layout via the ```getFragmentManager()``` method. Unless it fulfills a specific goal, not attainable through other means, this is not recommended. The recommended way is to have the parent (activity or fragment) always directly manage its own layout, and have the child fragments communicate their intents via public available methods to the parent.

After this pull is merged, developers should ensure they're making use of the support library api, instead of the regular api (i.e: ```getSupportFragmentManager()``` instead of ```getFragmentManager()```, etc...).
Making the switch to the support library api is easy though, as in most cases, it only requires updating the ```import``` statement.

This feature branch was updated with the latest from upstream/master so it should be ready to merge automatically.