Notifications and Services Landon Cox March 28 2017

Notifications and Services Landon Cox March 28, 2017

Networking so far • Volley (retrieve quiz stored at URL) • User starts app • Check with server for new quiz • Say you’re building a messaging app … • How else might you use the network? • Are the workflows different than those we’ve seen?

How do we keep device data fresh?

Solution 1: polling • Basic idea • App periodically sends message to server • Asks, “is there anything new for me? ” • Very simple to implement • Create a timer • When timer fires, exchange messages with server • What’s the problem?

Impact of polling on battery • Network power • • • Assume radio stays in high-power state for 10 sec. • • • Energy per LTE poll: 1500 m. W x 10 seconds = 15 Joules 5 min frequency: 480 J/day 30 sec. frequency: 4800 J/day Total Pixel battery: ~40 k Joules You probably have more than one app that needs to sync • • LTE: 600 – 1700 m. W Wi. Fi: 77 – 130 m. W If you have a lot of apps, your radios will always be in a high-power state Choosing the right period right is difficult • • Check too often and drain the battery with useless messages Check too infrequently and user experience will suffer http: //dl. acm. org/citation. cfm? id=2307658

Every outgoing query will put the radio in a high-power state.

Solution 2: push notifications • Share persistent network connection across apps • • • Device and server maintain (TCP) connection Radio can enter low-power state when no updates Server pushes updates to device Device can push updates to server Updates should be small (< 4 KB) • On-device service routes updates to apps • Example: Firebase Cloud Messaging (FCM)

Share one persistent connection. High-power only when data is ready.

Firebase cloud messaging (FCM) • Formerly Google Cloud Messaging (GCM) • On your device • Google Play Services (global, maintains connection to cloud) • Firebase. Instance. IDService (per app, receives instance ID) • Firebase. Message. Service (per app, receives notifications) • In the cloud • Firebase (routes messages to app server, devices) • App server (stores data, manages messaging)

Firebase cloud messaging (FCM) • Formerly Google Cloud Messaging (GCM) • On your device • Google Play Services (global, maintains connection to cloud) • Firebase. Instance. IDService (per app, receives instance ID) • Firebase. Message. Service (per app, receives data) • In the cloud • Firebase (routes messages to app server, devices) • App server (stores data, manages messaging) Next time

Services • Service • Performs tasks on main thread: on. Start. Command • Defined as an app component • Because it is a component, it is externally visible • Who schedules most work on threads? • Code already running inside our app

Services • Service • Performs tasks on main thread: on. Start. Command • Defined as an app component • Because it is a component, it is externally visible • Why might external visibility be useful? • Allows processes to communicate with each other

Services • Service • Performs tasks on main thread: on. Start. Command • Defined as an app component • Because it is a component, it is externally visible • Why are services essential for FCM? • Gives Google Play Services a place to send messages • Forward new data from Firebase to app’s Service

Services • Service • Performs tasks on main thread: on. Start. Command • Defined as an app component • Because it is a component, it is externally visible • Need to add Service to Android Manifest Android. Manifest. xml: <application … <service android: name=“. My. Service” /> />

Services • Example Service • Create a subclass of Service • Use a worker thread to process IPC requests • Handle requests serially public class My. Service extends Service { protected int on. Start. Command(Intent intent) { // process IPC request } What } thread does this run on?

Services • Example Service • Create a subclass of Service • Use a worker thread to process IPC requests • Handle requests serially public class My. Service extends Service { protected int on. Start. Command(Intent intent) { // process IPC request } } What is an Intent?

Quick Intents review

Displaying a web URL How does Android know which components could receive this Intent? Intent browser. Intent = new Intent(Intent. ACTION_VIEW, Uri. parse(" http: //www. google. com/images? q=duke ")); start. Activity(browser. Intent);

Intent filters Restricts which actions the Activity will accept (Intent Action must match) <activity android: name=". Main. Activity"> <intent-filter> <action android: name="android. intent. action. MAIN" /> <category android: name="android. intent. category. LAUNCHER" /> </intent-filter> </activity>

Intent filters <activity android: name=". Main. Activity"> <intent-filter> <action android: name="android. intent. action. MAIN" /> <category android: name="android. intent. category. LAUNCHER" /> </intent-filter> </activity> Describes categories of Intent Activity accepts (Intent categories must match all)

Implementing My. Service • We can do this! • Tools to use • Handler • Looper • Handler. Thread • Useful to peak under the FCM hood

Implementing My. Service public class My. Service extends Service { private Looper m. Looper; private Service. Handler m. Handler; protected void on. Create() { // on which thread does this code run? } protected int on. Start. Command(Intent intent) { // on which thread does this code run? } private class Service. Handler extends Handler { public Service. Handler(Looper l) { super (l); } public void handle. Message(Message m) { … } } } https: //developer. android. com/reference/android/app/Service. html What needs to happen?

Implementing My. Service public class My. Service extends Service { private Looper m. Looper; private Service. Handler m. Handler; protected void on. Create() { Handler. Thread thread = new Handler. Thread(…); thread. start(); // Get the Looper and use it for our Handler m. Service. Looper = thread. get. Looper(); m. Service. Handler = new Service. Handler(m. Service. Looper); // on which thread does this code run? } … private class Service. Handler extends Handler { public Service. Handler(Looper l) { super (l); } public void handle. Message(Message m) { … } } }

Implementing My. Service public class My. Service extends Service { private Looper m. Looper; private Service. Handler m. Handler; protected void on. Create() { // on which thread does this code run? } protected int on. Start. Command(Intent intent) { // on which thread does this code run? } private class Service. Handler extends Handler { public Service. Handler(Looper l) { super (l); } public void handle. Message(Message m) { … } } } What needs to happen?

Implementing My. Service public class My. Service extends Service { private Looper m. Looper; private Service. Handler m. Handler; … protected int on. Start. Command(Intent intent) { Toast. make. Text(…). show(); // For each start request, forward the Intent Message msg = m. Service. Handler. obtain. Message(); msg. arg 1 = intent; m. Service. Handler. send. Message(msg); return 0; // on which thread does this code run? } … }

Implementing My. Service public class My. Service extends Service { private Looper m. Looper; private Service. Handler m. Handler; Lucky for you, you can just subclass Firebase Services! protected void on. Create() { // on which thread does this code run? } protected int on. Start. Command(Intent intent) { // on which thread does this code run? } private class Service. Handler extends Handler { public Service. Handler(Looper l) { super (l); } public void handle. Message(Message m) { … } } }

Firebase services • Firebase. Instance. IDService • Why does each app instance need a unique ID? • Who manages mapping from users to instance IDs? • Firebase. Message. Service • What should happen if your app is in the foreground? • What should happen if your app is in the background? • Note: you will likely need to update via SDK manager git clone https: //github. com/firebase/quickstart-android. git