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