Hi Inosh, Instead of letting the app to fetch the operation from the IoT/EMM server (step 7 in the diagram), is it possible to attach the operation information also in the wakeup message itself? The FCM size limit of 4096 bytes will be enough to attach most of the basic operation payloads such as ring operation, mute operation, etc. That will reduce the amount of communications the app needs to do with the sever to execute an operation. Perhaps after doing the operation, the app may send a 'delivery report' to the IoT/EMM server if the delivery report of FCM is not enough to prove the completion of the operation sent to the app.
Thanks. On 30 November 2016 at 22:58, Inosh Perera <ino...@wso2.com> wrote: > > Hi Dilan, > > [1] Are we bringing FCM as a replacement for GCM or as another Push Notification Mechanism that can be enabled apart from GCM ? >> >> FCM is a replacement for GCM. With deprecation of GCM(1), we have moved to FCM. > > > [2] If as a replacement, what advantages are there with FCM over GCM ? >> >> Firebase platform has more features compared to GCM(2) which we can be utilised in the future for example crash reporting. >> >> FCM has an improved message delivery speed which is said to be 95% of total messages be delivered within 250ms(3) >> Firebase is cross platform(4) >> >> > > [3] When it comes to Google-services.json, It seems that it is required to obtain a separate Google-services.json + FCM server token per each production deployment and > compile the agent embedding this file. If that's the case here, cannot we achieve the same without letting a user to compile the source ? > Each customer need to compile the agent and have this file available in the root directory as mandated by Google(5). If this is not available, Android studio will not allow you to compile the agent/any other app that uses FCM. > > what if the device could retrieve this file at the time of enrollment with the server and we provide this configuration to the server via platform configurations ? >> >> Since this is in source folder, the original json file need to be available at compile time and we cannot replace it on-the-fly at runtime. > > > [4] And at last a general question, architecturally, how FCM differs from GCM ? > As mentioned main differences is in client side. Earlier we defined a key called the sender ID in the platform configurations and this was delivered to the device after authentication. With this ID, we initiated registration with GCM server. However with FCM, there is no sender ID, but all the configurations are stored in a json file we discussed earlier and at the time of app's first initialisation, token retrieval will happen automatically. This token is now called FCM instance ID token which was earlier known as the GCM registration ID. Google has also replaced the earlier "API key" which was used to invoke GCM server with "firebase cloud messaging token" to establish the link with FCM server. FCM instance ID token is provided instead of GCM registration ID when communicating with FCM server. > > (1). https://developers.google.com/cloud-messaging/android/legacy-regid#registration-state-sync-handling > (2). https://firebase.google.com/features/ > (3). https://www.youtube.com/watch?v=sioEY4tWmLI > (4). https://firebase.google.com/docs/cloud-messaging/ > (5). https://firebase.google.com/docs/android/setup > > Regards, > Inosh > > On Wed, Nov 30, 2016 at 9:25 PM, Dilan Udara Ariyaratne <dil...@wso2.com> wrote: >> >> Hi Inosh and All, >> >> Having following questions regarding this feature and the enabling technology : >> >> [1] Are we bringing FCM as a replacement for GCM or as another Push Notification Mechanism that can be enabled apart from GCM ? >> [2] If as a replacement, what advantages are there with FCM over GCM ? >> [3] When it comes to Google-services.json, It seems that it is required to obtain a separate Google-services.json + FCM server token per each production deployment and >> compile the agent embedding this file. If that's the case here, cannot we achieve the same without letting a user to compile the source ? what if the device could retrieve this file >> at the time of enrollment with the server and we provide this configuration to the server via platform configurations ? >> [4] And at last a general question, architecturally, how FCM differs from GCM ? >> >> Cheers, >> Dilan. >> *>> Dilan U. Ariyaratne* >> Senior Software Engineer >> WSO2 Inc. <http://wso2.com/> >> Mobile: +94766405580 <%2B94766405580> >> lean . enterprise . middleware >> >> >> On Wed, Nov 30, 2016 at 3:25 PM, Inosh Perera <ino...@wso2.com> wrote: >>> >>> Hi all, >>> >>> Following is the architecture of FCM implementation of Android agent of IoT/EMM. Firebase cloud messaging(FCM) is a push notification mechanism introduced by Google for app developers to send notifications to devices. Prior to FCM, EMM used Google cloud messaging(GCM) which was the earlier standard for sending notifications to devices. >>> Coming from GCM to FCM, major changes in architecture are in the Agent side implementation compared to server side implementation of EMM. In case of EMM, only a wake up call is sent to a device asking the device to contact the EMM server to fetch new pending operation. Following is a simple illustration of how the mechanism works with FCM. >>> >>> >>> >>> -- >>> >>> *>>> Prerequisites* >>> Using firebase console, a new project needs to be created which will provide the user with Google-services.json file and a firebase cloud messaging token. Google-services.json contains authentication details required to communicate with the Google FCM server. This file needs to be added to Android agent source code's root folder as defined by Google and will be later be used to communicate with FCM server. Firebase cloud messaging token has to be available to IOT/EMM server and this token acts as the API key when sending messages to FCM server. >>> *>>> Things that happen one time* >>> 1. Registration details sending >>>> >>>> When the agent starts up for the very first time, since the FCM related services are implemented in the agent and the Google-services.json is available, FCM services begin an automatic registration process with the FCM server. This call is hidden from the developers to avoid the earlier GCM complexities of handling the registration with the GCM server manually. Device will send the necessery details to FCM server extracted from Google-services.json to register it-self with the FCM server. >>>> >>> 2. FCM instance ID token >>>> >>>> FCM server will keep a record of the device and issue a token for the device, which will be returned and will be automatically persisted by the FCM libraries in the Agent. >>>> >>> 3. Send FCM instance ID token to EMM/IoT server >>>> >>>> Agent will retrieve the persisted token and send it to EMM/IoT server, so that it can send commands to FCM referring the instance ID token of the device. >>>> >>> Now the server has all the details that are necessery to send a message to the device. >>> *>>> Sending a wake up call to device* >>> 4. Whenever a new operation is added against a specific device, IoT/EMM server will send a wake up call to FCM server with the Firebase cloud messaging token and FCM instance ID token. Firebase cloud messaging token will show that the IoT/EMM server has permission to use FCM services and FCM instance ID token specifies to which device the wake up must be sent. >>> 5. FCM server send the wake up call to the device and the Android agent listens to incoming FCM messages. >>> 6. At this point FCM communication is over and as a response to the wake up, the Agent will poll the IoT/EMM server to fetch any pending operations such as ring and will execute it. >>> >>> Regards, >>> Inosh >>> >>> Inosh Perera >>> Senior Software Engineer, WSO2 Inc. >>> Tel: 077813 7285, 0785293686 >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org <Architecture@wso2.org> >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture <https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture> >>> >> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org <Architecture@wso2.org> >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture <https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture> >> > > > > -- > Inosh Perera > Senior Software Engineer, WSO2 Inc. > Tel: 077813 7285, 0785293686 > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org <Architecture@wso2.org> > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture <https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture> > -- Best Regards, *Pasindu Upulwan Jayaweera* Undergraduate, Department of Computer Science and Engineering, Faculty of Engineering, University of Moratuwa. Sri Lanka Web: pasindujayaweera.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
