Office Hours Transcript: 2021-08-28

Ndrocchietto_ivano joined

hello, Ivano!


how can I help you today?

Heyla Mark!


mmh dunno


lemme review the code of this week please


will come back to you if should find something that could not find in the internet

Well I would like to raise a minor curiosity


my senior says that I should never never use requireContext()


and that the way to go in our fragments(we use a lot of fragments and single activity, that are not really single but almost) is


to write context?.let{…}


it looks odd to me, is this a good defensive way to prevent bugs?

well, requireContext() will throw an exception if no Context is available, such as the fragment not being attached


context?.let { } will not throw an exception, but instead will just not do anything

and this is something linked with the infamous illegal state exception of fragment that get destroyed by the machine?

(if there is no Context, that is)

well looks quite elementar

I am uncertain which of the many IllegalStateExceptions you are referring to there


the downside of a simple context?.let { } is that by default you are not doing anything in the cases where context winds up being null

me neither, is something related to state loss in the fragments that few people add commitAllowingStateLoss()

so, you wind up doing context?.let { } ?: run { }, where the run { } represents whatever sort of fallback or logging that you want for the "context is null" case


personally, I try to avoid commitAllowingStateLoss()

the equivalent would be try { requireContext().whatever } catch (ex: Exception) { }

there are some steps I can do to prevent fragment loss then apart playing the super paranoic defensive game?


ah nice thanks

what exactly do you mean by "fragment loss"?

well I am guessing that the system autonoumsly causes a forced garbage collection of some fragments?


at least, no differently than any other objects

mmh ok thanks

if your fragment is not attached to an activity, and you are not holding a reference to it somewhere, it may get garbage collected


where developers get burned with fragments a lot is not paying attention to the natural lifespans of fragments

but a fragment is not for definition attached to an underlying activity, otherwise how could I launch?



for example, you want to have an animated effect occur when the user clicks some button in a fragment, and when the animation completes, you then want to do something else to the widgets in the fragment


so, you set up some animation with a listener that gets control when the animation is over, to do post-animation work

i see, a listener has then some reference that does not exist anymore?

now you get in trouble if the user destroys the activity (e.g., system back navigation) while that animation is running, because you try working with stuff in the fragment in the listener after the fragment was destroyed


I got it

it is very easy to make that sort of mistake, and normally the code works


but, with a large enough user base, you will see crashes in your crash-logging tool, and you then need to go in and make fixes

wow that is why in my previous job we had always crashes with fragment although we tested thoroughly


in firebase crashalytics from our users


well mark thanks was really informative

happy to help!

I am going to dive into this subject with some ad hoc medium smart post


i am done for today, but remain in chat maybe somebody is joining


that’s all for today’s chat – the next one is Tuesday in the 7:30pm US Eastern slot


have a pleasant evening!