stuff. In java, respond to util_playerScoreHeld() and
util_bonusSquareHeld() by putting up toasts with existing strings.
For util_setInTrade(), fix exchange mode. Add two buttons at bottom
that replace toolbar (and corresponding buttons on menu). Redraw
scoreboard and board with high transparency to make it clear they're
disabled. Still to do: deal with case where ability to switch which
player's tray is visible is enabled.
scheme as the rest of DlgDelegate. I'm still using a single ivar for
all dialogs, meaning they can't stack, but except for duplicate
showNotAgainDlgThen calls (where the message can be ignored) it
doesn't seem to be happening. Asserts are still in place to tell me
if I'm wrong.
crashes internally, and googling finds lots of reports/questions and
no answers. It appears NBS is broken on Android, at least for CDMA.
Might want to revisit on a newer OS version that the 2.1 I'm running
now.
listeners. They wind up getting called with mixed DlgDelegate.this
values, including one belonging to an Activity that's long-since
stopped and so the wrong ids are getting passed back.
button! Also assert the heck out of callbackIds to see if Android is
guaranteeing that no two dialogs can be up at once. I'm counting on
that, and need to know if it's not true.
button rather than just boolean. Add onDismissListener so can tell if
whole thing was backed-out of (since that's a different choice from
the two buttons "text" and "html" used in one case.) Fix compile
error that slipped by earlier: frequent clean builds required with
java.
from AndroidManifest.xml). Problem was that managed dialogs are
recreated between onStart() and onResume() yet onResume() was where
ivars (specifically m_gi) were set. Can't just set them in onStart()
because then I'd want to save state them in onStop() which isn't
guaranteed to be called. So create a function loadGame() and call it
from both, using a flag to prevent its running twice (which flag is
cleared in onPause())
dialogs depend only on bundleable ivars -- ints and strings, not Views
-- and bundle them. Don't use onPrepareDialog, only onCreateDialog,
and so call removeDialog() every time one's dismissed. Do some
refactoring to support this.
doing anything with it yet because any scheme to survive
OS-restoration has to deal with the Runnables I'm saving that can't be
bundled. Work in progress....
generalized for multiple events and map them to multiple notification
callbacks), and use it from DictsActivity to redraw the list when the
SD card comes back online. While the default android behavior works
for the unmount case (relaunches DictsActivity which correctly draws
only those dicts still available) it needs this change to redraw after
the available set grows.
so: change loadMakeGame() to return gamePtr rather than take one in,
and to return 0 when any dict no available. Move dict-gone-missing
dialog into DlgDelegate. Remove DlgDelegate always adding onDismiss
listener that removes the dialog, and instead add one to the
dict-gone-missing dialog that, like the onClick handler, calls
finish() on the activity.
figure out how to get that so I ignore it and am killed then
relaunched if I have a dict file open on the SD. On relauch, don't
crash. Instead, check if any dicts used by the game is unreachable
and put up an alert with only one choice: Close game. Thought about
using the missing-dicts stuff from GamesList, but this is a special
case that should be seen only when user umounts while a BoardActivity
instance is frontmost.
comms_resendAll() from feedMessages. The combination means that all
networked games get a chance to resend dropped packets periodically
which should help prevent stalls.
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.
dialog is up. I'm making two fixes, either of which is enough: saving
the rowid across teardown of the activity; and changing the manifest
to not tear down the activity. The reason for the latter is that the
teardown is unnecessary and wasteful. The former's just safer coding.
allow any control over whether the initial state is expanded.)
Getting click to work is a bit of a hack, requiring a callback from
the adapter back to the activity, but it works well on emulator. Need
to test on device then try to shrink the ImageButton.
with calls using formatting -- for consistency and effeciency in the
case where logging is disabled. There should be no discernable
change, though if I got and percent-format specifiers wrong I'll get
runtime exceptions.
Bad. So test if we can post (if the handler's still available) and
drop the request, freeing the thread, if not. (Access to m_handler
should probably be synchronized now that it's getting cleared, but
that's another bug.)
rare crash where class is reloaded (e.g. after long period of non-use)
after being taken down with a dialog in mid-load. The OS tries to put
the dialog back up but the dialog title string ID, passed to
setTitle() in onCreateDialog(), is 0.
singleTop is necessary, as with singleTask we get the whole actvity
stack nuked on every launch. Open a game into BoardActivity then
background Crosswords; when you re-launch from the launcher or hold
the home key you're back to GamesList. But with singleTop incoming
invite schemes would launch a second instance because though there was
one running it wasn't in the same task as the browser firing the url
to redir.php. The solution there is to move the scheme intent from
GamesList to DispatchNotify, which is already handling notifications.
There the addition of a second launch flag means that an existing
instance will always see the launch through its onNewIntent -- under
tests I've come up with so far, anyway.
