Trying to separate what's game-specific from what can be app/device
specific (i.e. with a long lifespan, and available when a game isn't
open.)
Android will be broken after this commit and fixed after the next
Make face-up tile picker util method return void and add mechanism for
passing in selected tiles asynchronously, as has been done recently with
the rest of the once-blocking util callbacks. Works perfectly in the gtk
case. Likely crashes in curses (if picking face-up option is on.) In
java all the callbacks are there but rather than put up a UI we pretend
the user says "pick 'em for me" each time. Putting up a UI is next.
Continue conversion of alerts that required blocking the JNI thread. Now
board_commitTurn() takes a second boolean indicating whether phonies
found have been approved by user. Common code informs user, and if he
approves client code calls board_commitTurn() again. In case where
turn's lost there's no call to make back, but there's the undesirable
change that if a robot moves next its move will be reported on top of
the turn-lost alert. Ideally new alerts would appear under, not on top
of, those that have not yet been dismissed.
Next step in converting util_ methods that required blocking: blank tile
assignment. Now post a query and add a method that the client code can
call when the user's decided. Include enough state (col, row, and
playerNum) so that it's probably pretty safe.
Probably breaks curses build, but for gtk and Android
turn move and trade confirmation into a two-step process, making
board_commitTurn() non-interactive when called with a second
parameter. The old blocking util methods now return void and it's up to
the client code to interact (on the main thread) then re-call
board_commitTurn() if appropriate.
First attempt to stop blocking the jni thread: instead of returning a
password from a util_ method, have it include enough state that the UI
can return, put up a dialog, and then pass that state and the password
back and have them matched up again. I think this will work for the
remaining blocking Alerts too.
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
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.
ID_TYPE_RELAY id that's not in the devices table (as has happened when
a device switches relay URLs during testing, but might also happen if
I have to delete an entry from the devices table.) In that case,
return ID_TYPE_NONE to the client, which will be its clue to delete
its ID_TYPE_RELAY id and submit the platform-specific id again.
Note: android won't compile this revision thanks to util.h change
which they're communicated to the device. Device is expected to have
a platform-specific notion of ID which the relay stores in a new
devices table and indexes with a 32-bit number which is returned to
the device -- which is encouraged but not required to use it in lieu
of the longer ID in future communications. Modify linux client and
test script to use the relay-supplied id. Some of this is commented
out for now.
dict, give chance to switch, and to download if required. Because of
the way the JNI thread works, and JNI's requirement in general that
env instances match up (e.g. dicts must be destroyed in the same
thread that creates them), substituting into a live game is too hard.
So the game's saved with its new dict and then reloaded.
used by server. Clients need to care if e.g. the server's disallowing
phonies based on its dict. Can only be sent if client is of latest
version. In that case, common code calls into new util function. In
future changes, BoardActivity's implemention of the callback will need
to check if the server's choice of dict is available, and if not offer
to download it. Once it's available, will want to install it.
it if any players are missing. Idea's to allow for non-relay devices
the invitation opportunity that comes when a game connects to the
relay and learns that no other games have joined its room.
to query model for values. Now everybody else queries new model API
rather than client via util_getSquareBonus(), model uses its internal
values if present otherwise falls back to util_getSquareBonus(), and
internalizes the array as part of the game. Now it should be easier
to have different bonus patterns and to have them exchanged as part of
network game init.
to enable it for a game yet). In common code, break pick tile utils
method in two, one for blank and the other for tray tiles. In java,
implement dialog for picking the tiles. Works, though is a bit clumsy
to have the dialog come and go after every pick. Better would be a
dialog that stays up and accumulates picks -- but it'd have to know to
reduce the set of tile choices as letters are chosen. This'll do for
now.
played that include that tile and pass to new util_cellSquareHeld()
method. In java implementation of that method, use existing lookup
activity code to display list of words. Enabled on the C side by a
compile-time flag in case it has problems. Right now the time spent
saving a game before launching the lookup activity, and reloading it
after, is pretty apparent, but that's in emulator which is slow.
util_userQuery(QUERY_ROBOT_MOVE) with new util_informMove(), into
which the number of words formed and the words themselves are passed.
The process of consing up the score explanation was already passing
over the model, so storing the words is very little effort, and will
save a call back into the model where the user actually wants to do
the lookup.
into the java world by making it a util_ctxt function. Do same on
linux to test. We'll see how it is -- and can back this commit out if
there's no improvement.
meaning it'll work on any tranport but relay doesn't know about it.
(If relay knew about it I could send a "shutting down for a minute"
message to every connected device, which would be cool. But this is
easier.) Written, BTW, enroute from Seattle with help from beer from
Chris in first class. :-)
game works to completion with both signing up as guests (no -s) with
one local and one remote player (identical commandlines.) Not yet
tested: if any signs up as a host, reconnecting rather than
connecting, etc. This is just a snapshot.
Includes ability to scroll horizontally by dragging. Board init API
changes to specify board width and max height instead of cell
dimensions, so now board owns task of picking cell size. If the
number of cells does not evenly divide into a board dimension then the
extra pixels are distributed among some columns/rows in a way that
still allows bitblit-based scroll implementations (though horizontal
scrolling at this point always does an invalAll()). Not yet tested
with overlapping tray. And still need to allow rows to be taller than
cols are wide if platform code has given the space. Stream format
changes with this checkin.
