Let's make it easier to add to the set of available BT devices from the
place where the user sees the need. TODO: update the descriptive text,
but not this release since it'll break existing localizations.
Use an array of actual objects rather than indices, and add an equals()
method, so checkbox status can survive changes in the set of available
items and even be reproduced when the objects backing them change (as
happens after a new BT scan finishes.)
On launching SMS invite dialog, ask for READ_CONTACTS permission. Where
it's needed, though, is for the user-invisible process of translating
phone numbers to names (not launching the Contacts app via an
Intent). This just seems like the best place to ask since the user's
thinking about contacts and phone numbers.
Add post-open test for SMS and then ask for SMS permission, giving
rationale if the OS says I should. Meant adding a new interface for
rationales and wiring that in. It's a bit spaghetti and I may think of a
cleaner way later.
When opening a game that sends via SMS, check if it has permission and
offer to remove the config if it doesn't, removing a similar check from
pre-opening code. (Here it'll catch e.g. games opened from the
GameConfig process.) Sends/receives without SMS permission are already
caught by existing catch{} blocks, so there's no crash.
Moving stuff into superclass and trying in general to simplify
things. BT and SMS invitation work, but the option to have more than one
player per device isn't available. RelayID invitation is a mess, but was
before I think. WiDir invitation crashes in assert because I can't
debug it on this branch. Lots of work and cleanup still required.
rewrite perms23 class to use Builder pattern, making it easier to pass
more than one required permission. Use that (with hard-coded set for
now) to check and ask for permissions a game needs to communicate. Offer
to remove the comms methods the user doesn't want to permit (but that's
not implemented yet.)
Two crashes reported on the Google Play store in the 112 version have at
least easy work-arounds: catching exceptions and doing nothing. In both
cases that should be harmless, so assuming the causes are rare it's a
good move.
Add UI, minor thanks to recent refactoring, to allow invitations via
wifi direct. Uses a mapping of all currently known device mac addresses
to names, with only the latter shown to users. Works well, though
something I changed seems to have causes devices to start losing track
of their connections to each other.
Grab and store the local device's mac address. Add p2p as a type of
address, represented by the mac address of the recipient. Include the
local device's address in invitations sent when specified by user. Now
the WifiDirectService class is being passed a packet and the address of
the recipient; it will next need to set up sockets with every device it
encounters and map them to their mac addresses so that it can do a send.
Problem: brain-dead Android code (on 5.1.0 anyway) caches the
SectionIndexer separately from the ListAdapter that implements it, so
when you change the ListAdapter it keeps using the old one for its
SectionIndexer. Solution is to replace the ListView in the layout with a
FrameLayout into which a ListView is inserted at runtime on init and
whenever the data changes.
Correct or not, this is my solution to the circular problem of how to
choose a vertical or horizontal toolbar before beginning the layout of
the board and toolbar. Adding a new custom container that holds the
board, toolbar(s) and tile exchange buttons and uses the ratio of its
own dimensions to choose which toolbar to show. Also drive toolbar
initialization from the layout process because when started from
BoardDelegate it now tries to install button listeners too early.
better strings, and explain when pref changed that user must restart for
it to take effect. Actually restarting from inside prefs delegate is
hard enough I'm not doing it for what should be advanced users.
This to prevent the game list item from resizing (and so reflowing the
whole list) when it's reloading game info. Better would be to set a
timer and only show the reloading view if it seems likely to take a
minute.
When a device is a tablet and not a first-time install, put up an offer
to enable dual-pane mode. Change confirm-alerts to include
do-not-show-again box, and use that. Add menu item, hidden when not in
dual-pane mode, to turn it back off. Exit app after posting a
notification and a toast on changing that preference so it'll take
effect.
