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.
When I've invited a Known Player, use that player's name in parens in
scoreboard and games list elem/summary until a remote device connects
(usually in response to an invitation) and provides an actual player
name. Makes it much easier to tell one pending game from another. And
doesn't really work (yet) where there's more than one remote player in
a game.
The old API required passing dict into game creation/loading. New
doesn't, but in some places I was doing other stuff there (like checking
existance), so can't remove there. Still code goes away.
Once in the archive games don't ever send unless opened explicitly (no
resend-all-on-gained-network stuff for them). So don't offer to put a
game there if it has unsent (unacked) messages. Should prevent problem
of a host being archived before it's managed to send its final move to
all guests.
It's simpler this way, and I'm tired of stuff not happening because the
OS chooses not to schedule e.g. an invitation send for minutes. Goal's
to be running BluetoothServerSocket.accept() as much as possible when
there are active BT games in play OR when the game's in the foreground.
If that's happening, sent invitations and moves will be received when
users expect. When there's no traffic and app isn't being brought to
foreground, backoff will ensure I don't try to run accept() too often.
FWIW, BTLE seems to offer a better way to do this (to have an app be
responsive to incoming invitations when it hasn't run in the foreground
in a while), but it requires users to accept FINE_LOCATION
permission. I'm hoping I can make this work to avoid asking for that
permission.
Not at all tested, but now the game's timestamp is kept and passed in to
where it can be used to determine, e.g., which of two Bluetooth device
names to keep for a given opponent.
I have a case where app crashed on launch due to the assert that resend_all()
wasn't being called on a standalone game. That happened because somehow
the game's android-side db entry showed pending packets to send, though the
game type was correct. Fix is to check for game type also, but also to add
a test so comms won't get invoked with a null ptr on release builds.
Thanks to my use of unseeded() rand() early on to generate mqtt device
IDs, a handful of devices are using the same devIDs. The server notices
this and passes a new response which triggers generating a new id that
should be unique (rand() being seeded earlier now.) Testing says the
games that are left behind with the old devid will limp along thanks to
their relay connection while newer games will be better.
I'm fixing android client not showing stats for or allowing to disable
mqtt after it's added automatically to a game that connects
otherwise. Problem was that only the channel got the mqtt address
flag. So now add the flag for any type that's added.
Noticed the same emulator would always generate the same MQTT id, even
after a factory reset. That's because I was seeding rand() in that
jni *game* init code, not the (called-earlier) init of the whole jni
world. MQTT id generation happens on app launch before any game can be
opened so was using an unseeded rand().
Supid bug generating keys from __FILE__ meant each release
build (usually done in /tmp/$$, or on a travis server) had a new key and
generated a new MQTT devID (and other stuff less frequently used.)
Replace the keys with something that won't change, and as a temporary
fix so the upgrade including this fix doesn't generate new keys use the
most recent stored key matching the suffix the old keys will have had in
common.
If a configured-as-host game joined an existing game the relay would
make it a guest. The android util_ callback for that change was only
implemented in BoardDelegate and so the change was dropped unless the
game was open/visible. Because comms recorded the change, though, the
callback would never be called again and so the game never learned to
behave as a guest and never registered: permanent failure to join game!
Implemented with a new server state so initClientConnection can be
called from server_do() instead of inside comms while processing an
incoming packet.
Add a basic regular expression engine to the dictiter, and to the UI add
the ability to filter for "starts with", "contains" and "ends with",
which translate into ANDed RE_*, _*RE_* and _*RE, respectively (with
_ standing for blank/wildcard). The engine's tightly integrated with the
next/prevWord() functions for greatest possible speed, but unless
there's no pattern does slow things down a bit (especially when "ENDS
WITH" is used.) The full engine is not exposed (users can't provide raw
REs), and while the parser will accept nesting (e.g. ([AB]_*[CD]){2,5}
to mean words from 2-5 tiles long starting with A or B and ending with C
or D) the engine can't handle it. Which is why filtering for word length
is handled separately from REs (but also tightly integrated.)
Users can enter strings that don't map to tiles. They now get an
error. It made sense for the error alert to have a "Show tiles"
button, so there's now a dialog listing all the tiles in a wordlist,
something the browser has needed all along.
This is meant to replace the relay eventually, but for now it's a new
option, like BT or SMS, to be chosen. Protocol is handled in common/
code for the first time, meaning that linux and android interact without
the need to keep two platforms in sync. Linux uses lib-mosquitto, and
Android uses eclipse's Paho client (the generic java version, not the
one that uses four-year-old Service patterns and so crashes for SDK >=
26.)
Hungarian is unique (so far) in having two-letter tiles that can be
spelled with one-letter tiles AND in allowing words to be spelled both
ways. This crashed search based on strings because there were
duplicates. So now search is done by tile arrays. Strings are first
converted, and then IFF there is more than one tile array result AND the
wordlist has the new flag indicating that duplicates are possible, THEN
the user is asked to choose among the possible tile spellings of the
search string.
Linux and Android duplicated all the code to parse a wordlist file --
and shared a bug that needed fixing. So now most of that is in a common/
function both call, and the bug -- failing to mask out flag bits I don't
care about -- is fixed.
I'm getting crashes and don't want to think about it. It may be time to
remove this, though it's needed for logging-storage to work from jni.
To be revisited....
Separated the refcounting and ptr-as-long wrapping aspects of GamePtr
into a superclass that others might later inherit from. Cleaned up
dict_iter entrypoints, and added sanity checks to both structs so I'll
quickly notice if I get the ptr management wrong.
Fixing a problem with languages (like Hungarian) where it's legal to use
a two-letter tile or two single-letter tiles to play the same word. When
words are seen, or searched for, as char-arrays, there are
duplicates. Current code crashes, but there's also risk the user gets
unexpected behavior. Crash is fixed, and foundation laid for better UX,
by doing all searches for tile arrays. If a search string translates to
more than one tile array the user must choose. For that choice to make
sense it's now possible to translate tile[] to char[] with a delimiter
between the tile strings.
I'm keeping it AND asserting at every possible location that the env
passed all the way in is the same as what the mapping produces. If in
months I haven't seen a single crash then I can evaluate which way of
passing the env around is better. (It'd be code size vs. performance,
as the passing of env is noticably faster. Code size could be fixed by
turning 'XWEnv xwe,' into a macro that goes away on some builds.)
I was getting an occasional crash using a stale env to delete a dict's
resources because the dict was cacheing the env that created it. Dumb!
Using the thread->env mapping stuff worked, but that felt risky and so I
tried just passing it in. It's safe, and involves an amount of change I
can tolerate. So likely going that way.
With reject-phonies set this will trigger the reject path.
Also init CommonPrefs in jni land since its makePhonyPct, left unitialized,
causes the robot to deliberately reverse every turn, firing an assertion that the
robot's moves are legal.
Currently detects the same as tiles not in a line and calls out to a new
util method that's currently parameter-less. On Android the option only
appears in d variants.
