Fragment Arguments


#1

You say the correct way for CrimeFragment to be “encapsulated” is to remove its need to access the Activity that is hosting it to get at the Intent data that has the UUID it needs.

Yet part of the solution is to have CrimeFragment create the instance of itself with the newInstance(UUID) method. So, at this point it creates itself and has the UUID it will need later in the onCreate() method. So, why use the Intent to pass the UUID and move it to the Bundle data? Why not just have a member variable have that info?

Add a new field to CrimeFragment:

And then:

Either have the newInstance method pass the UUID into a constructor which sets mCrimeID:

Or have it set a member variable after creating itself:

CrimeFragment fragment = new CrimeFragment(); fragment.mCrimeID = crimeID;

Then, in the onCreate() method, it just needs to use mCrimeID to get the instance of Crime it needs to display.

Am I missing something? Like maybe you are doing this to help use learn about Intent and Bundle data even though the example here is not a good way to use them?

Thanks!


#2

Please tell me if you don’t understand the question. I am trying to learn Java programming, Android programming, OOP, and rules versus efficiency.

It should be a simple question. Your book passes the data to the class instance through an Intent Extra and then Bundle data, when it could have just been put into the class instance without all of that.

When I see things like this, and see a much more efficient solution, I have to wonder why did you do it that way? Because, even though I want to learn how you do things in Android, like share data between Activities, Views, and Fragments, seeing examples of them being used does not help that much if it is not a situation where it would make sense to use them.

Thanks.


#3

Rick - I share your pain. I’m trying to get my aging brain cells around Android programming, and whereas there is plenty of advice on how to do something, it’s not always blindingly obvious why things should be done a certain way.

I’m working through the CriminalIntent [Note 1] app and using it to build myself a set of application classes which are (theoretically!) as generic as possible. In chapter 10, my first thought was "why not just pass the crimeID to a custom constructor for crimeFragment, but as we’ve discovered, this approach seems to be frowned upon in Android circles!

Try checking this out: androidchef.wordpress.com/2011/0 … callbacks/

If I understand correctly, the writer here is saying that the operating system is free to arbitrarily kill and recreate fragments at any time. Because the OS is unaware of a fragment’s custom constructor (let alone what arguments were passed to the constructor) there has to be some way of making the run-time state of the fragment persistent, independently of the constructor call. And that’s why we have to implement a static newInstance method which initialises the argument bundle.

This makes sense for me - hope it works for you.
Dave

Note 1: Guys - it really wasn’t a great idea to include the word “Intent” in the app name when “Intent” has such a specific meaning in Android dev. Remember, this book is for easily-confused noobies! :unamused: Maybe for next time, you might try renaming the app to CrimeNotes or something similar…


#4

Thanks Dave! In the next chapter you can see how a CrimeFragment will be destroyed and recreated as you use the ViewPager to manage them and you can navigate from one to the next without going back to the CrimeListFragment.

It is strange to be out of control of when a class is destroyed and recreated.

So, the OS will keep the Bundle data for each CrimeFragment around and knows what Bundle belongs to each one, and that is where you keep data that needs to persist.

I think this is a weakness with the approach of this book. By focusing on a single app to introduce the concepts, and introducing one concept at a time, it does not help us understand the bigger picture as we go along. Like, I still don’t understand why CrimeLab needs a Context. Hopefully this will be explained later.

The other problem is that the authors don’t seem to like to answer questions. Obviously, it isn’t possible to think of everything a newbie might wonder about when you are writing a book, but hosting a forum and then ignoring questions sure doesn’t make them look like they care about the students.

I am glad you did!