Notifications are an important part of Weavy. Whenever something happens that you follow or anyone mentions you or your team, you will be notified. Weavy has built in notifications in the web interface but will also try to push to a mobile device if configured correctly.
/
Mobile Push Notifications
- On this page
Introduction
Weavy Push Notification Providers
How you want to push the notifications is up to you. Weavy has an INotificationProvider provider interface that can be implemented with the service of your choice. We provide a default implementation which is Azure Notification Hubs. You can learn more about the INotificationProvider interface in the Create a Push Notification Provider tutorial.
Sending from Azure Notification Hubs
Sending push notifications from Azure Notification Hubs is the default implementation in Weavy.
Azure Setup
In Azure Portal, do the following:
- Create a new Notification Hub. Select the Free pricing tier for this purpose.
- On the newly created Hub, configure Apple (APNS) and/or Google (GCM/FCM). More information on how to create an Apple push notification certificate and a Google Firebase project can be found here:
Setup for iOS
Setup for Android - On Access Policies, copy the DefaultListenSharedAccessSignature and the DefaultFullSharedAccessSignature for later use when setting up Weavy and the mobile app.
Weavy Setup
Since Azure Notification Hub is the default implemented push notification provider in Weavy, the only thing we have to do is to configure the hubs in the settings. There are two ways of doing this depending if you are running a site locally when developing, or if the site is deployed via the Tenant SDK.
Running the site locally
Add the following to the web.config:
<appSettings>
<add key="weavy.notification-hub-connection-string" value="[DefaultFullSharedAccessSignature]" />
<add key="weavy.notification-hub-path" value="[the last part of the hub path]" />
</appSettings>
Replace [DefaultFullSharedAccessSignature] with the connection string you copied in step 3 above. The hub-path is the last part of the Azure Notification Hub path after the last slash (/). For example, in case of a hub named weavynotifications/weavymobile, the hub path you specify in the app setting should be weavymobile.
OPTIONAL:
The default Azure Notification Hub notification provider in Weavy handles different hubs for notifications in the Spaces and the Messenger.
If you want to configure a separate hub for notification sent from the Weavy Messenger, add a new Notification Hub according the the Azure Setup above. Then add the following settings to web.config:
<appSettings>
<add key="weavy.messenger-notification-hub-connection-string" value="[DefaultFullSharedAccessSignature]" />
<add key="weavy.messenger-notification-hub-path" value="[the last part of the hub path]" />
</appSettings>
Running the site in the Tenant SDK
If the site is up and running in the Tenant SDK, then you have to update the settings on the site from within the Tenant Dashboard (or optionally via the Tenant API).
- Select the site in the site list
- Click on the Settings tab
- Update the following settings. If the setting does not exist, then you should add them:
Setting: weavy.notification-hub-connection-string
Value: [DefaultFullSharedAccessSignature]
Setting: weavy.notification-hub-path
Value: [the last part of the hub path]
Replace [DefaultFullSharedAccessSignature] with the connection string you copied in step 3 above. The hub-path is the last part of the Azure Notification Hub path after the last slash (/). For example, in case of a hub named weavynotifications/weavymobile, the hub path you specify in the app setting should be weavymobile.
OPTIONAL:
The default Azure Notification Hub notification provider in Weavy handles different hubs for notifications in the Spaces and the Messenger.
If you want to configure a separate hub for notification sent from the Weavy Messenger, add a new Notification Hub according the the Azure Setup above. Then add the following settings to the site:
Setting: weavy.messenger-notification-hub-connection-string
Value: [DefaultFullSharedAccessSignature]
Setting: weavy.messenger-notification-hub-path
Value: [the last part of the hub path]
Mobile App Setup
Depending on how you build your app, the registering process is of course a bit different. If you are building the app with Xamarin as the example we provide, you can use the Nuget package Microsoft.Azure.NotificationHubs. More information on this can also be found here.
Please make sure to read through the instructions on the links above to fully understand the process of setting up a notification hub in Azure. When you are done, you should have a Notification Hub with both Android (GCM/Firebase) and Apple (iOS) credentials set and an Access Policy for the DefaultListenSharedAccessSignature.
When you created a new project in Firebase, you should have a google-services.json file that you downloaded. Add (or replace the existing one) in the Android project. Make sure the Build Action is set to GoogleServicesJson. The json file contains all the necessary settings and is automatically merged into the manifest when building the project.
How to register the user?
When sending out notifications from the Weavy web app, the notification is targeted to one or more recipients. Targeting a user is done by utilizing the users guid. This is a unique id for each user in Weavy. So, when you register the user in the mobile app, you have to supply the correct tag. One more thing, Weavy is using a generic template to send out a notifications. This means you have to use the same template when registering the user. See an example below how to get the user and call a register service.
Note! Click here for more information on how to use the Weavy Web View
weavyWebview.LoadFinished += (sender, args) => {
// get the current signed in user
weavyWebview.GetUser((data) => {
var user = JsonConvert.DeserializeObject<User>(data);
var tag = $"uid:{user.Guid.ToString()}";
Task.Run(() => {
DependencyService.Get<INotificationService>().Register(tag);
});
});
};
The INotificationService is a cross platform service that you need to create to call the registering process for each platform. An example of this could be:
public interface INotificationService {
/// <summary>
/// Register with the Azure Notification Hub
/// </summary>
/// <param name="tag">The tag of the user to register.</param>
void Register(string tag);
}
Figure 1. The interface is specified in the shared project
using System;
using Acr.Settings;
using WindowsAzure.Messaging;
using MyApp.Droid.Notifications;
using MyApp.Notifications;
using Android.App;
using System.Threading.Tasks;
[assembly: Xamarin.Forms.Dependency(typeof(AzureNotificationHubService))]
namespace MyApp.Droid.Notifications {
/// <summary>
/// Platform specific implementation for registering to Azure Notification Hub
/// </summary>
public class AzureNotificationHubService: INotificationService {
/// <summary>
/// Register with Azure notification Hub
/// </summary>
/// <param name="tag">The tag of the user to register</param>
public void Register(string tag) {
// get stored token from Firebase Messaging registration process. Store this in a setting when the firebase registration completes.
var token = CrossSettings.Current.Get<string>("token");
// create azure notificaion hub
var hub = new NotificationHub([NotificationHubPath], [ConnectionString], Application.Context);
try {
hub.UnregisterAll(token);
} catch (Exception ex) {
// handle error
}
// notifcation payload template for Android Firebase Messaging
const string template = "{\"data\" : { \"message\" : \"$(message)\", \"badge\" : \"#(badge)\", \"sound\" : \"default\", \"url\" : \"$(url)\" }}";
try {
var result = hub.RegisterTemplate(token, "Template", template, tag);
} catch (Exception ex) {
// handle error
}
}
}
}
Figure 2. Android specific implementation. Replace [NotificationHubPath] and [ConnectionString] with the values from your Azure notification hub.
using System;
using System.Globalization;
using Foundation;
using MyApp.iOS.Notifications;
using MyApp.Notifications;
using WindowsAzure.Messaging;
[assembly: Xamarin.Forms.Dependency(typeof(AzureNotificationHubService))]
namespace MyApp.iOS.Notifications {
/// <summary>
/// iOS implementation of the Notification Service
/// </summary>
public class AzureNotificationHubService : INotificationService {
/// <summary>
/// Register a device to the Azure notification hub
/// </summary>
/// <param name="tag">The user tag to associate the registration with</param>
public void Register(string tag) {
//Get token from APN registration process. Store the token when registration process was completed.
var token = NSUserDefaults.StandardUserDefaults["token"];
var ConnectionString = [ConnectionString];
var SharedKey = [SharedKey];
var NotificationHubPath = [NotificationHubPath];
if (token != null) {
var cs = SBConnectionString.CreateListenAccess(new NSUrl(ConnectionString), SharedKey);
var hub = new SBNotificationHub(cs, NotificationHubPath);
hub.UnregisterAll(token as NSData, (error) => {
if (error != null) {
return;
}
var tags = new NSSet(tag);
var expire = DateTime.Now.AddYears(1).ToString(CultureInfo.CreateSpecificCulture("en-US"));
NSError returnError;
hub.RegisterTemplate(token as NSData,
"Template",
"{\"aps\":{\"alert\":\"$(message)\", \"content-available\":\"#(silent)\", \"badge\":\"#(badge)\", \"sound\":\"$(sound)\"}, \"url\":\"$(url)\"}",
expire,
tags,
out returnError);
});
}
}
}
}
Figure 2. iOS specific implementation. Replace [NotificationHubPath], [SharedKey] and [ConnectionString] with the values from your Azure notification hub.
Sending from other providers
Want to use another provider or service to handle push notifications? No problem! Take a look at the Create a Push Notification Provider tutorial to learn more about creating a push notification provider.
weavy.com