Actualidad

• Alto nivel (Componentes nativas proporcionadas por el sistema)
  
  
• Bajo nivel (Componentes personalizadas desarrolladas por el programador)

Si, es verdad: Cuando un equipo de desarrollo se plantea el reto de comenzar un nuevo proyecto, una de las primeras cosas que le vienen a la cabeza es cuál será el aspecto del producto final.

Con el API de alto nivel todo programador tiene una serie de elementos (objetos) que puede usar libremente y a los que puede ajustar según qué parámetros. En concreto algunos de estos elementos son:

• Listas
  
  
• Formularios
  
  
• Cadenas de texto
  
  
• Etc. (Este "Etc." puede entenderse como "Poco más")

Por poner un ejemplo, para un elemento de tipo “Lista” podemos indicar el número de opciones, si ésta es múltiple o exclusiva, si se muestra a simple o doble línea, añadirle comandos como “Abrir”, etc.

Sin embargo no podemos determinar ni el tipo de fuente, ni la manera de resaltar la opción seleccionada ni otros elementos visuales, ya que delegamos en la plataforma (el sistema operativo del teléfono) el dibujado del elemento.

  
La misma lista en alto nivel con diferentes temas

Desde los primeros días de J2ME casi exclusivamente se usó este API para desarrollar aplicaciones, sin embargo y con el tiempo el deseo de ganar en “Look and Feel”, o de diferenciar unas aplicaciones de otras, hizo que muchos programadores comenzasen a usar el API de bajo nivel para generar algunas componentes que ya existían en alto nivel. (Listas, Formularios, etc.)

-“…pero es que en alto nivel, las aplicaciones se ven feas…(suspiro)” – M.M.

Con bajo nivel podemos elegir al pixel qué dibujar en cada zona de la pantalla, podemos colocar logotipos de fondo, elegir el tipo de letra, los colores, absolutamente TODO.

Lista en bajo nivel

Una vez seducidos por el lado oscuro de la fuerza, y viendo las posibilidades del bajo nivel, pocos programadores vuelven a fijarse en la acartonada, fea y rancia API de alto nivel.

Pero como casi todo en esta vida tiene un coste: Generar aplicaciones en bajo nivel es considerablemente más lento que hacerlo con el API de alto nivel, ya que hay muchísimos más parámetros a tener en cuenta (dimensiones de la pantalla, pulsaciones de teclado, anchura de la letra a maquetar, etc.)

Además otras pegas en las que no habíamos reparado comienzan a aparecer: Si yo añado un comando en una aplicación de alto nivel, ésta lo colocará según corresponda en la pantalla (El comando “Atrás” Nokia normalmente lo maqueta abajo a la derecha, Sony Ericsson normalmente abajo a la izquierda),  sin embargo en bajo nivel debo elegir dónde irá.

Esto que pueden parecer pequeños detalles son algunos elementos de usabilidad que hacen que el usuario se frustre o que el tiempo y coste del proyecto se disparen debido a que hay que empezar a hacer diferentes versiones de una misma aplicación para diferentes familias de terminales.

Como vemos, ni todo es blanco ni todo es negro, hay tecnologías y hay proyectos, pero sobre todo hay contextos de uso.

  
Galería de imágenes, Calendario y Radio, desarrollados con bajo nivel

Es recomendable usar alto nivel cuando…:

• La información prime sobre todas las cosas.
  
  
• Se desee que la aplicación se integre como una más del teléfono, respetando el look and feel del mismo.
  
  
• El nivel de usabilidad deba ser alto y por lo tanto la posición de los comandos, colores, etc. de la aplicación deban ser los familiares al usuario. (Plataforma)
  
  
• Se requiera el mayor grado de compatibilidad de la aplicación. (Nada se dibuja con más garantías que lo que dibuja la propia plataforma)
  
  
• Los presupuestos sean muy ajustados. (Relacionado con la siguiente)
  
  
• El periodo de desarrollo sea corto y los plazos de entrega ciencia ficción
  

Es recomendable usar bajo nivel cuando…:

• El Look de la aplicación sea vital para el objetivo de la campaña
  
  
• Técnicamente no haya alternativa en alto nivel (Calendarios, Mapas, Splash Screens, Videojuegos, etc.)
  
  
• Se requiera una distribución de los elementos en pantalla específica. (Bien por look, bien por conseguir alguna funcionalidad extra)
  
  
• Haya tiempo y presupuesto para probar la aplicación exhaustivamente en diferentes modelos de terminales.