T-Mobile G1: dudas
- ¿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.
- 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?
- ¿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?
- ¿Era necesario que fuese tan feo?
Los problemas de desarrollar para el iPhone
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.
De vuelta de vacaciones
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.
Artículo de Andrés en Loogic
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.
Programando en Android - NotePad (II)
Filed under: Android | Tags: Android, android notepad, desarrollo móvil
Comments(0) 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
Opiniones firmes
Filed under: Varios | Tags: jeff atwood, opiniones firmes, ricardo galli, velocidad de escape
Comments(0) 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.
Estadísticas curiosas: fisgando móviles con BlueTooth
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.
Programando en Android - NotePad (I)
Filed under: Android | Tags: Android, android notepad, AndroidManifest, intent-filter
Comments(1) 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
El informe Opera sobre la web móvil: reflexiones
Filed under: Web móvil | Tags: Estado de la web móvil, opera mini, Web móvil
Comments(0) 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.
Programando en Android - Conceptos iniciales (II)
Filed under: Uncategorized | Tags: Android, desarrollo móvil, Intent
Comments(1) Intents
Si las Activities son básicamente pantallas, las “intenciones” o Intents son la manera de invocar estas Activities. La definición breve de la documentación es: “Un intent es la descripción abstracta de una operación que se va a llevar a cabo”. O dicho de otro modo, un Intent es una clase que permite especificar una Activity a ejecutar, llamando a uno de los métodos de la clase Activity con ese Intent de parámetro. Parece fácil, pero he de confesar que en la documentación de Android el asunto me pareció un poco confuso, sobre todo por la cantidad de información que puede ir asociada a estas clases.
Dos formas de llamar a una Activity
Explicitamente o implicitamente. La forma explícita es simple de entender: creamos un Intent indicando el nombre de la clase correspondiente a la actividad y el paquete, llamamos a startActivity (o startSubActivity si queremos que nos notifiquen cuándo finaliza dicha actividad) y listo. El sistema busca la clase y crea la instancia, pasándo los datos que podamos haber añadido al Intent en el objeto Bundle del método onCreate de la nueva instancia.
// ClaseActividad1 es la clase de la actividad
//que queremos iniciar. El parámetro this indica
//el Context actual, para saber en qué
//package buscar esta clase
Intent i = new Intent(this, ClaseActividad1.class);
// Esta información se recuperará en el objeto Bundle de onCreate
i.putExtra(”NombreParametro”, valorParametro);
startActivity(i);
La invocación implícita de una actividad se realiza también a través de la clase Intent. Es implícita porque no se indica el nombre de la clase correspondiente a la actividad a invocar, sino que se establecen una serie de criterios, y se deja que el sistema elija una actividad que cumpla esos criterios.
Intenciones y criterios
A un Intent podemos asociarle una acción, unos datos y una categoría. Y aquí está el verdadero quid de esta clase. Las actividades pueden declarar el tipo de acciones que pueden llevar a cabo y los tipos de datos que pueden gestionar. Las acciones son cadenas de texto estándar que describen lo que que la actividad puede hacer. Por ejemplo, android.intent.action.VIEW es una acción que indica que la actividad puede mostrar datos al usuario. Esta acción viene predefinida en la clase Intent, pero es posible definir nuevas acciones para nuestras actividades. La misma actividad puede declarar que el tipo de datos del que se ocupa es, por ejemplo, “vnd.android.cursor.dir/person”. También puede declarar una categoría, que básicamente indica si la actividad va a ser lanzada desde el lanzador de aplicaciones, desde el menú de otra aplicación o directamente desde otra actividad. En el AndroidManifest.xml quedaría algo así:
<intent-filter>
<action android:name=”android.intent.action.VIEW” />
<category android:name=”android.intent.category.DEFAULT” />
<data android:mimeType=”vnd.android.cursor.dir/person” />
</intent-filter>
Así, para llamar implícitamente a una actividad a través de un intent, en vez de asignar el nombre de la clase le asignamos una de las acciones que esta puede llevar a cabo, con el tipo de datos adecuado. Las reglas exactas se indican en la documentación de la clase IntentFilter.
Conclusiones
Activities e Intents son los dos ejes sobre los que gira la arquitectura de las aplicaciones Android. Existen muchos más conceptos importantes, por supuesto, pero a partir de aquí lo mejor es verlo funcionando todo en una aplicación ejemplo. Pero eso será en la próxima entrada.
Entradas anteriores:
Programando en Android - Conceptos iniciales (I)
Programando en Android - Prólogo
