Today, let’s continue the topic of beautiful mobile products called widgets. We already presented to you a list of best Android widgets, now why don’t we explore how to actually make widgets on Android?
Widgets are an essential part of our Home and Lock screen customization. They simplify for us the process of accessing certain apps on our devices. If you still don’t have a clue how to find widgets on Android and use these little helpers, check out this quick tutorial. What’s more exciting is that the modern smart- and iPhones couldn’t be imagined without widgets! And here is an excellent opportunity for any developer to make a widget app for Android platform.
Now, we should proceed with the actual development procedure.
All widgets for Android platform have one particular scheme of making. We’ll cover the basics of making a simple widget that could win its place on the user’s Home screen.
Keep in mind, that it’s not an established order of your actions. A developer can create these files and classes in any specific line he wants, but it helps when one has a clear idea of how a product would look like before the building process will start.
For defining the AppWidgetProviderInfo object, you have to create a res/xml folder and then create a new XML layout inside this directory. This is going to be our AppWidgetProviderInfo file, so open it and set its root element to <appwidget-provider>. Now specify all the data:
Some explanation for the used attributes:
Here you’ll define the methods that will be called during the widget’s lifecycle. This section is also responsible for the code you’ll create to update a widget. The AppWidgetProvider class extends BroadcastReceiver as a convenience class. It handles only the relevant widget’s event broadcasts (updated, deleted, enabled, disabled). When such events happen, an AppWidgetProvider receives the next method calls:
1) Called for updates at updatePeriodMillis intervals. 2) And when a user adds the widget, so the essential setup should be performed. However, it’s possible only if you didn’t declare a Configuration Activity, which is responsible for updating sequences.
Called when the widget is placed in for the first and always it’s resized (starting from Android 4.1).
Called when a widget is deleted from the App Widget host.
Called an instance the widget is created for the first time.
Called when the last instance of a widget is removed from the Home screen.
Called for every broadcast and before each of the above methods. Usually, you don't have to implement this one because the AppWidgetProvider filters by default all broadcasts and calls as appropriate.
So, create a new Java class that extends the AppWidgetProvider class and override its update methods. For example:
Also, you must declare your AppWidgetProvider class implementation as a broadcast receiver using the <receiver> element in the AndroidManifest. We’ll discuss it later.
Any layout should be nice-looking and correctly functioning across a wide range of different devices. But when it comes to widgets you have to remember that its layout has to be as flexible as possible, however, not stepping out of screen’s boundaries.
So, widget’s layout is defined in the same way as for any Activity: in an XML layout resource file with all the UI elements which a developer wants to use. Yet, there is a major difference – widget layouts are based on RemoteViews, so you have limited options in term of development tools. When you’re creating an Android widget, you can only use the layout classes that are supported by RemoteViews:
And such widget classes:
Anything else is not supported. In addition, RemoteViews also tolerates ViewStub – a zero-sized, invisible View.
About that AppWidgetProvider class declaring we mentioned in Step 2. So, it would look like this:
An <intent-filter> contains the <action> element with the android:name. It defines that an AppWidgetProvider accepts the ACTION_APPWIDGET_UPDATE broadcast. This is one you have to explicitly declare!
The <meta-data> specifies the AppWidgetProviderInfo resource and requires: 1) android:name for the metadata name. The android.appwidget.provider is used as the AppWidgetProviderInfo descriptor to identify the data. 2) An android:resource defines the AppWidgetProviderInfo resource location.
As is customary, widgets shouldn’t extend to screen edges and be visually flush with other widgets. Android 4.0 automatically gives widgets a padding between a widget frame and the bounding box for a better alignment with other stuff on user's Home screen. It's easy to code a single layout with custom margins for previous platform’s versions and no extra margins for Android 4.0 and higher. Here is a way.
This step is necessary only if you plan to let the users configure some settings after adding your widget. This Activity allows you to play with such available settings as update period, color, size, etc. After the code is done, the App Widget host will automatically launch a Configuration Activity (CA) with the ACTION_APPWIDGET_CONFIGURE action. So, this Activity needs to accept such Intent.
Then, declare it in your AppWidgetProviderInfo file with the android:configure attribute (CSS) like this:
Keep in mind that when the App Widget host calls the CA it must always return a result that includes App Widget ID. This ID has to be passed by the Intent that launched the Activity (EXTRA_APPWIDGET_ID in the Intent extras).
The first rule says – don’t update too often! In your configuration file, you specify a fixed interval for updates which would be performed automatically (the smallest one is 1800000 milliseconds (30 min)). If the device is asleep at the needed time then it’ll wake up in order to activate updates. Note that the higher update frequency will be the faster a battery will be drained, and you don’t want this to scare off the customers.
There are two general methods to update a widget:
Since the first one is more common and easy way, let’s see an example:
After you set up the widget to respond to the APPWIDGET_UPDATE intent, go on and update your AppWidgetProvider class code. There you’ll specify how often you this calls will be sent and how your widget should deal with these intents when they occur.
As we mentioned in the beginning, when you build a product you absolutely must test it to see if it works appropriately. Take a couple of devices with different screen configurations and install your App Widget. Check its layout optimization for particular screen size, the view in portrait and landscape mode, and resize parameters. If you find that a widget is acting weird in a certain condition, then you should consider making some changes in your layout or update section. Maybe, you need different minimum size values?
Summing it all up, make sure, you follow this path:
For a more thorough guide on widget making and a code sample, check out this awesome tutorial by JessicaThorns.