It's simpler this way, and I'm tired of stuff not happening because the
OS chooses not to schedule e.g. an invitation send for minutes. Goal's
to be running BluetoothServerSocket.accept() as much as possible when
there are active BT games in play OR when the game's in the foreground.
If that's happening, sent invitations and moves will be received when
users expect. When there's no traffic and app isn't being brought to
foreground, backoff will ensure I don't try to run accept() too often.
FWIW, BTLE seems to offer a better way to do this (to have an app be
responsive to incoming invitations when it hasn't run in the foreground
in a while), but it requires users to accept FINE_LOCATION
permission. I'm hoping I can make this work to avoid asking for that
permission.
Add a single method to provide candidate devices; don't bother passing
bogus BT MAC addrs; let instance belonging to background-user start
communicating again when user becomes foreground.
I was comparing the wrong strings and so broke deleting known BT
devices. And wanted to see how often since I'd seen them updated, though
every 10 seconds is still 10 seconds.
Some devices unpair themselves and needed to stop being listed so user'd
know to fix. And my Nexus 5x is neither a PHONE nor a COMPUTER per BT,
so accept a larger range of BT classes when scanning.
Working around a bug in Android 11 that broke invitation http urls
getting passed to CrossWords. They always launch the backstop script on
eehouse.org. So modify that script to include a link that will pass the
invitation params to CrossWords via a proprietary scheme it already
registers for. No change to app required!
If you've bypassed the quick-start game it's probably because you want
to play somebody not yet in the Known Players list. So don't start out
with that list as how you'll invite.
Not at all tested, but now the game's timestamp is kept and passed in to
where it can be used to determine, e.g., which of two Bluetooth device
names to keep for a given opponent.
I have a case where app crashed on launch due to the assert that resend_all()
wasn't being called on a standalone game. That happened because somehow
the game's android-side db entry showed pending packets to send, though the
game type was correct. Fix is to check for game type also, but also to add
a test so comms won't get invoked with a null ptr on release builds.
