comms) and incoming (from NBSReceiver) messages through it. Since
some messages are too big, add header/protocol for breaking them up
and reassemble. With this commit complete robot-vs-robot games are
possible between two very new Samsung phones on T-mobile. Older
phones and other networks not tested.
contrast right on all platforms any other way. Previous change to
using dialogs was motivated by speed, but I don't see any slowdown so
far. Will address if I find it.
NewGameActivity and from BoardActivity when the new notifyMissing
method gets called. Works as before called from NewGameActivity but
BoardActivity crashes on iterating over list of devices returned.
keeping the listener/sender threads going much easier. Create new
message sink to dispatch incoming messages, and start passing return
addresses into comms (not required before when relay was only
transport as it has no return addresses.)
specify a pair of flags when background-launching GamesList that
strips any stack it has and doesn't launch a new instance. Seems to
fix the problems with launching from notifications and invite emails.
But then I've thought this fixed before.
AndroidManifest rather than created programatically: only with this
can I get EJECT events to work. Replacement class has static
register/unregister methods which DictsActivity uses.
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.
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.
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.
(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.)
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.
work of pinging relay on timer. That work, which can cause receiver
to exceed its timeout if there are e.g. problems resolving hostnames,
must be done in a thread and Receivers aren't supposed to have
threads. Seems to work as well as it did before and also fixes
force-restart bugs when the network is slow/unavailable.
history, and store it in the game record in the DB (new column). This
will allow to not drop chat messages that arrive in the background,
though that's not implemented yet.
the only way to have it wind up on top *and without it being a second
instance of the activity* when relaunched in response to a move-made
notification. Even passing the SINGLE_TASK flag to the relaunching
Intent doesn't accomplish this.
that information to connect and not. There seems to be no way to get
notified when a socket's underlying transport goes down (might not
even want to) so this will be the best way to have the arrows go red
when the device goes into airplane mode.
thread that stops itself immediately. Eventually that thread will
check the relay for pending moves, put up a notification offering to
open the game that has moves pending, and schedule itself to run again
later before stopping itself.
