Communication Fragmentation and Interaction and Fragmentation

Question

One design question about communication between fragments,

why does someone use a slightly complicated callback template that implements listeners, compared to using simple static methods from the class we want to call from (something similar to using Singleton for some methods / attributes). Is there a performance issue or is it just “bad OO programming practice for Android / Java? Thus, an 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

It is better to use a well-defined communication interface than the assumption that it is. Therefore, if you define an interface for your communication, then:

• your Fragment can easily check if the parent Activity implements this interface, so Fragment will be able to communicate its needs,
• To define an interface, you need to think about something, and not just start coding, which leads to some standardization, and that’s good,
• it’s easy to maintain interface updates, as the compiler will complain if you change the interface but don’t implement it.

You can also read this Android SDK article .

Answer 2

If you have a simple use case for fragment / activity, then the solution is viable. Don't always buy what java purists say - if we did all this, no one would do anything. Sometimes it's best to throw the convention out of the window and do what is the fastest and easiest to use - especially if it's a small application and someone pays you to do it.

Answer 3

The reason for using documented callbacks and recommended templates is that you will be working with the Android framework, not against it. Using static methods completely circumvents this and looks simple, but there are problems at two levels.

First, from the point of view of object-oriented design, you are closely related classes that have completely different and independent responsibilities, which complicates their reuse and refactoring. The more static methods you introduce into your fragments and activity classes, the worse this problem will be.

Secondly, you work beyond the life cycle for both types of objects, and this will cause you a lot of pain. Firstly, fragments are destroyed and recreated by Android all the time. For example, when you rotate your device, and the screen changes from portrait to landscape, all your fragments are destroyed and created again, because in the landscape you can use different fragments or create different contours in the same fragments. Snippets and actions can also be paused when the user moves to a new action or other application.

Create static methods for fragments and actions, and you can call these methods at any time, and you do not know how much the fragment or activity will be noticeable even when you do it. You do not know at what stage of your life cycle it is if it is part of an ongoing activity, and therefore you are either going to write a lot of additional code to handle this, or not write at all (and have buggies).

Using callbacks also means that in operations with multiple fragments, you can more easily verify that alternative fragments can be used for alternative layouts, and parental activity, deciding which fragment to use, can ensure that data from sister fragments is directed to the correct fragment.

Answer 4

Download the latest Android tools (SDK r20, r14 tools at the time of this writing) and create a new Android application project ( New > Other > Android Application Project ) using the Eclipse IDE. In the "Create Event" step, select the MasterDetailFlow base project. This will create an instance of the application with two fragments (ListFragment and a detailed view) that will work right out of the box before writing a line of code. You can check how they interact through the main action.