Appwidget

1. AppWidgetHost (Context context, int hostId)

what is the hostId for?

 

The hostId is a number of your choosing that should be internally
unique to your app (that is, you don't need to worry about collisions
with other apps on the system).  It's designed for cases where you
want two unique AppWidgetHosts inside of the same application, so the
system can optimize and only send updates to actively listening hosts.

 

 

When creating an AppWidgetHost instance, there is a hostId that
> needs to be supplied, what happens if this collides with another
> application's hostId?

You can use any hostId you'd like, and only need to be unique inside
of your package name.  (The system keys them on both the package name
and the hostId combined.)

 

> 2) It seems the only way to obtain an AppWidgetProviderInfo object for
> an AppWidget is to throw the APPWIDGET_PICKER intent.  Is this true?
> Or is there another way I can directly request it from an
> application?  The reason being, I only want a subset of the widgets,
> and I know what packages contain them, so I don't need the picker to
> pop up.

You could walk the PackageManager information yourself and figure out
everyone who provides widgets, but you'll still need to launch the
PICK intent explicitly.  The PICK intent is special because the system
is the only one we trust to bind appWidgetIds to a specific widget
that the user has picked.

We could totally add something like filtering or categories to the
list that PICK exposes to users, but that's a topic for future
releases.

 

> 3) Also, can I pass extra data to the AppWidget's creation activity
> for use when figuring out what to display?

Sure, you can add any extras to the CONFIGURE intent, such as
positioning information.  Most widgets will probably just ignore
extras, but some could take advantage of them.

 

 

> I don't want to
> choose de widget from a list, instead of this, I want to insert a
> specifically widtget, so, is it necessary to use the
> "android.appwidget.action.APPWIDGET_PICK" intent in this case?

The platform only offers that PICK intent, which requires the user to
interactively pick from the list.  Binding to a specific widget is
protected by a permission that can only be granted to platform apps
for the security reasons mentioned earlier.

 

Android之appWidget按钮事件

http://blog.sina.com.cn/s/blog_62c194760100g75u.html

 

 

2.Appwidget

> I don't know how to get the button object from appwidget(get the ture
> layout copy of home screen).

You can't access the actually-inflated layout from your app because it
exists entirely in another process.

 

> I know the RemoteView offeres an interface
> RemoteView.setOnClickPendingIntent,but what I need is
> RemoteView.setOnClickListener(R.id.delete,OnClickListener)

You can't setOnClickListener() directly, because the target View lives
in another process.  If this were allowed, the other process would be
executing your code as itself, which is a security hole.

 

 

 

> actually add multiple instance of the same widget to the home screen,
> is there a way to prevent this?

You probably don't want to enforce a limit like this, because your
widget might be installed on several home screen apps.  Also, you can
delete widgets by long pressing on them and dragging to the delete
tab.

 

> Also I am looking into buliding my own app widget container, not a
> home screen replacement, just a container that can host other widgets,
> I read the appwidgethost api doc, is there any sample code or guide on
> how to use the appwidgethost api, thanks a lot!

The Launcher source code is available, but it can be a little
confusing.  From a high level:

1. Start listening for widget updates using AppWidgetHost .startListening()
2. Allocate an appWidgetId using AppWidgetHost .allocateAppWidgetId()
3. Launch AppWidgetManager.ACTION_APPWIDGET_PICK using
startIntentForResult(), sending along the allocated ID and any
additional details in the extras.  This will show a dialog to the
user, allowing them to pick which widget they want bound to the
appWidgetId you just allocated.
4. When the user is finished, use resultCode to determine if the
binding was successful.
5. Use AppWidgetManager.getAppWidgetInfo() to find details for the
newly-bound widget, including its layout dimensions and any
configuration activity.
6. Launch the configuration activity for the widget, if they provided one.
7. Use the AppWidgetHost .createView() helper to create an
AppWidgetHostView that contains the inflated widget, and insert into
your on-screen layout.
8. When user deletes the widget, call
AppWidgetHost .deleteAppWidgetId() so the system can clean up
resources.