This is the description of AppWidgetHost.startListening():
Start receiving onAppWidgetChanged
calls for your AppWidgets
I can't find any reference to this mysterious onAppWidgetChanged thing anywhere. The only Google hits are quotes from the same piece of documentation.
What is it actually referring to? What does one need to call, override, or implement to get widget updates?
Its very unlikely that you need to implement a Widget host yourself. The home page is an existing Widget Host. Most likely what you are looking to do is Implement a WidgetProvider which basically means extending android.appwidget.AppWidgetProvider and overriding two methods:
onUpdate() and onReceive() some time onEnabled too. You almost never need to implement a Widget host, but if this is your goal please clarify. The widget provider is essentially a broadcast receiver which is designed to run inside widget host (usually home). The widget provider might live for only milliseconds, to process the broadcasted events and processing one of them is mandatory and must be specified in the manifest. To communicate out information the widget provider like any broadcast receiver extends context and can issue startActivity(intent) or startService(intent) I think this is most likely what you need to do unless you really are implementing a Widget Host.
Related
The Android widget documentation (http://developer.android.com/guide/topics/appwidgets/index.html#AppWidgetProvider) seems to indicate that you can set your own broadcast receiver to handle widget activity instead of using the AppWidgetProvider helper class. For reasons of activity/service structure this would be the most convenient way for me to manage the widget I would like to create.
Is it possible to do this with a broadcast receiver registered in OnCreate as opposed to on in it's own class. The trouble, I think, is that it then isn't registered in the manifest, and thus the widget never shows up in the list.
Documentation/examples of this setup are essentially non-existent. Does anyone know if this is possible or have a good example?
Is it possible to do this with a broadcast receiver registered in OnCreate as opposed to on in it's own class.
Not really. In theory, you could have two receivers registered, one in the manifest and one via registerReceiver(). I cannot imagine a scenario in which this would be a good idea, as your activity will not be running all of the time anyway, and so you need the manifest-registered receiver to do everything anyhow.
So what I'm trying to do is just updating an activity's views in intervals like, say, once per second. In this specific case a handful of buttons, and all I want to change is their text. I've read quite a few questions here addressing the same problem, but I seem to be stuck a little more than other people, and I'm going to blame that on my restricted experience with Android (which actually means, I did not understand the solutions proposed, or was unable to identify the core ideas in the sample code, and that this is actually the first time I'm trying to program for Android).
Since I would like a service to own the data (and its creation), I thought of a callback to the activity, and that's what I've been trying got get my head around for the past few hours. What I do have is a service with onCreate(), onStartCommand() and onDestroy() and basically, that's fine. I registered it in the android manifest file, and succeeded at bringing it to life (I'm logging the lifecycle methods).
But how do I get to
have the Views updated frequently with the data from the service
give the service certain information it depends on (like notifying it of a button event)
Thanks for your help!
Read about Binding to a Service from the official Android docs.
It should answer all of your questions.
Basically, the idea is that you "bind" to a service, and doing that gives you the service object. From there, you can just call the service's methods directly. In your case, you'd probably want a method declared in your service called notifyButton1Pressed() or something similar.
To refresh the Activity's views in an interval, use a TimerTask and a Timer. Those are pretty self-explanatory if you research them via Google.
In order to update your activity from service, you have to register an BroadcastReceiver in your activity. In the receiver you do your update, and in the service, you have to sendBroadcast to your activity. And information between activity and service you could send through Intent which is sent by sendBroadcast.
There is actually a pretty simple way to update an activity from within itself using a Timer and a android.os.Handler. The idea is to give the activity an interface (e.g. IUpdateable) that exposes an update method. Then extend the TimerTask to take (Handler, IUpdateable) as arguments and keep references to it. In the TimerTask's run() method, call e.g. updateableActivity.update(). In the activity, instantiate a Timer and schedule new UpdateTask(new Handler(), this);.
This way you have an actually reusable approach (using an interface makes this easy to implement in any activity). If this was unclear, have a look at this gist.
I am having some trouble creating a NON-IPC service that allows adding/removing multiple listeners at various times, for example, I would like to be able to contact the service and "subscribe" to its events any time, or "unsubscribe" from it. The service wakes up every once in a while and sends an event to all subscribed listeners.
I have been looking at stackoverflow examples, googling, etc, particularly I found something similar here:
android restful api
In that example, the suggestion is to use ResultReceiver to serve as a callback from a service. But in this approach, doesn't it mean that the service can only notify listeners sent to it as part of the first intent (i.e I cannot add/remove listeners whenever I want)?
Also, in that example, what happens if the activity gets destroyed by the OS for some reason, but the service still has a reference to the listener and tries to invoke it? The listener will try to perform some action on the activity, which no longer exists, right?
Maybe I am missing something... I'd appreciate some input if possible..
Tnx
First, 'sleeping' services are anti-pattern in Android. If you need to do something periodically, start your service using AlarmManager. Second, the service can be restarted at any time, so you cannot rely on 'subscribing' where you keep references to other components (activities mostly). If you need to send a notification to multiple activities, use a broadcast receiver. Activities can register for it statically (using AndroidManifest.xml), or dynamically (with code).
When the device is restarted, my appWidgets are all broken. In my WidgetProvider class i have implemented only the onRecieve method, since i'm using a ConfigureActivity to create the widget. What method should I override on the WidgetProvider for my widget to be updted properly when the device is restarted?
When the device reboots, all the desktop widgets are rebuilt via the onUpdate method in the WidgetProvider class. Just implement this method to recreate your widget as shown here.
If I understand your problem correctly, register to receive the ACTION_BOOT_COMPLETED broadcast, and re-create your widget when you receive it.
Make sure you also hold the RECEIVE_BOOT_COMPLETED permission.
It's best practice to make sure you respond and exit from your BOOT_COMPLETED handler as quickly as possible - spending too long responding to BOOT_COMPLETED will give a poor user impression of the platform.
Widget Provider is a specialized BroadcastReceiver.
Assuming there exists an Application, 1-n android service,1-k activities, and potentially additional 0-n broadcast receivers that are not widgets, I would like to verify what belongs and does not belong logically inside the broadcast receiver. Here are some items ..
And assuming that generally what gets launched is the widget first.
Please comment on any of the items as to whether they belong inside or outside the widget and why. Thanks.
1) If the application needs to always listen for certain events whether they show up in the widget or not where should this go? In the Widget? If not what would keep the broadcast receiver available to listen to the events for the application?
2) Should the widget issue notification? or request a service to issue them? ie should the notification logic reside in the widget itself or in the service.
3) Should the widget issue broadcasts or ask a service to do this?
4) Should the widget ever access any system services like like Notification Manager, PowerManager etc Why, Why not?
5) Should the widget keep any of its own state? If it should not keep state how can it change what it displays? Like a different text or icon?
6) Should the widget start off activities or let a service handle this?
7) is it ok to user the context passed to update and receiver or should one use ctx.getApplicationContext() to do things like context.startService? ( Perhaps the one passed in is the application context ? )
Quoting myself from your cross-post to the android-developers Google Group:
Your entire question is phrased around "the Widget". There is no "the
Widget". From the opening sentence of your question, I am interpreting
"the Widget" to mean "a subclass of AppWidgetProvider that handles the
processing for an app widget or family of app widget instances".
1) If the Application needs to always listen for certain events
whether they show up in the widget or not where should this go? In the
Widget?
There is no reason for an AppWidgetProvider to respond to other
broadcasts, since anything can update the app widget's RemoteViews.
And an AppWidgetProvider cannot register listeners (e.g.,
PhoneStateListener).
Hence, I would say the answer here is "no".
2) Should the widget issue notification? or request a service to issue
them? ie should the notification logic reside in the widget itself or
in the service.
Technically, AFAIK, raising a notification is cheap and therefore safe
for an AppWidgetProvider to do.
Logically, an AppWidgetProvider should never have any reason to raise
a notification, IMHO.
3) Should the widget issue broadcasts or ask a service to do this?
Technically, AFAIK, sending a broadcast is cheap and therefore safe
for an AppWidgetProvider to do.
Logically, an AppWidgetProvider should never have any reason to send
broadcasts, IMHO.
4) Should the widget ever access any system services like like
Notification Manager, PowerManager etc Why, Why not?
This cannot be answered in the abstract.
5) Should the widget keep any of its own state? If it should not keep
state how can it change what it displays? Like a different text or
icon?
It may need to. For example, suppose you have an app widget that shows
the weather for a certain city. The configuration activity for that
app widget allows the user to choose the city. Somewhere, you need to
store that city, and distinct from the cities that any other instance
of that app widget may need (e.g., user adds two copies of the app
widget to track weather in two cities).
6) Should the widget start off activities or let a service handle
this?
An AppWidgetProvider should never have a reason to directly "start off
activities", nor should a service triggered from an AppWidgetProvider
have any reason to directly "start off activities", IMHO.
However, either are perfectly welcome to create PendingIntents that
"start off activities" and attach them as click handlers for widgets
in an app widget's RemoteViews.
7) is it ok to user the context passed to update and receiver or
should one use ctx.getApplicationContext() to do things like
context.startService? ( Perhaps the one passed in is the application
context ? )
Most things you can just use the passed-in Context. One thing that
will not work for is using registerReceiver() with a null receiver to
get the last value of a sticky broadcast, such as
ACTION_BATTERY_CHANGED -- for that, you will need to use
getApplicationContext().