to local, non-robot players, which at the moment means only the first
will get used. Not sure what the right strategy is now so maybe all
but the first goes away.
between dict and language. I really want to lock the two defaults --
force to change both if one is a different language -- but am not sure
it that's easy enough to do quickly (for next beta.)
(eventually) explanatory text. Currently more-or-less works,
including sending an email with a link that when clicked launches
Crosswords. (Still need to respond to that link on receipt, but I'm
at least pulling out the necessary fields.)
downloading dicts. Still to do: check if external is available before
offering; and either remove ability to download from within config
dialog or offer that choice there. Or just use a preference to
determine where storage happens. Also, on emulator game hangs during
download when using external storage.
player: remove dictName from CurGameInfo and GameSummary classes and
from DB; deal with missing dicts (the warning, fetching and replacing)
when opening games and deleting dicts. Etc. Trivial testing passes.
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.
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.
Add an Application subclass that fetches the value from a preference,
a checkbox setting in advanced prefs, and modify the static when
that's changed at runtime.
implementing same in GamesList up into DlgDelegate where it can be
called from both. Also, make syncing fire off the service just as the
timer does so that results generate Notifications. Makes it better
for testing if nothing else.
from networked games since as currently implemented it can quickly get
them permanently out-of-sync (and cause the jni code to assert.) Need
to debug this....
