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
OK
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()
ah nice
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?
no
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?
ah
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
OK
that’s all for today’s chat – the next one is Tuesday in the 7:30pm US Eastern slot
have a pleasant evening!