The last change meant the test whether to show the words under the
pen-down cell would pass when it shouldn't because a drag to an occupied
location didn't register as movement. Change so movement counts to stop
the timer even if it wouldn't change the drag-target's location.
Rather than have a tile revert to its original location if it's dropped
where it can't be (on an occupied tile or outside the board), put it in
the last place it could have been. Do that by only updating cur when
it's to a legal location, and then relocating to cur when drag ends.
If you've bypassed the quick-start game it's probably because you want
to play somebody not yet in the Known Players list. So don't start out
with that list as how you'll invite.
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.
Got as far as having gtk client display list of previously harvested
known players to be invited. Their addresses, or at least mqtt ids are
saved. Next is to actually invite one.
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.
At least one device was mysteriously losing games. They were winding up
with a group ID for a non-existant group. Now on startup I look for such
games and assign them to a new "recovered games" group. We'll see how
common this is before deciding whether it's a good enough
solution. Another perhaps better solution would be to display all games,
ordered by groups, rather than displaying all known groups and their
games.
On a small-screen (?) emulator (Nexus 5 1080x1920) the icons in the
new-game alerts are huge. Setting their size to 32x32 instead of 120x120
seems to fix this. Haven't tested on more than two devices, on one of
which they were ok before and still are.
Doing away with letting user build a local phone list (left over from
the NBS case where it made sense.) Just launch the default SMS app with
the message and let 'em choose a recipient. Hard to test, but works on
two of two phones so far.
It's coming up too often, sometimes several times in a row so that all
must be dismissed. Until I can detect which result from explicit user
action (tapping a URL) rather than duplicated delivery over MQTT and
bluetooth, this is better.
I'm using model names to detect duplicates, but there are enough that
may not suffice. So add a new random per-device ID to be used only until
the dupes are resolved.
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.
Not sure this even belongs here, but that decision will wait until BYOD
is online and I have to figure out how people will distribute custom
wordlists.
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.
Don't wait for user to tap one of the buttons. Instead notice when
scrolling becomes possible, and offer once per launch until user says
"hide" or clicks the don't-ask-again box.
Invitations will now only allow opening the game (Dbg or not) that
created them. Should prevent bogus warnings that games have been
deleted. Impacts only developers and friends running CrossDbg and
CrossWords on the same device. Can still get games going between the two
using room names or invite-by-devid.
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 you're using a monster font and have the keyboard up you might not be
able to touch the "apply filter" button without dismissing the
keyboard. (Hi Deb :.) So make it possible to scroll it into view. Won't
ever become scrollable for most people, and seems to play well with the
scrolling wordlist regardless.
Do away with debug setting to accept duplicate invitations. Change
definition of duplicate to mean specifying a channel and gameID that
already exist. So now send-to-self works without a debug
preference. Accidentally clicking on the same emailed invite twice will
still be blocked. There will be problems if a game's been deleted but
those have probably always been here.
There was a way to get to the sender before its handler had been
initialized. That can only happen on UI thread, so just drop the send
rather than figure out a better way (for now).
As happened with expander arrows on the right when I turned on fast
scrolling, the on-left-side scrollbar was preventing selecting rows when
there were enough list elements for fast scrolling to be enabled. So use
a listener to turn it on only after the user starts to scroll. And move the
bar back to the right side since that's where people expect it.
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.
To avoid inviteless relay games not having an mqtt channel (and so
yielding a crappy experience) pass the mqtt devid when device registers
and when server replies with all-here.
Some relay bug (I think) misroutes or duplicates packets. Don't assert
as that means test scripts fail to finish. Instead drop the
message. Scripts seem to recover ok with this change and I've never seen
the assert on a device so suspect it's test-world only
Recent changes in how nli address sets were stored led to rejecting
incoming invitations when BT had been removed (e.g. on emulator) because
I didn't notice the removal when validating.
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.
The Maven repo that includes the (FOSS) client library for MQTT isn't
approved by the f-droid build system, so for now rip MQTT out of that
variant. Long-term I'll have to fix this, either by persuading the
f-droid folk to permit the library or by building the C client from
source in my jni library -- or when the relay goes away the f-droid
build will cease to offer internet play.
I was really after the situation where a game could never be
opened. There are lots of reasons a single failure can occur, not least
of which is installing via adb while game's open. :-)
It looks bad, especially to a new user we suspect. Also add retries,
hoping that whatever caused the thumbnail to fail to load once will not
happen again.
Get rid of subclasses, since there's not the clear inheritance structure
I imagined. Any dialog type might want a not-again checkbox, or to have a
third button offer an unexpected option. This is a big change that needs
some bake time.
The Maven repo that includes the (FOSS) client library for MQTT isn't
approved by the f-droid build system, so for now rip MQTT out of that
variant. Long-term I'll have to fix this, either by persuading the
f-droid folk to permit the library or by building the C client from
source in my jni library -- or when the relay goes away the f-droid
build will cease to offer internet play.
I was really after the situation where a game could never be
opened. There are lots of reasons a single failure can occur, not least
of which is installing via adb while game's open. :-)
It looks bad, especially to a new user we suspect. Also add retries,
hoping that whatever caused the thumbnail to fail to load once will not
happen again.
