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.
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.
more dev-only code, likely: if the game that's sending the invitation is
open when the invitation arrives, should still check if it's a dupe or
should be accepted.
Was creating a second game in some cases in response to duplicated
invitations. Add a test for forceChannel: if there's already a game with
the same gameID *and* forceChannel assume the invitation is a dupe and
drop it.
So I don't have to open a game to see e.g. how it's connecting, refactor
the network status stuff so it can be called from both board and
gameslist views. Then add new context menuitem that calls it.
Instead, keep them forever (for now), sorted by how long since they were
last seen. A Delete button's probably needed to prevent ex-partners from
sticking around too long. :-)
Adding a second permission a while back resulted in two Actions being
received and acted on. Needed instead to group the two and receive a
single Action IFF both were granted.
Put up an error message if too many tiles selected for trade
(a condition that couldn't exist when the pool was guaranteed to
have at least 7 in it.) (It's a hack: there's not even an enum
giving Spanish's code, and the lang_locale stuff in info.txt isn't
making it into the .xwd format.)
I've learned a bit about java since writing that class. Should be faster
now without the sleep/polling. Also making it illegal to use blocking
lock() call on UI thread. There may be some assertions to fix in the
next few days.
Was seeing race condition on slowest device where JNIThread init hadn't
finished before the event loop tried to use the gamePtr. So use
wait()/notifyAll() to fix.
And: Don't start the foreground service with its user-visible
notification, as that's too obtrusive and the ACL_CONNECTED stuff seems
to work well enough. Launching timers on a new install is mostly for my
own dev use, but won't hurt user experience either.
On O and beyond it's possible to tweak notification channels separately,
meaning users can hide the new BT-is-running notification and still get
game event notifications. So add a button that takes you to the right
Settings app page.
Separate processing of sockets from accepting them so that when an ACL
CONN notification is received and we open a socket (but don't yet have a
Service running because the ACL thing is most likely for some other app)
we can set it aside to be processed once we do have a service. Use the
same block-until-non-null thing as in RelayService to keep that thread
free of NPEs.
Rather than just dropping it and going back to a wait that will likely
last forever. I *think* wait() throwing that exception means the
thread's being killed, in which case the exception should be thrown up
to the containing loop that will then exit.
I thought I had to stop using a service instance before returning from
its onDestroy(), but that made the UI incredibly laggy AND appears not
to be necessary. At least in a bit of testing things still work.
Oreo's creating a new service instance for every single intent passed to
enqueueWork, meaning a brand new set of threads with a new queue, empty
set of messages to be retried, etc. was created every time, and all
attempts to optimize and retry were broken. So: make the threads a
static singleton that are given a Service instance from onCreate() and
told to drop it from onDestroy(). The threads proceed until they need an
instance, then block until one's available. Seems to work on Oreo and an
older Android as well.
Apparently one of the newer Android SDK levels adds the requirement to
have RECEIVE_SMS permission in order for a broadcast receiver to get
called. Meaning receipt didn't work even if SEND_SMS had been
granted. Since they're both in the same group (for now) the OS will
grant the second silently if the first has been granted, but it still
has to be requested. So request both at the same time. This still leaves
the problem that a user who's never tried to create an SMS game won't
have been asked for either permission and so won't receive SMS
invitations, but fixing that is for a later release.
Other code will take care of duplicates. This was meant to avoid a race
condition, for which 5 seconds is enough. Blocking forever complicates
testing.
Receiver is created and installed by a non-UI thread sometimes so can't
create the Handler there. onReceive() is called on an ok thread however
so create it there on demand. Fixes crash that showed when receiving
relay messages in background.
Fire up the receiver thread, and start the service, on receipt of this
ACTION (if they're not already running.) On start, the service takes
over the thread and begins dispatching messages. Works to launch the app
when it's not running and in most cases, though messages received before
the service launches are currently dropped, things seem to work.
reset timer on receiving meaningful data and on moving app to
background. If it fires and we're in background, kill the service.
(There's currently no way to restart it except bringing the app into the
foreground. Fixing that's coming.)
Moving toward a better BT invite experience: use BTService to scan for
ourselves on all paired devices, and only allow selecting from among
those on which we're running (and so likely to respond to an
invitation.)
It's a pain to have to change code to run in Genymotion, and to have
upgrade not testable using Genymotion. Consider verting this change
before next release.
