Group items tagged

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);

Gson is a Java library that can be used to convert Java Objects into its JSON representation. It can also be used to convert a JSON string to an equivalent Java object. Gson can work with arbitrary Java objects including pre-existing objects that you do not have source-code of.

java.security.DigestInputStream

MessageDigest md = MessageDigest.getInstance("MD5");InputStream is = new FileInputStream("file.txt");try {  is = new DigestInputStream(is, md);  // read stream to EOF as normal...}finally {  is.close();}byte[] digest = md.digest();

Calling a Javascript method from your Java code: webView.loadUrl("javascript:jsToggle()"); Calling a Java method from Javascript: window.jsinterface.nativeToggle(); /*   // Before using the above code, you have to inject the interface object which   // has a name "jsinterface"   webView.addJavascriptInterface(jsInterface, "jsinterface"); */

As part of my job, I ran into memory leaks issues in Android applications and they are most of the time due to the same mistake: keeping a long-lived reference to a Context.

There are two easy ways to avoid context-related memory leaks. The most obvious one is to avoid escaping the context outside of its own scope. The example above showed the case of a static reference but inner classes and their implicit reference to the outer class can be equally dangerous. The second solution is to use the Application context. This context will live as long as your application is alive and does not depend on the activities life cycle. If you plan on keeping long-lived objects that need a context, remember the application object. You can obtain it easily by calling Context.getApplicationContext() or Activity.getApplication().

In summary, to avoid context-related memory leaks, remember the following: Do not keep long-lived references to a context-activity (a reference to an activity should have the same life cycle as the activity itself) Try using the context-application instead of a context-activity Avoid non-static inner classes in an activity if you don't control their life cycle, use a static inner class and make a weak reference to the activity inside. The solution to this issue is to use a static inner class with a WeakReference to the outer class, as done in ViewRoot and its W inner class for instance A garbage collector is not an insurance against memory leaks

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.

I am just making some AppWidget and I want to pass some Strings through UpdateView to an Activity. But the Bundle is null. I try this: -Widget.java                       Intent defineIntent = new Intent(context, Visor.class);                        defineIntent.putExtra ("org.rss.androides.post2","artist");                        PendingIntent pendingIntent = PendingIntent.getActivity(context, 0, defineIntent, 0);                        updateViews.setOnClickPendingIntent (R.id.widget, pendingIntent); -Viewer.java           Bundle b = intent.getExtras();                 if (b == null) {                     finish();                     return;                 } b is always null.

Remember that PendingIntents aren't keyed using extras: http://groups.google.com/group/android-developers/msg/b296f43ae70c4587 You could hack the extras through by mangling them into Uri parameters, or if you're using a ContentProvider, just point to a specific row.

Or use PendingIntent.FLAG_UPDATE_CURRENT; just be careful that each active instance has its own unique Intent.

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