NullPointer crash in TalkCursorAdapter::bindView

[intermarc]

This crash has been happening frequently in the last month. Here is a stack-trace from the google play console:

Exception java.lang.NullPointerException:
at org.dharmaseed.android.TalkCursorAdapter.bindView (TalkCursorAdapter.java:58)
at androidx.cursoradapter.widget.CursorAdapter.getView (CursorAdapter.java:274)
at android.widget.AbsListView.obtainView (AbsListView.java:2709)
at android.widget.ListView.makeAndAddView (ListView.java:2237)
at android.widget.ListView.fillSpecific (ListView.java:1535)
at android.widget.ListView.layoutChildren (ListView.java:1931)
at android.widget.AbsListView.onLayout (AbsListView.java:2485)
at android.view.View.layout (View.java:25771)
at android.view.ViewGroup.layout (ViewGroup.java:6822)
at androidx.swiperefreshlayout.widget.SwipeRefreshLayout.onLayout (SwipeRefreshLayout.java:689)
at android.view.View.layout (View.java:25771)
at android.view.ViewGroup.layout (ViewGroup.java:6822)
at android.widget.LinearLayout.setChildFrame (LinearLayout.java:1891)
at android.widget.LinearLayout.layoutVertical (LinearLayout.java:1729)
at android.widget.LinearLayout.onLayout (LinearLayout.java:1638)
at android.view.View.layout (View.java:25771)
at android.view.ViewGroup.layout (ViewGroup.java:6822)
at com.google.android.material.appbar.HeaderScrollingViewBehavior.layoutChild (HeaderScrollingViewBehavior.java:149)
at com.google.android.material.appbar.ViewOffsetBehavior.onLayoutChild (ViewOffsetBehavior.java:43)
at com.google.android.material.appbar.AppBarLayout$ScrollingViewBehavior.onLayoutChild (AppBarLayout.java:2348)
at androidx.coordinatorlayout.widget.CoordinatorLayout.onLayout (CoordinatorLayout.java:918)
at android.view.View.layout (View.java:25771)
at android.view.ViewGroup.layout (ViewGroup.java:6822)
at androidx.drawerlayout.widget.DrawerLayout.onLayout (DrawerLayout.java:1263)
at android.view.View.layout (View.java:25771)
at android.view.ViewGroup.layout (ViewGroup.java:6822)
at android.widget.FrameLayout.layoutChildren (FrameLayout.java:332)
at android.widget.FrameLayout.onLayout (FrameLayout.java:270)
at android.view.View.layout (View.java:25771)
at android.view.ViewGroup.layout (ViewGroup.java:6822)
at android.widget.LinearLayout.setChildFrame (LinearLayout.java:1891)
at android.widget.LinearLayout.layoutVertical (LinearLayout.java:1729)
at android.widget.LinearLayout.onLayout (LinearLayout.java:1638)
at android.view.View.layout (View.java:25771)
at android.view.ViewGroup.layout (ViewGroup.java:6822)
at android.widget.FrameLayout.layoutChildren (FrameLayout.java:332)
at android.widget.FrameLayout.onLayout (FrameLayout.java:270)
at android.view.View.layout (View.java:25771)
at android.view.ViewGroup.layout (ViewGroup.java:6822)
at android.widget.LinearLayout.setChildFrame (LinearLayout.java:1891)
at android.widget.LinearLayout.layoutVertical (LinearLayout.java:1729)
at android.widget.LinearLayout.onLayout (LinearLayout.java:1638)
at android.view.View.layout (View.java:25771)
at android.view.ViewGroup.layout (ViewGroup.java:6822)
at android.widget.FrameLayout.layoutChildren (FrameLayout.java:332)
at android.widget.FrameLayout.onLayout (FrameLayout.java:270)
at com.android.internal.policy.DecorView.onLayout (DecorView.java:1084)
at android.view.View.layout (View.java:25771)
at android.view.ViewGroup.layout (ViewGroup.java:6822)
at android.view.ViewRootImpl.performLayout (ViewRootImpl.java:5279)
at android.view.ViewRootImpl.performTraversals (ViewRootImpl.java:4526)
at android.view.ViewRootImpl.doTraversal (ViewRootImpl.java:3288)
at android.view.ViewRootImpl$TraversalRunnable.run (ViewRootImpl.java:11344)
at android.view.Choreographer$CallbackRecord.run (Choreographer.java:1689)
at android.view.Choreographer$CallbackRecord.run (Choreographer.java:1698)
at android.view.Choreographer.doCallbacks (Choreographer.java:1153)
at android.view.Choreographer.doFrame (Choreographer.java:1079)
at android.view.Choreographer$FrameDisplayEventReceiver.run (Choreographer.java:1646)
at android.os.Handler.handleCallback (Handler.java:958)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:230)
at android.os.Looper.loop (Looper.java:319)
at android.app.ActivityThread.main (ActivityThread.java:8919)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:578)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1103)

As yet no clear idea what might be going on here. Could this be somehow related to users clicking a dead media notification?

[intermarc]

Having looked at the code, this issue is almost certainly not connected to the media notification: the problem here occurs in the navigation activity and is not directly connected to media playback at all!

My only guess is that this problem is a race condition when talks are removed from the DB during app initialization. Commit da311f6 is intended to address this. I haven't tried to reproduce this issue, though, so this is all a bit hypothetical.

[bb4242]

I agree it seems likely this is a race condition related to the database (and specifically, the talks table, since the talk lookup in TalkCursorAdapter.bindView is what is failing and returning null). As far as I understand from my memory as well as a quick review of the current code, I think there is only one place where we might delete talks from the database:

dharmaseed-android/app/src/main/java/org/dharmaseed/android/DataFetcherTask.java

Line 93 in e0f3642

dbManager.deleteIDs(idsToDelete, tableName);

This is how we remove stuff from the database that the dharmaseed API tells us should be removed (via the x_items result of an API call). It seems plausible to me that if the TalkFetcherTask deletes a talk in the background while that talk is still present in the navigation list, we'd get the error we're seeing. I think da311f6 looks like a perfectly reasonable fix; I'd be happy to try putting that into production and seeing if it fixes the issue. It seems that we're getting a fairly steady stream of these errors in production, so presumably we wouldn't have to wait too long to see if the fix makes a difference.