Getting an NPE iterating over fragment/children of dualpane view
because, I think, committing them's been postponed. So add the iteration
as a Runnable to the same postponement mechanism. This may be wrong:
needs to be run for a while to see if it fixes the NPEs I'm seeing (on
opening an intent in the morning after the device has been idle all
night.)
Attempt to fix crashes happening when the occasional fragment
transaction happens before the OS is ready. Keep a boolean indicating
whether we're in that state, and when it's not set create a Runnable to
be run next time it is. Temporary Toast lets me know when it's working.
Attempt to fix crashes happening when the occasional fragment
transaction happens before the OS is ready. Keep a boolean indicating
whether we're in that state, and when it's not set create a Runnable to
be run next time it is. Temporary Toast lets me know when it's working.
Problem: brain-dead Android code (on 5.1.0 anyway) caches the
SectionIndexer separately from the ListAdapter that implements it, so
when you change the ListAdapter it keeps using the old one for its
SectionIndexer. Solution is to replace the ListView in the layout with a
FrameLayout into which a ListView is inserted at runtime on init and
whenever the data changes.
Setting up an emulator that'll grab {menu,layout}-small resources is a
pain so this script exchanges them with regular resources so that a
subsequent compile will produce something that (when run) will catch
missing resources etc.
tweaks to BoardContainer and Toolbar to better position toolbar and
better hide/show it in tile exchange mode. The bar's still partially
offscreen sometimes on a 2.3.7 emulator but it's usable. Next I need to
try specifying the size of the bar rather than having it derive from the
size of the images it contains.
They crash on 2.3.7 at least, and don't seem to be required anyway. I
think the only reason I need to implement onMeasure() is because
BoardView expects to be called a certain way.
Correct or not, this is my solution to the circular problem of how to
choose a vertical or horizontal toolbar before beginning the layout of
the board and toolbar. Adding a new custom container that holds the
board, toolbar(s) and tile exchange buttons and uses the ratio of its
own dimensions to choose which toolbar to show. Also drive toolbar
initialization from the layout process because when started from
BoardDelegate it now tries to install button listeners too early.
Fix crash when game config opens dict download for result and nothing's
chosen. Was sending Activity.RESULT_OK in that case instead of
RESULT_CANCELED.
Docs and some logcat crash statements from the OS say I need no-args
constructors for fragments. So rework initialization and use bundling so
parent name doesn't have to be passed into the constructor. Seems to
work, and fixes the crash I was seeing (happened when sending an
invitation via SMS) but requires more testing.
Fixing a crash when a game offers both to create a rematch and to delete
itself because its opponent has been deleted. Deleting and then hitting
rematch would crash because the rematch alert referred to a dead
game. Now onStop() for delegates removes any pending alerts. In
dual-pane mode only since when there's an activity going away the alerts
go automatically.
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....
Trying and failing to get just the content area of the tree view to
scroll, whether by putting it in its own container or hooking into the
scrollable interface tree view allegedly supports.
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.
Toward something that should work with android: pass a potentially
unique draw context into new method that creates a new board just for
the draw and makes its scoreboard and tray disappear.
Done in a way that won't work for Android just to try out the gtk
way. Tweaks and reuses the existing draw context and board, which is
precisely what the android version can't easily do.
Add new "snap" blob to db and pixbuf column to games display table, and
add code to store and retrieve from db. What's stored now is a
hard-coded file, so next up is generating an actual snapshot from the
game.
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.
Whenver we get the draw signal, invalidate the whole board and draw
it. This is resulting in a lot of wasted effort that might be mitigated
if I figured out how to get the invalid region out of the cairo_t*
that's passed in, but this is a test app and my machine's pleny fast. So
go with it for now.
