Skip to content

Fix crash when returning to swap after cancelling

Fixes #409 (closed). The problem was that there was some listeners being added for broadcast events when the swap view was shown. These were never removed, and so cancelling swap, then returning to it would spin up a new activity with new views, while the old listeners were still around. When the old listeners received events, they would try to talk to their associated Activity. This no longer existed, so a crash ensued.

While I was fixing the specific bug associated with #409 (closed), I took the opportunity to make more of the event listeners well behaved in the swap process. I don't think any of them were liable to cause crashes, but were likely to cause some weirdness at some point in time if they were not fixed.

Note: This swap view was an exercise in moving away from Fragments towards an Activity with individual Views. I'm going to call this a bit of a failure at this point, because there is so much work that needs to be invested in implementing lifecycle stuff in our custom views. Fragments naturally come with lifecycle methods that are familiar to other Android dev's looking to contribute to this project (even if they are a little difficult to understand at times). Implementing our own custom Views instead still results in similar classes of bugs (i.e. talking to an Activity when the view no longer is part of that activity).

A classic example of this is in my usage of the onDetachedFromWindow function in the View. I have no idea if this is the best place to unregister listeners or not. In a Fragment, it would be a matter of onPause or one of the more well defined lifecycle methods. Empirically, onDetachedFromWindow seems to be well behaved. The other alternative would be for the Activity to explicitly invoke a onRemoved type method each view when it knows it is transitioning from one state to the next. However at this point, we are then really into reimplementing Fragment land.

Merge request reports