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().
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.
Hello for all in 2013!
I have following android challenge:
Assume I have an app consisting of an activity and a widget. Both of these provide the same informations as actual as possible - so I have a service mining requested data and sending in message objects to the activity's or widget's handler, if possible. I'm OK with fact it causes large battery consumption and so on, it's not problem.
There are three possible layouts of the widgets. Current layout is determined on the fly (depends on data from the service) and setted via remoteviews.
Now my problem: I want to be able to toggle the service on/off by tapping on the widget. I have implemented PendingIntent as onClickPendingIntent (maybe the name is different, doesn't matter) and onReceive method to handle this one. It works pretty well but only for a while. After widget creation I'm able to trigger the intent by tapping the widget. But after a couple of minutes (nondeterministic) it makes nothing and the intent is not catch in onReceive anymore.
I have found in the log there is an intent ACTION_READY intent received in the widget before it stops responding my events. Is there any way to set the widget to listen for my touches anytime?
I have another problem with widget-zombie. I tried to google some doc about widgets, but not found any suitable document. If the system decide to kill my process, there will be still hanging dead widget UI on the screen. Its not responding any gestures and I guess it is not handling any messages too. Is there some chance to wake this widget programmaticaly (for example from the service)?
I will have second Christmas in two weeks if someone help me.
Lot of thanks!
I am trying to fix somebody else's code and would like to have as few mods as possible. The project is a widget. The way the code is designed, there can be multiple instances of the widget added to the home screen. There is a service that receives broadcasts for actions in the widgets and deals with the broadcasts accordingly.
As there can be multiple instances of the widget, the service keeps track of the instances using a HashMap, mapping widget IDs to actual widgets. This works quite well until the service is killed (usually from the task manager). The next time a widget sends a broadcast, the service will be restarted (I haven't spent too much time understanding how it's restarted, but it does). However in killing/restarting the service, the map of widget IDs to actual widgets gets cleared, therefore the service doesn't know what widget is sending the broadcast and thus doesn't do anything.
What would be the best way to manage this situation? Somehow save/restore the map maybe?
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.
I want to create an application in which
- Create a listener which listens for outgoing/incoming messages and calls
- UI is shown/hide based on listener results
Shrini,
As dds stated, you will definitely need at least two BroadcastReceivers. You will need one BroadcastReceiver for each incoming call and message that you want to respond to, and one for each outgoing one as well. A BroadcastReceiver may only capture one BroadcastMessage at a time. You will specifically need to capture the Intents sent by the operating system and your Application will need to have the appropriate Permissions for each. That's just setting up the listeners.
Once the BroadcastReceiver has been called you will need to start an Activity for you UI and possibly a Service to do any other processing. In the cases of single-point events (like messages) an Activity is often enough. Calls, however, depend largely upon what you are doing. Since a call has two distinct events, in order to tie them together, many people prefer to use a Service just to hold and watch the call.
In order to best help you, I must inform you that your question is remarkably vague as to what you need to do. Does your custom UI display information about the calls? Does it allow the User to respond or change that information? What kind of messages is your app responding to? SMS? Email? IMs? These are important because each one has different considerations.
Given that the limitation of information provided here, I would recommend researching your topic by downloading and viewing some of the open source projects stored on Google. Here is a Here.
Fuzzical Logic
Create a listener which listens for
outgoing/incoming messages and calls -
UI
To achieve this I think you need to use broadcast receivers to catch the broadcast message when any message activity is going on. You may need 2 in BroadcastReceivers , one for incoming and one for outgoing messages.
In the receivers you need to call your related Activity (your UI) to interact with the user. But note that you should not do any time consuming work in BroadcastReceiver since in BroadcastReceivers are expected to be light weight and killed in 10 seconds after they are invoked. See Broadcast receivers at here