GameListItem was clearing its summary when kicking off a replacement
load. Instead keep the old around in case somebody wants it (e.g. to
figure out what menus to enable) until the reload finishes.
Also add logging of how long loading takes. I think a cache might be
called for.
Darned thing was dropping packets, failing to connect games built in
response to invitations, and otherwise misbehaving. First was due to not
resheduling when exited with outbound packets in queue; second to not
overriding relayNoConnProc() (due to signature change.) Though it still
happens occasionally.... Also added timestamps to track how long it
takes a packet to be sent and ACK'd.
It's too useful to live without. So: tap into the static list of live
Delegates, and if any of them has an Activity available use it to run
Toast on UI thread. Otherwise there will be no display.
Looks like certain launches that went through DispatchNotify could
create a second "instance" of the app. Giving that Activity a launchMode
of singleTask fixes this (singleTop does not.)
Launching a game in response to a wordlist it needing being downloaded
went through a different Intent-creation path from the rest, and
resulted in a second instance of the app showing in the launcher. This
shoudl fix that. I don't *think* it's the only way I'm getting second
instances or stacked GamesLists, but it should get fixed.
I modified existing translated strings, adding the new clause. Not doing
that would cause the existing strings to be stripped because they'd no
longer have the matching set of format specifiers.
Fix a race condition introduced by making initing jnithread be
asynchronous: all the layout that was supposed to happen after listeners
were added instead happened before, so that they weren't there to be
installed as part of layout. So now, after adding them, get them hooked
up to the UI. (The complexity of this is all historical: at some point
the listeners were getting added BEFORE there were views to attach them
to, so they were cached and added later. Probably now they could simply
be installed as part of adding them. But I'm not doing that now.)
Was seeing frequent failure to open games as JNIThread.getRetained() was
unable to get a lock without waiting. Which it can't do on UI thread. So
added a method to GameLock that takes a callback to be called when the
lock's obtained, with the actual waiting done on a local thread. Then
fixed BoardDelegate a bit to not crash while waiting for the callback.
Once built for SDK 26 the old GCM support code crashes as it's calling
startService() from background. Duh! Will have to bring in Firebase's
replacement at some point. For now if I'm to release it has to be
without GCM.
