Exploring the story behind Widgets

By he minggui (http://blog.csdn.net/hmg25) reprint please indicate the source

 

Previously, I analyzed the process of adding widgets to laucher. Now we can analyze the stories that happen after widgets are added to laucher.

AppWidgetProvider

 

The group type implemented by the Desktop component. Its parent class is a broadcast receiver, which is used to receive broadcast messages that update the Desktop component and then update the Desktop component.

I.Public VoidOnUpdate (Context context, AppWidgetManager appWidgetManager,Int[] AppWidgetIds ):

Event corresponding to this method:Android. appwidget. action. APPWIDGET_UPDATE,When the Desktop component is updated periodically, it is called. You can find out the onReceive method of the parent class. When the onReceive method of the parent class receivesAndroid. appwidget. action. APPWIDGET_UPDATEThe update method is called.

Ii.Public VoidOnReceive (Context context, Intent intent ):

AppWidgetProvider is a broadcast receiver. The parent class already overwrites this method. When you overwrite this method again, add super. onReceive to your method, otherwise onUpdate will no longer be called

Iii.Public VoidOnDeleted (Context context,Int[] AppWidgetIds ):

AppWidgetProvider receives messagesAndroid. appwidget. action. APPWIDGET_DELETEDThis method is called.

 

 

Each Desktop component is an AppWidget. When you need to implement a desktop component in code, you must first implement the AppWidgetProvider class. When you click the AppWidgetProvider class, you will find that AppWidgetProvider is actually a BroadcastReceiver subclass, that is to say, it is also a broadcast receiver. The content of the Desktop component is updated through the RemoteViews object. When you create a desktop component, the system binds AppWidgetProvider to an AppWidgetId, and then uses AppWidgetManager. the updateAppWidget method updates the RemoteViews object to the corresponding Desktop component.

 

Return to the previous process when adding Widgets. When the Desktop component is added, the system allocates a new AppWidgetId to the Desktop component through the AppWidgetHost. allocateAppWidgetId function. When selecting widgets, you can click the list option to obtain the ComponentName corresponding to the corresponding Desktop component. A ComponentName is uniquely specified by a package name and an AppWidgetProvider class name, and then AppWidgetManager is used. bindAppWidgetId (int appWidgetId, ComponentName provider) binds the previously generated AppWidgetId to one ComponentName, and one ComponentName can be bound to multiple AppWidgetId. So you can place several widgets on the desktop.

An AppWidgetProvider can be uniquely identified by a ComponentName. In a common widget application:

 

// Obtain an AppWidgetManager object <br/> AppWidgetManager appWidgetMgr = AppWidgetManager. getInstance (context); <br/> // create a ComponentName object to obtain the Desktop component widgetIds <br/> ComponentName compName = new ComponentName (context, <br/> ExampleWidgetProvider. class); <br/> // The int [] widgetIds corresponding to ComponentName <br/> int [] widgetIds = appWidgetMgr. getAppWidgetIds (compName ); 

Multiple desktop components may be created on each AppWidgetProvider. Each Desktop component corresponds to an AppWidgetId. To obtain AppWidgetId data of all desktop components on an AppWidgetProvider, You can first create a ComponentName object, set the class name and package name in ComponentName to AppWidgetProvider and package name, and then use AppWidgetManager. the getAppWidgetIds (ComponentName provider) method gets the AppWidgetId list.

Through AppWidgetId, we can operate on the specified widget.

The update of the widget interface is through the RemoteViews day, while RemoteViews is not a real View. It does not implement the View interface, but is just an object used to describe the View. For example, the resource ID required to create a View and the Event Response Method of each control. RemoteViews is transmitted to AppWidgetHost through the inter-process communication mechanism.

AppWidgetHost and AppWidgetHostView are two base classes defined in the framework. Applications can use these two classes to implement their own Host. Launcher is the default desktop, and it is a real-time Host.

LauncherAppWidgetHostView extends AppWidgetHostView to process long-pressed events.

LauncherAppWidgetHost extends AppWidgetHost, which only reloads onCreateView and creates the instance of LauncherAppWidgetHostView.

Remoteviews to update the Desktop component will eventually be executed in the launcher process. There is a handler in the launcher: AppWidgetHost. updateHandler, which is used to process Remoteviews updates. Once we call appWidgetManager. updateAppWidget (appWidgetId, views), AppWidgetHost. updateHandler. the handleMessage event will respond, but note that the event response is executed in the launcher process:

 

 

 

 

 

Switch (msg. what) {<br/> case HANDLE_UPDATE: {<br/> updateAppWidgetView (msg. arg1, (RemoteViews) msg. obj); // execute Remoteviews update <br/> break; <br/>}