In the previous installment of this blog series, we talked about setting up a service to talk to the MetaWear board. In the app, we flash and change the colors of the LEDs on the t-shirt by sending broadcast intents from the activity to the service. But, wouldn’t it be cool if the colors could change when we receive tweets, likes or mentions on social media? As it turns out, Twitter can send Android notifications that we, in turn, can listen to in the app. Let’s take a look at the details of setting this up.
Overriding NLServiceReceiver
Previously, we set up a service to override NotificationListenerService. This yields us a method called onNotificationPosted, which gets called whenever a new Android notification is received on the device. The method passes in a StatusBarNotification object. A Twitter notification always has a packageName of com.twitter.android and its .notification.extras includes a field called “android.text” that contains a string with the name of the intended Twitter account. Using this, we’re able to look at the notification and respond to Twitter notifications for specific accounts that we wish to monitor.
For example, if our Twitter client is logged in to both our @rubyfuza and @lgleasain accounts and someone tweets at @rubyfuza, the message will come in with a packageName of “com.twitter.android” and an “android.text” field under .notification.extras with the text “@rubyfuza”.
override fun onNotificationPosted(sbn: StatusBarNotification) {
val i: Intent = Intent(ACTIVITY_NOTIFICATION);
i.putExtra("notification_event", "onNotificationPosted :" + sbn.getPackageName() + "\n");
if (sbn.packageName.equals("com.twitter.android")) {
// turn into rubyfuza
Log.i(TAG, "aaaand the text is " + sbn.notification.extras.get("android.text"))
if (sbn.notification.extras.get("android.text").equals("@rubyfuza")){
Log.i(TAG, "sending ruby intent")
val i: Intent = Intent(SERVICE_NOTIFICATION)
i.putExtra("command", "ruby")
sendBroadcast(i)
}
}
}
Note that we cannot directly call MetaWear methods in this service because it will throw a threading exception. Instead, we send a broadcast intent with an extra field called “command”, which has the value “ruby”. The broadcast receiver that we talked about before will receive the intent and send a command to flash the LEDs.
In a typical application we’d probably set this up in its own service, but NLServiceReceiver requires application permissions that can be enabled via Settings->Sound¬ification->Notification access. When you enable notifications for the app, it starts the service, and when you disable notifications, it ends the service. Normally, you’d add a control to the main application in order to start and stop the service. However, since this is a proof of concept wearables project, we kept them together to ensure that a bug doesn’t cause the service to consume more battery when we’re not using the shirt. You can find a video of what we have so far over here.
Stay tuned for the next post when we’ll talk about adding AndroidWear support to the app.
About Me: I am a Atlanta based, native Android/IOS developer with AngularJS/Ruby experience and am founder of Polyglot Programming Inc.. Many of my projects focus on IOT and Wearables. You will often find me purr programming and I regularly speak at conferences around the world. I am available for hire! More Posts
Follow Me:
I am a Atlanta based, native Android/IOS developer with AngularJS/Ruby experience and am founder of Polyglot Programming Inc.. Many of my projects focus on IOT and Wearables. You will often find me purr programming and I regularly speak at conferences around the world. I am available for hire!