Isn't it complicate?


#1

Hi All, Hi Brian and Phillips

I just finished chapter 12 and I think I am missing something.
I have been doing software development for more than 30 years mainly in C, C++ and Obj C (I bought your book on IOS programming and have been very satisfied with it, that is why I am coming back :slight_smile: )

But I am quite new to Java and to Android programming, may be that’s the reason why I am puzzled.

Anyway, my problem is that I don’t understand why the communication between our 2 fragments is done in such a complicate way and why we have to use so often the Bundle.

First, sending the date to the datePickerFragment.
In the newInstance method (in DatePickerFragment.java), why don’t we directly set mDate with the date. I mean once the “new DatePickerFragment()” method has been called, the DatePickerFragment object exists no ? Then, why can’t we directly set its mDate member from there ?
Why passing it into the bundle and retrieve it from the arguments inside the onCreateDialog method

Second : sending data back to the CrimeFragment.
wow !!!
is it really necessary to follow all this long track ?
I mean, isn’t it something a little bit less complicate like callback function or delegate, without having to store the result date in an Intent and do all those strange things ?

To be honnest with you, it is not the first time I think that things are done in a way that seems complicate or not very logical to me. Now, as I trust the way you do things (once again, I really learned a lot on IOS with Big Nerd Ranch Guide), I conclude that it is Android dev which sometimes takes complicate ways. I guess it is a matter of history (keep compatibility between android releases).

So, am I missing something ?

Thanks again for your great books,

Cheers

Antoine


#2

Hey Pich,

1- You can do what we do with fragment arguments in a slightly different way if you like, but the bundle must be involved at some point. Your other option is to save it in mDate, and the save it out in onSaveInstanceState.

2- The mechanism for sending data back, however, is actually the best solution we know of.

Why? There are examples out there of using a simple callback. We do not recommend using them, though. The reason is that your activity+fragment, as well as your entire process, may be blown away. That means that you must be able to recreate the callback relationship using nothing but the information stored in your bundle! Doing that by hand is a huge pain.

This is why we recommend using the fragment target mechanism - behind the scenes, it will stash this relationship in the bundle for you, as well as restore it.


#3

Hi Philips,

Thanks for the reply but that leads me to another question :
If I have one activity displaying 2 different fragments at the same time and if I need those 2 fragments to communicate together. Let’s say I want to disable (or enable) a button on fragment 2 when a toggle located on fragment 1 is set OFF (or ON), or I want to transfer an object from one to the other.

Whether if I use a “master class” that will control both, or not, do I have necessarily to serialize and transfer through the bundle or can I have direct link calling setters of fragment2 from fragment1 (or the contrary) ?

In this specific case, I guess everybody will be blown away at the same time.


#4

Yeah, target fragments are a very bad fit for the situation you describe. In the book, we recommend the Callback pattern for the sort of interfragment communication you’re talking about. You can see this demonstrated in Chapter 22.

In practice, lots of folks rely on event buses for this sort of interfragment communication. Here are two common implementations I’ve seen used to good effect in practice:

Otto - http://square.github.io/otto/
EventBus - https://github.com/greenrobot/EventBus