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.
