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.
Get rid of treating 0 as a legit date (1970 being illegit). Tweak
formatting. It's not perfect, but few people see it so we'll see how it
goes during development.
revert a bit, dropping use of git revision and repo to provide an
order. Instead use aapt (which is an ubuntu package now) to pull the
version code and appID from .apk files, order by versionCode, and
secondarily by file mod time.
Auto-update was based on my manually setting what the newest is. Better
to use the git revision stored in the .apk, or failing that (later) in
the file name, to determine "age". This is all based on forcing a linear
order on git commits, but at least at the granularity of releases that
should be ok.
Mistake was putting "download more languages" at the bottom of list of
wordlists in one language. Having separate strings is a bigger change,
and in context just "Download more" works in both cases. Change name of
string so translators will notice.
Was passing through DlgState params a number of classes that weren't
serializable or that didn't have equals() methods required for DEBUG
assertions to pass. Added versions of equals() that just call super in
non-DEBUG case since it's a lot of code and isn't required except for
testing. (Serialization of course is.)
Now that params[] are being bundled all objects passed that way must be
serializeable. And as long as I'm asserting bundle success using
equals() the objects being serialized must implement it.
I wasn't saving/restoring params[] Object array with DlgState, and under
circumstances I can't reproduce that could cause a null object
dereference I was via the Play store. So added a test case that failed
for DlgState instances that have non-null params arrays, and fixed that.
Attempt to fix invite alert sticking around after game connection
finishes, which resulted from the variable pointing to the alert having
been set to null. So stop setting it in onDismiss listener. I think
trying to track it via an iVar is a mistake, that dismiss by tag or
somesuch is the right way to go. But my dialog fragment code isn't up to
that yet.
Add new Utils methods that turn Serializable objects into B64-encoded
Strings, and vice versa. Use in place of existing code, and use anew to
store the array of DeviceID records. Implement the "Delete checked" button.
In Dbg version only (with enabling boolean moved to BuildConfig.)
Currently crashes when first used, and recipient can't always connect to
relay until app rebooted. And of course there are still open questions
like how to populate the list -- how user learns the deviceID of an
opponent.
Was previously a "global" so that a resend over SMS might delay a resend
for relay games. Since communication problems tend to be
comms-type-specific that's dumb.
Added a wrapper function since for compatibility with the jni's encoding
the flags matter and need to be the same everywhere. Or at least there
should be no chance of their getting changed.
As a first step, use mine and android's and assert results are the
same. Note using built-in Base64 class requires moving the min android
version from 7 to 8.
Copy config file into the right place, turn it on for debug builds, and
fix compile-time complaints by adding -keep clauses. Resulting builds
seem to work (after a few minutes in emulator only) except that net
status icon taps crash at first (eventually recovering somehow) likely
because of problems with base64 en/decoding which goes through jni.
Get rid of black background of center icon, instead running the green or
red all the way to the middle. For better contrast make the green and
red darker and the non-active arrows white.
The debug-only settings for disabling individual conn types weren't
kept in sync with which types were enabled, and that set of types was
lost on rotation. Fixed (including keeping the disableds across rotations.)
I'm seeing assertions when a game gets into a state I don't fully
understand: host receives messages that need a channelNo assigned but
the game's full. With luck they're duplicates and can be ignored,
because that's all I can do.
Since it's now possible to add a name for an SMS contact added manually,
don't assuming a missing name means it was added manually. Just leave
blank if not provided.
I made these changes a while ago then stashed them. They worked when I
needed them then, and seem to work now, but I haven't verified now so
don't trust 'em too far. :-)
Crittercism is dropping free support of FOSS apps, so I'm dropping
it. Unfortunatly integration isn't as clean: so far at least I haven't
figured out how to make it possible for others to build the 'd' variant,
which includes Crashlytics, without their having a Fabric API key.
Resetting it on every ACK etc meant it happened forever at the most
frequent interval, at least on devices that have both sides of a game,
which is my usual test setup.
In game config, when the play game button's hit and the changes pending don't
"matter" (require reset), apply them. The motiviation is to allow
setting the "disableds" and immediately launching a game via the button,
but I think it's the right thing to do anyway. Needs testing.
Deal with occasional droppage of SMS data messages by running a
timer (via AlarmManager) with backoff that resends any pending moves for
games connected via SMS. Successful receipt of SMS data resets the backoff.
When Android client is backgrounded with a game playing (BoardActivity
on top) then brought to front again it fails to reconnect to relay
because it didn't disconnect and the relay thinks it's still there. The
right fix is in making the java code do the right thing (complete
disconnect), but it seems harmless to just honor the reconnect in this
case. Doesn't even cause leaks, per valgrind.
cleanup, iterating over built-in data rather than my hard-coded VARIANTS
and BUILDS arrays, which now go away. Renamed obj- and libs- directories
to better fit the variables the system provides.
Add DEBUG-builds-only UI at the bottom of GameConfig for turning on the
comms feature dropping outgoing or incoming messages. The idea's to use
this to reproduce and fix stalls. There's a noticable slowdown opening
the GameConfig fragment, but it should all be no-op in a release build.
Add BuildConfig boolean that's true when a gradle property is passed in
from the fdroid metadata/build file. Test when putting together upgrade
state and omit app info when it's true, same as if from Play store.
F-droid build system modifies git-controlled files so no build will ever
be clean. So look for a -P property and if that's set don't use the
--dirty flag when capturing the git revision. Requires a change to the
fdroid metadata to pass that property.
Years back what I read said you opened and closed the database around
every query. Now I'm reading differently, that the OS will close it for
you on app shutdown and that it's ok to just leave it open. Trying
that after a few minutes on one device looks ok. Will need to test the
heck out of it, especially on older OS versions, before ship.
Play store reports crashes but stack crawl doesn't tell me where
from. So try catching the exception and on debug builds logging what
dialog is responsible.
When those became an advanced feature I added a warning for upgrading
players who'd miss them. That was long ago, and the warning was only
supposed to last a release or two.
If a Makefile defines a dirty word list then a new python script is
invoked to filter for and remove those words as the dict is being
built. So far I have for English only, which makes sense because only
English wordlists are built-in on Android and Google's rating system
cares only about what's built in.
showDialog() goes away except for PrefsActivity which can't do
fragments. Move stuff required by PrefsDelegate into it from
DelegateBase since no other subclasses does old-style Dialogs
any more. Remove a bunch of stuff from DlgDelegate, e.g. saving
state, that no longer gets used.
Was getting crash with "Can not perform this action after
onSaveInstanceState". This lets the back stack get back into shape so it
can put up another alert.
Add to DldID the ability to specify whether dialog fragments bearing
that id go on the back stack. Set INVITE alerts (only) to use that
mechanism. Having them on the back stack seems to be required by their
buttons being hacked to not dismiss them, which in turn is required
because I want them to stick around underneath other alerts their
buttons launch.
Get rid of explicit enable-dualpane boolean pref, instead relying on the
three way default/force-phone/force-tablet pref. Offer to change that
rather than the former in BoardDelegate when run on upgrade. Move the
prefs setting from Debug to Appearance since it's "real" now.
Recent recommendations are not to attempt to handle it myself, so don't
and we'll see how it goes. And unify notions of tablet and enabling
dual-pane: a device that isn't dual-pane should not be using the new
single-activity stuff at all.
Had to disable use of the back-stack for DialogFragments, though that
means I can't prevent duplicates from stacking up (esp. in the
pathological robot-vs-robot case, but also just when I rotate the device
while a "rematch" alert is up.) The problem seems to be in dismiss
actions being handled too late. One easy-to-duplicate case is the
tile-picker. When it's enabled and you commit a turn I post first the
confirmation and then, in response to a "yes", the picker. But the
picker gets added to the stack moments before the confirmation is
removed, and it's the nature of stack removal that everything above
what's being removed gets pulled too. So you never see the
picker. Simply post()ing a runnable to put the picker up later fixes
this one case, but a similar trick doesn't work elsewhere, so I'm
punting until I have time to root-cause the problem.
Each alert gets a unique name. Add to backstack, and before doing so
look for another with the same name and dismiss it. This works most of
the time, especially to prevent them from piling up with orientation
changes. But in a robot-vs-robot game, and occasionally in a game with
three robots and one not, SCORE alerts stack up. It's the removal that's
failing, not the test for a duplicate, so perhaps I need to somehow wait
for it to succeed before adding the new alert.
DELETE_DICT Action is expected to flow through child, at least until I
fix to disable deleting a dict while it's open in the dict browser. It
may be confusing but with the assert gone does no harm.
Make the default be that it's on, and move the new-feature notice from
app launch to board open, the point where most will see the feature for
the first time. Remove the notify-and-exit thing, which is harder to
make work from the board, instead just posting an alert, if user chooses
to disable, that the setting change takes effect after a restart.
Needs to show different text and buttons, so now that it isn't getting
dismissed and rebuilt every time a button's pressed force that process
manually the time it's required.
When game's resumed (brought from background) and Wait alert is up
onStart() is called before getDialog() has a non-null value to
return. onResume() is the place to modify the dialog.
Rewrote Wait/Invite alert to use new functionality that allows it to set
its AlertDialog buttons to not exit when tapped. Turns out things are
much simpler when I don't have to hook into all the places my dialog
might need to be put up again.
