Why not encapsulate the result all in CheatActivity?

Going through the 4th edition after previously having gone through the 2nd & 3rd editions. When implementing the result from CheatActivity, it appears a change has been made from the 3rd to 4th editions.

In the 3rd Edition Listing 5.14, EXTRA_ANSWER_SHOWN was declared as private on CheatActivity. Then in the 3rd Edition Listing 5.15, a public function was added to CheatActivity:

// in Java
public static boolean wasAnswerShown(Intent result) {
    return result.getBooleanExtra(EXTRA_ANSWER_SHOWN, false);
}

This completely encapsulated and hid the existence of the EXTRA_ANSWER_SHOWN variable.

Now in the 4th Edition Listing 6.14, EXTRA_ANSWER_SHOWN is declared as public within CheatActivity.kt. Then in the 4th Edition Listing 6.16 we have on MainActivity a direct call for the result

// in Kotlin
quizViewModel.isCheater = data?.getBooleanExtra(EXTRA_ANSWER_SHOWN, false) ?: false

I haven’t gone far enough yet to see how Fragments are handled, but shouldn’t we be encapsulating all the necessary information within each class? Right now, MainActivity needs to know what is available inside of CheatActivity.

1 Like

Was wondering the same thing. Did you ever get an explanation?

I did not. And by the time we move to fragments we’re using callbacks to have the Activity handle tasks.

And while not in the book, if you use the Jetpack Navigation AC then there is a third style for handling events such as this.

For the purpose of GeoQuiz, I chose to encapsulate the information all inside of CheatActivity.