Group items tagged

> Now I just want to update the GUI from this method. > Can I somehow call a method in PushEndpointDemo.java? No, for two reasons: 1. Because C2DMReceiver is a manifest-registered BroadcastReceiver and therefore has no access to any activities 2. There might not be an activity, since you have no control over the timing of when the C2DM message is received (e.g., the user pressed BACK, the user pressed HOME) > Do I need a Broadcast Intent to do this? Possibly. -- If you want to update an activity or else ignore the message, have C2DMReceiver send out a private broadcast, picked up by a receiver registered via registerReceiver() in the activity -- If you want to update an activity or else raise a notification, have C2DMReceiver send out an ordered broadcast, as described here: http://commonsware.com/blog/2010/08/11/activity-notification-ordered-... -- If you want to update a database, call startActivity() on an IntentService, and have it do the database I/O, plus possibly broadcast an Intent to update an activity/raise a notification.

To find your minimum width and height in density-independent pixels (dp), use this formula: (number of cells * 74) - 2

how often the App Widget framework should request an update from the AppWidgetProvider by calling the onUpdate() method

exactly on time

I’ve run into the following generalized question a lot recently: I have an event that occurs in the background. I want to update my activity, if the activity is on the screen. Otherwise, I want to raise a Notification.

Hence, the recipe for the activity-or-Notification pattern is: Define an action string you will use when the event occurs that you want to go to the activity or notification (e.g., com.commonsware.java.packages.are.fun.EVENT). Dynamically register a BroadcastReceiever in your activity, with an IntentFilter set up for the aforementioned action string and with a positive priority (the default priority for a filter is 0). This receiver should then have the activity do whatever it needs to do to update the UI based on this event. The receiver should also call abortBroadcast() to prevent others from getting it. Be sure to register the receiver in onStart() or onResume() and unregister the receiver in the corresponding onStop or onPause() method. Register in your manifest a BroadcastReceiver, with an <intent-filter> set up for the aforementioned action string. This receiver should raise the Notification. In your service (e.g., an IntentService), when the event occurs, call sendOrderedBroadcast(). And that’s it. If the activity is on-screen, its receiver will be registered, so it will get the event, process it, and cancel the broadcast. If the activity is not on-screen, its receiver will not be registered, so the event will go to the default handler, in the form of your manifest-registered BroadcastReceiver, which will raise the Notification.

It allows third-party application servers to send lightweight messages to their Android applications. The messaging service is not designed for sending a lot of user content via the messages. Rather, it should be used to tell the application that there is new data on the server, so that the application can fetch it. C2DM makes no guarantees about delivery or the order of messages. So, for example, while you might use this feature to tell an instant messaging application that the user has new messages, you probably would not use it to pass the actual messages. An application on an Android device doesn’t need to be running to receive messages. The system will wake up the application via Intent broadcast when the the message arrives, as long as the application is set up with the proper broadcast receiver and permissions.

It uses an existing connection for Google services. This requires users to set up their Google account on their mobile devices.

C2DM imposes the following limitations: The message size limit is 1024 bytes. Google limits the number of messages a sender sends in aggregate, and the number of messages a sender sends to a specific device

I am just getting started with Android development and I have created a nice little widget that displays some info on my home screen. However, I now want to implement a Button on my widget that updates the info in my widget TextView.

Solved - I can confirm that an Activity is NOT needed if you want create a Button to update an Android AppWidget. I have been able to implement my AppWidgetProvider class such that it registers an android.appwidget.action.APPWIDGET_UPDATE intent-filter with the Broadcast receiver in the AndroidManifest.xml, which then fires the onUpdate event in the AppWidgetProvider class (which in turn then runs the UpdateService).

The UpdateService in my AppWidgetProvider class then uses onHandleIntent to run a private buildUpdate method - which registers the onClick event with a call to setOnClickPendingIntent as follows:

An AppWidgetProvider is a BroadcastReceiver. That gives you two possibilities right off the bat: 1. Have it also handle whatever other Intents you were planning on setting up with a separate BroadcastReceiver, or 2. Send an Intent from whatever component you want to the AppWidgetProvider. In other words, don't worry about trying to talk directly to the app widget (which I suspect is impossible) -- just talk to your code that already talks to the app widget.

I update my widget from within my app, when I delete/add entries to a list. To do this, I have a method (updateWidget) and a static String (UPDATE_ACTION). My updateWidget() method sends a broadcast which is received by the widget class and then calls onUpdate() with the appropriate params: private void updateWidget() {                 Intent i = new Intent(this, TVWidget.class);                 i.setAction(TVWidget.UPDATE_ACTION);                 sendBroadcast(i);         } In TVWidget class: @Override         public void onReceive(Context context, Intent intent) {                 String action = intent.getAction();                 if (action != null && action.equals(UPDATE_ACTION)) {                         final AppWidgetManager manager = AppWidgetManager.getInstance (context);                         onUpdate(context, manager,                                         manager.getAppWidgetIds(new ComponentName(                                                         context, TVWidget.class)                                         )                         );                 }                 else {                         super.onReceive(context, intent);                 }         } This seems to work fine.

When onReceive() returns

by the system at any time

So the basic idea is: launch an AsyncTask making your service call, show a nifty progress dialog while the task thread is running, and have the task’s result be posted back to your activity once it completes. Cool, but what if the user decides to rotate the screen while your task is running? Or a phone call comes in, interrupting your app, and Android decides to kill it? Both these actions will effectively terminateyour activity, and recreate it when resuming (yes, a screen rotation kills your activity, very clever, isn’t it?). Unfortunately, any AsyncTask that was still running now holds a stale reference to your activity, because the restarted activity will be an entirely different object in memory (and it will go through onCreate(), as if the activity had started for the first time). I’m not entirely sure whether AsyncTask will actually post back the data to the old activity object (if it was a weak reference, it may already have been garbage collected), but in any case, your “new” activity will never see it, because it’s a different instance.

Droid-Fu offers both support classes meant to be used alongside existing Android code, as well as self-contained, ready-to-be-used components like new adapters and widgets. The areas tackled by Droid-Fu include: application life-cycle helpers support classes for handling Intents and diagnostics better support for background tasks super-easy and robust HTTP messaging powerful caching of Objects, HTTP responses, and remote images custom adapters and views I suggest you read this introductory article, and anything that follows.

launches the pending intent

checkout flow finishes