"Android Development Art Exploration" reading notes (iv)--remoteviews

NO1:

remoteviews Usage scenarios: Notification bar and desktop widgets

No2:

The notification bar is mainly implemented by Notificationmanager 's Notify method.

Desktop Widgets are implemented through Appwidgetprovider , and Appwidgetprovider is essentially a broadcast

No3:

Implementation of the notification can see my other notification notice

The implementation of the Desktop widget can be seen in my other desktop widget development

No4:

Pendingintent 's understanding can be seen in my other article pendingintent

NO5:

The types supported by Remoteviews are as follows:

Layout: Framelayout, LinearLayout, Relativelayout, GridLayout

View: AnalogClock, Button, chronometer, ImageButton, ImageView, ProgressBar, TextView, Viewflipper, ListView, GridView, StackView, Adapterviewflipper, viewstub

Remoteviews does not support their subclasses and other view types , and therefore does not support custom view

NO6:

A series of set methods for Remoteviews is done by reflection .

No7:

Layout files in the notification bar and desktop widgets are actually loaded in notificationmanagerservice and Appwidgetservice , and they run on the system's Systemserver , this is a scenario in which our process forms a cross-process communication

No8:

The role of Remoteviews is to display and update the view interface in other processes .

No9:

The REMOTEVEIWS is passed through Binder to the systemserver process because remoteviews implements the parcelable interface, so it can be transferred across processes , the system will get the resources of the application based on such information as the package name in Remoteviews. The layout file in the Remoteviews is then loaded via Layoutinflater

No10:

The notification bar and desktop widgets are managed by Notificationmanager and Appwidgetmanager , respectively, and Notificationmanager and Appwidgetmanager through binder respectively and systemserver in the process of Notificationmanagerservice and Appwidgetservice for communication.

NO11:

Theoretically, the system can fully support all view and view operations through binder, but it is too expensive to do so because there are too many ways to view it, and a large number of IPC operations can affect efficiency.

To solve this problem, the system does not directly support view's cross-process access through binder, but rather provides an action concept, the action represents a view operation, and the action also implements the Parcelable interface.

The advantage is that there is no need to define a large number of binder interfaces, followed by a large number of IPC operations to improve the performance of the program.

No12:

The remote process uses Remoteviews's apply method to update the view, and the Remoteviews's apply method iterates through all the action objects and invokes their apply method, specifically The view update operation is done by the Action object's apply method .

NO13:

Remoteviews's Apply method first loads the layout file in the Remoteviews (obtained through Getlayoutid) through Layoutinflater, and the layout file is loaded through performapply To perform some update operations.

NO14:

The apply method of the Action object is where the view is actually operated .

NO15:

When calling the set method of Remoteviews, they are not immediately updated with their interface, but must pass through the Notificationmanager notify method and the Appwidgetmanager Updateappwidget to update their interface.

"Android Development Art Exploration" reading notes (iv)--remoteviews