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.
Got a crash opening games where tile pick was on and first player was a
robot. Cause: non-robot player's tiles were being assigned before the
robot's, and the move stack didn't like the out-of-order assignments.
Now we assign tiles in order as before, but pause each time we find a
non-robot that needs to pick its own.
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.
Back in August I "fixed" timers running after the board was cleared but
didn't realize that util contexts were shared by snapshot
boards. Clearing those timers when the board's destroyed was stopping
timers for a visible board as well. So I added a boolean indicating
whether to clear timers. Ref counting or similar would be better, but a
lot of work given the concept isn't really in the common/ code at
all (outside of dicts...)
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.
