workaround to fix a bug where the UI isn't updating often enough and
sometimes delete or other position-based long-tap menu actions on the
list act on the wrong game. This gives an order that won't change.
Revisit later if a more dynamic order is desired.
game they were passed to. This prevents duplicate messages from
generating notifications over and over -- and dupes are common when
messages stay on relay until the receiving game ACKs them.
the only way to have it wind up on top *and without it being a second
instance of the activity* when relaunched in response to a move-made
notification. Even passing the SINGLE_TASK flag to the relaunching
Intent doesn't accomplish this.
correspondent's having occasional crashes with a single dictionary.
It appears that if it were truncated during the download that it would
appear ok until a word search spread into a missing area. This fix is
untested, and should probably be replaced by a checksum that computed
and checked after the download, but I think it's an improvement.
dependency on an open game having a visual representation. This
should allow e.g. receiving and caching chat messages that come in
while game is not in foreground.
short time on the live relay. I'm not sure why it's needed, why they
happened only this time (likely due to a single device) or
alternatively why I don't see those crashes in testing, but the
addition doesn't break anything.
GET_MSGS. When the messages come in, open up saved games and play
them into them, saving them after if there were any changes. Tested
by playing a two-device game all the way through fetching messages
after every move.
object) rather than allocating a new array in the C heap -- for the
DAWG data of a dictionary. This can use up to 5% of the java heap for
huge dictionaries, but I'm hoping it fixes a problem reported by a
user of the large German dictionary that seems to involve allocation.
If I'm reading correctly, as long as I stay within 16M (24M or more on
newer devices) I'm sure to get my memory in the java world while it's
less a sure thing in the JNI world (where in addition linux's
aggressive overallocation is used, meaning I'll fail when I try to
swap in memory on write rather than get back NULL from malloc.)
bytes to read from downloaded dictionary file -- because available()
will not always return the full size. I suspect this is why a German
user is crashing when using the very large 2_15 German dict.
