Motiviation was to be able to deliver a message in the background, but
at least for now it's easier not to close games again. Can always do
that later if it's a memory problem.
I'm wrestling with how to have concurrent tabs open. They can't be on
the same game because both can't connect using same MQTT dev id (and
they'd quickly get the saved state screwed up.) Only problem is
sometimes a tab in a new window doesn't have access to localstorage and
so is able to connect on its own. But later that state isn't reachable
any more: relaunch firefox and you get back the to the older state.
Recent change added Delete button to game-over alert, but only when no
unacked messages remained (since deleted games can't continue trying to
send messages other games might still need to know the game's over.)
Typically the alert would go up and then, if the remote device is
online, shortly after acks would arrive. Now when that happens the alert
gets updated to offer to delete and archive.
There's code on all platforms to force user to have dict prior to
opening a game or responding to an invitation. "Empty" dict play hasn't
made sense in a long time.
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.
Scroller is allowed only one child and I guess I wanted the TableLayout
to suffice, but having unrelated stuff in it sucked. So wrap it in a
LinearLayout and move the unrelated stuff out.
commit f68186cafb
Author: Bernard Massot <bmassot@free.fr>
Date: Sun Feb 21 19:22:45 2021 +0000
Translated using Weblate (French)
Currently translated at 99.4% (883 of 888 strings)
commit fabc29dfef
Author: Bernard Massot <bmassot@free.fr>
Date: Sun Feb 21 18:25:36 2021 +0000
Translated using Weblate (French)
Currently translated at 99.3% (882 of 888 strings)
commit b26f383d32
Author: Hosted Weblate <hosted@weblate.org>
Date: Sun Feb 21 19:09:29 2021 +0100
Update translation files
Updated by "Cleanup translation files" hook in Weblate.
Translation: Crosswords/Android
Translate-URL: https://hosted.weblate.org/projects/xwords/android/
I want to encourage people not to think there's action to be taken
between when they invite and an invitee responds, e.g. to email. So make
the "Close Game" button the "positive" one that case.
I balked at writing code consisting of a bunch of classes there only to
provide a mapping to resource file IDs, instead opting to generate them.
(The right move might have been to generate everything from the old
xwprefs.xml, but it's too late for that. :-)
I realized I'd made some mistakes and so rebuilt them from the old
xwprefs.xml file. Didn't find any new mistakes, but there are fewer
unnecessary changes so the release-to-release diff should make more
sense.
commit 8e985b09a7
Author: Bernard Massot <bmassot@free.fr>
Date: Wed Feb 17 22:47:17 2021 +0000
Translated using Weblate (French)
Currently translated at 99.3% (883 of 889 strings)
We've decided that on upgrade users shouldn't be surprised by a busy
board and unaware of how to fix it. So keep it the way it's been and let
the curious discover the new ability. Also, simplify code.
commit 3176272c43
Author: Muha Aliss <muhaaliss@pm.me>
Date: Tue Feb 9 17:56:50 2021 +0000
Translated using Weblate (Turkish)
Currently translated at 4.2% (38 of 887 strings)
commit 5579eae91d
Author: Bernard Massot <bmassot@free.fr>
Date: Thu Feb 11 21:27:37 2021 +0000
Translated using Weblate (French)
Currently translated at 99.2% (880 of 887 strings)
This is an experiment. I suspect the eventual fix will be to have two
modes, one of which draws the values and the other doesn't, replacing
the TILES/VALUES pref.
Use the current recommended classes and organization of app
settings. Means breaking xwprefs.xml into eight or so files and a bunch
of changes to classes derived from Preference. Seems to work, but there
will be bugs. Also got rid of most Activity subclasses that were
alternatives to Fragments, since all Android versions I'm allowed to
support now support Fragments.
commit 663c0c3395
Author: Wellington Terumi Uemura <wellingtonuemura@gmail.com>
Date: Sat Jan 23 16:22:50 2021 +0000
Translated using Weblate (Portuguese (Brazil))
Currently translated at 100.0% (887 of 887 strings)
commit d255dc7758
Author: Allan Nordhøy <epost@anotheragency.no>
Date: Sun Jan 17 18:26:54 2021 +0000
Translated using Weblate (Norwegian Bokmål)
Currently translated at 69.3% (619 of 892 strings)
commit 542af0a287
Author: Allan Nordhøy <epost@anotheragency.no>
Date: Sun Jan 17 18:27:24 2021 +0000
Translated using Weblate (English)
Currently translated at 100.0% (892 of 892 strings)
commit 8ced0990d0
Author: Luca De Filippo <luca.defilippo@translationcommons.org>
Date: Thu Jan 14 15:41:05 2021 +0000
Translated using Weblate (Italian)
Currently translated at 96.3% (859 of 892 strings)
commit 8ced0990d0
Author: Luca De Filippo <luca.defilippo@translationcommons.org>
Date: Thu Jan 14 15:41:05 2021 +0000
Translated using Weblate (Italian)
Currently translated at 96.3% (859 of 892 strings)
Returning null from createDialog() isn't allowed, so return this as a
fallback as before. But the old code immediately dismissed it and
created another in an infinite loop. So just suck it up and display it.
And as always hope users don't see it.
commit ef81d3ce08
Author: joaooliva <joaooliva@protonmail.com>
Date: Sun Jan 3 18:15:16 2021 +0000
Translated using Weblate (Portuguese (Brazil))
Currently translated at 97.1% (867 of 892 strings)
Author: joaooliva <joaooliva@protonmail.com>
Date: Sun Jan 3 03:54:00 2021 +0000
Translated using Weblate (Portuguese (Brazil))
Currently translated at 88.4% (784 of 886 strings)
Author: Luca De Filippo <luca.defilippo@translationcommons.org>
Date: Mon Dec 14 15:04:16 2020 +0000
Translated using Weblate (Italian)
Currently translated at 2.8% (25 of 883 strings)
Fix -- I think -- problem where game-deleted message received but not
handled by ChatDelegate would loop forever. Fix is to let non-visible
fragments take a shot, the BoardDelegate in this case. Seems to work,
but wasn't 100% reproducible AND the fix may break something else.
For some reason, in Spanish but not Catalan, filtering doesn't work with
two-letter tiles. The reason is that e.g. with RR two patterns, R.R and
RR (i.e. two R tiles, or one RR tile), are returned. The first shouldn't
be there since there are no words with RR that are spelled with two R
tiles. Until I can fix this picking the second (last) pattern seems to
work better.
If I can't figure out how to register for .xwd files, next best idea is
to encode a download in a custom url. This is one way of doing that, and
works with the urls just added to BYOD. Will likely change.
Known Players is a feature I'm devloping and right now want to keep it
capitalized as players learn what it is. It's only in debug builds at
the moment anyway.
Catch the onCancelled event, and treat as "close" button tap. Also
disable cancel via taps outside the alert, which I think is less
confusing than leaving the unplayable game up without the alert or
closing it without explanation.
BoardDelegate can have a one-to-one relationship to this thing, and
occasional leakage was preventing opening a new alert, so some fix was
needed. This one's simple.
Because I'm doing a singleton thing, if I miss the alert going away I
won't up another up. This tries to always catch dismissal. Might still
be screwed if it's not actually put up for some reason. Needs testing.
Try using both secure and insecure sockets. The latter appears to cause
fewer problems on OS/device combos with crappy BT. It's only possible if
I know the addr of the device I want to, so hack around that being
secret by passing it on request.
If inviting known players to a more-than-two-player game, can select all
at once. Required using checkboxes instead of radiobuttons for the case
where nMissing > 1.
Create new class that owns the alert. Let it decide whether to post,
remove, etc. Seems to work, but I've removed some of the "reinvite"
options I'm not sure were helpful anyway. To be considered...
When thumbnail was required but couldn't be produced list item showed up
tiny as height followed thumbnail's. Instead, when there's no thumbnail
behave as if it's disabled, a layout that looks ok.
There are ways I can't record a close, e.g. user swiping app to kill
it. To avoid that leading to a corrupt-game warning, or to failure to
open in background, drop the count to 0 rather then merely decrementing
it when it closes correctly. Assumption is that if it closes ok once
it's ok.
Invitations over MQTT were handled by different code that always opened
the new game on top of any other open one. Use instead existing code
that puts up a notification instead where appropriate.
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.
This won't impact shipping code, but if during development I add then
remove a new INVITEMEANS I can crash with AIOOB trying to load by
ordinal. So check first.
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.
Add a single method to provide candidate devices; don't bother passing
bogus BT MAC addrs; let instance belonging to background-user start
communicating again when user becomes foreground.
I was comparing the wrong strings and so broke deleting known BT
devices. And wanted to see how often since I'd seen them updated, though
every 10 seconds is still 10 seconds.
Some devices unpair themselves and needed to stop being listed so user'd
know to fix. And my Nexus 5x is neither a PHONE nor a COMPUTER per BT,
so accept a larger range of BT classes when scanning.
Working around a bug in Android 11 that broke invitation http urls
getting passed to CrossWords. They always launch the backstop script on
eehouse.org. So modify that script to include a link that will pass the
invitation params to CrossWords via a proprietary scheme it already
registers for. No change to app required!
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.
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.
Change copy-strings.py to insist that no language provide a format
string not also found in English (since parameters to match all English
format string are sure to exist, but other languages are free NOT to
match them.) It's ok for other languages to provide "few", for example,
when English doesn't.
For some reason I wasn't unless it was the current instance, meaning
that some would leak and forever be connecting and disconnecting as
failures were in effect ignored.
Moving logic into the timer itself. There's always meant to be one
running, set from between 10 seconds and 23 hours from now. Code
receiving messages (mqtt or relay) resets the backoff when a message is
received, so when there's activity the timer should stay short. Somebody
with no games at all will have attempts made to connect to the relay and
mosquitto once/day, which is when invitations via that method would be
received. Devices with FCM should see lower latency of course.
Didn't handle the case where a game included NFC or BT. I should
probably be stripping those on receipt as I think the android side does
when the devices doesn't support 'em. And that in turn should be common/
code. So just fix it for now so testing can continue.
There were ways of leaving multiple instances running, I think fighting
for resources and keeping each other from connecting. Now I think there
can only be one. And lots of logging will help find future problems.
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.
Strictly speaking I think a subset is ok. I need to fix my build scripts
OR figure out how to enable the checking Weblate claims to have. The
string I modified is isn't used AFAIK so it's not urgent.
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.
For some reason the header and dawg data in Spanish wordlist don't
agree. Until I fix this, remove the assertion from the (dev-use-only)
script that dumps wordlist since it breaks it for other uses.
Find-prefix feature in current code crashes on Hungarian because it
allows duplicates (words that occur spelled with the same letters but
different tile combinations.) Modify Makefile to exclude those (as it
does for all other multi-letter-tile languages). And to pull the git
source of the wordlist on demand.
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.
For Hungarian, there are "duplicate" words because e.g. the string CS
can be spelled with two tiles or one. If a delimiter is printed at tile
boundaries the duplication goes away.
Add Makefile filters to create a wordlist with about 42K words derived
from a github project (thanks to pointers from an informant. :-) Per
him, and contrary to how Catalan does it, double-letter-tile words
also appear in single-letter variants if the tiles allow.
Duplicate games get lots of crashes when mixed with phonies code. Will
need to fix that before enabling duplicate mode. In general there are
lots of assertion failures mixing trades and undos and phonies and
running dozens of games at once. I don't think that's new so will ship
now and fix later.
Turns out the host, when inviting a remote device, needs to know how
many players are on it (since more than one is supported and the script
currently generates that case.) So pass to --server devices an array,
one per remote -- but don't bother when all entries are "1";
Bad programmer. And because the raw bytes form was so large it always
caused the fake sms stuff to send immediately rather than waiting for a
timer to expire -- which never happened when run by the test script. So
I'm not allowing any timer for invitation-sends only.
(Another problem is that there's no mechanism in the xplat code to retry
invitation sends. That needs fixing.)
If slow network traffic has given a guest time to move tiles to the
board while the host decides its last move must be rejected, those tiles
must be removed before the rejected turn can be undone.
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.
When a guest sends a move to the server it's not the next player's turn
until the server checks the move and rejects or accepts it. It was
possible still to manipulate the board, playing new tiles, and even to
attempt to commit them. And if the move came back rejected, the bogus
committed one would be that was cleared. Bad. So I'm just setting the
turn to -1, which disables board etc., and letting nextTurn() assigne it
after the confirmation comes back.
On each open, increment a counter. And if we're able to close without a
crash intervening, decrement. Once we're trying to open with a non-0
counter we have a bad game. Open only after warning the user.
Yikes. I used to assert, in nextTurn(), that you were in the right
state. On release builds that went away, and you were moved into the
right state regardless. The bug happened when I changed that to exit
nextTurn() without changing the state, meaning that for PHONIES_DISALLOW
the host filled up its message queue trying to communicate that the
latest move was ok, never getting out of the state that required sending
that message. The fix is simply to change the state after sending and,
guest-side, after receiving, that message.
The lock was leaking when sometimes the OS would call onStop() without
isFinishing() being true, then never use the fragment again. And never
call onDestroy(). Releasing the lock in onStop and regetting it in
onResume seems to fix, but this needs some testing and time.
The problem appears to be that the new <vector/> .xml drawable has a
greater height for purposes of layout. Specifying dimensions seems to be
the way to go, though devices may vary.
I don't know why, but in my tests the relay seems to be delivering
messages to the wrong device. The linux device detects this. It used to
assert, but now just drops the message. If this is happening on Android
it might be why I'm seeing crashes...
The problem appears to be that the new <vector/> .xml drawable has a
greater height for purposes of layout. Specifying dimensions seems to be
the way to go, though devices may vary.
reverse change in 19fa3fce05 (April 4
2019) making MainActivity singleTask, which caused starting the app to
launch the gamesList screen rather than the game that had been open when
it was moved to background. Now it's "standard," and I have to hope that
doesn't produce new problems. As I wrote back then, we'll see. More
quickly I hope.
Required redoing how I invoke the NDK. The limititations I had to hack
around before seem fixed, so this is probably better. But there will be
glitches. :-)
The common code truncates to 255 *bytes*, not chars, so this isn't even
right, but at least for ascii users it'll make it less likely that
what's typed doesn't all get sent. The right fix is to change the format
to not limit sent str len to 255 bytes. See commit 512a8e1af.
Len byte was limited to 255, but would get clipped (masked with 0xFF)
then all the string data would get written. So on receipt, the clipped
length was taken to be that of the string data, with the rest of the
string to be interpreted as something else. An array index, in this
case.
The common code truncates to 255 *bytes*, not chars, so this isn't even
right, but at least for ascii users it'll make it less likely that
what's typed doesn't all get sent. The right fix is to change the format
to not limit sent str len to 255 bytes. See commit 512a8e1af.
Len byte was limited to 255, but would get clipped (masked with 0xFF)
then all the string data would get written. So on receipt, the clipped
length was taken to be that of the string data, with the rest of the
string to be interpreted as something else. An array index, in this
case.
