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.
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.
