At least where QR was being used, it didn't go away. Not sure why, but a
global was getting nulled when it shouldn't have been. Race condition I
guess.
Often I want to view a different wordlist from what's in use in the
game. So make the in-board long-tap shortcut to a wordlist remember what
the short-tap gesture chose most recently and use that instead of
assuming the game's list is what's wanted. Remember the choice on a
per-language rather than per-game basis.
This seems to do what I want: cause it to be dismissed whenever the
board fragment behind it (that launched it) goes away, e.g. because the
remote deleted first and local got a deleted-elsewhere-so-delete-here?
alert.
The old API required passing dict into game creation/loading. New
doesn't, but in some places I was doing other stuff there (like checking
existance), so can't remove there. Still code goes away.
Recent change added Delete button to game-over alert, but only when no
unacked messages remained (since deleted games can't continue trying to
send messages other games might still need to know the game's over.)
Typically the alert would go up and then, if the remote device is
online, shortly after acks would arrive. Now when that happens the alert
gets updated to offer to delete and archive.
Once in the archive games don't ever send unless opened explicitly (no
resend-all-on-gained-network stuff for them). So don't offer to put a
game there if it has unsent (unacked) messages. Should prevent problem
of a host being archived before it's managed to send its final move to
all guests.
Scroller is allowed only one child and I guess I wanted the TableLayout
to suffice, but having unrelated stuff in it sucked. So wrap it in a
LinearLayout and move the unrelated stuff out.
I want to encourage people not to think there's action to be taken
between when they invite and an invitee responds, e.g. to email. So make
the "Close Game" button the "positive" one that case.
I balked at writing code consisting of a bunch of classes there only to
provide a mapping to resource file IDs, instead opting to generate them.
(The right move might have been to generate everything from the old
xwprefs.xml, but it's too late for that. :-)
I realized I'd made some mistakes and so rebuilt them from the old
xwprefs.xml file. Didn't find any new mistakes, but there are fewer
unnecessary changes so the release-to-release diff should make more
sense.
We've decided that on upgrade users shouldn't be surprised by a busy
board and unaware of how to fix it. So keep it the way it's been and let
the curious discover the new ability. Also, simplify code.
