GamesList menu was in a bad state after a game closed because hadn't
been rebuilt. It's simplest to invalidate it surgically, when the
BoardDelegate notifies that the board's closed, though doing in in
onWindowFocusChanged() might catch more edge cases. We'll see. I want a
low-risk impact right now.
but not on emulator running same OS version (or close). And in spite of
an exception being thrown the work being done, hiding a preference,
still succeeds. Whatever.
Fixes case where user has received invitations but not allowed SMS then
decides to do so. It's a hack giving Perms23 class knowledge of how to
send moves etc. Instead I should be letting interested parties register
for perms-granted events, but that can happen later, and is less
valueable while SMS is the only "dangerous" permission and the only one
that blocks message sends.
JSONObject(<string>, null) clears out any existing entry but doesn't add
a new one. So store missing names as "" instead. Not sure how this
worked when I first tested it....
My old asking for permission to turn on/off SMS is confusing and adds no
value when the OS separates out permissions and is confusing. So get rid
of it on Marshmallow and later, always returning true from the old API
and hiding the preference in that case.
The write-red-on-it thing doesn't work for the notify.png file used in
notifications (I think because I can't find a color Android doesn't
strip out.) So use a rotation transform instead. Users will never see
this anyway.
Move connection options READ_PHONE_STATE check from ConnViaViewLayout to
GameConfigDelegate and give it a rationale. Preferences stuff can't do
permissions because it can't override onRequestPermissionsResult (base
activity is of wrong class). Should fix that at some point, either by
moving to preference fragments or with a dummy activity to go over the
top.
Explicit "ask again" and "skip" buttons in alert showing rationale;
check/ask for permission before sending invitation via SMS; warn each
time SMS-enabled game is opened without permission but allow it to stay
open and if necessary send an invitation.
add "close game" button to warning about lack of comms, and do that on
dismiss too. Nothing good can come from having the thing stay open.
Eventually the "close" should turn into "edit" and launch GameConfig on
the game with the comms selector up, but that's hard, as currently the
launch only happens from GamesList and is via
startActivityForResult. Might be easiest to close and send an intent to
GamesList to cause it to launch GameConfig that way. Not for this release.
An edge case, but: doing "new from" on a game without any connection
types crashed because of an assertion in comms that assumed
addr_setType() was being called on zero-initialized flags, which
shouldn't have been a requirement. Pulled that as well as java code that
added RELAY-type connectivity to any game that had none. If a game has
none, leave it that way.
replace dlgButtonClicked() with separate methods for positive and
negative buttons and alert dismissal. I was making too many mistakes
because the old method was getting called twice (e.g. for negative and
then dismissal) and I hadn't needed to differentiate until adding that
new Action. There should be no behavior change with this, but it's
pervasive and replaces some spaghetti.
Let OS ask for STORAGE when user chooses Downloads dict storage option,
but do nothing if it's not granted. Existing code asks again when the
actual move is to done.
If an game's open that uses a wordlist kept in Downloads and permission
is revoked, close cleanly. On re-opening the user will be prompted by
existing code to download again. (Note: not prompted to turn STORAGE
permission back on. It would't be easy to detect that case, and I'm not
spending time helping people who are perverse.)
Add new static method that takes a request, rationale and Action, offers
the rationale if required and then, if user hasn't cancelled, asks for
permission. Eventually the Action is issued with either POSITIVE or
NEGATIVE. Use this to ask for STORAGE when downloading upgrades and
moving wordlists to the downloads area.
You need PHONE permission to start and play an SMS game but not to have
started it in response to an invitation. But to rematch you need it. So
ask, including offering a rationale that differs depending on whether
there's a way for the game to communicate once SMS is removed.
They were hacks for debugging SMS early on, probably infrequently
seen. Instead post messages. BUT: they aren't being received because of
how listeners get cleared in onPause(). Needs to be fixed, but there's
no harm in having them dangle for now.
Sometimes when a new game is created the board winds up with the toolbar
drawn over the tray. That's because when it was laid out the game wasn't
running yet and so none of the toolbar buttons was enabled, giving the
toolbar a height of 0. So now the first time the updated toolbar reports
that at least one button is enabled we force the board to lay itself out
again.
Little hack to dismiss a game when the invitations dialog was cancelled
broke invitations altogether. Revert that change, and simply check on
getting focus whether all players are present; if they're not, put up
the "invite or wait" dialog. This is a big change, but in 10 minutes of
testing I can't get the wrong thing to happen.
Remove strings that no longer exist in English, add missing "other"
quantities in Japanese (taking a guess from context that it's ok to use
generic counters), and in a couple of languages fix typos in format
specifiers that would have caused crashes.
It wasn't even checking all languages. Now it does, lets you specify
which ones if a subset's desired, and differentiates between sets of
format specifiers mismatching in a way that'll cause a
crash (e.g. expecting int in one and string in another) and just having
some missing.
