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.
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.
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....
count them, and do so based on new msgNo passed from comms that's
concatenation of channelNo and msgID so that duplicates (over multiple
transports) aren't counted twice.
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.
Note: because the substitution is done in common code I can't use the
positional specifiers (%1$s vs %s) and so this breaks the generated
"translations". The scripts that do the generation need to be fixed to
understand the formatted="false" attribute.
quantity through to java world, use it, convert English <string>
resources to <plurals> (using python script) based on parallel changes
in French, and modify callsites to call getQuantityString() where
R.string.xxx became R.plurals.xxx.
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.
