Adding a second permission a while back resulted in two Actions being
received and acted on. Needed instead to group the two and receive a
single Action IFF both were granted.
Put up an error message if too many tiles selected for trade
(a condition that couldn't exist when the pool was guaranteed to
have at least 7 in it.) (It's a hack: there's not even an enum
giving Spanish's code, and the lang_locale stuff in info.txt isn't
making it into the .xwd format.)
I've learned a bit about java since writing that class. Should be faster
now without the sleep/polling. Also making it illegal to use blocking
lock() call on UI thread. There may be some assertions to fix in the
next few days.
Was seeing race condition on slowest device where JNIThread init hadn't
finished before the event loop tried to use the gamePtr. So use
wait()/notifyAll() to fix.
And: Don't start the foreground service with its user-visible
notification, as that's too obtrusive and the ACL_CONNECTED stuff seems
to work well enough. Launching timers on a new install is mostly for my
own dev use, but won't hurt user experience either.
On O and beyond it's possible to tweak notification channels separately,
meaning users can hide the new BT-is-running notification and still get
game event notifications. So add a button that takes you to the right
Settings app page.
Separate processing of sockets from accepting them so that when an ACL
CONN notification is received and we open a socket (but don't yet have a
Service running because the ACL thing is most likely for some other app)
we can set it aside to be processed once we do have a service. Use the
same block-until-non-null thing as in RelayService to keep that thread
free of NPEs.
Rather than just dropping it and going back to a wait that will likely
last forever. I *think* wait() throwing that exception means the
thread's being killed, in which case the exception should be thrown up
to the containing loop that will then exit.
I thought I had to stop using a service instance before returning from
its onDestroy(), but that made the UI incredibly laggy AND appears not
to be necessary. At least in a bit of testing things still work.
Oreo's creating a new service instance for every single intent passed to
enqueueWork, meaning a brand new set of threads with a new queue, empty
set of messages to be retried, etc. was created every time, and all
attempts to optimize and retry were broken. So: make the threads a
static singleton that are given a Service instance from onCreate() and
told to drop it from onDestroy(). The threads proceed until they need an
instance, then block until one's available. Seems to work on Oreo and an
older Android as well.
Apparently one of the newer Android SDK levels adds the requirement to
have RECEIVE_SMS permission in order for a broadcast receiver to get
called. Meaning receipt didn't work even if SEND_SMS had been
granted. Since they're both in the same group (for now) the OS will
grant the second silently if the first has been granted, but it still
has to be requested. So request both at the same time. This still leaves
the problem that a user who's never tried to create an SMS game won't
have been asked for either permission and so won't receive SMS
invitations, but fixing that is for a later release.
Other code will take care of duplicates. This was meant to avoid a race
condition, for which 5 seconds is enough. Blocking forever complicates
testing.
Receiver is created and installed by a non-UI thread sometimes so can't
create the Handler there. onReceive() is called on an ok thread however
so create it there on demand. Fixes crash that showed when receiving
relay messages in background.
Fire up the receiver thread, and start the service, on receipt of this
ACTION (if they're not already running.) On start, the service takes
over the thread and begins dispatching messages. Works to launch the app
when it's not running and in most cases, though messages received before
the service launches are currently dropped, things seem to work.
reset timer on receiving meaningful data and on moving app to
background. If it fires and we're in background, kill the service.
(There's currently no way to restart it except bringing the app into the
foreground. Fixing that's coming.)
Moving toward a better BT invite experience: use BTService to scan for
ourselves on all paired devices, and only allow selecting from among
those on which we're running (and so likely to respond to an
invitation.)
It's a pain to have to change code to run in Genymotion, and to have
upgrade not testable using Genymotion. Consider verting this change
before next release.
Did a bunch of stuff to inherit from JobIntentService and use enqueue(),
but doesn't work yet. OS is unable to bind, with this error:
09-21 17:20:51.678 3050 3050 W JobServiceContext: Time-out while trying to bind 2edee28 #u0a277/1111 org.eehouse.android.xw4dbg/org.eehouse.android.xw4.BTService, dropping.
Notifications don't work on Oreo without this change, which includes a
new Support Library in order to get NotificationChannel and creates and
uses that as docs describe. Requires that MinSDK be raised from 8 to 14,
which may lock some users out. It *should* be possible not to do this in
the fdroid variant since their app store doesn't requires SDK 26, but
I'll look at that later.
For some reason my laptop wouldn't build without this change. No idea
what happened to the newer version I was using or if the change
works (beyond compiling). Should be easy to find the change later if
it's a problem.
Some devices, including my Moto, are apparently calling server_do() more
than most. When the game's supposed to be asking the user to pick tiles
that resulted in stacked TilePickAlerts. The stack of these
sending (taken together) too many picked tiles to the game made it
crash. So modify server to have only one pending tile-pick request going
at a time. Because the server can't know when the user dismisses the
alert in Android and so won't post again, respond to the dismissal by
closing the game. Reopening will put it in a state where the tile picker
can get called again.
Logic error meant it was never sent. Now always send on receipt of a
well-formed invitation, even if e.g. the recipient's missing a wordlist
and the game can't be started immediately.
Had inadventently changed how NetLaunchInfo was transmitted, and crashed
on receiving from older builds. Fix to not crash, and then fix to send
and recieve in the old format.
So now all jni code uses a single dutil context, but also a single
mempool and jniutil instance instead of new instances of the latter two
per game and dict-iteration.
A number of jni calls were "stateless", which meant they allocated their
own vtmgr and mpool instances each time invoked. Instead invoke them
with the global jni closure and add to it vtmgr (already has mpool) and
use these instead of allocating/freeing each time. To make sure no race
conditions are introduced (mpool, though debug-only, is probably not
thread-safe), guard these new uses with an in-use flag. If that fires
I'll need a mutex or something.
Somehow I got a wordlist into a location different from what was
recorded in the DB table and since the delete command matched on
location as well as name it was never deleted (which meant the checksum
was never updated and so upgrading never seemed to succeed.) Removing
the match on location fixed that problem, and since I don't see any harm
in cacheing only one version of a wordlist will simply leave it that
way.
Did a bunch of cleanup as well.
I'm seeing several IllegalStateException crashes due to e.g. having an
alert posted when app's in the background. Need to fix them, but the
debug build crashing isn't helpful. Log.e() instead.
The pesky thing is back. When app's in the background with an
unconnected game open displaying the "resend/wait" alert and the game
connects get IllegalStateException because the fragment stack's being
modified after onSaveInstanceState() (or, because the dialog fragment,
saved as an instance variable in BoardDelegate, dates from an earlier
state. Anyway, catching and dropping the exception and elsewhere failing
silently to rebuild the alert seems to fix the problem, but the right
fix is likely different. I suspect hanging onto that iVar is wrong, and
that the dialog should go away when onStop() is called and then be
rebuilt later from saved state. But for now, not crashing is good.
Remove a bunch of duplicated code, replacing with implementation in
XWService. Fixes duplicate invitation and game opening policies being
slightly different.
Try some funky layout shite to get, within a horizontal linear layout,
the first text field trucated if necessary so that the second (holding
the score) can be fully displayed. Tested on exactly one emulator so
far.
Try some funky layout shite to get, within a horizontal linear layout,
the first text field trucated if necessary so that the second (holding
the score) can be fully displayed. Tested on exactly one emulator so
far.
I think there's a bug in Weblate because I've seen this before: where
the English provides only an <other> the translation comes back with
only a <one>. That's wrong. Try adding a <one> in the English case to
see if that makes a difference.
I think there's a bug in Weblate because I've seen this before: where
the English provides only an <other> the translation comes back with
only a <one>. That's wrong. Try adding a <one> in the English case to
see if that makes a difference.
Otherwise it takes too long to scroll if you have hundreds of
games. To make this work had to move scroller to left side of games
list display as otherwise the scroller steals events from the expander
thingies.
Likely because of something in the jni world unset per-player dict name
is empty string rather than null, so test for that too. Fixes dicts
popup in newly-created game have an empty first line " (in use)".
I like this better than the previous fix: rather than share a
thread->env map with the game world allocate a new one for each
iterator. This could cause problem if the iterator is used on threads
that don't currently call map_thread(), or if there are callbacks that
need to look up the env that I'm not aware of. Needs testing...
Stumbled on a NPE opening up the wordlist browser configuring the first
game on a new install. So now test for null there and init early if
necessary. Seems to work, and won't do anything in places were not
needed.
Remake the min and max spinners every time either value changes so they
can't be used to set nonsensical values. (Which leads to immediate
crashes.) I'm sure this wasn't always a problem, but...
As reported to google, dict iterator destruction was crashing due to a
race condition if it happened after a game using the same dict had been
closed since it needed a mapped env that the game closure would
remove. Fixed in two ways, one by adding the mapping prior to the code
that uses it (a common pattern: add happens many times, whenver it might
be needed, but remove only once), and second by passing env into the
code that was crashing.
The mapping stuff remains inherently racy and I'm not sure now how to
fix that. It depends on there being a place to unmap after which it's
guaranteed the mapped value won't be needed again. When two
objects (game and dict_iter in this case) map the same env/thread combo
there's a race.
Looks like the assertion was left in when adding support for dual-pane
mode, as all other onPosButton() implementations called super rather
than assert. Which this one does now too.
Getting ANRs because (I think) the main thread's waiting for the write
thread to die and now the write thread's doing a ton of work
sometimes. So move the threads into a standalone object that can be
allowed to die on its own time without anybody waiting.
I *think* the reason I'm occasionally seeing toasts about not finding a
move is that when the engine's interrupted by there being a UI event in
the queue that error is posted. Instead try posting only when at the end
of the search nothing's been found.
Having reconfigured to use non-existent relay port as a test of falling
back to the web apis, tweak stuff: send the packets that have been
accumulated when an EOQ is found (rather than dropping all of them
immediately) before exiting the write thread; and start the threads up
when posting a packet in case they aren't (they may not be when the post
happens via timer firing.)
Seemed to be causing ANRs. Integrate instead into outgoing message queue
by using poll(timeout) then checking for unack'd packets every time
through the loop (but not more than once/3 seconds or so.)
Presence of timestamp instead of a boolean determines whether packet
should next via Web. Timestamps might also allow to process a larger
number of unacked packets in a single timer fire....
Track ack'd and unack'd packets. When there are ten more of the latter,
skip the UDP-send step. This is probably not the algorithm I'll settle
on (an explicit PING to the relay over UDP might be simpler), but it's
simple and easy.
