for both the loading and loaded phases, toggling its state once the
data's available. Reuse it: pay attention to what's passed into
getView and only allocate when there's no existing View to reuse.
Stop caching Views, as that defeats Android list logic that might
limit in-memory representation to the subset that's visible on-screen,
instead tracking a set of rowids whose data is known to be good as a
way of quickly drawing when there's a refresh.
dicts. Now you select a single dict for such games in a new spinner
just below the lang spinner, and player's dicts are no longer
displayed. For standalone games, the single dict choice isn't there,
the individual dicts are displayed, and you must open a player config
to change the dict as before. The idea is that this will be less
confusing, particularly when I need to tell the guest that the host is
using a different dict.
force user to realize the potential costs (by requiring interaction).
Until that's enabled, show in New Game activity an explanation and
button that goes to Preferences.
remote device[s] as part of summary view and in game config screen
(read-only). Use same field in summaries table for remote phone
numbers and bt addresses.
into superclass that NBSInviteActivity can share and use to make their
UIs similar: fetch mobile numbers from DB one-at-a-time, keep a list
there, and let you check then delete or return. Rough, and doesn't
save state the way BT does, but works.
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.
white-on-white on several OS versions. Need to test further to try to
reproduce the conditions that had me trying to manage contrast myself.
Or use a dialog-themed Activity for lookup dialog -- prev checkins say
that was too slow but that might be fixable....
UI and background service disappear/don't run when it's off. Goal's
to ship two apps that differ in this setting, a change in Android.mk,
and little else.
more is checked. On launch, get the set of known device, and on scan
do NOT start by emptying. This allows to maintain a set of devices
and still scan without losing those not present.
that as starting point so initial scan can be skipped. When unable to
deliver a message to remote device, give up after three tries and send
message to that effect.