There was some confusion around host and self addresses, where they're
created, default values, removing conTypes from defaults that are not
in received host addr, etc. I left in some asserts to help understand
if code that seems wrong but hard to fix is still getting called.
Current networking, based on invitations rather than a relay that
plays matchmaker, allows host to know its address when a game is
created, and for guest to know its host's address in
addition. Enforcing this makes inviting and rematching in common
code (coming soon) easier. Big change on Android is I used to create a
new game prior to passing it to GameConfigDelegate, but now I have to
wait for user to configure (including choosing how to communicate)
before I can create it.
Somehow getLangIsoCode() is returning null when called early in app
launch, on some subset of devices the Play Store isn't
identifying. I'm just going to default to "en" when that happens.
I'd removed it when the relay went away, but MQTT apparently doesn't
listen for network changes on its own and so there was no attempt to
resend messages when the device regained connectivity. Now there
is. Old logic to avoid thrashing remains and is not tested with MQTT
-- shouldn't need to be....
Add checkboxes to allow delete or archive action to be scheduled for
after a rematch is done. The UI's a bit awkward. NA tips help,
but it may be possible to make it easier to understand.
The assertion's clearly blocking testing, but I'm not sure it's not an
error for two move explanations to want to co-exist. For now they're
concatenated.
I was getting language name and iso code confused so adding a new type
to keep them separate. Keep string type for crossing JNI boundary and
passing as param e.g. in URLs and Bundles.
I want receiver to know when message was originally created. This adds
timestamp to messages and passes it via send proc. Client needs to
send it where possible. So far, MQTT format can't include it without
change, so I'm adding a new proto version. This change can read the
new version. Once that's well-enough distributed I can start sending
using it. Other transmission types than MQTT are for later.
