miércoles, 21 de septiembre de 2011

Platform Versions


Cupcake, Froyo? Cansado de esa jerga usada por los informáticos?
Todo se explica en este artículo de Android Developers.
He aquí la traducción de esos nombres aparentemente estúpidos, infantiles  y que no dicen nada.
Como si le hubieran puesto boquerón, sardina y mero.
Se ve que el nombre está relacionado con lo que habian desayunado esa mañana.

Aquí la traducción que hace google translator de los nombres:

Cupcake: Magdalena   (android 1.5)
Donut:  buñuelo (android 1.6)
Eclair: eclair (android 2.1)
Froyo: froyo (android 2.2)
Gingerbread: pan de gengibre (android 2.3)
Honeycomb: panal (android 3)


Y aquí la explicación proporcionada por la wikipedia:

Las versiones de Android reciben nombre de postres en inglés. En cada versión el postre elegido empieza por una letra distinta siguiendo un orden alfabético:
Oficiales:

Esta explicación de la inicial parece más lógica, y una regla memotécnica para recordar y asociar la palabra a la versión de Android.

Otra regla para acordarse sería la siguiente: A cada versión de android le asociamos una nota musical Do, Re, Mi, Fa, Sol, pero en notación  inglesa o alemana, es decir, C, D, E, F, G, y al llegar aquí continuamos por orden alfabético, aunque ya no son notas, H, I, J, K,...
Sabiendo que la primera versión comercial es la 1.5, esta correspondería a la nota Do, en inglés C, inicial de Cupcake. 
La segunda versión 1.6 sería Re, en inglés D, inicial de Donut.
La tercera versión 2.1, sería Mi, en inglés E, inicial de Eclair.
La cuarta versión 2.2, sería Fa, en inglés F, inicial de Froyo.
La quinta versión 2.3, sería Sol, en inglés G, inicial de Gingerbread.
La sexta versión 3.x, sería H, inicial de Honeycomb



 

Platform Versions

This page provides data about the relative number of active devices running a given version of the Android platform. This can help you understand the landscape of device distribution and decide how to prioritize the development of your application features for the devices currently in the hands of users. For information about how to target your application to devices based on platform version, see API Levels.

Current Distribution

The following pie chart and table is based on the number of Android devices that have accessed Android Market within a 14-day period ending on the data collection date noted below.

Platform Codename API Level Distribution
Android 1.5Cupcake 31.0%
Android 1.6Donut 41.8%
Android 2.1Eclair 713.3%
Android 2.2Froyo 851.2%
Android 2.3 -
Android 2.3.2		Gingerbread 90.6%
Android 2.3.3 -
Android 2.3.4		 1030.7%
Android 3.0 Honeycomb 110.2%
Android 3.1120.7%
Android 3.2130.5%
Data collected during a 14-day period ending on September 2, 2011

Historical Distribution

The following stacked line graph provides a history of the relative number of active Android devices running different versions of the Android platform. It also provides a valuable perspective of how many devices your application is compatible with, based on the platform version.
Notice that the platform versions are stacked on top of each other with the oldest active version at the top. This format indicates the total percent of active devices that are compatible with a given version of Android. For example, if you develop your application for the version that is at the very top of the chart, then your application is compatible with 100% of active devices (and all future versions), because all Android APIs are forward compatible. Or, if you develop your application for a version lower on the chart, then it is currently compatible with the percentage of devices indicated on the y-axis, where the line for that version meets the y-axis on the right.
Each dataset in the timeline is based on the number of Android devices that accessed Android Market within a 14-day period ending on the date indicated on the x-axis.
Last historical dataset collected during a 14-day period ending on September 2, 2011
Publicado por en No hay comentarios:

lunes, 19 de septiembre de 2011


Painless threading

Posted by Romain Guy on 06 May 2009 at 9:30 AM

Whenever you first start an Android application, a thread called "main" is automatically created. The main thread, also called the UI thread, is very important because it is in charge of dispatching the events to the appropriate widgets and this includes the drawing events. It is also the thread you interact with Android widgets on. For instance, if you touch the a button on screen, the UI thread dispatches the touch event to the widget which in turn sets its pressed state and posts an invalidate request to the event queue. The UI thread dequeues the request and notifies the widget to redraw itself.
This single thread model can yield poor performance in Android applications that do not consider the implications. Since everything happens on a single thread performing long operations, like network access or database queries, on this thread will block the whole user interface. No event can be dispatched, including drawing events, while the long operation is underway. From the user's perspective, the application appears hung. Even worse, if the UI thread is blocked for more than a few seconds (about 5 seconds currently) the user is presented with the infamous "application not responding" (ANR) dialog.
If you want to see how bad this can look, write a simple application with a button that invokes Thread.sleep(2000) in its OnClickListener. The button will remain in its pressed state for about 2 seconds before going back to its normal state. When this happens, it is very easy for the user to perceive the application as slow.
Now that you know you must avoid lengthy operations on the UI thread, you will probably use extra threads (background or worker threads) to perform these operations, and rightly so. Let's take the example of a click listener downloading an image over the network and displaying it in an ImageView:
public void onClick(View v) {
  new Thread(new Runnable() {
    public void run() {
      Bitmap b = loadImageFromNetwork();
      mImageView.setImageBitmap(b);
    }
  }).start();
}
At first, this code seems to be a good solution to your problem, as it does not block the UI thread. Unfortunately, it violates the single thread model: the Android UI toolkit is not thread-safe and must always be manipulated on the UI thread. In this piece of code, the ImageView is manipulated on a worker thread, which can cause really weird problems. Tracking down and fixing such bugs can be difficult and time-consuming.
Android offers several ways to access the UI thread from other threads. You may already be familiar with some of them but here is a comprehensive list:
Any of these classes and methods could be used to correct our previous code example:
public void onClick(View v) {
  new Thread(new Runnable() {
    public void run() {
      final Bitmap b = loadImageFromNetwork();
      mImageView.post(new Runnable() {
        public void run() {
          mImageView.setImageBitmap(b);
        }
      });
    }
  }).start();
}
Unfortunately, these classes and methods also tend to make your code more complicated and more difficult to read. It becomes even worse when your implement complex operations that require frequent UI updates. To remedy this problem, Android 1.5 offers a new utility class, called AsyncTask, that simplifies the creation of long-running tasks that need to communicate with the user interface.
AsyncTask is also available for Android 1.0 and 1.1 under the name UserTask. It offers the exact same API and all you have to do is copy its source code in your application.
The goal of AsyncTask is to take care of thread management for you. Our previous example can easily be rewritten with AsyncTask:
public void onClick(View v) {
  new DownloadImageTask().execute("http://example.com/image.png");
}
private class DownloadImageTask extends AsyncTask {
     protected Bitmap doInBackground(String... urls) {
         return loadImageFromNetwork(urls[0]);
     }

     protected void onPostExecute(Bitmap result) {
         mImageView.setImageBitmap(result);
     }
 }
As you can see, AsyncTask must be used by subclassing it. It is also very important to remember that an AsyncTask instance has to be created on the UI thread and can be executed only once. You can read the AsyncTask documentation for a full understanding on how to use this class, but here is a quick overview of how it works:
In addition to the official documentation, you can read several complex examples in the source code of Shelves (ShelvesActivity.java and AddBookActivity.java) and Photostream (LoginActivity.java, PhotostreamActivity.java and ViewPhotoActivity.java). I highly recommend reading the source code of Shelves to see how to persist tasks across configuration changes and how to cancel them properly when the activity is destroyed.
Regardless of whether or not you use AsyncTask, always remember these two rules about the single thread model: do not block the UI thread and make sure the Android UI toolkit is only accessed on the UI thread. AsyncTask just makes it easier to do both of these things.
If you want to learn more cool techniques, come join us at Google I/O. Members of the Android team will be there to give a series of in-depth technical sessions and answer all your questions.
| Tags: , ,
Publicado por en No hay comentarios:
Suscribirse a: Entradas (Atom)