Ha pasado un mes y medio desde que tengo el HTC Magic. Me pasé de Orange a Vodafone por este móvil, un mes antes de que Orange anunciaran en exclusiva el HTC Hero. En fin…

Como Internet está lleno de análisis del Magic me limito a soltar algunas impresiones personales. No he tenido ocasión de usar de forma continuada otros móviles de gama similar, así que no voy a hacer comparaciones.

• La pantalla es mejor de lo que esperaba. Brillante y nítida. Hubiese sido aún mejor con 3,5 pulgadas. Para evitar llevar la funda puesta le compré un protector de pantalla. 
• La interfaz de usuario resulta cómoda y agradable. Fácil de configurar. Echo en falta un sistema rápido para desinstalar aplicaciones.
• No hay multitouch. Podría ser útil para ampliar imágenes o páginas web.
• El sistema es razonablemente estable, pero de vez en cuando se ralentiza sin motivo aparente. No demasiado a menudo ni durante mucho tiempo, pero resulta molesto. Probablemente se deba a alguna de las aplicaciones instaladas. Aún no se me ha quedado colgado.
• El Market contiene una buena cantidad de aplicaciones, tanto de pago como gratuitas. La interfaz es simple pero un poco limitada. Me gustaría que hubiese un sistema para actualizar varias aplicaciones de golpe.
• El GPS es muy rápido. El magnetómetro es interesante. El acelerómetro es un pelín lento, o al menos es lenta la transición entre las dos orientaciones posibles de la interfaz.
• Por algún motivo no se puede tener el home en formato landscape.
• La cámara no tiene flash. Y además es muy mala.
• El trackball funciona bien, pero nunca lo uso.
• La batería no va sobrada, pero no tengo problemas para que me dure todo el día.
• La calidad del sonido en las llamadas en buena. Tener toda la información de los contactos centralizada (y sincronizada con los contactos de GMail) resulta muy cómodo.
• El WiFi va bastante bien. El bluetooth no lo he probado.
• Me he aficionado a Twitter. Aún no me he decidido entre Twidroid y TwitterRide.

1. ¿Cómo funcionará el Android Marketplace? ¿Aplicará Google restricciones sobre el tipo de aplicaciones que se pueden publicar? Parece que en la presentación insinuaron que existirá algún tipo de proceso de validación.
2. El G1 sólo funcionará con SIMs de T-Mobile. Además, se impide el uso de aplicaciones de voz sobre IP en las conexiones a través de la red de T-Mobile, limitando su uso a conexiones WiFi. ¿Veremos algún dispositivo libre? ¿A qué precio?
3. ¿Cómo es de estable el sistema? La versión 1.0 de la SDK acaba de salir, así que habrá que esperar unas semanas antes de comprobar si es mínimamente usable. ¿Cuánto dura la batería?
4. ¿Era necesario que fuese tan feo?

El iPhone 3G has sido sin duda la estrella tecnológica del verano. Eso es bueno para Apple, pero probablemente también para los usuarios que deseen utilizar su móvil para navegar por Internet, y por dos motivos. Uno, ha estimulado a las operadoras para competir, aunque tímidamente, con sus tarifas de datos. Dos, presiona a los fabricantes para que las características de sus nuevos modelos de gama alta estén a la altura del iPhone. Es decir, pantallas grandes e interfaces intuitivas.

Para los desarrolladores la aparición del iPhone y su SDK ha venido acompañada de cierta polémica, causada por las estrictas condiciones impuestas en la licencia de uso de la SDK. ¿Beneficia o perjudica al desarrollador la actitud de Apple?

La App Store

La única manera de instalar legalmente un programa en un iPhone es a través de la App Store. El desarrollador envía la aplicación finalizada a Apple, quien decide si la publica o no, basándose en criterios no del todo claros. Antonio Ortiz menciona varios ejemplos en Apple e iPhone, el paradigma de la plataforma cerrada. La clave en este caso está en el éxito de la plataforma: la demanda del consumidor final obliga a los desarrolladores a seguir trabajando sobre el iPhone, pese a que Apple impide la competencia con su propio software.

Una aplicación a la vez, por favor

No se permite más de una aplicación ejecutándose a la vez, y las aplicaciones de terceros no pueden ejecutarse en segundo plano. Con esta restricción Apple se evita un montón de problemas de duración de la batería, a costa de hacer volver a los programadores a los tiempos de la multitarea cooperativa. Además de tener que garantizar el buen funcionamiento de la aplicación cuando otra aplicación reemplace su lugar, no será posible diseñar programas que se ejecuten en el escritorio o que esperen aletargadas a la espera de algún evento. Es casi lógico que no exista la funcionalidad de copiar y pegar si las aplicaciones no van a poder utilizarla.

Conclusiones

Apple ha diseñado un sistema pensado como teléfono móvil, reproductor multimedia y plataforma para juegos. Precisamente los videojuegos son el tipo de aplicaciones que menos sufre las restricciones de la plataforma. Para el resto de cosas siempre quedará la web.

Ninguna plataforma puede ofrecerlo todo, y esta es la propuesta de Apple. Veremos qué proponen Google, Nokia y Microsoft en los próximos meses.

Unas cuantas novedades en Ipoki durante el verano:

• Integración con Qik para enviar vídeo en tiempo real desde Ipoki: Qik Live Video y geolocalicacion en tiempo real con Ipoki.
• Opción para importar contactos: Mas opciones en Ipoki.
• Descarga de rutas desde Ipoki: Ipoki Life Stream.
• Integración con Fire Eagle: Integración de Ipoki y Fire Eagle.
• Geolocalización de fotos de Flickr con Ipoki: Como geolocalizar fotos de Flickr con Ipoki.

Y además, tenemos en fase de pruebas las nuevas versiones de Ipoki para BlackBerry.

Andrés ha escrito el Loogic un artículo sobre redes sociales y geolocalización: “Redes sociales y Geoweb“.

Un extracto:

En un futuro estaremos siempre conectados a Internet, en casa, en el trabajo y andando por la calle, y los servicios de Internet que utilizamos nos mandaran la información que necesitemos según el sitio en el que estemos. O nos pondrán en contacto con la gente a la que podemos ver en ese lugar. A medida que los servicios sean mas inteligentes reaccionaran mejor a nuestras necesidades, y para eso es muy importante que sepan donde estamos. Esto también va a cambiar los usos sociales y va a crear nuevos. Se van a crear cada vez más puntos de contacto entre el mundo real y el ciberespacio.

La clase NotesList
La actividad principal de la aplicación NotePad es NotesList, como se puede ver en el manifest. La clase NotesList se define en el archivo NotesList.java, y es la responsable de la pantalla principal de la aplicación, mostrando una lista de las notas disponibles. Para ello hacemos que esta clase herede de ListActivity, un tipo de actividad especial diseñada para enlazarse a un cursor y mostrar los elementos del cursor en una lista.

Al iniciar la aplicación se invoca esta clase a través de su método onCreate:

   1: @Override

   2: protected void onCreate(Bundle icicle) {

   3:     super.onCreate(icicle);

   4:

   5:     setDefaultKeyMode(SHORTCUT_DEFAULT_KEYS);

   6:

   7:     Intent intent = getIntent();

   8:     if (intent.getData() == null)

   9:         intent.setData(NotePad.Notes.CONTENT_URI);

  10:

  11:     setupListStripes();

  12:

  13:     Uri uri = intent.getData();

  14:     mCursor = managedQuery(uri, PROJECTION, null, null);

  15:

  16:     ListAdapter adapter = new SimpleCursorAdapter(this,

  17:             R.layout.noteslist_item, mCursor,

  18:             new String[] {NotePad.Notes.TITLE},

  19:             new int[] {android.R.id.text1});

  20:     setListAdapter(adapter);

  21: }

En la línea 5 simplemente habilitamos los atajos de teclado. Las líneas 7-9 establecen el esquema de datos sobre el que vamos a operar, que se define en la clase NotePad. Lo veremos más adelante.

Las líneas 13 y 14 acceden a los datos. Las referencias a los orígenes de datos son objetos de tipo Uri, y en nuestro caso tienen esta forma:

   1: public static final Uri CONTENT_URI =

   2:     Uri.parse("content://com.google.provider.NotePad/notes");

El enlace entre este Uri y la base de datos se realiza en la clase NotePadProvider, que veremos en otra entrada. Basta decir por ahora que la línea 14 accede a la base de datos para abrir un cursor con las columnas especificadas por PROJECTION, que se define al comienzo de la clase NotesList:

   1: private static final String[] PROJECTION = new String[] {

   2:     NotePad.Notes._ID, NotePad.Notes.TITLE };

   3: private Cursor mCursor;

Como decíamos al principio, la actividad NotesList hereda de ListActivity, lo que le permite mostrar datos en una lista. Para ello creamos un adaptador ListAdapter, como se muestra en las líneas 16-19. La clase SimpleCursorAdaptor es un creador genérico de adaptadores, al que indicamos el layout que vamos a usar (en nuestro caso R.layout.noteslist_item), el cursor que hemos definido, los nombres de las columnas a mostrar (en este caso sólo el título), y los ids de los controles (tienen que ser del tipo TextView) que van a mostrar cada columna. ´

Finalmente el método setListAdapter asigna el ListAdapter a nuestra actividad para mostrar los datos.

Nos queda por ver el método setupListStripes:

   1: private void setupListStripes() {

   2:     Drawable[] lineBackgrounds = new Drawable[2];

   3:

   4:     lineBackgrounds[0] =

   5:         getResources().getDrawable(R.drawable.even_stripe);

   6:     lineBackgrounds[1] =

   7:         getResources().getDrawable(R.drawable.odd_stripe);

   8:

   9:     View view = getViewInflate().inflate(

  10:             android.R.layout.simple_list_item_1, null, null);

  11:     TextView v = (TextView)view.findViewById(android.R.id.text1);

  12:     v.setText("X");

  13:     v.measure(

  14:         View.MeasureSpec.makeMeasureSpec(View.MeasureSpec.EXACTLY, 100),

  15:         View.MeasureSpec.makeMeasureSpec(View.MeasureSpec.UNSPECIFIED, 0)

  16:         );

  17:     int height = v.getMeasuredHeight();

  18:     getListView().setStripes(lineBackgrounds, height);

  19: }

Entradas anteriores:

Programando en Android – NotePad (I)
Programando en Android – Conceptos iniciales (II)
Programando en Android – Conceptos iniciales (I)
Programando en Android – Prólogo

Me encuentro ocasionalmente con ideas reveladoras. Las leo y noto como si un grupo de neuronas aletargadas se activasen de repente, haciéndome pensar en algo en lo que no había pensado antes.

La última la he leído en el artículo de Jeff Atwood “Strong Opinions, Weakly Held“, algo así como “Opiniones firmes, mantenidas débilmente”. El artículo es una defensa frente a otro artículo, “Blogging Horror“, que acusa a Jeff Atwood de haber perdido credibilidad emitiendo opiniones desinformadas sobre diversos temas relacionados con la programación. Esta discusión tiene una ramificación española, a través de una entrada en VELOCIDAD DE ESCAPE, que apareció en la portada de menéame y fue contestada por Ricardo Galli, entre otros.

El título del artículo de Atwood se refiere a una idea expresada en otro artículo del mismo nombre, cuya idea central se resume en este párrafo:

A couple years ago, I was talking the Institute’s Bob Johansen about wisdom, and he explained that — to deal with an uncertain future and still move forward – they advise people to have “strong opinions, which are weakly held.” They’ve been giving this advice for years, and I understand that it was first developed by Institute Director Paul Saffo. Bob explained that weak opinions are problematic because people aren’t inspired to develop the best arguments possible for them, or to put forth the energy required to test them. Bob explained that it was just as important, however, to not be too attached to what you believe because, otherwise, it undermines your ability to “see” and “hear” evidence that clashes with your opinions. This is what psychologists sometimes call the problem of “confirmation bias.”

que traducido por mí dice:

Hace un par de años, le estaba hablando a Bob Johansen [del Instituto de para el Futuro de Palo Alto] sobre la sabiduría, y él me explicó que – para tratar con la incertidumbre del futuro y aún así seguir avanzando – recomendaban a la gente que tuviese “opiniones firmes, que se mantuviesen de forma débil.” Llevaban dando este consejo durante años, y por lo que entiendo había sido inicialmente desarrollado por el director del Instituto Paul Saffo. Bob me explicó que las opiniones débiles eran problemáticas porque no inspiran a la gente a desarrollar las mejores ideas posibles para ellas. Bob me explicó que era igualmente importante, sin embargo, no sentirse demasiado ligado a tus ideas porque, de otra forma, socava tu habilidad para “ver” y “oír” las evidencias que choquen con tus opiniones. Es lo que los psicólogos llaman a veces el problema del “sesgo de confirmación.”

Cuando expreso una opinión en un ambiente formal (en el trabajo, en una discusión seria…), siempre intento hacerlo dejando claro que esa opinión se aplica a un ámbito concreto, que es posible que sea errónea en casos que no he contemplado y que por lo tanto admite matices y condicionantes, y que se basa en el conocimiento necesariamente limitado que tengo sobre el asunto en cuestión. Nunca se me había ocurrido que esa forma de actuar puede estar, a veces, equivocada.

No sé si cambiaré mi forma de opinar, pero me lo pensaré dos veces antes de llamar dogmático a quien exprese sus ideas con demasiada firmeza.

Aún no me he mirado el documento (que es un zip de 58 megas), pero por lo que veo en Mi N70 y yo contiene datos de dispositivos móviles recogidos por BlueTooth. Por ejemplo, esta gráfica que colgó el propio fernand0 en su cuenta de Picassa (y que me ha servido para darme cuenta de que el autor de Mi N70 y yo es el mismo de Reflexiones e irreflexiones, otro blog al que estoy subscrito), mostrando el número de dispositivos Nokia detectados por modelo:

Lógicamente, como toda muestra estadística, esta gráfica está condicionada por la forma en la que se recogieron los datos, así que la principal conclusión que podemos sacar (sin haber leído el documento) es que los usuarios del 6021 se dejan con mucha frecuencia el BlueTooth activado.

La mayoría de los mortales olvidamos cualquier conocimiento abstracto en la décima parte del tiempo que nos costó adquirir dicho conocimiento (dato completamente inventado, pero en mi caso muy próximo a la realidad). Así que lo que vamos a hacer en concretar este conocimiento, y ponernos a programar.

El programa NotePad es un ejemplo que se incluye en la documentación de Google y en la SDK. Es un programa muy simple: permite crear notas, editarlas, borrarlas y modificar el título. Vamos a ver cómo funciona.

El ejemplo NotePad. El archivo Manifest.

Comencemos por el Manifest, que es donde se definen los componentes de la aplicación. El manifest.xml es, como su extensión indica, un archivo xml, que desde hace unos años se convertido en un formato habitual para contener configuraciones. El elemento raíz se llama manifest y contiene el namespace de la aplicación. Dentro se define el elemento aplicación:

<application android:icon="@drawable/app_notes" android:label="@string/app_name">

Aquí asociamos un nombre y un icono a la aplicación. La ‘@’ nos indica una referencia a un recurso. En general tiene este formato: @[package:]type/name, donde el paquete es opcional y sólo se indica cuando no pertenece a nuestra aplicación, el tipo corresponde a uno de los definidos en la carpeta res, y el nombre indica el identificador del recurso.  En nuestro caso, el icono se encuentra bajo la carpeta drawable, y la app_name se define en el archivo strings.xml de la carpeta values.

Dentro del elemento application lo primero que aparece es un provider, que nos dará acceso a la base de datos y que veremos más adelante. Tras él podemos ver definidas tres Activities: NotesList, NoteEditor y TitleEditor. Corresponderán a cada una de las ventanas: la que muestra las notas, la que las edita y la que modifica el título. Por ejemplo, este el elemento TitleEditor:

<activity android:name="TitleEditor" android:label="@string/title_edit_title" android:theme="@android:style/Theme.Dialog">

Además de indicar el nombre de la actividad, y la etiqueta que aparecerá en la ventana asociada, también especificamos que vamos a utilizar un tema concreto para esta actividad. Los temas nos permiten cambiar el look&feel de las aplicaciones con temas predefinidos o creados por nosotros. En este caso podemos ver como el recurso correspondiente al tema se referencia a través del paquete android, ya que está definido en el sistema, no en nuestra aplicación.

Dentro de cada activity hay definidos intent-filters, que permiten concretar el ámbito en el que se van a ejecutar, como ya vimos anteriormente. Por ejemplo, en NotesList encontramos:

<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>;

que indica que esta es la actividad principal de la aplicación, y que aparecerá en el menú de aplicaciones del sistema. El filtro

<intent-filter>
<action android:name="android.intent.action.VIEW" />
<action android:name="android.intent.action.EDIT" />
<action android:name="android.intent.action.PICK" />
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="vnd.android.cursor.dir/vnd.google.note" />
</intent-filter>

nos indica que la actividad está disponible para ver, editar o seleccionar elementos del tipo vnd.android.cursor.dir/vnd.google.note, que es el tipo que definiremos más adelante para las notas. Finalmente, el filtro

<intent-filter>
<action android:name=”android.intent.action.GET_CONTENT” />
<category android:name=”android.intent.category.DEFAULT” />
<data android:mimeType=”vnd.android.cursor.item/vnd.google.note” />
</intent-filter>

permite al usuario seleccionar el tipo de dato vnd.android.cursor.dir/vnd.google.note. A diferencia de la acción android.intent.action.PICK, donde se selecciona un elemento de un conjunto de datos, aquí se selecciona un tipo de dato para que el usuario haga algo con él.

Todo esto se verá más claro al examinar el código de las actividades.

Entradas anteriores:
Programando en Android – Conceptos iniciales (II)
Programando en Android – Conceptos iniciales (I)
Programando en Android – Prólogo

Opera ha publicado estos días un pequeño informe llamado “Estado de la web móvil” (en inglés aquí), que analiza tendencias en la navegación por Internet a través de dispositivos móviles usando datos anónimos enviados por su navegador Opera Mini durante los tres primeros meses del 2008.

Este tipo de informes contienen sesgos imprevisibles que nos obligan a sacar conclusiones con mucho cuidado. El sesgo más evidente es que nos habla de usuarios de Opera Mini, lo que excluye a dueños de móviles iPhone, y minimiza el impacto de las BlackBerry, entre otros dispositivos (aunque existe Opera Mini para BlackBerry, creo que aún no es compatible con la tarifa plana del servicio BIS).

Dicho esto, algunas ideas que me sugiere el informe:

• La lista de los diez países que más navegan es llamativa: encabezada por Rusia, con Indonesia en segundo lugar, e incluyendo a Sudáfrica y Polonia junto a Estados Unidos o Gran Bretaña. Esta mezcla de países ricos y pobres reafirma una tendencia conocida: en los países menos desarrollados la falta de infraestructuras para acceder a Internet por cable o ADSL incentiva el acceso a Internet a través del móvil.
• Si observamos las gráficas que muestran, desde Enero del 2006, la evolución en número de usuarios, número de páginas y megas transferidos por mes, observamos un crecimiento aparentemente exponencial. Esta información está distorsionada por el hecho de que Opera Mini apareció en el mercado precisamente a principios del 2006, pero parece deducirse un incremento drástico en el acceso móvil a Internet en los últimos meses.

• Si comparamos los diez sitios más visitados en Estados Unidos y Reino Unido con el top Alexa para estos países, vemos que coinciden en gran medida. Dos cosas me llaman un poco la atención: el sitio www.mocospace.com, que está en el top móvil de ambos países pero no aparece en los 100 primeros del ranking Alexa para ninguno de ellos; y la ausencia de youtube en la lista completa de países que ofrece Opera, aunque esto último puede que sea debido a que la página no funcione bien en Opera Mini.

El informe contiene una conclusión un tanto capciosa: el triunfo de la “web completa” sobre la web wap o específica para móviles, basandose en que esta última sólo supone una cuarta parte de los datos obtenidos. Pero son datos obtenidos a través de un navegador que soporta razonablemente bien las páginas más habituales. ¿A qué tipo de páginas navegan los que no usan Opera Mini? Y sobre todo, ¿a cuántas páginas dejan de navegar, por ser difíciles o imposibles de usar, los usuarios de la web móvil? Puede que la conclusión del informe sea correcta, pero es pronto para afirmarlo.

Vía: Estado de la web móvil de Opera