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.
