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.
Send each packet via UDP if that's thought to be working (always is,
now) and start a 10-second timer. If it hasn't been ack'd by then,
resend via Web API. Tested by configuring to use a UDP socket that the
relay isn't listening on. Only problem is that the backoff timers are
broken: never stops sending every few seconds.
The plan's to use the native relay protocol first, then to fall back to
the slower but more reliable (esp. on paranoid/block-everything wifi
networks) webAPI. This is the name change without behavior
change (except that the native kill() to report deleted games is gone.)
When grouping to allow multiple packets per outbound API call I forgot
that some are there to mark the end-of-queue: can't be sent! Trying
caused a NPE. Now if any EOQ is found in the queue that batch is dropped
and the thread's exited.
Making the right_side elem match its parent height prevents the
lower-right region of game list items from falling through and
triggering a toggle-selection event.
Making the right_side elem match its parent height prevents the
lower-right region of game list items from falling through and
triggering a toggle-selection event.
As expected, moves are no longer received instantly because the UDP
socket isn't available for the relay to write too once the URL
handler (relay.py) finishes.
Working around there being a border around the game-type image area.
With this change long-tapping works only on the right 2/3 of the
region. There might be a fix, but it's still better than there being
a hole (the border) in the thing where behavior's different.
Duh. The .java file was removed, but the declaration that all apps can
handle an intent (that requires WakeLock they no longer all have) was
not. Should fix crashes I'm seeing.
Board and Games List were using same menuid which meant that even when
chosen from Board's menu it would up getting handled by GamesList (in
dual-pane mode.)
Somehow the d variant was crashing without the WAKELOCK permission, the
OS having invokes something GCM-related. This should ensure nothing
GCM-related can ever happen.
This seems to fix that app, when built by me where GCM_SENDER_ID's set
in the environment, being a battery hog. Apparently google's code
doesn't handle being passed the wrong senderID very well.
I'd added inputType="text" everywhere I added maxLines="1" but it turns
out that breaks touches being handled at least on some devices. And it
makes no sense to have an inputType for something user can't put into.
Several EditText fields are configured so monkey breaks things, e.g. by
entering too much text in the default player name config. Fix. This
probably won't impact users but it lets the monkey tests move on to
other things that might.
Can't repro on Nexus emulator running 4.4 nor on Samsung running 4.4.4,
but the reporter says this fixes it. And from reading it appears
expecting older devices to load Material themes without an AppCompat
library is wrong.
For the ORDER BY clause that governs how games are displayed within a
group, use a static string built from a list of clauses that are then
easy to move up and down. Add clause that moves games with unread chat
to the top. Another commit will modify the display so it's clear why
it's there.
Bring back the test for being null, and add an additional one via a new
boolean iVar that we haven't tried posting it already. On some devices
there's enough of a lag that the is-null test passes several times
before the first makeDialog() call, leading to a cascade of attempts to
create that hangs the UI. The test's needed, but only once should be
start the process.
When the back stack is restored commit() is not called, so the fragment
needs to save it. Without this 0 is passed to popBackStack() and
everything's dismissed, not just the one fragment.
Rather than just pop whatever's on top of the back stack, which might be
the alert whose listener called finish(), use saved commit() ids to pop
down to the fragment itself. This feels like a risky change, and it's
tested only by back-button-dismissing the Wait alert in an unconnected
game in BoardDelegate, so needs some bake time.
When SDK >= 19 there's an API to tell if a listview is full enough to
require scrolling. So use that, rather than the raw count of games, to
decide whether to offer new users to hide the new game buttons.
What's here is merged with the main one, so no point in duplicating and
it's just a pain to maintain. Remove as much as possible that's not
unique to the debug variant (crashlytics and wifidirect, basically.)
