that implies a connection) is sent and received by no-conn code. Use
flags to determine if comms can support no-conn sending without making
up the message only to have it fail to send.
(return false) so add new iface comms can call once to get flags to
tell it whether to use that proc. One implementation of
TransportProcs returns one flag; the other, the other.
without user having to open the game, which will e.g. allow a host to
assign tiles, or a robot to move, without the phone's owner noticing
there's a message. This is on a branch because it may never work.
arrays into the jni, pass the full file paths in in addition to the
byte arrays. This isn't possible with the built-in dicts, but does
work for the downloaded ones (which are usually larger). This checkin
does the mmap and uses memcmp to verify that the bytes are the same as
passed in. Next step is to not pass the bytes when the path will do
and to actually use the mmap'd ptr.
passing a 0-length array of bad words. Which should never happen, and
would be caught by asserts in a debug build, but: when there are no
bad words don't call back into the java world.
and whose names have not yet been received from host/server -- as part
of summary. They can be drawn differently to give a clear visual
indication which games are not in play and for which the user might
want to issue an invitation.
Robots default to BasEnglish dict and humans to CollegeEng. Add new
per-game default for robot dict. Still need to deal with language
changes and non-English case in general.
player. Works for gtk client. Compiles for Android but there's no UI
yet to specify more than one dict. Management of dupicate dicts
without duplicating memory -- refcounting -- will be up to the
platforms.
show them and another group depending on whether trading at the time.
To make that work, replace the individual calls made to dis/enable
toolbar buttons with a single jin call that takes a struct full of
booleans and make that struct available in BoardActivity where menus
are hidden/shown. Remove the individual calls from the jin interface.
object) rather than allocating a new array in the C heap -- for the
DAWG data of a dictionary. This can use up to 5% of the java heap for
huge dictionaries, but I'm hoping it fixes a problem reported by a
user of the large German dictionary that seems to involve allocation.
If I'm reading correctly, as long as I stay within 16M (24M or more on
newer devices) I'm sure to get my memory in the java world while it's
less a sure thing in the JNI world (where in addition linux's
aggressive overallocation is used, meaning I'll fail when I try to
swap in memory on write rather than get back NULL from malloc.)
