Code puzzle for all #AndroidDev out there!

Let's display a Toast! Yes, Snackbar is the new cool kid, but toasts tastes better.

𝚃𝚘𝚊𝚜𝚝.𝚖𝚊𝚔𝚎𝚃𝚎𝚡𝚝(𝚌𝚘𝚗𝚝𝚎𝚡𝚝, "", 𝙻𝙴𝙽𝙶𝚃𝙷_𝙻𝙾𝙽𝙶).𝚜𝚑𝚘𝚠()

𝚌𝚘𝚗𝚝𝚎𝚡𝚝 should be...

Let's look at each possible answer!

"an Activity Instance"

=> Toasts are enqueued and displayed serially. Each stays for 2-3.5 seconds. Until toast is displayed, the activity will be held in memory even after Activity#onDestroy().

Enqueue several toasts => activity leak!

"an Application instance"

This is the right answer to avoid Activity leaks. However, on API 25, there's a race condition leading to crashes when the app is in background: BadTokenException. Not just activity though, this happens with every context!

See https://android.googlesource.com/platform/frameworks/base/+/0df3702f533667a3825ecbce67db0853385a99ab%5E%21/core/java/android/widget/Toast.java

One approach to avoid this is a custom context wrapper that catches BadTokenException

E.g. https://github.com/PureWriter/ToastCompat or https://github.com/LouisCAD/Splitties/blob/main/modules/toast/src/androidMain/kotlin/splitties/toast/Toast.kt#L88-L113 by @Louis_CAD (still could leak activity though)

Another approach is to use an Activity context but cancel the toasts when that Activity is destroyed. After all, should you really display a toast after the activity has been destroyed? Users hate toasts randomly appearing!

I'm making LeakCanary better at surfacing this edge case: when a ViewRootImpl is held by WindowManagerGlobal and references a destroyed activity, LeakCanary will now hint that you might need to cancel a toast (the activity ViewRootImpl is automatically removed)

So, what's the right answer?

Obviously: don't use Toast, use Snackbar!

But if you really want to use Toast: either use an application context with a horrible context wrapper hack, OR use whatever context and cancel toasts on activity destroy.