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.
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.)
Oops. Debug build assertion showed I was leaving an infrequently used
field out of serialization, adn then required that that object be
Serializable and implement equals() to pass more tests.
