XCode Tips - Cambiar el nombre de la compañía

Cuando creas archivos en XCode, aparece al comienzo de los archivos un texto comentado tal que este:

//
// ClaseBasica.m
//
//
// Created by Jesús Mazcuñán Arnandis on 20/11/11.
// Copyright (c) 2011 __MyCompanyName__. All rights reserved.
//

¿Cómo podemos cambiar el nombre __MyCompanyName__?

Como somos personas con recursos, lo primero que haríamos sería buscar en Google. Y probablemente lleguemos a una de esas dos soluciones:

Utilizar el terminal para cambiar el nombre de la compañía por defecto

Abrimos el terminal y escribimos…

defaults write com.apple.Xcode PBXCustomTemplateMacroDefinitions '{ORGANIZATIONNAME="YourNameHere";}'

Esto funciona, pero es mucho más sencillo…

Cambiar el nombre de "Empresa" para nuestro contacto en la Agenda de Apple

Simplemente hay que ir a la agenda, buscar nuestro nombre y ponerle lo que queramos en el campo "Empresa". No era tan complicado… :D

AFAIK: Android y Fragmentacion (II)

Este artículo el ALT1040 ilustra bastante bien parte de lo comentado en el post anterior:

URL: http://alt1040.com/2011/10/la-fragmentacion-de-android-contra-la-de-ios-en-una-grafica

AFAIK: Android y fragmentación.

Hace tiempo estuve pensando en ponerme a desarrollar para Android igual que hago con iOS. Pero al final lo aparqué por diversos motivos. Aún así, tuve la suerte de conocer a un desarrollador de Android (Roberto de Android Spa, y digo quién fue exáctamente porque no se convierta en un "un amigo me dijo que...") que me habló de uno los problemas que se puede encontrar uno desarrollando para este sistema: la defragmentación.

Hasta donde entendí, el problema de la fragmentación, desde el punto de vista del desarrollador, consiste en la gran variedad de dispositivos con capacidades distintas (variaciones leves o no tan leves... como la presencia o no de teclado) que nos llevan a una situación en la que el desarrollo para abarcar el máximo de dispositivos es algo complicado (disponer de dispositivos de pruebas suficientes). No se hasta que punto afecta la fragmentación al software, pero si ya es difícil programar para múltiples dispositivos, añadir a esa fórmula múltiples sistemas operativos distribuyéndose en el mercado de manera conjunta parece complicar el tema. En Geektual hay un gráfico que muestra las versiones actuales de Android conviviendo. Respecto a iOS, no he encontrado nada oficial sobre la distribución de versiones, pero si este interesante estudio de Marco Arment basado en una de sus aplicaciones.

Desde el punto de vista del hardware detrás de iOS, también existen diversas capacidades y versiones. Pero se trata de un entorno controlado. Básicamente existen 4 teléfonos capaces de correr iOS (iPhone OS). El iPhone 2G o EDGE, el iPhone 3G, el iPhone 3GS y el iPhone 4. La variación de capacidades es en ocasiones evolutiva (procesador, RAM...) y en ocasiones "innovadora" (giróscopo, cámara frontal...). En cualquier caso se produce una "ampliación" de características en las versiones más modernas. No un abanico de opciones contrarias entre si. Si un programa necesita la cámara para realizar una acción, el programa puede funcionar perfectamente en dispositivos sin cámara. Esto no tiene sentido si el programa precisa de la cámara, pero si no es su función esencial no es un problema. En el caso de Android, si no disponemos de teclado físico tendremos que sacar un teclado por la pantalla.

La fragmentación en iOS se puede pretender también en el tema de las resoluciones de pantallas. Pero tampoco es un problema. No considero iPad una versión de iPhone, por lo que el cambio real de resolución de 320x480px a 1024x768px no es un problema de fragmentación. Y el cambio de 320x480px a 640x960px de Retina Display no es un problema para el desarrollador. En primer lugar porque se resuelve cambiando el sistema de coordenadas de pantalla de pixels a puntos, con lo que el iPhone 4 tienen la misma resolución de pantalla (en coordenadas) que el resto y no hay que tocar los programas. En segundo lugar porque el mecanismo interno para hacer que una imagen salga en HD es realmente sencillo. Basta con incluir en el proyecto las imágenes en HD y recompilar. No hay que tocar el código.

Por otra parte, también podemos considerar como fragmentación la "obsolencia" de los dispositivos. Si compré un iPhone 3G, no voy a poder estar al día en firmware. Pero eso tampoco significa que los programas que se van a crear no sean compatibles con ese teléfono. Significa que no podrá hacer uso de ciertas capacidades. Aún así, el tiempo de vida del iPhone 3G fue de 32 meses (hablamos de tiempo que soportó actualizaciones de firmware).

Con Android el problema (que habrá gente que no lo vea como un problema) es que puedes comprar un dispositivo y nunca llegar a ver una actualización. No por capacidades del teléfono, sino porque la compañía que lo desarrolla personaliza el entorno y tiene más dispositivos en el mercado a los que les da prioridad.

Desde mi punto de vista como desarrollador web, veo el mismo problema que veo en el Internet Explorer. Hay múltiples versiones en el mercado (aunque en este caso si no se actualizan es mayoritariamente porque la gente no los actualizad, no porque no se pueda) y para hacer ciertas cosas en las páginas web tienes que tener en cuenta múltiples versiones del mismo navegador.

El problema de la fragmentación, tal cual me comentó otro desarrollador (Diego Freniche) puede llevarnos a la situación en que dos personas que compran móviles nuevos y de distribución actual vivan en mundos distintos en relación a las aplicaciones que pueden utilizar.

Entrando (3 de Agostro de 2011 a las 10:00) en la web de Vodafone y marcando que queremos que nos muestre dispositivos con Android, el listado que obtenemos (buscando en Internet qué versión del sistema operativo llevan) es este: Samsung Galaxy S II (2.3.3), LG Optimus 3D (2.2), HTC Sensation (2.3), Sony Ericsson Xperia NEO (2.3), Samsung Galaxy S (2.1).

En los 6 primeros teléfonos que aparecen en el listado vemos que se tenemos versiones 2.1, 2.2, 2.3 y 2.3.3. Y, hasta donde yo se, las actualizaciones entre sistemas no son triviales. No porque sean difíciles (hablamos de actualizaciones para usuarios medios), sino porque algunos fabricantes sacarán la actualización cuando les parezca (si la sacan).

Si vemos los iPhone, aparecen 4 entradas y son el mismo teléfono variando el HD (16/32) y el color (Blanco/Negro). Todos con el mismo sistema operativo y que cuando lo conectemos al iTunes para sincronizar ** nos avisará de la existencia de una nueva versión y se actualizará a la última versión.

Como me decía Diego Freniche: "Explícale tú al usuario, que su móvil recién comprado no es capaz de correr cierta aplicación porque no es compatible con su versión de Android y que puede que nunca lo sea". Por cierto, me encantó el símil que me hizo con este tema y los drivers de tarjetas gráficas para Linux tiempo atrás.

¿A dónde quiero llegar con todo esto? Pues los cortos de mente entenderán "Apple mola". Pero el que lea entre líneas, verá que la fragmentación existe, que es un problema de cara a que el desarrollador pueda abarcar un margen de público maximizado para su aplicación y que las compañías que se apuntan a "la moda del Android" (aclaración para trolls, NO creo que Android sea una moda... y los números están ahí para demostrarlo) sin hacer los deberes van a crear más decepciones en el usuario (que se traducirán en decepciones frente a Android de manera injustificada) y se tirarán piedras sobre su propio tejado. Android se merece más. Sobre todo, porque a este paso, la frase que escuché ayer en la NSCoder Night de Valencia será tristemente cierta: "El usuario medio no se compra un móvil con Android, le venden un móvil con Android". Afortunadamente, parece que Google conoce perfectamente la existencia de este problema.

** A partir de la versión iOS 5 no hará falta conectarse al iTunes para actualizar el dispositivo, según se puede leer en más de una página en Internet.

iOSeando

Mi relación con iOS va viento en popa.

http://www.mazcunan.net/iphone

Los últimos proyectos en los que estoy trabajando son el episodio 2 de RedLED (que hace que el uno me de vergüenza... estoy aún a tiempo de cancelar el proceso de aprobación... pero casi que no) y un proyecto de RPG sencillito.

La verdad es que he visto un juego que es prácticamente el Adventures in LedLand original pero en casposo (y mira que el Adventures in LedLand original era chungo...). Así que no descarto un remake en el tono original. Aunque ya está bastante avanzada una versión nueva que me fue muy útil para hacer pruebas de conceptos pero no acaba de convencerme.

En la líneas de los juegos, también está en marcha (debería ser revisado en breve) el Muff in Line, un tres en raya con magdalenas para entretener a mis sobrinos. También gratuito. Pensaba que era imbatible, pero ya le hemos sacado el bug y sabemos como ganarle. Algo que se corregirá en la versión siguiente. :)

Por otra parte, hay un pack de aplicaciones de esas que hacen mi vida más fácil y llevadera que tengo entre manos. Ya os contaré más... :D

Mucho trabajo...

Estoy trabajando sobre muchas cosas de desarrollo iOS. Tal cual están las cosas, voy a tener que impartir clases de iOS durante 30 días de aquí a Verano. :)

De paso, estoy empezando a tocar también el Cocos 2D para iPhone. La verdad es que está resultando muy entretenido.

He estado probando conceptos en un minijuego sencillito al que le faltan unas cuantas cosas para poder siquiera plantearme el mandarlo al App Store (pero todo llegará...). Os dejo una captura del juego.

La mecánica actual es muy sencilla, se trata de esquivar los donuts que caen desde el toldo, aguantando el máximo de tiempo si chocar con ninguno de ellos. Los gráficos son provisionales y tengo muchas ideas que aplicarle... Ya iré contando como avanza el tema.

Documento técnico de la semana

Coding Guidelines for Cocoa (Apple)

Guías para determinar la forma correcta de poner nombre a las clases, métodos, variables de instancia, funciones, constantes...

Conocer estas guías permite al programador entender mejor cual es la filosofía de Apple a la hora de nombrar los distintos elementos, lo que ayuda a la hora de intuir como debería llamarse algo o averiguar qué es lo que hace.

APIs Privadas

Hace tiempo un alumno me dijo que si la aplicación de inicio del XCode "Window Based Application" era un ejemplo valido de aplicación a modo de linterna. La verdad es que no lo había pensado con detenimiento. Tenía toda la pinta.

Hace poco me lo volvieron a preguntar, pero mi respuesta fue distinta. Puedes hacer que la pantalla se ponga blanca y que la luz ilumine... pero cuando estás a oscuras el brillo del iPhone en la configuración estandar se regula y baja (a menos luz, menos brillo es necesario para ver los contenidos). Luego realmente no es una linterna correcta. Debería encenderse más.

Y luego viene la búsqueda de la función para incrementar el brillo. La respuesta que veo en los foros es: "No se puede. API privada". Mi segundo pensamiento es "¿Stanza lo hace?". La respuesta es "No". Si analizamos Stanza, vemos que es capaz de cambiar el "brillo" de la parte de lectura, el de los controles no cambia. Ergo no cambia el brillo de la pantalla. Lo que hace (o lo que podría hacer) es variar el brillo de una vista. Por ejemplo, podríamos duplicar este comportamiento poniendo una capa negra detrás y variando la opacidad del elemento de lectura. Esto no afecta a los negros pero si a los colores claros. En el caso de la pantalla de texto blanco sobre fondo negro podemos hacerlo al reves.

En cualquier caso, en relación al brillo de la pantalla, solo podemos reducir la cantidad de luz que se emite. No aumentarla (no aumentarla más allá del brillo que tenga la pantalla configurado en ese momento, se entiende...).

Luego las aplicaciones de linterna deben funcionar igual. Es decir, no son tan prácticas como podría parecer... La solució podría estar en el flash del iPhone 4.