Rather than have callers of getSummary() try JNIThread for the lock, do
that check inside getSummary(), and move it to GameUtils from DBUtils
since it's using higher-level knowledge now.
Add new parameterless setTitle() method on delegates, and call it when a
fragment is removed so the new right-most pane can restore a title that
makes sense. So far only board and gameconfig delegates implement this
new method.
Current GameLock implementation means you can't get a lock for an open
game, so try getting one from an existing JNIThread instance
first. Which is a hack that's start to appear in lots of places.... Also
fix so just in case we are unable to lock a game we drop the rematch
process rather than crash in an assert later. The test case: rematch a
solo game that's currently open in the right pane.
Fixed race conditions revealed by dual-pane mode where GameLock could be
instantiated and then attempts made to reference its game (jni calls)
before it had been loaded. So now loading happens inside the same
synchronized methods as opening or creating a game.
Rare crashes are happening inside the jni, in game_dispose(), when a
game's double-disposed. Adding a jni call to check if the thread about
to do a game_dispose() will fail then asserting its result in java
allows useful stack traces to come via Crittercism. Or should.
There was a race condition between finish() and the popping of fragments
that happens inside dispatchNewIntent(). If dispatchNewIntent() won then
later finish() would pop the GamesListFragment and we'd crash. Ideally
finish() would pass a fragment to finishFragment() which would then do
nothing if that fragment wasn't on the stack. Later....
better strings, and explain when pref changed that user must restart for
it to take effect. Actually restarting from inside prefs delegate is
hard enough I'm not doing it for what should be advanced users.
I want to use ReentrantLock instead of my implementation but I'm
breaking its rule that the thread that locks a lock must be the one to
unlock it. Add commented-out assertion for some later time when I might
want to fix this. No change for now.
Game created for rematch was coming up unconnected and without
explanation if recipient of invitation hadn't responded. Don't dismiss
the INVITE alert in that case.
This to prevent the game list item from resizing (and so reflowing the
whole list) when it's reloading game info. Better would be to set a
timer and only show the reloading view if it seems likely to take a
minute.
When a gtk3 window's shutting down it appears we can't get a cairo_t*
for it. This change makes it possible to turn that fact into aborting
the whole draw operation.
I'm seeing unreproducible crashes trying to double-dispose jni game
instances and think it's a race condition involving JNIThread. Forcing
it to hold the lock in the constructor, access to which is synchronized,
is an improvement and may well fix it.
When a device is a tablet and not a first-time install, put up an offer
to enable dual-pane mode. Change confirm-alerts to include
do-not-show-again box, and use that. Add menu item, hidden when not in
dual-pane mode, to turn it back off. Exit app after posting a
notification and a toast on changing that preference so it'll take
effect.
When app's launched via a move-made intent that will lead to opening
the board, let the GamesList fragment get fully in place before
opening the board. To open two at the same time confuses my fragment
code (OS kills it with a fatal exception.)
When during onResume() of BoardDelegate we notice an undisplayed chat
message, don't add add a Chat fragment because (perhaps due to a bug
in my code) it'll come up blank. Instead use post() to open it via a
Runnable() that'll run after onResume() and the rest of current
fragment setup have completed.
When loading gamelistitems in dual-pane mode there will often be an
open game. Don't hold up the whole process by first waiting 1 second
to get a lock that's unavailable. Instead check if there's a JNIThread
instance available and if so use its lock to get the summary. Required
fixing JNIThread to not crash trying to save when released too early.
Fixes, or at least makes extremely unlikely, race condition where one
thread makes use of an existing JNIThread instance then releases it
before the thread that created it has had a chance to call configure()
to actually load the game.
Problem was that changes to games didn't show up in the thumbnail
until the game was closed. Simply using existing snapshot didn't work
because it changes the board layout in order to "draw" to
ThumbnailCanvas and that change isn't easily reversed. So copy
existing code to open a new JNI object with just-saved game data
and use it to create a thumbnail bitmap.
