In a lot of cases the Fragment is the right place to handle events but what about the Activity - does it get to do anything useful?
The whole point of a UI, even a fragment of a UI, is to provide some data to or display some data from the application. At some point the Fragment has to accept data or give data to the application and the Activity in particular.
To get data from the Fragment there is nothing new as the Activity can simply access the View objects created by the Fragment in the usual way using findViewById or similar. To put data to the Fragment the Activity can use the same technique. The Fragment can also offer the Activity public properties which it can set and get. There is nothing new here.
The only complication is that the Fragment can be destroyed and recreated by the system by calling its onCreateView. What this means is that any public properties it might have could be re-initialised at any time.
The solution is, of course, to preserve the state of the Fragment using the Bundles provided for the job.
There is a tricky problem if the Activity tries to attach an event handler to a View provided by the Fragment. There is nothing wrong with creating a listener in the Activity and setting it as the event handler for a View object created by the Fragment. This works perfectly until the moment the Fragment is destroyed and recreated by the system calling the onCreateView. At this point the View object that the event handler was attached to is recreated and the connection to the event handler is lost.
The simplest solution is to set the event handler each time the Activity onCreate is called but this turns out to have lots of subtle difficulties - there are better but more elaborate solutions which will be explained in detail in the next chapter.
You just need to be very aware that the fact that the Fragment can be destroyed and recreated at any time makes its use more complicated than you might first think.
When you have a single Fragment backed by an Activity there seems to be little point in splitting the code between the two. However if you keep in mind the idea that the Fragment should provide the UI and the Activity should provide the processing then you have a good division of concerns and code which should allow the Fragment or the Activity to be reused. If you know about the MVC - Model View Controller - design pattern then you can think of the Fragment as the View and the Activity as the Model.
Things get much more interesting when you build an application with multiple Fragments and this is something we have to look at in a later installment.
Summary
A Fragment is a class that implements the onCreateView method to supply a View hierarchy that can be displayed by an Activity.
To use a Fragment in an Activity you have to add it using a FragmentManager and a FragmentTransaction. You can add the Fragment using the add method but nothing happens until you call the commit method.
After the method that used the commit, usually the Activity's onCreate, terminates the CreateView event runs the Fragment's onCreateView and the Fragments View hierarchy is added to the Activity's content.
A Fragment can be destroyed by the system and recreated from scratch automatically by having its onCreateView called.
You have to write code to save and restore any additional state the Fragment may have.
If a task is common to all instances of the Fragment then its code should live in the Fragment.
In particular the code to handle events can be defined within the Fragment.
The Activity should be used to host code that processes the data provided by the UI.
Attaching Activity event handlers to the Fragment's UI or is difficult to do correctly. There is a better solution.
Conclusion
Next we need to look at how you can use Fragments with XML layouts and with Android Studio.
You can download the code for the programs from the CodeBin (note you have to register first).
