Add support for the old protocol, and define to use it. After the next
release has been adopted and everybody can read the new protocol another
release will turn it on.
Fix race condition that would have cleared all messages including those
added after a send began. In the process, move to storing outbound
messages individually rather than concatenated in their stream format.
Set a boolean every time app's upgraded, and clear it on first launch of
MainActivity. In between, if we try to launch the BTService but the OS
doesn't schedule it, post a notification asking user to launch the app.
Lots of changes. Old BT proto is no longer compatible. New one
batches messages per device and sends all on a single connection.
The queue (now a single buffer) is now a static global and the thread
that services it doesn't die (but gloms onto whatever Service instance
is most recent.) Code to pack and unpack the protocol can probably be
reused for wifi-direct or any other pass-through transport.
I'm seeing an assertion failure in cleanup that could be explained by
the cleanup happening when initGame() has been called but no subsequent
jni method that would have added the env to the map. So let's add it
immediately so that can't happen.
JNIThread is somehow sticking around sometimes and holding the lock for
a game so that that game can never be opened again. On the theory that
there's some place retain() was called but not release(), use the thing
in try-with-resources wherever possible. Which is pretty much
everywhere.
Also added age to the lock-holder report being uploaded.
I'm seeing something permanently lock a game so it can't be opened. So
add code to report the stack of the owner to Crashlytics when opening
fails 3 times in a row. It's stubbed out for non-debug builds.
I didn't like having to re-open a game to archive it after
rematching, so now there's a checkbox that lets you archive it after
either rematching OR just using OK to dismiss the alert. Also fixed
rematch of a solo game causing new game to be created in Archive
group if that's where the source game was.
squash me
Got tired of the space the forground-service notification icons were
taking. So now BT sends and receives are done via static threads and
onHandleWork(). The send thread times itself out quickly. The receive
thread doesn't yet. We'll see how long the OS lets it run and what
needs to be done to deal with that.
It's useful when testing to have the remote device play without human
interaction. So add an option, and UI to trigger it, for the players
created remotely in response to an invitation to be robots. There are
guards in place to catch the feature slipping into a release build.
Eliminate the writer thread, since onHandleWork() is already getting
called on a thread and can process the outbound queue itself. And get
rid of reader thread needing to wait for an instance of the RelayService
to be available to process a packet (which was taking 5-10 seconds all
the time): just post received packets via an enqueueWork() call using
the app context that's always available.
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.
Not sure why I was doing this, but it's not worth the
trouble (e.g. stopping updates of other data to fix an android bug
sending too many reregistration messages.) So now just use the first
element of arrays, replacing what's there instead of prepending. Ideally
those columns would not be arrays, but that's a harder change.
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.
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.
