Read The Fucking Source Code

The introduction

  • Android AppWidgets are relatively unpopular.
  • Straight to the point a picture, complex problems poached cattle.

1. The introduction of AppWidget

  • Android widgets, also known as desktop plug-ins, are part of the Android application development layer, but have special uses and can be the highlight of the entire Android system. Appwidgets in Android are not the same as Google widgets and China Mobile widgets. Appwidgets here are just a way to embed a control from one process into another process’s window.
  • The service core of an AppWidget is in AppWidgetService, which is the system application in the SystemServer process.
  • The app provides the AppWidget (for most app developers, understanding the actions is enough).
  • The display side of an AppWidget, which basically runs in the Launcher.
  • Controls supported by AppWidget are limited, such as RecyclerView is not supported.
  • RemoteViews is used in Android in the following scenarios: custom notification bars and desktop widgets.

2. AppWidget provider

Appwidget Provider

2.1 the provider XML

XML manifest file appWidget-provider

  • MinHeight and minWidth define the minimum height and width of the Widget (widgets can be stretched to resize).
  • PreviewImage defines the icon to display when the widget is added.
  • InitialLayout defines the layout used by the widget.
  • UpdatePeriodMillis defines the period in milliseconds during which the widget is automatically updated.
  • ResizeMode specifies rules for resizing widgets. The value can be horizontal, vertical, or None. Horizontal means that the widget can be stretched horizontally, vertical means that the widget can be stretched vertically, and None means that the widget cannot be stretched. The default is “None”.
  • WidgetCategory specifies where the widget can be displayed: on the Home Screen, lock Screen, or both. Its value can be home_screen or keyguard. Android 4.2 introduced.

2.2 the Provider overloading

AppWidgetProvider overloads the method

  • OnUpdate () This method is called when a Widget is added or updated. We mentioned above that widgets can be periodically updated by configuring updatePeriodMillis. However, when android:configure is declared in the widget’s configuration file, the onUpdate method is not called when the widget is added.
  • *onAppWidgetOptionsChanged()* This method is called when adding a Widget or changing the size of the Widget. In this method we can also selectively show or hide certain controls depending on the size of the Widget.
  • OnDeleted (Context, int[]) This method is called when the control is deleted.
  • OnEnable (Context) is added first to the screen.
  • OnDisabled (Context) Removes the last widget from the screen.
  • OnReceive (Context, Intent) is called when a broadcast is received.

2.3 the Provider summary

Experience with AppWidgetProvider

  • As the implementer of AppWidgetProvider, it is important to implement the onUpdate function, because this function determines how the widget will be displayed, without which the widget would not appear at all.
  • The implementation of onUpdate basically follows the following flow:
    • To create a RemoteViews.
    • Call the updateAppWidget of AppWidgetManager to update the widget.

3. Display side of AppWidget

3.1 AppWidgetHost

  • AppWidgetHost is the place to actually control the widget. Note that the widget is not a separate UI application. It must be parasitized in an activity so that AppWidgetHost is implemented in order for the application to support widget parasitize.
  • It has two main functions:
    • Listen for events from AppWidgetService.
    • Another function is to create an AppWidgetHostView.
  • RemoteViews are not a real View, but a description of the View, while AppWidgetHostView is a real View. AppWidgetHostView is created and AppWidgetService is used to query the RemoteViews corresponding to appWidgetId. Finally, pass RemoteViews to AppWidgetHostView to update The AppWidget.
  • AppWidgetHost and AppWidgetHostView are the two base classes defined in the framework. Applications can leverage these two classes to implement their own hosts. Launcher is the default desktop, which is an implementer of Host.
  • AppWidgetHostView is a real View, but it’s just a container to hold the View of the actual AppWidget. The AppWidget View is created based on RemoteViews’ description.

3.2 Launcher3 example

Understanding the use of widgets in Launcher3

  • Launcher3 traverses all widgets in AppWidgetManagerCompat and its subclasses.
  • Through the AppWidgetManager getInstalledProvidersForProfile/getInstalledProvidersForPackage (Android version difference), Gets a collection of AppWidgetProviderInfo.
  • To update to update LauncherAppWidgetHost is responsible for monitoring and create LauncherAppWidgetHostView.
  • LauncherAppWidgetHostView expanded the AppWidgetHostView, realized with long press event processing.
  • LauncherAppWidgetHost expanded the AppWidgetHost, here just overloading onCreateView, create LauncherAppWidgetHostView instance.

3.3 Launcher3 code

Launcher3 core code description

4. AppWidget service providers

4.1 Service Framework

  • AppWidgetService, the core class of the framework, is one of the system services responsible for managing widgets. AppWidgetService handles loading, deleting, timing events, and so on. Boot automatically.
  • AppWidgetService exists primarily to decouple AppWidgetProvider from AppWidgetHost. If the relationship between AppWidgetProvider and AppWidgetHost is fixed, the AppWidget cannot be displayed in any process. With AppWidgetService, the AppWidgetProvider doesn’t need to know where its AppWidget is displayed.
  • The AppWidgetManager is responsible for the actual updates to the Widget view and related management.

5. To summarize

My understanding of the overall AppWidget

Why is the onUpdate () argument appWidgetIds in AppWidgetProvider an array?

  • An AppWidgetProvider may be used in multiple places, and there may be several instances. Array is the existence of multiple instances, which can be updated separately. But generally, there’s only one.

Can the update process of an AppWidget be simplified?

  • Widget update: The provider wraps up the app info + RemoteViews and sends them to the server (these are just info structures, not actually views), and the display listens for callbacks from the server to retrieve the info structures.
  • Although our purpose is to update the View, but we can not use the idea of updating the View to understand, can only use the idea of updating Data to understand.
  • Marv & MA: Frequent updates are definitely not good, because while there is no frequent loading of views on the application provider side, there is no frequent loading of views on the display side, which is why the system sets the minimum passive refresh rate for AppWidgets at half an hour. Afraid of the groom (providing party) drive the horse (show party), the horse dead tired.

The understanding of the RemoteViews

  • RemoteViews is not a real View; it does not implement the interface of the View, but is an entity that describes the View. For example, the resource ID needed to create the View and the event response method of each control. RemoteViews are passed to AppWidgetHost via interprocess communication.
  • Now, we can see that the AppWidget in Android is not the same as the Google widget and The China Mobile widget. The AppWidget here is just a way to embed the control of one process into the window of another process. The View is displayed in another process, but the event handling method is still in the original process.

Brief description of the whole process processing time sequence.

  • AppWidgetService startup: Starts the SystemServer service upon startup.
  • AppWidgetProviderInfo access: AppWidgetService by PMS for registering the ACTION_APPWIDGET_UPDATE (” android. Appwidget. Action. APPWIDGET_UPDATE “) of the static radio scan queries.
  • Meta-data parsing: Query the AppWidget and start parsing the AppWidgetProviderInfo structure from the XML file corresponding to the “AppWidget-Provider” in its configured meta-data.
  • Launcher3 gets Widget information: The Launcher uses the AppWidgetManager to get all the AppWidget information from the AppWidgetService on demand for display.
  • Launcher3 displays Widget information: Launcher creates an AppWidgetHost and uses the Widget information to generate the corresponding AppWidgetHostView for display.
  • Launcher3 Updates Widget information: AppWidgetHost creates a Widget that listens for updates to the AppWidgetService and receives callbacks to display the updates.
  • Passive Refresh of AppWidget: AppWidgetService maintains a minimum update clock of 30 minutes based on AppWidgetProviderInfo’s configuration to send update notifications to AppWidgetProvider.
  • Active Refresh of an AppWidget: The AppWidgetManager is available on the app side for active refresh.

6. The appendix

Framework layer code path and structure

 

Xiaobian blog series

Android Framework family bucket

Recommended Blogs

Android’s official website

Android list Widget development details

Android UI components —-AppWidget control introduction

AppWidget development for Android

The Android Widget

Analysis of Android Launcher’s handling of AppWidgets: AppWidgetHost roles

Android Widget tips

Android Widget Development (part 1)

Why android widgets suddenly stop updating