Moodle Mobile Push Notifications

Goal

Moodle Mobile should receive Moodle messages as push notifications on iOS and Android.

Use case

currently implemented use case

1. the app contacts Apple push notification server to get its device token (it's done by the mobile app PushPlugin plugin that itself uses Cocoa API)
2. after login on the site, the app gets an Airnotifier access key from the site. (this access key is currently the same for each site => meaningless). It's done calling the webservice message_airnotifier_get_access_key(permissions). create_token is the only possible permission.
3. the app sends its token to Airnotifier server - it's done by a HTTP POST request.
4. the app registers its device to the site - it's done by a ws call message_airnotifier_add_user_device(appname, devicetoken, devicename)
5. Airnotifier provider (Moodle site) sends a payload message for a specific device token to airnotifier server - it's done by a HTTP POST

brainstorming use case

1. during Airnotifier provider installation, the site contacts Airnotifer server to request an access key for itself + an access key for the devices (to send their device token to Airnotifier server).
2. the app contacts Apple push notification server to get its device token.
3. after login on the site, the app get an access key from the site to add its token to airnotifier. It's done calling the webservice message_airnotifier_get_access_key(type). An admin could request the site access key, the others only get the device access key.
4. the app sends its device token to Airnotifier server indicating the site url (so airnotifier knows the device/site couple, and so Airnotifier can allow site broadcast) - it's done by a HTTP POST request.
5. the app registers its device to the site - it's done by a ws call message_airnotifier_add_user_device(appname, devicetoken, devicename)
6. during this web service, the site confirms the device token to Airnotifier. It's done by a HTTP POST request. Airnotifier server deletes unconfirmed device tokens older than one minute every hours.
7. Airnotifier provider (Moodle site) sends a message for a specific device token to airnotifier server - it's done by a HTTP POST
8. Airnotifier checks Apple feedback service every hour and delete the unactive device tokens.
9. When the Airnotifier provider tries to send a message to a deleted device, it stores the error and send a unique alert to the device user. The device is disabled. After a month, the cron processes delete the device.

Payload content

The current payload content would need a bit of brainstorming. We need to identify what to send as it is extremely short. The app will behave following the content it receives.

Apple

The Apple payload is limited to 256bytes and it includes everything sent. Our current implementation is still quite of a wip: {type:'moodle_instantmessage',id:'8',urlparams:'{"user":"2","id":"8"}',userfrom:'Manager Moodle',date:'1367477362',alert:'This is a message text.',}

GCM

The Apple payload is about 4Kb. As it's more more permissive than Apple, it is not an issue. The content will be the same than Apple ones, just the format changes.

Deliverables

• push notification support on the mobile app - the app receives the push notification and behaves correctly.
• The Airnotifier server - it sends notification to APNS / GCM.
• The Airnotifier provider - it sends Moodle messages to Airnotifier - MDL-36445

Airnotifier messaging provider

In your messaging setting page you can select which of your devices can receive push notifications. MDL-36445 The provider has usual messaging provider settings.

Airnotifier server

To install the server follow: https://github.com/dongsheng/airnotifier/wiki/Installation

Need to be done:

• feedback - MOBILE-191
• load stress - Done
• IP banning - Done MOBILE-192
• Site broadcast (site keys) MOBILE-395
• DDOS attacks
• iOS support - Done
• Android support MOBILE-396

App push notification support in the mobile app

1. Get the token from Apple (through phonegap PushPlugin)
2. Send the token to Airnotifier server (+ site url). See https://github.com/dongsheng/airnotifier/blob/master/test/token_create.sh. Currently it's not possible to link the site url to the token.
3. send the token by web service to the Moodle site.

The app is closed or is running in the background

It's a normal OS notification. The user can open the app from it. We need to define what happens when we open the app.

The app is opened

The app displays a notification popup. Or better, it's a small temporary notification message at the top that retarct by itself - less intrusive.

Risks

These risks have been raised by Dan in MDL-36445:

• Have we load tested it with large numbers of users/notifications?
• What is stopping someone downloading Moodle getting the keys to DOS our push notification service (surely blacklisting us with apple)
• If someone gains access to device ids, could they then use our service to spam users?
• Are we checking the 'feedback service' and removing devices which no longer exist, apple ominously writes "Note: APNs monitors providers for their diligence in checking the feedback service and refraining from sending push notifications to nonexistent applications on devices."

Improvements

See Apu's comment in https://tracker.moodle.org/browse/MDL-36445?focusedCommentId=200343&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-200343. Specially the mention about language.

Payload content

The current payload content would need a bit of brainstorming. We need to identify what to send as it is extremely short. The app will behave following the content it receives.

Apple

The Apple payload is limited to 256bytes and it includes everything sent. Our current implementation is still quite of a wip: {type:'moodle_instantmessage',id:'8',urlparams:'{"user":"2","id":"8"}',userfrom:'Manager Moodle',date:'1367477362',alert:'This is a message text.',}

GCM

The Apple payload is about 4Kb. As it's more more permissive than Apple, it is not an issue. The content will be the same than Apple ones, just the format changes.