Was passing through DlgState params a number of classes that weren't
serializable or that didn't have equals() methods required for DEBUG
assertions to pass. Added versions of equals() that just call super in
non-DEBUG case since it's a lot of code and isn't required except for
testing. (Serialization of course is.)
Now that params[] are being bundled all objects passed that way must be
serializeable. And as long as I'm asserting bundle success using
equals() the objects being serialized must implement it.
I wasn't saving/restoring params[] Object array with DlgState, and under
circumstances I can't reproduce that could cause a null object
dereference I was via the Play store. So added a test case that failed
for DlgState instances that have non-null params arrays, and fixed that.
Attempt to fix invite alert sticking around after game connection
finishes, which resulted from the variable pointing to the alert having
been set to null. So stop setting it in onDismiss listener. I think
trying to track it via an iVar is a mistake, that dismiss by tag or
somesuch is the right way to go. But my dialog fragment code isn't up to
that yet.
Add new Utils methods that turn Serializable objects into B64-encoded
Strings, and vice versa. Use in place of existing code, and use anew to
store the array of DeviceID records. Implement the "Delete checked" button.
In Dbg version only (with enabling boolean moved to BuildConfig.)
Currently crashes when first used, and recipient can't always connect to
relay until app rebooted. And of course there are still open questions
like how to populate the list -- how user learns the deviceID of an
opponent.
Was previously a "global" so that a resend over SMS might delay a resend
for relay games. Since communication problems tend to be
comms-type-specific that's dumb.
Added a wrapper function since for compatibility with the jni's encoding
the flags matter and need to be the same everywhere. Or at least there
should be no chance of their getting changed.
As a first step, use mine and android's and assert results are the
same. Note using built-in Base64 class requires moving the min android
version from 7 to 8.
Copy config file into the right place, turn it on for debug builds, and
fix compile-time complaints by adding -keep clauses. Resulting builds
seem to work (after a few minutes in emulator only) except that net
status icon taps crash at first (eventually recovering somehow) likely
because of problems with base64 en/decoding which goes through jni.
Get rid of black background of center icon, instead running the green or
red all the way to the middle. For better contrast make the green and
red darker and the non-active arrows white.
The debug-only settings for disabling individual conn types weren't
kept in sync with which types were enabled, and that set of types was
lost on rotation. Fixed (including keeping the disableds across rotations.)
I'm seeing assertions when a game gets into a state I don't fully
understand: host receives messages that need a channelNo assigned but
the game's full. With luck they're duplicates and can be ignored,
because that's all I can do.
Since it's now possible to add a name for an SMS contact added manually,
don't assuming a missing name means it was added manually. Just leave
blank if not provided.
I made these changes a while ago then stashed them. They worked when I
needed them then, and seem to work now, but I haven't verified now so
don't trust 'em too far. :-)
Crittercism is dropping free support of FOSS apps, so I'm dropping
it. Unfortunatly integration isn't as clean: so far at least I haven't
figured out how to make it possible for others to build the 'd' variant,
which includes Crashlytics, without their having a Fabric API key.
Resetting it on every ACK etc meant it happened forever at the most
frequent interval, at least on devices that have both sides of a game,
which is my usual test setup.
In game config, when the play game button's hit and the changes pending don't
"matter" (require reset), apply them. The motiviation is to allow
setting the "disableds" and immediately launching a game via the button,
but I think it's the right thing to do anyway. Needs testing.
Deal with occasional droppage of SMS data messages by running a
timer (via AlarmManager) with backoff that resends any pending moves for
games connected via SMS. Successful receipt of SMS data resets the backoff.
When Android client is backgrounded with a game playing (BoardActivity
on top) then brought to front again it fails to reconnect to relay
because it didn't disconnect and the relay thinks it's still there. The
right fix is in making the java code do the right thing (complete
disconnect), but it seems harmless to just honor the reconnect in this
case. Doesn't even cause leaks, per valgrind.
