iOS notifications

[hape42]

Besides all the background work to refactor the code (and make it more readable for new developers joining the team) I also need a challenge that I enjoy.
I think the "IOS Notifications" are a manageable effort. And it is an interesting problem.

You have to be able to adjust the various parameters for the notifications in the app settings. That means you have to rework the setup page as well.

I could use some concept suggestions how the setup page could look like. Maybe the setup also needs subpages? Topics must be summarized sensibly.

[Smiles2go]

By "iOS notifications" do you mean having the app periodically poll the DG user account in background to see if a new move or message is available?

Assuming so, doesn't seem like user would need much choice in how that would function. Possibly to set polling interval, but users will naturally want that as short as possible.

Users will need reminder to go to System Settings to allow DG to run in background, maybe also to adjust alert presentation modes for DG. Some apps open Settings to right location so user doesn't need to dig around trying to find the right spot.

Possibly user could get choice of moves-available or also messages-waiting alerts. Given the limitations on DG messaging (would really like if we could have DG app keep conversation and alert histories per-opponent), I don't usually care about waiting messages, especially broadcasts like "Fred just won Wildcats tournament."

Care is needed to not generate lots of extra polling traffic hitting DG service all the time. I'm thinking maybe limit polling interval to 15, maybe 10 minutes. Maybe 30 min to start and find way to measure actual impact before shortening. Getting fancy, could consider longer interval during sleep or driving focus.

Also, once an available message or move is detected / alerted, increase polling interval (2x? 3x?) since goal of user alerting has been met, and user knowing the current number pending to highest fidelity is less important than just letting the user know attention is needed.

Finally, unless you can reliably store messages, may have to block polling after a pending message is awaiting delivery or it will be lost.

[hape42]

I would implement this only so that only the Toppage is analyzed whether there is something pending.

The complete topic is new for me. If I succeed in implementing TopPage, we can think about whether other checks are feasible.

Saving messages and chats is also an interesting topic, I have also already considered.

[Smiles2go]

Maybe I'm oversimplifying. Seems like you have function to retrieve TopPage and may be able to add a faceless (no-display) mode for it, returning number of pending matches. Check TopPage based on a timer wake-up like Linux cron (not busy wait that will kill battery).

When nonzero, post alert.

I don't know when messages or notices could be received from DG service. If there's no danger of getting one when checking TopPage, then no worries about losing them.

[Smiles2go]

Notification and badge (number) working pretty well now, thank you.

Waiting-game count is often inaccurate but is really most important just to know at least one move is waiting.

After playing all available moves, there is a delay before waiting-count is removed from DG icon, but is not a serious problem.