hello, Steve!

how can I help you today?

Hi Mark!

My app has a terms of service in a WebView, however I've been noticing various issues in Crashlytics

NameNotFoundException: com.google.android.webview

my impression has been that this comes from devices with a messed up System WebView app

ClassNotFoundException: com.android.webview.chromium.WebViewChromiumFactoryProvider

Right

same thing

Is there any workarounds that you know of?

nope

other than to avoid WebView

for example, a terms of service might work just in a TextView, perhaps using Html.fromHtml()

unless you have an awfully fancy terms of service... :-)

Marquees and everything!

Jk ;)

Thanks for the suggestion

I have another question while I'm here, after Dave

OK

hi, Dave!

Hi Mark and Steve. This is my first time here.

it's your turn -- do you have a question?

I have a zillion questions but would rather take today to just get acclimated. Eavesdrop, if you will!

um, OK

if you have a question at some point, chime in to let me know

So go ahead, Steve.

Steve: back to you!

I will chime in if I need to. Thanks.

Ok

We actually wrote a s/o post about it but haven't gotten any responses

About the architecture components lifecycle observers

how are you registering the observer? unregistering is usually handled by the Lifecycle

We add the observer in the constructor of the class

oh, I see

And we don't know if we have to explicitly listen for onDestroy

And remove the observer

Or if it does that automatically

yeah, sorry, I was thinking about LiveData

I don't work with observers directly very much

I noticed the documentation and examples don't really use removeObserver

They only mention adding it

I don't know what the official rules are, and I'd need to poke through the sources to try to get a bead on what is required

generally, they hold things weakly, and so my guess is that you can get away without unregistering, if the Lifecycle is going out of scope (e.g., the activity is getting destroyed)

Ok

so, off the cuff, I don't have a definitive answer for you -- sorry!

Right, that's what I assume, but we've been removing it just in case

That's ok, was just curious if you did :)

Thank you!

I believe that is everything I have, thanks a lot!

you're welcome!

Hey, Mark. Like I said, just dropping in, first time, see what it's like. I have to go to bank and eat a meal before a meeting I have at six. So I'm leaving, too. I'll be back. Thanks for all the times you've helped me, directly and indirectly.

happy to be useful!

tell the bank and meal that I said "hi!" :-)

hi, Steve S #2!

Hi Mark!

Interestingly, all my life people have referred to me as Steve. So can I be Steve S. #3? Or is Dave better?

But I'm gone anyway!

Steve: how can I help you today!

Which one?

at this point, any Steve can ask a question :-)

Steve Strates, you were here first - do you want to ask first?

the original Steve had indicated that he was done with questions earlier (sorry that you can't scroll backwards in the live chat transcript to see...)

sure, then i'll paste in a question:

I'm working on a master-detail interface that needs to run on both a large-format and a small-format device. I know a common way to implement this is to use fragments. I also know that some people think you should avoid fragments. Is it reasonable for me to implement this using fragments, or is there an alternative I should consider?

a common problem in programming overall, and in Android in particular, is that there are attitude waves

AsyncTask was awesome, then it was horrible

fragments were awesome, then they were horrible

in reality, both were fine, when used correctly

ok

but they weren't the all-singing, all-dancing, magic-bulleting solutions that people originally thought

so, fragments are fine

to put it another way, I'm doing master-detail-y work, and I'm using fragments

great. that's very helpful!

then i'll use fragments. are problems with fragments more likely to arise when you're doing things like nesting them?

I never liked nested fragments

that was due to bugs in early versions

I haven't seen all that many complaints about them in recent years

i see

so if you need 'em, and can keep track of the right FragmentManager instances to use, give it a whirl

the only use case I ever found compelling for them was fragment -> ViewPager -> fragments as pages

and I've switched to a RecyclerView in lieu of a ViewPager

so I haven't had a use case for nested fragments in a while

sure. what do you mean: "keep track of the right FragmentManager"?

a fragment working with nested fragments should use getChildFragmentManager()

for any transactions related to those nested fragments

i see. i won't be using nested fragments, so that shouldn't be an issue for my use case

so, for example, in my fragment -> ViewPager -> fragments as pages scenario, you would use the FragmentManager returned by getChildFragmentManager() with your FragmentPagerAdapter

ok

i don't have any more questions today

OK

thanks so much for your expert advice, Mark!

you're very welcome!

have a great rest of the day!

and now I eagerly await the next Steve S to enter the chat, so I can hit the trifecta... :-)

you too!

shouldn't take long...