Fragment-Activity communication, and inter-fragment communication

Question

One question for design about communicating between fragments,

why would someone use a bit complicated callback pattern implementing listeners, versus using a simple static methods from a class we want to call a method from (something similar to using Singleton for some methods/attributes). Is there any performance issue or it is "just" a bad OO programming practice for Android/Java? So the easy way for two-way communication could be:

MyActivity activity
    Fragment A
    Fragment B
static method canBeCalledFromAnywhere() {}
method activityMethod()
    call FragmentA.doSomething();
    call FragmentB.doSomething();



FragmentA
    onCreate()
        onMe = this;

static method doSomething()
    do something with static or use onMe for instance;

method oneMethodFragmentA()
    call MyActivity.canBeCalledFromAnywhere();



FragmentB
onCreate()
    onMe = this;

static method doSomething()
    do something with static or use onMe for instance;

method oneMethodFragmentB()
    call MyActivity.canBeCalledFromAnywhere();

Answer 1

If you have a simple use-case scenario for the fragment/activity, then you're solution is viable. Don't always buy what the java purists say - if we all did that, no one would ever get anything done. Sometimes it's best to throw convention out the window and do what is the quickest and easiest to do - especially if it's a small app and someone is paying you to do it.

Answer 2

The reason for using the documented callbacks and recommended patterns is that you will be working with the Android framework rather than against it. Using static methods completely bypasses this and looks simple but there are problems on two levels.

First, from an Object Oriented design perspective you are tightly coupling classes that have very different and independent responsibilities, making them harder to re-use and refactor. The more static methods you introduce into your fragment and activity classes, the worse this problem will get.

Second, you are working outside the lifecycle for both types of object and this is going to cause you a lot of pain. First off, fragments get destroyed and re-created by Android all the time. For example, when you rotate your device and the display changes from portrait to landscape mode all your fragments are destroyed and created again - because in landscape you might be using different fragments or rendering different content in the same fragments. Fragments and activities can also be paused when the user navigates to a new activity or different application.

Create static methods on fragments and activities and you can invoke those methods at any time and you have no idea if the fragment or activity is even visible when you do so. You don't know what stage of its lifecycle it is at if it is part of the current activity and therefore you're either going to write a lot of extra code to deal with this, or write none at all (and have a very buggy application).

Using callbacks also means that in a multi-fragment activity you can more easily ensure that alternative fragments can be used for alternative layouts and the parent Activity, having decided which fragment to use, can ensure that data from sibling fragments is routed to the correct fragment.