There are some screen dimensions, especially with dual-pane mode, where
the board is just bit narrower than the screen. Rather than have narrow
white borders, allow the cells to take up the slack. The API takes an
upper bound on the ratio of width to height so things shouldn't get too
odd looking.
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.
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.
whose lifespan matches its, e.g. the gameptr and gi. This is a big
change, and there are still some bugs/crashes, but it's worth
committing this snapshot.
once instead of at every call site. There's probably a performance
penalty to making bunch of extra calls back into java, but the code's
much cleaner. Will pay attention to performance changes.
game_dispose()). There was one that had been undetected for years. The
int is still passed into the jni, and each call site has to pull it
from the wrapper. Better would be to pass the wrapper, but I'm worried
about the performance hit of making a call back into the java world
from every jni entrypoint. Will test....
side translate that into showing the sender's name in
notification. Not yet done: replacing silly "not me" in chat listing
with same, but now it should be easy.
Conflicts:
xwords4/android/XWords4/archive/R.java
side translate that into showing the sender's name in
notification. Not yet done: replacing silly "not me" in chat listing
with same, but now it should be easy.
works between linux and Android clients. Required renaming so struct
names and names of fields within match in c and java code. The point
is to test this as the foundation of rematch: now you have to type in
a deviceID in order to invite, which clearly sucks for users. Either
that goes away, or it's replaced with something that scans existing
games and lists past opponents as possible invitees.
what's going on when multiple participants in a single game are on the
same device. But for a couple of strings passed into the jni the
changes are only in DEBUG code.
needs to save it there on receipt of an invitation (doesn't create
full game with comms until later.) Passes discon2 tests and seems to
work on a single Android device. (Haven't tested inviting on Android
yet.)
jni, mostly by having jnithread explicitly announce that it's closing.
Yuck. This stuff *should* obey a stacking protocol but the callback
stuff I'm doing makes me unsure that can work.
env for that thread to fix occasional assertion failure that indicated
I was using the wrong env occasionally. I'm not super confident in
this because I've seen the env for a thread change, but that could be
due to reuse of the thread id.
