Preventing the user being asked permission for Push notifications on start

[munkii]

Shiny 2.4.0.2960

As per the docs we configure Shiny in our Startup classes ConfigureServices method

        public override void ConfigureServices(IServiceCollection services, IPlatform platform)
        {
            services.UsePush<PushDelegate>();
            services.UseNotifications<NotificationDelegate>();
        }

This code gets run on startup. In iOS, the wire up done within Shiny for local notifcations does not causes the "AppName Would Like to Send You Notifications" dialog to be shown to the user, that is not shown until we call RequestAccess.

However the wireup being done within Shiny for Push notifcations is causing that dialog to appear on startup which isn't the greatest of user experiences. We'd want to introduce the idea of notifcations before having the user see that dialog. I'm assuming this can't be helped and Shiny must do the wireup on Startup and that wireup must include requesting permission.

Assuming this is the way it is, is it OK to wrap the services.UsePush<PushDelegate>() call in a conditional along the lines of "have we spoken to the user about these yet" and to call UsePush as a one off elsewhere in the code when they say Yes to the idea of Push notifications

p.s. Many thanks for opening up the Q&A section.

[aritchie]

I would always recommend looking at the code. I may be taking down the docs as I simply can't do everything, they are not complete, and people are quoting them far too often.

Push & Local Notifications don't do anything automatically. If you "uninstall the app", secure settings may be hanging around so Shiny.Push is auto re-initing itself. Try calling UnRegister, reinstall app, and see if the behaviour is still the same. If it is, you can file an enhancement request.

[munkii]

As @aritchie said this is a case of settings being left on the device despite the app having been uninstalled. To be fair I should have noticed the very useful (thanks) debug log messages

"Information: Container has active push registration token - attempting to start"

The TryAutoStart method of the Shared PushContainer looks to see if there is a CurrentRegistrationToken and if there is it does a RequestAccess.

Worse case this is a less than brilliant UX for users that have uninstalled then reinstalled. That is not the "happy path" and will be mostly seen by me and our tester.

I did try grabbing the PushManager in ConfigureServices and try calling Unregister for "new" installs but obviosuly that didn;t work because it wasn't registered at that point.

I confirmed the issue was caused by the old registration by following the suggestion to call Unregister as a one off prior to uninstalling and that did prevent the dialog.

"I may be taking down the docs as I simply can't do everything, they are not complete, and people are quoting them far too often."
FWIW I am sure the docs are a PITA to maintain but I wasn't meaning to use them like a weapon, just wanted to show I had at least read them :-)