There's likely a bug in Android now where I'm registering over and
over though the fcm id hasn't been changed. That's wrong, but it's
also wrong (and filling up the db) to register a duplicate as if it
were new. So stop that.
My VSIZE is no longer legal, and apparently there's no workaround (no
way to safely figure the length of an array whose size is known at
compile time.) To avoid the risk of duplicating little constants, added
macros that define length in a way a new VSIZE can pick it up. Couldn't
make that work for struct field arrays, however, so there I'm using
constants.
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.
