Push Notifications - Tizen

This article is an overview of how to set up Remote Push Notifications for your games on the Tizen target platform, and is for those users with experience using GameMaker:Studio, as well as experience with web servers and API procedures. 

Note that push notifications are also available for other target platforms, but each one requires it's own unique setup. You can find details for the other available platforms from the links below:

Push Notifications on Android

Push Notifications on iOS

Getting Started

On the Tizen platform, to enable remote notifications you must first get permission from Tizen and have them activate the functionality for you. To request the Tizen push messaging service, send an email to the administrator at push.tizen@samsung.com with all the required details (listed below). When the Tizen Push Service Team approves your request, you will receive an email and from then on you can use the Tizen push messaging service in your game.

The following details are required for the email request to be processed (You can simply copy and paste this and add in the relevantinformation):

Developer information

Email address - Your email address to receive the approval response.
Last name - Your last name.
First name  - Your first name.
Country  - Your country of residence.

Application information

Application ID - The ID of the application package that is using the push service. It is a 10-bytes-alpha-numeric value contained in the <ID> element of manifest.xml file.
Application name - Name of the application that uses the push service.
Testing purpose - Yes or no. If you request the service for testing purposes only, the duration of the push service is limited to 3 weeks.
Purpose of the push message usage - Description of how you plan to use the push service, including the situations in which you want to use it.
App launch date - Application launch date in the format YYYY/MM/DD. For example: 2012/08/01.
Service area / country - Service area (such as Asia, Africa, America, or Europe) or the country where the application is going to be used.
Daily push requests - Estimated total number of daily notifications.
Transactions per second - Estimated peak number of transactions per second (the recommendation is below 100).

Server Implementation

The server side of things is extensively documented by Tizen here: https://developer.tizen.org/...push_server_api.htm Therefore we shall not cover that part of things here. However there are one details that is important to know for the data being sent to your game from your server.

For your notifications to work correctly you will need your Application ID.  This can be found at the end of the compile console when you run your game from GameMaker:Studio, and it is generated from, but not the same as, the App ID in Tizen Global Game Settings General Product Information. To get this ID value, you need to check the compiler window in GameMaker:Studio for the following:

On the Tizen Native target platform, look for "C:\tizen-sdk"\tools\ide\bin\native-run -p 333843A0A4" where the part in bold is the Application ID for the native game.

On the Tizen JavaScript (JS) target platform, you need to look for "9247C1492F.RedRoom launch successful", or similar, at the end of compile, where the part in bold is the Application ID for the JS game. 

When a notification is received by GameMaker:Studio, and the game is run, it will generate an Asynchronous Event (further details are given below) where the “data” key of the generated ds_map will be in the form of a JSON string.

For development of your game, you can use your PC as the server but for production use, you need at least something like a VPS (Virtual Private Server), as a cheap shared hosting account is just not good enough. You need to be able to run a background process on the server, install an SSL certificate, and be able to make outgoing TLS connections on certain ports.

Example

The following is an example JSON http post that was made (for testing) using the PostMan Google Chrome extension

POST /spp/pns/api/push HTTP/1.1
Host: apnortheast.push.samsungosp.com:8088
appID: 5771C6A5E2
Content-Type: application/json
appSecret: 4B130F5DC03A21185558332744A92D
Cache-Control: no-cache

{ "regID":"04a1c1555ca11cea2dd42bf0cdbd03a4778ca29836abd7a2e2bf28dc00ab6e4563d771ed3330d7804eebb13ebd", "requestID":"000022", "message":"badgeOption=INCREASE&badgeNumber=1&action=ALERT&alertMessage=wakeup2", "appData":"app not running again 2" }

In your Asynchronous Event, the value of "appData" above is received in the "data" key of the ds_map if successful.

GameMaker:Studio

There are no functions in GameMaker:Studio to directly deal with remote notifications, as they must all be generated by your server and handled by the respective Service Providers. However, once set up correctly, GameMaker:Studio games will receive these notifications, which can then be dealt with in the Asynchronous Push Event, as you would a local notification.

For all available platforms (once you have done the necessary set-up) when the game is run on a device it will register that device with the platforms push notification service. This will trigger an Asynchronous Push Notification Event, and the ds_map key "type" will have the value "register" as well as a new key, "reg_id", containing the registration id for the user device. 

You must then send this registration id to your server. Your server must maintain a list of ids for registered devices, as when when you send a push notification message from your server, you use these stored registration ids to send the message to the individual devices (every device that your game is installed on will have a unique registration id).

NOTE: There is no guarantee that remote push notifications will be delivered, and that the allowed data payload for each notification is fairly small.

The Asynchronous Push Event

The Push Notification Event is one that is triggered by the call back from push notifications. It generates a ds_map (more commonly known as a "dictionary") that is exclusive to this event and is stored in the special variable async_load. This ds_map has the following keys:

"type": Value can be "local" for a device local notification, "remote" for a remote notification, or "register" for remote notification registration.

"status": Value will be "1" for success or "0" for an error.

There may be additional key entries based on the "type" returned and the "status" value. For "status", if an error has been returned ("0"), then you will also have the following key:

"error": Contains details of the error received.

If the "status" value is 0 (ie: no errors) then the ds_map will contain the following additional values, depending on the value of the "type" key:

"reg_id": If the "type" received was "register", then this key will hold the device registration id for remote notifications.

"data": If the "type" received was "local" or "remote", then this key will hold the string payload that you defined when you called the notification function.

In the event itself you would handle the callback something like this:

var type = ds_map_find_value(async_load, "type");
var status = ds_map_find_value(async_load, "status");
if status == 0
   {
   //error of some kind
   var error = ds_map_find_value(async_load, "error");
   show_debug_message("error=" + string(error));
   }
else
   {
   if type == "register"
      {
      var reg_id = ds_map_find_value(async_load, "reg_id");
      //post reg_id to your server
      }
   else
      {
      var data = ds_map_find_value(async_load, "data");
      //Decode the JSON data and perform any actions according to the contents
      }
   }

Have more questions? Submit a request

0 Comments

Article is closed for comments.