hello, Kai!

Hello again

how can I help you today?

I have a Fragment hosting two other Fragments, via a TabLayout and a Viewpager.

The parent Fragment has an "save" button, which saves some data input in the child Fragments.

The first child Fragment has some EditTexts. When being in the second Fragment and clicking "save" there will be a problem, as the first Fragment is ofc not accessible.

the parent fragment should still have access to the first child

There is a ViewModel for all three Fragments. I guess the question is how to best save the input from the EditText into the ViewModel when changing Fragments.

you can register a listener on the TabLayout or the ViewPager to find about page changes

the parent can then ask the child to ensure the ViewModel is up to date

Are you sure? When changing to the second Fragment, onPause() is called for the first and when trying to access the first Fragments EditText, I get a NPE.

Is using the listener a solid way to do it? It was one way I found.

I don't know how you are accessing the first Fragment's EditText

findViewById() will work between onCreateView() and onDestroyView()

Another was to register to the EditText and just save every change.

The third was throwing LiveData on it.

LiveData cannot solve this problem on its own

a TextWatcher on the EditText, and using it to update the viewmodel, is possible

I do getActivity().findViewById(...) and it returns null.

a fragment should never be doing getActivity().findViewById()

call findViewById() on the fragment's own View, typically in onViewCreated()

getActivity().findViewById() implies the ability to mess with widgets that are beyond the fragment itself

(which isn't good)

Ok

I do feel that, rather than trying to get some field in a parent Fragment, the child Fragment should set the data via the ViewModel

Which would imply using TextWatchers.

TextWatcher is one approach, but the parent can also tell the child "hey, make sure the viewmodel is up to date" at appropriate points, such as when the tab changes

the downside of TextWatcher is that it gets called frequently as the user types

you can try to add some "debounce" logic to update the viewmodel, just not as frequently as TextWatcher gets called

Yes, that is something I don't like.

I was about to try using "onResume()" and "onPause()" inside the child to save away my contents.

And set them

to be honest, I forget what lifecycle callbacks get called when a ViewPager switches pages

And advantages or disadvantages to the approach of the parent telling the child to save away the data?

With ViewPager2 it seems to be those.

that's surprising, if true

I would have expected onAttach()/onDetach()

onResume() and onPause() are supposed to be tied to the overall activity lifecycle

but, I haven't played with ViewPager2 significantly yet

regardless, updating the viewmodel in the right lifecycle methods should also be fine... but you will still need the ability for the parent to tell the child to update the viewmodel

If you say the parent hooking into the viewpager and telling the children to save the data away is more robust, I'll do it that way.

Why will I need that?

I can't say whether or not it is more robust -- it's been years since I did that

if the user is on the first tab and the user clicks save, you need to make sure that the first tab has updated the viewmodel before you use the viewmodel data for saving

clicking save will not trigger any lifecycle callbacks on the first fragment

Right. That would be the clean way I guess, better than trying to get the EditTexts from the parent Fragment.

Hi sudokai

yeah, the parent really should consider the child to be fairly opaque, rather than messing with its widgets directly

let me take a question from sudokai, and I'll come back to you shortly

sudokai: hi! how can I help you today?

ofc

Hi, no questions for now. Just hanging out here in case.

OK, if you come up with a question, let me know!

Kai: back to you!

Do you happen to have a "complex" ViewModel example?

the app in *Exploring Android* is about as complex as I have

The ones I could find so far are all quite simple and easy while the one I build is quite big.

(in terms of public samples)

Hm ok.

on the whole, my focus is on "how to use these APIs" more than "how to assemble them into something large"

because there are an infinite number of ways of doing the latter, any of which would be a headache to maintain

I wonder if it's worth it at the end of the day, as I spend so much time making sure the ViewModel is in the right state at the right time.

I would like to be able to say "this field is always the value of this EditText, this Field is always the value of this Checkbox, ..." and not have to deal with the details.

the stateful UI of the Android view system does not make that very easy

But I end up writing a lot of "boilerplate" code to make sure the right values get saved at the right time and such.

two-way data binding was an attempt to address that, with its own problems and limitations

Jetpack Compose gets rid of the stateful views, so the viewmodel (or other app-supplied state containers) is *the system of record* for what gets rendered

but Jetpack Compose is 1-2 years away from being something you would want to use for mainstream stuff

Especially for my mainstream stuff ;-)

Do you think I should read through your first generation books or will the second generations books be enough?

for general-purpose stuff, the second-generation books are better

simply because they cover more up-to-date approaches

I see. I started reading Android Architecture Components.

but, the Warescription site search engine covers both generations

mostly, that has been eclipsed by *Elements of Android Jetpack* and *Elements of Android Room*

there are some Room things from *Android's Architecture Components* that I have not gotten into *Elements of Android Room*

and there are probably some chapters in *Android's Architecture Components* with no equivalent in the second-generation books

I actually skipped all but the first chapter on Room because I am not using that (yet).

I see. So I should probably work my way through Jetpack instead.

yes

looking through my table of contents... most of the non-Room stuff in *Android's Architecture Components* is now in *Elements of Android Jetpack*

with the benefits of being more up-to-date, showing Java and Kotlin, etc.

Do you think Android is going strong in the future? Or will it be replaced by Flutter or even PWA?

I think that you are conflating "Android" and "native Android app development"

Android, the OS, can't be replaced by Flutter or PWAs

native Android app development could, in theory

I suspect that Flutter and PWAs each will be 5-10% of the Android app development space, and another 10% or so for various game frameworks (e.g., Unity 3D)

Flutter and PWAs have a higher ceiling than do the game frameworks, simply because game frameworks are optimized for a specific domain (games)

however, I don't anticipate that Flutter or PWAs will eclipse traditional Android app development any time soon

That gives me more confidence to dive deeper into native Android development.

OK, that's a wrap for today's chat!

the transcript will go up on https://commonsware.com/office-hours/ in a few minutes

the next chat is Thursday at 7:30pm US Eastern

Have a good time everyone.

have a pleasant day, and stay healthy!