This should complete sending to multiple topics (for backwards
compatibility) and supporting combined messages in the future (sending
them is hard; receiving not so much.)
I didn't understand MQTT at all. Per the docs anyway it only keeps a
message around if its "persist" flag is set, and then it only keeps
the most recent per topic. I expected that when a device connected,
messages would be waiting for it, but that's apparently not true (some
evidence to the contrary.) But having all games on a device share the
same topic means only one message can be waiting. So switch to
including gameID in the topic, subscribing to a wildcard topic and
sending to a different one per game. For now, for legacy purposes,
we'll keep sending to the old per-device topic.
Add dutil proc haveGame() and use it to detect duplicate
invitations. I'm passing, but ignoring on android, the channel, which
means that for now you can't invite yourself and on-device testing
requires having CrossWords and CrossDbg or a second user.
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.
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.
Now we use only ISOCode string internally to identify languages, and
since that's universal it can be built into an wordlist and used
without the build of CrossWords knowing about that language
specifically (though it'll have to know about it to have the language
name be localizable.) For legacy support, though, the old int codes
are transmitted in invitations and URLs IFF available, otherwise the
string's used. If a newer build invites and older build to play in a
too-new language there will be trouble.
