Las API, queridos lectores, son herramientas que ayudan a los programadores a desarrollar una aplicación, de ahí su nombre: Application Programming Interface. Existen varias APIs para el desarrollo de software para el iPhone, que permiten el acceso a el acelerómetro, la cámara, la librería de música, etc.
John Gruber se ha dado cuenta de algo muy curioso: Google Mobile tiene acceso al acelerómetro (algo muy común) pero también al sensor de proximidad, el cual regularmente es muy limitado ya que dentro de una aplicación puede ser activado pero ésta no sabrá cuándo fue activado o desactivado.
En cambio, la aplicación de Google no sólo puede activarlo sino que también sabe en que momento está activada y así capturar tu voz a la hora de realizar una búsqueda (una de las novedades que presentaron hace poco). Así que John cree que hay 3 posibilidades:
- En Google descubrieron esta API secreta pero Apple no se dio cuenta de esto en el proceso de selección.
- Apple sí se dio cuenta pero lo dejó pasar.
- Apple facilitó el acceso a esa API a la gente de Google.
Él descarta la tercera posibilidad por el oscuro proceso de selección que se tiene en el App Store, y puede que tenga razón pues hay manera de utilizar a APIs privadas del iPhone SDK, pero también se trata de Google, un gran aliado y consentido de Cupertino.
Enlace: Google Mobile Uses Private iPhone APIs
Cocotron es un interesante proyecto open-source que pretende “implementar una API multi-plataforma de Objective-C similar a la descrita por Apple Inc. en su documentación de Cocoa.”
Esto supondría un paso importante a la hora de que aplicaciones de OS X puedan ser portadas a Windows, ya que lo haría todo más fácil. No será coser y cantar, pero una gran parte del trabajo ya estaría hecho gracias a Cocotron. Sólo bastaría con adaptar el código propio de Mac a Windows, amén de otros pequeños detalles. Con lo que los desarrolladores ahorrarían en tiempo y dinero.
Esto podría provocar que aparezcan aplicaciones en Windows que antes eran exclusivas para Mac, haciendo que el argumento evangelista de “Esta aplicación sólo está disponible para Mac…” careciera totalmente de sentido. Hablo de aplicaciones de la envergadura de Pixelmator, Coda o el futuro Espresso.
¿Perdería Apple posibles switchers si la mayoría de sus aplicaciones exclusivas estuvieran en Windows? ¿Qué opináis vosotros?
Enlace: Cocotron | Imagen: dirkstoop Flickr | Vía:TUAW
Buenas noticias para los desarrolladores de parte del equipo de Google encargado de la implementación de la API (interfaz de programación de aplicaciones) para Mac OS X ya que, además de poder escribir aplicaciones para el sistema operativo de Apple que hablen directamente con los servidores del buscador, ahora también podrán ser desarrolladas para iPhone.
De esta forma se simplifica todo lo posible el soporte a las aplicaciones en red de Google permitiendo, por ejemplo, integrar la exportación a álbumes de Picassa las fotografías tomadas en el terminal e incluso ideas tan interesantes como mantener un registro de llamadas directamente en Blogger así como el uso de Google Spreadsheet ó Google Base como fuentes de información en forma de base de datos.
Tienes toda la información disponible y el código fuente de la librería en su propia página en Google Code listo para ser utilizado.
Enlace: New frontiers with Google Data APIs and Objective-C
Está claro que ahora tenemos acceso a mucha más información y de manera más sencilla que hace 10 años y vemos con más detalle todos los procesos de la compañía, incluso los de desarrollo de software. Según Vladimir Vukicevic, del equipo de desarrollo de Firefox, Apple usa ciertas API (interfaces de programación de aplicaciones) no documentadas en Safari con las cuales podría dotarle de mayor rendimiento con respecto a las demás aplicaciones.
Todo apunta a que con la actualización de Mac OS X 10.4.4 se introdujo un cambio en la forma de refrescar el contenido de la ventana de los programas que conllevaba la modificación de los archivos de propiedades (.plist) de los mismos para solventarlo. Esto no sería noticia si no fuera porque Safari no implementaba dicho cambio, lo cual indica que no estaba afectado por el problema debido a que utilizan un método de aceleración propio no documentado en su código.
Estas funciones no documentadas no tienen por qué ser un acto de mala fé por parte de los ingenieros, lo que comenta Vukicevic es que estas prácticas no tienen lugar en un proyecto de código abierto como es Webkit y piensa que sería conveniente el acceso por parte de terceros a las mismas para poder realizar mejoras en sus programas.
Enlace: Finding the OS X Turbo Button | Vía: Slashdot
