Not sure if making a new issue is the right call and sorry in advance for the email spam and wall of text, but I dug into what was going on with the hokey display stuff seen while doing #153.
It turns out that there are two things going on here:
FishEntry.isCatchable is computed prior to when the FishWatcher is told to reinitRangesForFish. This is a problem for the layout because the layout uses the new ranges to compute the time it ought to print, but it uses the FishEntry's isCatchable for determining if the fish availability has changed.
When a fish becomes available during the same countdown event as a fish becomes unavailable, a double sort happens:
The countdown event happens and the newly available fish triggers an immediate sort.
Additionally, during the countdown event the newly unavailable/transitioning fish fires of a fishAvailabilityChanged event via the FishWatcher.reinitRangesForFish call, which triggers another update and sort some 350ms or whatever later.
For resolving (1) I think the easiest is to just recompute isCatchable if reinitRangesForFish is called, however this would result in the issue for (2) occurring whenever a fish becomes unavailable, meaning (2) would need to be resolved as well.
For resolving (2) it is a bit trickier, but I think the easiest "solution" is to remove the fishAvailability event handling from the ViewModel.update. With the change described in (1) above updates/sorts should happen correctly for all availability transitions in the countdown handling code. Note, this does make FishWatcher even somewhat more of a misnomer but I think trying to multiplex FishWatcher provoked updates and the countdown event updates is pretty challenging...
Not sure if making a new issue is the right call and sorry in advance for the email spam and wall of text, but I dug into what was going on with the hokey display stuff seen while doing #153. It turns out that there are two things going on here:
FishEntry.isCatchableis computed prior to when the FishWatcher is told toreinitRangesForFish. This is a problem for the layout because the layout uses the new ranges to compute the time it ought to print, but it uses the FishEntry'sisCatchablefor determining if the fish availability has changed.countdownevent as a fish becomes unavailable, a double sort happens:countdownevent happens and the newly available fish triggers an immediate sort.countdownevent the newly unavailable/transitioning fish fires of afishAvailabilityChangedevent via theFishWatcher.reinitRangesForFishcall, which triggers another update and sort some 350ms or whatever later.For resolving (1) I think the easiest is to just recompute
isCatchableifreinitRangesForFishis called, however this would result in the issue for (2) occurring whenever a fish becomes unavailable, meaning (2) would need to be resolved as well.For resolving (2) it is a bit trickier, but I think the easiest "solution" is to remove the
fishAvailabilityevent handling from theViewModel.update. With the change described in (1) above updates/sorts should happen correctly for all availability transitions in thecountdownhandling code. Note, this does makeFishWatchereven somewhat more of a misnomer but I think trying to multiplexFishWatcherprovoked updates and thecountdownevent updates is pretty challenging...Anyway let me know what you think. Thanks.