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.
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.
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.
Override onCancel() in order to finish when the alert's closed via the
back button. Count the number of alerts and when it drops to 0 (when all
the alerts launched from the invite/wait dialog are gone) put the
invite/wait up again.
I can't figure out how to prevent rotation from duplicating the wait
alert, and don't have the ability to have makeDialog() return null, so
when that happens -- when a second is being created -- dismiss the first
first. And clean up some callbacks made unnecessary by onDismiss().
Try to track in local saved state enough, including a count of
sub-alerts the main Invite alert has put up, whether when something's
dismissed the alert should go back up or the game should be
closed (which is the right thing to do when the back button's pressed.)
Hack: setting a variable to null in onSaveInstanceState() then testing
it in an onDismiss() call that happens as part of rotation avoids an
exception when rotation the phone.
Move most state that needs to be saved in Bundle into a single
Serializable class so adding new is easier. Add to that the current
selected group so we don't crash when nothing's been set. (I think in
the move to DialogFragments I lost the code that would have disabled the
Move button. That's back.)
Move call to end of derived class' method. This may very well be the
solution to a bunch of random crashes logging
"java.lang.IllegalStateException: Can not perform this action after
onSaveInstanceState". Chief suspect is the change in XWActivity.java,
but I'm making it everywhere for consistency's sake: it's a good habit
to get into.
New classes implement custom alert and its view, where most of the logic
for putting up one button per tile, hiding and showing buttons based on
what's left, etc. lives. Rough, but works well until rotated, when gets
redrawn without spaces for the buttons that could come back.
The crazy hack to get around Android's lack of modal dialogs is at long
last gone. Remove semaphore and code that uses it. Will leave the
background thread in place, at least for now, as removing it would be a
huge change.
Make face-up tile picker util method return void and add mechanism for
passing in selected tiles asynchronously, as has been done recently with
the rest of the once-blocking util callbacks. Works perfectly in the gtk
case. Likely crashes in curses (if picking face-up option is on.) In
java all the callbacks are there but rather than put up a UI we pretend
the user says "pick 'em for me" each time. Putting up a UI is next.
Rewrite the overly-complex invite dialog that's posted when a game opens
and is missing players so that it doesn't crash after an orientation
change. It's still possible to dismiss it yet have the game stay open.
The goal is that a game in that state always has a dialog on top of it
so you don't get confused about e.g. why you don't have tiles, but
there's more work to be done there.
Also added a common superclass for all my DialogFragments. It may be
useful e.g. for having each DelegateBase instance able to track what
dialogs it currently has up, e.g. to have a policy about how many of the
same class can be live. I'm thinking here of how to prevent a
robot-vs-robot game from ending with a stack of 25 move reports. (The
change here is that the old activity.showDialog(int) only allowed one at
a time, and some of my logic takes that for granted.)
There were multiple places launching it, which in a DialogFragment
world (in the absence of other per-dlg-id controls) means stacked
multiple alerts. And dismissDialog() didn't work. So use a boolean to
prevent more than one being posted and keep a reference to the
DialogFragment behind it in order to be able to call dismiss() on
it. That's the only place I was calling dismissDialog() (other
than the tile-picking stuff which has to be rewritten anyway) so this
little hack is probably ok.
This alert still gets messed up with the screen config changes. Fixing
that is next.
I can't get preference fragments working in my world (mostly because
nested PreferenceScreens don't open when clicked on and the workarounds
for that are too complex) so next best thing is to fix alerts to work on
top of prefs activity. That involves creating a new transparent activity
that subclasses XWActivity and has a DelegateBase subclass. Launching an
alert is then just a matter of passing DlgState into the new activity
via an Intent, at which point everything Just Works. Button clicks are
returned via an intent as well.
Continue conversion of alerts that required blocking the JNI thread. Now
board_commitTurn() takes a second boolean indicating whether phonies
found have been approved by user. Common code informs user, and if he
approves client code calls board_commitTurn() again. In case where
turn's lost there's no call to make back, but there's the undesirable
change that if a robot moves next its move will be reported on top of
the turn-lost alert. Ideally new alerts would appear under, not on top
of, those that have not yet been dismissed.
Next step in converting util_ methods that required blocking: blank tile
assignment. Now post a query and add a method that the client code can
call when the user's decided. Include enough state (col, row, and
playerNum) so that it's probably pretty safe.
Probably breaks curses build, but for gtk and Android
turn move and trade confirmation into a two-step process, making
board_commitTurn() non-interactive when called with a second
parameter. The old blocking util methods now return void and it's up to
the client code to interact (on the main thread) then re-call
board_commitTurn() if appropriate.
First attempt to stop blocking the jni thread: instead of returning a
password from a util_ method, have it include enough state that the UI
can return, put up a dialog, and then pass that state and the password
back and have them matched up again. I think this will work for the
remaining blocking Alerts too.
Includes a hack in DBAlert that's required I think because
GameConfigDelegate is launched "for result". onCreateDialog() always
fails after a rotation the first time because GameConfigDelegate isn't
there to have its makeDialog() dispatched to. So it puts up a dummy
alert and then post()s code that is successful in calling makeDialog()
to get an alert from GameConfigDelegate that can replace the
dummy. Nothing shows on the screen on simulator anyway.
The major problem remaining is that blocking alerts in BoardDelegate are
recreated after rotation but the thread that was blocking has been freed
so nothing can be done after the new alert returns. E.g. blank tile
picker will be posted again, user will pick a tile, but the common
code's not in a state to do anything with that choice (which cannot even
be "returned.") Options are to find a way to make the JNIThread survive
the configuration change without unblocking or to rewrite all the common
code to not expect return values from util_ methods.
This commit is not well tested, and diffs don't allow a thorough check
of the conversion of each DlgID type.
New way of adding onDismiss listener to DialogFragment-based alerts
required API change to DBAlert and the makeDialog() method. Fixes
customizing default player name.
Had left out dispatch of "negative" buttons populated from an
ActionPair. Tested for offer to remove redundant new game buttons at
bottom of games list.
For GamesListDelegate only so far, replace calling <activity>.show(int)
to launch an Alert with something producing and showing a
DialogFragment. Replaces passing and saving state inside the
DelegateBase subclass with saving it as part of the fragment's bundle,
and it looks as if a single class will work for nearly all of the alerts
managed by DelegateBase.{onCreateDialog,prepareDialog}(), which will
eventually go away. The beauty is that the implementations of
onCreateDialog and onPrepareDialog remain, but as the body of a new
makeDialog() that's called by the fragment's onCreateView. Less code
changes, but now it's all called every time an alert's created.
Since associated DlgDelegate instance doesn't survive a rotation, needed
to pipe results through a DlgClickNotify implementation on XWActivity
that then dispatches in the DualpaneDelegate case to all visible
fragments. I hope this turns out to work for all DlgClickNotify
implementations as I switch them over. We'll see.
Add script that when copied to device and run from 'adb shell' captures
all app and OS logs to file. Next: add code to XWApp.java to copy it
from assets/ and run it on launch.
On 2.3 anyway there's a java.lang.VerifyError trying to load that
class. So wrap the loading in a new class that catches the error and
sets a boolean so subsequent calls don't need it. There are other calls
that could load the class, but they may not be reachable. To be tested.
Required to fix alerts going away now that orientations are handled by
the OS (which in turn is the preferred way to do things now since not
ALL config changes CAN be handled by the OS.) With this change some
alerts will probably cause crashes during a rotation. Those all need to
be fixed.
Add listener interface to DBUtils and hook StudyListDelegate into it so
that if a word is added while the list is being displayed the new word
shows up immediately.
wordlist browser selection and downloaded info about downloadable
wordlists didn't survive rotation. They do now, the latter as a huge
serialized array. To make selection work I save the keySet() of a
mapping of selected names to the views that represent them. Now the
presence of a key, even if the value is (temporarily) null, signals that
something's selected.
Old code that didn't rotate properly was meant to associate view IDs
with fragments so I could iterate over them, e.g. to dispatch
intents. To replace that the common superclass of all fragments now
keeps a set of active ones and provides a method that uses that to find
the fragment that owns a view. So I can iterate over fragments based on
the dualcontainer-contained views as before.
Remove the generated FrameLayout that was breaking restoration after a
config change. Set layout_weight=1 for all fragment root views so they
get half the screen in landscape mode. Remove some code. Problems
remain, first among them that notification intents aren't dispatched correctly.
A group that's closed stays closed even if a game's added to it. The
change flushed out a bug where the groups cache wasn't being invalided
on a game move, so fix that too.
Name file and set internal constant sent to server to use same git rev
string so that the script will correctly identify whether the version I
have is the latest it has available. Fixes server offering to replace
with what I already have.
replace symlink silliness ant required with gradle commands to sign
debug builds with the checked-in (local file) debug keystore. Make
it possible for an environment variable to override in case somebody
wants to use his own.
Looks like there are battery drainage issues with the current half-done
implementation, so add option to turn it off. Only takes effect on
restart, and only matters on dbg variant now since it's compile-time
disabled on the main variant.
Also add discovery machine state to ConnState printout, stop running the
machine over and over (likely the battery problem), but add ability to
restart it triggered by the ConnState's "reconnect" button.
Also start persisting the most recently seen set of peers. If service
discovery and not connecting is the problem having these available to
try to connect to on startup might help.
Build different jni code (into different obj and libs directories) for
the different release/debug and xw4/xw4dbg combinations. This works when
only one build is done, but when doing two some later task tries to put
both multiple same-named libraries into the .apk and so fails. I still
think it's worth adding this to keep from using the wrong binary, but
that needs to be fixed.
cleanNDK just nukes all the directories. Easier than invoking build-ndk
clean...
Merging of AndroidManifest.xml files meant the dbg flavor was getting
its C2D_MESSAGE permission and the main flavor's, which on recent OS
versions meant it couldn't be installed. Use substitution from gradle to
fix.
