Welcome to the final part of this review of the Pluralsight course Android Programming with Intents by Jim Wilson
Jim has over 30 years of software engineering experience, with the past 15 years heavily focused on creating mobile device and location-based solutions. He has co-founded multiple software-related startups and has served in a consulting role at several more.
After nearly a decade as a Microsoft Device Application Development MVP, Jim now focuses on developing Android and iOS device applications. Jim’s passion is mentoring software developers. He blogs at hedgehogjim.wordpress.com.
Android Programming with Intents is the 6th course in the Pluralsight learning path for Android, and this month I am reviewing every course in this learning path.
Working with Platform Features Through Intents
Changes in system state
This lesson explains how to detect changes in the system state and the environment.
Mostly this is exposed through broadcast intents, and the information we need is accessible through simple action-based filters
Jim talks about many of these. We can monitor for system boot up and shutdown:
We can detect whether a headset has been plugged or unplugged.
We can also detect changes in power state:
Jim says most of these notifications are transient and system notifications are considered passing events.
However some notifications are “sticky”. They are in a persistent state.
There are only a few of these extra important states:
The device is docked
The available storage is low
Jim also discusses registering to receive system events, and this is pretty simple.
We create a broadcast receiver and generally put our intent filter in our manifest with the name of each action we are interested in.
There are however a few cases where we might need to use registerReceiver. These are events that can only be registered for at run time, and this includes ACTION_BATTERY_CHANGED. Jim explains why we need to be very careful about handling this.
ACTION_TIME_TICK can also only be registered for at run time. These notifications are sent every minute.
Demo: Changes in system state
We begin by creating a broadcast receiver to listen for when a device is plugged or unplugged.
We can choose the broadcast receiver Android component to have the code generated for us. However here we see the code written from scratch, starting with a new Java class PlugUnplugReceiver.java which extends the class BroadcastReceiver.
Jim adds an intent filter into the manifest, and this has action filters for ACTION_POWER_CONNECTED and ACTION_POWER_DISCONNECTED.
In PlugUnplugReceiver.java we override the onReceive method, setting a message value according to the received action.
We see that we can simulate these power events by using telnet and opening localhost with the port number for our emulator. This number can be found written as the window title of our emulator window, and is this case is port 5554.
To see all of the available power commands in telnet type:
? power
We see how commands such as power ac on and power ac off result on different messages being displayed in our app.
That’s the first half of this demonstration. In the second half, we learn about using registerReceiver to register at run time (rather than through the manifest).
Jim shows us his BatteryStatus.java helper class and this has a lot of potentially useful functionality.
We see BatteryStatusReceiver.java created, which again overrides onReceive. It makes use of the helper class.
In our activity class we declare this receiver as a class level variable and call registerReceiver, passing in an intent filter with the action filter ACTION_BATTERY_CHANGED.
We also see the use of several other telnet power commands, such as power capacity 75.
Scheduling app components
Sometimes we want to schedule an event to run at a specific time. This is why we have the AlarmManager.
It’s very powerful and allows actions to be performed even when our program isn’t running.
Jim explains the scheduling options we have. We can set it to fire once, repeatedly at exact intervals, or repeatedly at approximate intervals.
Beginning with Android KitKat, the AlarmManager has been made inexact for the purposes of optimizing power usage and battery life.
Also in this lesson Jim introduces the elapsed flags and the RTC flags:
Although the wakeup flags give us more control, they can reduce the battery life of the device.
Demo: Scheduling app components
As with some of the previous demonstrations, we start off with a MyActivity.java and a IntentTargetActivity.java class.
Jim shows us how to write a showActivityIn5Seconds method.
In the emulator we see this does just what the method implies.
Using platform activities, browser and telephone
Many platform features are simply activities, and they’re accessible by sending intents.
Jim explains that in most cases we use startActivity, but if output is expect, for example we want to use the camera, we use startActivityForResult.
We also learn how to display web content in our activity, and this is easy. We set intent data to a “http” or “https” URI and use a Intent.ACTION_VIEW action.
Making phone calls is discussed. Telephone features are exposed to us through the phone Activity.
We can make a phone call directly using ACTION_CALL and this requires the CALL_PHONE permission. You should think carefully about whether the user experience is good here.
In most cases, we will want to use ACTION_DIAL. This displays the phone number to the user with the phone number already filled in.
All the user needs to do is press the connect button. This doesn’t require any security permissions to be set.
Demo: Using platform activities, browser and telephone
The first demo is how to view a website and we see how useful URI.parse is.
The second demo is how to phone home. This uses URI.parse again as well as the ACTION_DIAL. The phone number displays and if we press the green phone icon it connects us to someone named Franklin.
Using platform activities, camera and contacts
We learn about taking pictures with the MediaStore.ACTION_IMAGE_CAPTURE intent action.
Jim explains that we need to override the onActivityResult method, and the image is stored in the extras of the intent. Or rather, a low resolution image is stored there.
If we like, we can write a high resolution image to a file. We pass the file name that we want to the intent’s MediaStore.EXTRA_OUTPUT.
Jim also talks about how to work with the contact list. See ContactsContract.Contacts for full details.
Demo: Using platform activities, camera and contacts
The first demo is on taking a picture. Jim explains request identifiers here and we use startActivityForResult.
We see a handleCameraRequest method that Jim wrote. This uses getParcelableExtra to get the image data.
Jim also explains his getImageFile helper method, which is useful for working with emulators.
Also demonstrated is working with contact lists.
Jim has written another helper method called getContactCommonDataItem which takes care of the details of reading this data.
In the emulator when we press “Select Contact” we see a contact list featuring Buzz, Franklin and other random people.
The End
This concludes this review of Jim’s Android Programming with Intents course. I am continuously adding more Pluralsight reviews and you can find them all here.
Zombie Code Kill 