Group items tagged

Spinner s2 = (Spinner) findViewById(R.id.spinner2);Cursor cur = managedQuery(People.CONTENT_URI, PROJECTION, null, null);     SimpleCursorAdapter adapter2 = new SimpleCursorAdapter(this,    android.R.layout.simple_spinner_item, // Use a template                                          // that displays a                                          // text view    cur, // Give the cursor to the list adatper    new String[] {People.NAME}, // Map the NAME column in the                                         // people database to...    new int[] {android.R.id.text1}); // The "text1" view defined in                                     // the XML template                                         adapter2.setDropDownViewResource(android.R.layout.simple_spinner_dropdown_item);s2.setAdapter(adapter2);

onSaveInstanceState() is called by Android if the Activity is being stopped and may be killed before it is resumed! This means it should store any state necessary to re-initialize to the same condition when the Activity is restarted. It is the counterpart to the onCreate() method, and in fact the savedInstanceState Bundle passed in to onCreate() is the same Bundle that you construct as outState in the onSaveInstanceState() method.

Note that saveState() must be called in both onSaveInstanceState() and onPause() to ensure that the data is saved. This is because there is no guarantee that onSaveInstanceState() will be called and because when it is called, it is called before onPause().

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

Removing the window's background can be achieved very easily by using a custom theme. To do so, first create a file called res/values/theme.xml containing the following:

<resources>    <style name="Theme.NoBackground" parent="android:Theme">        <item name="android:windowBackground">@null</item>    </style></resources>

You then need to apply the theme to your activity by adding the attribute android:theme="@style/Theme.NoBackground" to your <activity /> or <application /> tag. This trick comes in very handy for any app that uses a MapView, a WebView or any other full screen opaque view.

The android:inputType attribute has three pieces: The class is the overall interpretation of characters. The currently supported classes are text (plain text), number (decimal number), phone (phone number), and datetime (a date or time). The variation is a further refinement on the class. In the attribute you will normally specify the class and variant together, with the class as a prefix. For example, textEmailAddress is a text field where the user will enter something that is an e-mail address (foo@bar.com) so the key layout will have an '@' character in easy access, and numberSigned is a numeric field with a sign. If only the class is specified, then you get the default/generic variant. Additional flags can be specified that supply further refinement. These flags are specific to a class. For example, some flags for the text class are textCapSentences, textAutoCorrect, and textMultiline.

    <EditText android:id="@+id/edtInput"        android:layout_width="0dip"        android:layout_height="wrap_content"        android:layout_weight="1"        android:inputType="textShortMessage|textAutoCorrect|textCapSentences|textMultiLine"        android:imeOptions="actionSend|flagNoEnterAction"        android:maxLines="4"        android:maxLength="2000"        android:hint="@string/compose_hint"/>

If you're managing the cursor yourself the cleanest way to go is probably this: Cursor cursor = getContentResolver().query(...); try {     // read from the cursor and do stuff } finally {     if (cursor != null) cursor.close(); }

Another option if you still want to use Activity.managedQuery() is to get your information and then: stopManaging(cursor); cursor.close(); Cheers, Justin Android Team @ Google

GreenDroid is a development library for the Android platform. It is intented to make UI developments easier and consistent through your applications

This projects aims to provide a reusable action bar widget. The action bar replaces the default title and is therefor located at the top of the screen. The action bar highlights important actions. The action bar pattern is well documented over at Android Patterns. The action bar widget is an Library Project. This means that there's no need to copy-paste resources into your own project, simply add the action bar widget as a reference to your existing project.

The question is: How do I reference the Android default icons? In XML this would be: android:icon="@android:drawable/ic_menu_info_details

android.R.drawable.ic_menu_info_details

Current Instapaper and former Tumblr developer Marco Arment wonders out loud if Google Android phones can ever achieve the levels of usability and polish Apple’s iPhone has arguably had since day one

Android will continue to exhibit what Google does best: great low-level engineering and tight integration with Google’s other services. But it’s never going to be Apple-like in user experience, polish, or design. Attention to detail, like most facets of truly good design, can’t be (and never is) added later. It’s an entire development philosophy, methodology, and culture