message over and over when getting updated by GCM. The problem
occurred when one device had an un-ACKable initial message still in
its queue. I call resendAll a lot, which caused that message to get
resent to the other game which then replied without being able to ACK
it so it remained to be sent again. This would continue until users
moved forward in the game. The fix is to add a backoff timer to
resendAll() so that it can't loop. The timer is reset when an ackable
and new message is received, meaning there's been a change in what's
available to resend. And since users calling resendAll manually
expect it to do something, add a force param that ignores the backoff.
seems to fix the problem (but needs a lot of testing.)
dict, give chance to switch, and to download if required. Because of
the way the JNI thread works, and JNI's requirement in general that
env instances match up (e.g. dicts must be destroyed in the same
thread that creates them), substituting into a live game is too hard.
So the game's saved with its new dict and then reloaded.
callback to see if there's already one in the DB. Required passing
context into jniutils getter, and passing name into jni dict
constructors that previously didn't need it.
save what it had ACK'd leaving the game permanently broken. Do that
by adding a new method game_saveSucceeded() called after the client
claims to have committed bytes returned by game_writeToStream() to
disk. In that method comms updates the value it'll use in subseqent
ACKs.
digraph tile when at the end of a prefix so that e.g. GORIL in Catalan
will list GORIL·LA (rather than nothing since GORIL, ending with the L
tile, is not a prefix.)
remote device[s] as part of summary view and in game config screen
(read-only). Use same field in summaries table for remote phone
numbers and bt addresses.
remove use of java base64 encoding in favor of the C version I'd
already written (and that was probably compiled into the library
anyway unless the strip step catched unused code.)
devices in summary DB so, e.g., we can quickly determine what games
care when a devices becomes available via BT. First use of this is
notifying when a remote game's deleted -- least that's the plan. This
commit just adds to the DB and scans the DB to build a map of
device->gameIDs array.
keeping the listener/sender threads going much easier. Create new
message sink to dispatch incoming messages, and start passing return
addresses into comms (not required before when relay was only
transport as it has no return addresses.)
