Change Azure Push Notification Endpoint After App Startup

[jmichas]

I am still running v2.2 so I am registering my azure push like this:
services.UsePushAzureNotificationHubs<PushDelegate>(listenConnectionString, notificationHubName);

Based on the user's role that signs into my app I need to change the connection string and hub name.
Is there a way to "re-register" the push service stuff later in the app's runtime?

Thanks.

[aritchie]

Technically, you can resolve Shiny.Push.AzureNotificationHubs.AzureNotificationConfig, change its values and call RequestAccess again. Anytime you are changing anything within the connection string, you will need to call UnRegister first to clear any existing configuration.

This is not a supported scenario at all, but in theory, could work. Best of luck.

[jmichas]

It appears that Shiny.Push.AzureNotificationHubs.AzureNotificationConfig properties are read-only.
Any other thoughts?
Is there a way to access the DryIoc container and unregister/reregister the AzureNotificationConfig?

[jmichas]

Cool, thanks for the quick reply. I will give it a shot!

[jmichas]

For any who are interested here is how I accomplished this:

await _pushManager.UnRegister();

//var azureCfgBefore= ShinyHost.Resolve<Shiny.Push.AzureNotificationHubs.AzureNotificationConfig>();

var container = ShinyHost.ServiceProvider as DryIoc.Container;
var azureConfig = new Shiny.Push.AzureNotificationHubs.AzureNotificationConfig(_configuration.NotificationHubSettings.ListenConnectionString, _configuration.NotificationHubSettings.NotificationHubName);

container.Unregister(typeof(Shiny.Push.AzureNotificationHubs.AzureNotificationConfig), DryIoc.DefaultKey.Value, DryIoc.FactoryType.Service, (f) => true);

var factory = new DryIoc.DelegateFactory((DryIoc.IResolverContext r) => azureConfig, new DryIoc.SingletonReuse(),knownImplementationType: typeof(Shiny.Push.AzureNotificationHubs.AzureNotificationConfig));
container.Register(factory, typeof(Shiny.Push.AzureNotificationHubs.AzureNotificationConfig), DryIoc.DefaultKey.Value, DryIoc.IfAlreadyRegistered.Replace, false);

//var azureCfgAfter= ShinyHost.Resolve<Shiny.Push.AzureNotificationHubs.AzureNotificationConfig>();
var result = await _pushManager.RequestAccess();

You can set some breakpoints and inspect the azureCfgBefore and azureCfgAfter to see if it worked.

Also, this is for Shiny 2.2, not sure if it works in more recent versions.

[jadenrogers]

Sorry to but in. I had a similar need and just prefixed the registration tags. Eg in test mode the tag was $"TEST_{UserId}" and so on but I didn't have to worry about changing the hub registration.

[jmichas]

@jadenrogers No butts, thanks for the input. 😄
So, you didn't have any worries about a test notification leaking to production users? Your solution may work, I need to think it through a bit to make sure I'm not overlooking something.

[jadenrogers]

@jmichas I found it more problematic when switching out hubs connection strings when investigating issues. Did they register to the right hub etc. 1 Hub you have eliminated a possible pain point.

I wasn't concerned about prod messages leaking out as I used 1 method the build up the tag, the environment portion is read from the app.config so it's not like you can use the method incorrectly. The only risk was the app.config value having the wrong "env" setting in prod which is just as possible as having the wrong hub connection string in prod IMO so both scenarios require some serious oversight.

Food for thought :-)

[jmichas]

@jadenrogers Awesome! Thanks for taking the time to explain. I think I will just set my user roles as tags then and on the service side do what you said. Makes better sense for sure.

@aritchie Do you think this is something that could be supported in the future? I mean, a hub endpoint can support multiple "hubs" so being able to register multiple PushManagers or at least changing the hub name on the fly might be useful. Or maybe I just live in "Edgecaseville"

[aritchie]

@jmichas Definitely not. Too many issues can arise with this. You are best to implement your own provider on IPushManager to deal with all of the business cases you have there.