Group items tagged

Consumers want immediate access to what’s relevant and QR codes are being used to make that possible.

Bar codes are linear one-dimensional codes and can only hold up to 20 numerical digits, whereas QR codes are two-dimensional (2D) matrix barcodes that can hold thousands of alphanumeric characters of information. Their ability to hold more information and their ease of use makes them practical for small businesses.

When you scan or read a QR code with your iPhone, Android or other camera-enabled Smartphone, you can link to digital content on the web; activate a number of phone functions including email, IM and SMS; and connect the mobile device to a web browser.

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:

$ sudo gedit /etc/udev/rules.d/99-android.rules

$ sudo restart udev

$ adb kill-server $ adb start-server

Additionally, you can feel free to use the Search bar selection mechanism as a replacement for tabs since it’s really just a fast pivot on a data set. If you have more than 3 data sets, tabs become problematic since no more than 3 can be onscreen at once. For example, look at how we implemented the Profile switching mechanism below:

The good news for developers is you get this highly functional contacts feature for free if users choose to sync contact information into your app

The good news for developers is you get this highly functional contacts feature for free if users choose to sync contact information into your app. QuickContact for Android provides instant access to a contact's information and communication modes.

> 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.

If you add multiple changes to the transaction (such as another add() or remove()) and call addToBackStack(), then all changes applied before you call commit() are added to the back stack as a single transaction and the BACK key will reverse them all together.

The most significant difference in lifecycle between an activity and a fragment is how one is stored in its respective back stack. An activity is placed into a back stack of activities that's managed by the system when it's stopped, by default (so that the user can navigate back to it with the BACK key, as discussed in Tasks and Back Stack). However, a fragment is placed into a back stack managed by the host activity only when you explicitly request that the instance be saved by calling addToBackStack() during a transaction that removes the fragment.

In some cases, you might need a fragment to share events with the activity. A good way to do that is to define a callback interface inside the fragment and require that the host activity implement it. When the activity receives a callback through the interface, it can share the information with other fragments in the layout as necessary.

When you switch orientations, Android will create a new View. You're probably getting crashes because your background thread is trying to change the state on the old one. (It may also be having trouble because your background thread isn't on the UI thread) I'd suggest making that mHandler volatile and updating it when the orientation changes.

But in practice, you will notice that the AsyncTask is limited to 10 threads. This number is hardcoded somewhere in the Android SDK so we cannot change this. In this case it’s a limitation we cannot live with, because often more than 10 images are loaded at the same time.

I’ve shown you how to improve performance of a ListView in three different ways: By loading images in a seperate thread By reusing rows in the list By caching views within a row

I haven't looked in details at the 3 other approaches but I know that a big difference between what I do in Shelves and what I've seen done in other places is how user interaction is handled. Shelves listens to scroll events on the ListView and tries to identify taps vs scrolls vs fling to always give priority to the UI. For instance, when you touch the screen to stop a fling, Shelves starts loading images, but does so only after a very short delay so that if you are touching the screen to fling some more, the fling animation won't stutter because of the extra work load. But that's details.

For completeness we really should handle the possibility of the task getting cancelled. This can happen when the user navigates away from the app and the task is killed before its completed. This will cause the onPostExecute() method to not be called and so the onRefreshComplete() method won’t be called. Depending on how the user navigates through the app, they could return to this activity without going through the complete onCreate() lifecycle, and you’ll end up with the screen still showing the “loading” progress message in the header. This is common when using tabs between multiple ListViews. Also, the documented best practices for implementing an AsyncTask says that in long running background work you should periodically check if the task has been cancelled and try to gracefully quit your work and exit. So let’s get all of that in there.

RemoteViews can't manipulate a buttons enabled/disabled state, but it can modify its visibility. So the trick is to have two buttons, the real one, and an other which is designed to look like the real one in disabled state, and change witch one is visible.

<Button android:id="@+id/startbutton" android:text="Start" android:visibility="visible"></Button> <Button android:id="@+id/startbutton_disabled" android:text="Start" android:clickable="false" android:textColor="#999999" android:visibility="gone"></Button>   <Button android:id="@+id/stopbutton" android:text="Stop"  android:visibility="gone"></Button> <Button android:id="@+id/stopbutton_disabled" android:text="Stop" android:clickable="false" android:textColor="#999999" android:visibility="visible"></Button>

RemoteViews remoteView = new RemoteViews(context.getPackageName(), R.layout.widget); remoteView.setViewVisibility(R.id.startbutton, View.GONE); remoteView.setViewVisibility(R.id.startbutton_disabled, View.VISIBLE); remoteView.setViewVisibility(R.id.stopbutton, View.VISIBLE); remoteView.setViewVisibility(R.id.stopbutton_disabled, View.GONE); AppWidgetManager.getInstance(context).updateAppWidget(appWidgetId, remoteView);