jueves, 28 de junio de 2012

Venta de Aplicaciones iOS vs Android, en graficos!


Mi agradecimiento a Alejandro Luengo por la info y a http://www.xatakamovil.com
Game Of Phones Infografic
De entre el maremagnum de infografías que florecen en la red al cabo del día, de vez en cuando podemos dar con alguna realmente interesante en el campo que nos ocupa. Esta en concreto, que toma prestado el nombre de una de las series televisivas de moda, muestra de una forma creativa un completo análisis recién salido del horno realizado por Appennie sobre el estado actual de la “guerra” que enfrenta a iOS con Android en el terreno de la venta de aplicaciones, con algunas conclusiones que pasamos a desglosar a continuación.
La batalla por la supremacía entre ambos ecosistemas y el desmesurado crecimiento en cuanto a número de activaciones y aplicaciones, hace que fijemos nuestra atención sobre la posibilidad de que Android haya ganado terreno a iOS como principal fuente de ingresos para los desarrolladores.
Los datos muestras claramente que la voracidad de los asiáticos en el consumo de iPhone e iPad se traslada al número de aplicaciones instaladas desde la App Store, suponiendo China y Japón un 25% del grueso del volumen total de descargas. Si bien el crecimiento de Android en el extremo oriente ha sido uniforme, Google Play no sólo ha de competir con iOS en el mismo terreno, sino que debe enfrentarse a la dura competencia de las tiendas de aplicaciones regentadas por operadores de la región, por lo que aún le queda un difícil camino para consolidarse.
Game Of Phones Infografic
Sin embargo, sólo en el caso del país nipón y los Estados Unidos se cumple el hecho de que son los países que mayores ingresos generan, siendo el Reino Unido el tercero en discordia, llegando a representar más del 60% de los ingresos globales para ambas plataformas.
Ingresos que, por otro lado, han experimentado un fuerte crecimiento en países con enconomías emergentes, como Brasil, donde parece que los fabricantes de terminales con Android parecen haber hecho su agosto, considerando el crecimiento de las descargas de aplicaciones de la plataforma en un 88%. Rusia es otro de los países que aparecen en esta lista con un crecimiento bastante notable con pocos puntos de diferencia en ambos ecosistemas.
No obstante, a pesar de superar de forma arrolladora a Android en cuanto a penetración en los diferentes mercados, esto no se ha traducido en un mayor volumen de ingresos provenientes de Google Play. Por cada dólar que un usuario gasta en la tienda de aplicaciones de Android, un usuario de iOS gasta 2.45 dólares, situando su nivel de ingresos en un 71% frente al 29% de los de Mountain View.
Para más inri de éstos, los datos recopilados entre los meses de enero y abril del presente año dejan bien claro que ambas plataformas crecen al mismo ritmo, por lo que a Google parece quedarle bastante terreno por recorrer aún con el propósito de alcanzar a Apple en el campo de la distribución de aplicaciones para su ecosistema de dispositivos móviles.
Mientras tanto, los desarrolladores parecen tenerlo muy claro a la hora de comercializar una aplicación tratando de obtener el mayor rendimiento económico posible.
Más información | Appannie.

miércoles, 27 de junio de 2012

Jelly Bean: El Resumen


Android 4.1 Jelly Bean
Por fin es oficial, las expectativas de medio mundo para este Google I/O 2012 se han cumplido y la compañía californiana ha presentado puntual en el Moscone Center de San Franscico la que será la próxima versión de Android. Ahora que ya estamos más tranquilos, y a pesar de que media España estará pendiente de las semifinales de la Eurocopa, vamos a recopilar todo lo que significa Android 4.1 Jelly Bean.
Para comenzar, y como se esperaba por la numeración en la versión, las mejoras son más bien profundas, sin que la interfaz sufra un cambio muy grande con respecto a Android 4.0 Ice Cream Sandwich, aunque todo lo que hemos visto nos ha dado la sensación de venir directo a tapar las lagunas que había dejado la anterior versión.

Android 4.1 Jelly Bean, un sistema operativo optimizado y rápido

Esta era sin duda la mejora más esperada, y también el gran caballo de batalla de Android 4.1 Jelly Bean. Lo que Google ha presentado como proyecto Butter llega para mejorar la velocidad, la estabilidad y también la experiencia de uso del sistema operativo.
La compañía de Mountain View está muy segura de las evolución en este sentido, y lo han mostrado con un vídeo a cámara superlenta comparando las animaciones entre Ice Cream Sandwich y Jelly Bean, donde se podía ver la mejora evidente en suavidad al mostrar animaciones gráficas.
Android 4.1 aumentará automáticamente, al tocar la pantalla, la velocidad de trabajo del procesador, haciendo que el sistema se mueva mucho más fluido. Esto conllevará, sin embargo, un probable mayor consumo energético para nuestras maltrechas baterías.

Pocos cambios en la interfaz, muchas más funcionalidades

Era esperado que la interfaz en Jelly Bean se mantuviese prácticamente idéntica, como finalmente ha sucedido. Gráficamente el sistema se moverá mucho más rápido y fluido, con mejor aprovechamiento de los recursos hardware, aunque los cambios más puramente estéticos los veremos en la barra de Google Search y en la cortina de notificaciones.
Jelly Bean Notificaciones
Ahora el sistema de notificaciones es más inteligente y permite muchas más funciones. Se puede extender información gestualmente o interactuar con ciertas aplicaciones desde la propia cortina de notificación, incluso realizar llamadas o controlar ciertas opciones.
Además, se ha conseguido mayor integración para lo que ya era la niña bonita de Android, y es que su sistema de notificaciones es envidiado por la mayoría de sistemas operativos.
Otra mejora muy importante será el tratamiento de widgets y accesos directos desde el escritorio, y es que a partir de ahora los widgets podrán moverse y posicionarse de una forma mucho más intuitiva y natural. Los widgets se redimensionan sólos al tamaño disponible, y los accesos directos se recolocan si es necesario.
Jelly Bean Android 4.1
También se ha puesto mucha atención en mejorar la accesibilidad de nuestro dispositivo, y un nuevo teclado con predicción más inteligente dará fe de ello. Además, habrás nuevos idiomas y tendremos combinaciones de gestos táctiles para invidentes.
Por si esto fuera poco, la síntesis de voz funcionará también en modo “off-line”, es decir, podremos hablarle al teléfono aunque no tengamos conexión a la red para escribir un texto.
Más mejoras han llegado a la cámara, permitiendo ahora ver la galería arrastrando hacia la derecha, y pudiendo recuperar fotos de una manera muy sencilla en caso de eliminarlas sin querer. La integración cámara/galería es insuperable.
Otro servicio que recibirá un empujón será Android Beam, permitiendo ahora que puedan compartir imágenes o sincronizar el Bluetooth.

Google Search se reinventa

Si a algo debe Google su éxito es a las búsquedas, y como se esperaba el cambio en Google Search no será sólo estético. Tampoco vamos a ver una evolución muy grande que acerque las búsquedas a Siri, aunque el camino marcado tiene muy buena pinta.
Ahora las búsquedas podrán utilizar Knowledge Graph, tanto vía teclado como por voz, y aunque la aplicación no funcione completamente como un asistente, si muestra respuestas efectivas a casi cualquier pregunta.
La gran evolución en este aspecto es, sin embargo, Google Now, un sistema que servirá para, según nuestros gustos, predecir las búsquedas que más puedan interesarnos.
En este sentido, podremos ver recorridos, compañías o tiendas, tráfico, vuelos, e incluso nos mostrará resultados de eventos deportivos. Además, la información interactuará entre sí para que podamos aprovechar mejor nuestro tiempo.

Disponibilidad y conclusiones

Android 4.1 Jelly Bean no llega para suponer ningún cambio radical, ni tampoco hará crecer las posibilidades de Android con pantallas grandes o como sistema multimedia. Sin embargo, todas sus mejoras van enfocadas a madurar todavía más una base tan efectiva como Ice Cream Sandwich, que suponía hasta la fecha la mejor versión de Android que se había visto.
Crecimiento de Android
Se han mejorado las lagunas evidentes de versiones anteriores, con mejor rendimiento y velocidad, y un mayor aprovechamiento de los recursos de un hardware que parecía crecer desproporcionadamente con respecto al software.
El resto de mejoras llegan para facilitar directa o indirectamente la experiencia de usuario, y que Android sea por fin un sistema operativo de referencia para dispositivos móviles.
El SDK de la nueva versión de Android estará disponible desde hoy mismo, y también se pondrá a disposición de los fabricantes y desarrolladores un PDK para facilitar la integración del sistema operativo con diferentes tipos de hardware.
Los primeros dispositivos que verán llegar Android 4.1 Jelly Bean serán el Galaxy Nexus, el Nexus S y la tablet Motorola Xoom, que recibirán su actualización a mediados del próximo mes. Los demás, como siempre, necesitarán esperar a que se vayan actualizando poco a poco.

Y como se filtro la info de JellyBean?


Miren esta noticia que publico la gente de http://www.xatakamovil.com , a quienes les agradezco ser la fuente:
Jely Bean
Bueno, ya podemos confirmarlo, la próxima versión Android, numerada como 4.1, será llamada Jelly Bean. El Google I/O 2012 está a la vuelta de la esquina y ya nos parecía raro que no aparecieran informaciones sobre el sistema operativo móvil de Google.
Sobre Jelly Bean sabíamos que era el nombre elegido, pero lo interesante es que no se trata de la versión 5.0, todavía habrá versiones importantes de por medio. Como curiosidad, hace un mes se movió por la red información sobre una tablet Nexus firmada por ASUS, en la que justamente la versión era 4.1.
La información no surge como un rumor, es que en la propia tienda de Google Play se puede ver descrita la versión, sin duda lo más interesante es que es en la página del Samsung Galaxy Nexus. El teléfono será el primero que vendrá con esa versión.
Vía | Droid Life

martes, 26 de junio de 2012

JellyBean en el campus de Google!


La nueva versión del sistema operativo de Google, Android 4.1 Jelly Bean, integrará la primera Google Tab.

Después de los smartphones Nexus de Google, la compañía de Mountain View tiene previsto lanzar una tableta, la cual, será el primer dispositivo que integre Android Jelly Bean, la nueva versión del sistema operativo diseñado por Google.
jelly bean googleplex

La nueva tablet de Google fabricada por Asus
Por el momento, no se conocen oficialmente las posibles prestaciones del nuevo dispositivo de Google aunque todo parece indicar que haya sido producido por la compañía Asus. Sin embargo, el sitio web australiano Gizmodo asegura que ha conseguido una fotografía de la tableta así como apuntes sobre sus características.

Posibles características de la tableta de Google
Google Nexus Tablet dispondrá de un procesador de cuatro núcleos a 1,3 GHz Tegra 3, una unidad de procesamiento gráfico de 12 núcleos GeForce y 1GB de memoria RAM. El tamaño de su pantalla será de 7 pulgadas con una resolución de 1280 x 800 píxeles y niveles de visibilidad desde cualquier punto con un ángulo de visión de 178º.


La estatua de Android Jelly Bean ya adorna el campus de Google, Googleplex, y lo sabemos gracias a las fotos filtradas en Google Plus por parte de los propios trabajadores de la empresa, que comentan que llegó esta mañana.
Android jelly bean googleplex
Quedan horas para saber que nos tiene preparado el Google I/O de este año, pero queda claro que una nueva versión del sistema aparecerá entre las novedades en el escenario.
Aún nos quedan las incógnitas referentes a la cantidad de novedades incluidas en esta versión y que número de versión exacto será (todo apunta a que será Android 4.1), pero lo dicho, mañana (o pasado) lo sabremos definitivamente.

jelly bean googleplex
jelly bean googleplex


miércoles, 20 de junio de 2012

Android - Account Manager (Manejar Cuentas)


Android - Account Manager - Parte I

1. Introducción
Por defecto, Android incorpora un gestor de cuenta, que se utiliza para almacenar las credenciales del usuario y sincronizar con el servidor, si es necesario. Su uso ha sido alentada por el Google en Android  I / O 2011:






2. Nociones básicas
El gerente de cuentas es un servicio centralizado que ofrece el sistema Android. . Cualquier aplicación puede obtener la lista de cuentas y solicitar al usuario utilizar sus tokens de autenticación Básicamente contiene una lista de cuentas, cada una se identifica por:


  • Nombre de la cuenta : El nombre de usuario utilizado para entrar, por ejemplo, jiahaoliuliu
  • Tipo de cuenta : El tipo de la cuenta. Por ejemplo, com.google
Todas las cuentas deben ser únicos en un dispositivo. Esto es, para un dispositivo determinado, no puede haber dos cuentas que tienen el mismo nombre de cuenta y tipo de cuenta.

Para cada una de las cuentas, hay un conjunto de datos relacionados con ella:
  • Contraseña : La contraseña de la cuenta. Podría ser vacía ("").
  • AuthTokens : La cadena que utiliza el servidor para identificar al usuario, en lugar de la contraseña. Normalmente, el token de autenticación es temporal y será vencido después de un tiempo. Todos los tokens de autenticación tienen un tipo, llamado AuthTokenType. Esto es debido a una cuenta podrían ser utilizados para varios servicios, y para cada uno de los servicios que podría haber fichas diferentes auth. Por ejemplo, la cuenta de Google podría ser utilizado para Gmail y Youtube. El authTokenType de Gmail es "mail" y la authTokenType de YouTube es YouTube. Visite esta página web para más información.
  • UserDatas:  Además, el usuario puede guardar los datos del usuario como el par de claves / valor de tipo String. Esto es útil cuando los datos adicionales están asociados con la cuenta de los cuales no son ni la contraseña de token de autenticación.
3. Permisos
Hay varias permiso necesario para interactuar con el administrador de cuentas:
  • android.permission.GET_ACCOUNTS
Este permiso se utiliza para obtener la lista de cuentas y comprobar si una cuenta específica tiene una función específica. (Las características no se habló en este post.)
  • android.permission.USE_CREDENTIALS
Este permiso se utiliza para obtener e invalidar fichas autenticación.
  • android.permission.AUTHENTICATE_ACCOUNTS
Este permiso se utiliza para modificar la información relacionada con la cuenta, como por ejemplo la contraseña, los datos de los usuarios, los tokens de autenticación, etc También se utiliza para crear las cuentas y obtener la contraseña.
  • android.permission.MANAGE_ACCOUNTS
Este permiso se utiliza para agregar o quitar cuentas. Podría ser necesaria cuando la aplicación utiliza las funciones avanzadas de la aplicación, como las credenciales de actualización o propiedades de edición.


4. Gestión de datos con el administrador de cuentas
4.1 Gestor de cuentas
El gerente de cuentas es un servicio centralizado. Las aplicaciones no pueden crear un nuevo administrador de cuentas, pero conseguir la sola existencia de pasar el contexto. Es

Accountmanager Accountmanager = AccountManager.get (Contexto)

Donde el contexto es el contexto de la aplicación.

4.2 Cuentas 
4.2.1 Agregar una nueva cuenta
La forma más sencilla de agregar una nueva cuenta es utilizar el método de:
  • boolean addAccountExplicitly (cuenta de la cuenta, String contraseña, Paquete de datos de usuario)
Avisos de la Cuenta de la clase puede ser fácilmente construido con:

Cuenta = Cuenta nueva (nombre de usuario, accountType)

Ambos parámetros son String.

4.2.2 Obtener una cuenta
La aplicación puede obtener información acerca de todas las cuentas del sistema. Hay dos métodos principales:
  • Cuenta [] getAccount ()
  • Cuenta [] getAccountsByType (tipo String)
El primer método recibe todas las cuentas en el administrador de cuentas y la segunda, obtener sólo las cuentas que coinciden con un tipo específico.

Todas las cuentas tienen dos campos:
  • Nombre : account.name accesible a través de
  • Tipo : acceso account.type utilizando
Por lo tanto, una manera fácil de obtener una cuenta de tipo "com.jiahaoliuliu" que tiene el nombre de usuario "jiahaoliuliu" es la siguiente:

        Cuenta [] = cuentas Accountmanager getAccountsByType ("com.jiahaoliuliu").;
        Cuenta miCuenta = null;
        para la (cuenta de la cuenta: las cuentas) {
            si (account. nombre . equalsIgnoreCase ("jiahaoliuliu")) {
                MyAccount = cuenta;
                romper ;
            }
        }

4.2.3 Eliminar una cuenta
Las cuentas podría ser eliminado por:
  • AccountManagerFuture <boolean> removeAccount (Cuenta, AccountManagerCallback <boolean> de devolución de llamada, el controlador de controlador)
Tenga en cuenta que para cada cuenta, podría haber algunos ajustes que impiden que la cuenta que desea eliminar. Por lo tanto, no garantiza el éxito.

4.3 Contraseña
La contraseña es un conjunto de datos muy sensibles que no deben ser almacenados en ella. Uno de los problemas de seguridad tan grande es que guarda la contraseña en texto plano, sin ningún tipo de cifrado.Revise la sección de seguridad de la segunda parte de este mensaje para obtener más información.

4.3.1 Configuración de la contraseña
Para una determinada cuenta, la contraseña puede establecerse de dos maneras:
  • Cuando la cuenta se crea por primera vez, utilizando el método

boolean addAccountExplicitly (cuenta de la cuenta, String contraseña, Paquete de datos de usuario)

  • Después de que la cuenta ha sido creada

void setPassword (Cuenta cuenta, String password)

4.3.2 Obtener la contraseña
La contraseña puede ser recuperada por el método:

Cadena getPassword (Cuenta)

4.3.3 Borrar la contraseña
No hay un método específico utilizado para eliminar la contraseña.

void clearPassword (Cuenta)

El método anterior tiene el mismo efecto que:

setPassword (Cuenta, null)

4,4 Auth fichas
Como ya he explicado antes, una cuenta es posible que un conjunto de fichas autenticación, cada uno para un servicio específico, identificado por el authTokenType.

4.4.1 Establecer el token de autenticación
Para configurar un token de autenticación, el método de seguimiento se podría utilizar:
  • anular setAuthToken (Cuenta, String authTokenType, String authType)
4.4.2 Obtener el token de autenticación
Hay varias manera de obtener los tokens de autenticación. La forma más sencilla es utilizar el seguimiento uno:
  • AccountManagerFuture <Bundle> getAuthToken (Cuenta, String authTokenType, boolean notifyAuthFailure, AccountManagerCallback <Bundle> de devolución de llamada, el controlador de controlador)
Aquí es un buen ejemplo de uso:

4.4.3 invalidar el token de autenticación
Debido a que normalmente las fichas de autenticación tiene una fecha de caducidad, es una buena práctica para invalidar un token de autenticación cuando no es válida. Para hacerlo así, hay un método específico:
  • void invalidateAuthToken (String accountType, String authtoken)
Tenga en cuenta que el uso debe entrar en el authtoken completa para invalidarlo.

4.5 Los datos de usuario
Además, la aplicación puede introducir cualquier información adicional relacionada con la cuenta mediante el uso de los datos del usuario. Es sólo un mapa de clave / valor que todos ellos son de cadena.

4.5.1 Establecer los datos del usuario
Como la contraseña, los datos del usuario puede ser establecido cuando la cuenta se está creando o más tarde, cuando la cuenta ya existe.
  • boolean addAccountExplicitly (cuenta de la cuenta, String contraseña, Paquete userData)
  • void setUserData (cuenta de la cuenta, clave String, String value)
4.5.2 Obtener los datos de los usuarios
Sólo hay un método para obtener los datos del usuario.
  • Cadena getUserData (cuenta de cuenta, clave String)
4.6 El receptor cuenta actualizada
El gerente de cuentas ofrece la posibilidad de añadir un detector de actualización de la cuenta para actuar cuando una cuenta se ha actualizado. El oyente se aplican a la instancia actual de la Accountmanager.
  • void addOnAccountsUpdatedListener (escucha OnAccountsUpdateListener, controlador de controlador, boolean updateImmediately)
  • void removeOnAccountsUpdatedListener (escucha OnAccountsUpdatedListener)
Es importante notar que mientras que una instancia del gestor de cuentas se está escuchando, no va a ser recogido por el gerente de cuenta, ni el contexto utilizado para recuperarlo. Para evitar fugas de memoria, es importante eliminar el oyente si no se va a utilizar. Por ejemplo, OnDestroy () .

5. Conclusión parcial
El gerente de cuentas es muy útil disponer de todas las cuentas centralizadas en un solo lugar, pero tiene algunos inconvenientes.

martes, 19 de junio de 2012

¿ Es Rentable ser Programador Android ?


Para quienes programamos aplicaciones para Android está claro que sabemos que su entorno permite hacer programas maravillosos. Sin embargo, es clara la competencia con Apple, que con su iOS también tiene verdaderas joyas de la programación. He aquí algunos hechos sobre el entorno de Android, el cual nos podrá dar una idea de si vale la pena programar para este sistema.
Android continúa creciendo así como el número de apps disponibles. Hay actualmente unos 300 millones de dispositivos corriendo Android en el mundo y se activan unos 850 mil dispositivos Android por día. Google ofrece unas 500 mil apps.
Las 10 apps más populares son Facebook y algunas de las que usan los servicios de Google, tales como Search, Gmail y Maps. En el universo de uso, éstas tienen un 43% y después de las 50 apps más populares, el resto —unas 450 mil— tienen el 40% de uso en total. Es decir, sólo las 50 apps más populares se llevan ellas el 60% de los usuarios.
Angry Birds está entre las 10 aplicaciones más populares de Android, la cual es jugada por un 35%  de los usuarios de Android en edades de 35 a 44 años.
Las 10 aplicaciones de paga más populares no significa necesariamente mucho dinero para los programadores, pues no está muy claro cuántos desarrolladores hacen dinero con Android.
Este estudio estadístico es de la empresa StartApp, la cual tiene un modelo alternativo para generar ventas de las apps de Android basadas en la búsqueda de utilidades. Cuando un desarrollador integra el SDK de StartApp en su app, cualquier  usuario que la descargue hallará un icono de búsqueda en su pantalla. Cuando el usuario busca la web a través del nuevo icono, StartApp hace dinero y en vista de esto, puede pagar hasta 50 dólares por cada mil descargas (en Estados Unidos) y 10 dólares por cada mil descargas en otros países. En solamente unos 8 meses, han pagado cerca del millón de dólares a desarrolladores. Para más información sobre este esquema, favor de entrar aquí .

lunes, 18 de junio de 2012

Algunas Razones para Programar en Android

Gente, buenas!
Les comparto un interesante post, que leí en: http://www.elandroidelibre.com

saludos,
MAriano!

desarrollo
Cada dos por tres tenemos ocasión de disfrutar de una característica nueva en Android o en iOS y acabamos comparando estos dos sistemas entre sí, centrándonos en características de atractivo de cara al usuario final.
No obstante, como el interés en general es un poco menor, pocas veces nos ponemos en la perspectiva del desarrollador, tratando de ofrecer argumentos sobre qué plataforma puede resultar más o menos atractiva, sobre todo cuando estás empezando. De hecho, yo mismo me he visto envuelto en esa disyuntiva, cuando planteando un proyecto de entretenimiento móvil, la reunión se sumió en un silencio incómodo (a pesar de que nadie había contado una vergonzante anécdota sexual) y entonces alguien preguntó, ¿y para qué sistema desarrollamos? Tuvimos que debatir largo y tendido para conseguir encontrar una respuesta satisfactoria para nuestros propósitos. Y somos conscientes en EAL de que ahora mismo, hay muchos desarrolladores que se encuentran en una situación como la que nos encontramos mis amigos y yo.
Y así, patrullando por los internetes en busca de porno duro nos hemos encontrado con una interesante recopilación de razones por las que elegir Android frente a iOS para empezar a desarrollar, así que si tenéis alguna duda, o queréis evitar tenerlas, echadle un vistazo.
  • crecimientoMercado mayor y de mayor crecimiento. Podríamos ponernos a citar estudios, pero todos coinciden en un punto: Android crece más y más rápido que ninguno de sus competidores. Esto puede parecer una obviedad (a fin de cuentas, Android cubre mucho más espectro de dispositivos que la competencia), pero es un factor importante, al empezar necesitas visibilidad, ¿y dónde mejor para que te vean que donde hay mucha más gente?
  • Mejor posibilidad de entrar en el mercado.La empresa de búsqueda de aplicaciones Xyologic ha realizado un estudio que descubre que Android funciona más (relacionado con lo anterior) como un entorno creciente, por lo que hay más movimiento en el Top100 que iOS, y que además, debido al crecimiento del mismo, las 25 aplicaciones más descargadas de iOS han sido mucho menos descargadas que las 25 más descargadas en Android durante el pasado Marzo (es donde se ha centrado la muestra).
  • Capacidad de ser descubierto.Tanto el Appstore como Google Play sirven como entornos de búsqueda para las aplicaciones, no obstante, la capacidad en iOS está más limitada, sobre todo en la vertiente del desarrollador, por lo que no podemos saber a través de qué búsquedas han llegado los usuarios hasta nuestras aplicaciones, sino que el ranking, puro y duro, influye mucho más, obligando a que muchos desarrolladores tengan que invertir enormes cantidades de tiempo y dinero en campañas de marketing para poder conseguir situar a su aplicación donde merece (o para situarla mejor de lo que merece).
  • Menor coste de obtención de usuarios nuevos.Debido además a que el Play Store está algo menos poblado, es fácil llegar a la gente. Según un estudio realizado por Fiksu, el inventario de anuncios de Google en este sentido es un 12% mayor que el de Apple, con una ventaja añadida de que el coste por estar ahí es de un 40% menos.
  • Menores problemas de privacidad.Y aquí, queridos niños, no os voy a hablar de una brecha de seguridad abierta por una aplicación malintencionada, sino del método que utilizan los propios proveedores del sistema para hacer un análisis y de esa forma segmentar la publicidad que nos envían. Pues bien, ante un panorama en que la privacidad es cada vez más importante, Apple ha estado apoyándose en una plataforma que a la postre se ha revelado insegura como es el UDID, provocando la búsqueda de alternativas y la fragmentación del mercado de anunciantes en la plataforma.
  • Publicidad mejor segmentada. Y es que, puede gustarte Android o iOS, puedes adorar a Microsoft sobre todas las cosas y que Gates sea tu dios y Ballmer tu profeta, o que esperes con ansia la resurrección del todopoderoso Steve Jobs. En cualquier caso lo que no puedes negar es cuál es el negocio de Google, y que son los mejores en él ahora mismo: la publicidad segmentada. Llevan años haciéndolo, y la parte aplicada a sus plataformas móviles no es una excepción, y aunque desde Cupertino no lo hacen mal, no es lo mismo, por lo que es más fácil conseguir un clic en la publicidad en una plataforma con una publicidad mejor adaptada a ti.
  • androidlabCampo de pruebas más ágil.Si tienes tu cuenta de desarrollador en Android, y creas tu aplicación, subirla al Play Store es tan sencillo como un par de clicks. Si quieres hacerlo en la tienda de iOS es necesario pasar un proceso de aprobación que tarda en torno a una semana, si todo va bien y sale aprobada a la primera. Con lo que si quieres añadir una característica nueva o testear un nuevo modo de juego (por poner algún ejemplo), cosa que suele ocurrir bastante en los desarrollos más nuevos, el sistema facilitado por Google ayuda bastante más, pues las pruebas son mucho más ágiles.
  • Mayor posibilidad de reutilizar conocimiento.Teniendo en cuenta los puntos anteriores, al permitir ser más ágil con la implementación del producto, así como mejor sistema de publicidad, y con menor coste para nosotros en todos los aspectos, es muy fácil utilizar Android para evaluarnos a nosotros mismos, y aprovechar ese conocimiento si damos el salto a otra plataforma como iOS.
  • El sistema de evaluación. Los algoritmos para subir o bajar aplicaciones en los ranking en cada sistema son muy diferentes, pero básicamente en iOS se basan en el número de descargas, mientras que en Android se basa en la cantidad y porcentaje de usuarios que mantienen la aplicación instalada (el marketing te puede llevar a un numero 1 de descargas, pero si tu aplicación es mala, la gente la desinstalará), de esta forma se consigue democratizar un poco el ranking, no limitándolo solamente a aquellas aplicaciones que pueden permitirse ciertos métodos publicitarios para llegar a un público más amplio.
  • Mejoras en la monetización. Este ha sido el talón de Aquiles de Android prácticamente desde su nacimiento, y es que había muy poca gente dispuesta a pagar por las apps. Gran parte de ese problema era Google Checkout, aunque parece que desde la integración de las plataformas Google Wallet y Checkout los pagos se están incrementando en un 80% de media desde Diciembre de 2011 hasta Marzo del presente año. Y claro, eso unido a que Google deja un margen mayor a los desarrolladores permite que los beneficios por aplicación empiecen a aproximarse peligrosamente en ambas plataformas (y por lo que comentan en el estudio, que queden muy por detrás de la tienda de Amazon).
Bueno, pues como veis, razones hay para programar en Android antes que en iOS. Estas son las que han encontrado los chicos de Marketing Pilgrim, si vosotros tenéis otras diferentes compartidlas con nosotros, si las vuestras os llevan a iOS, no dudéis en comentárnoslo también a fin de cuentas, cuanto más ricas sean las opiniones, mejor será la decisión.
En cualquier caso, si decidís desarrollar, echadle ánimo, ilusión (y un buen puñado de horas, os aviso ya) y disfrutad con lo que hacéis, pues es la mejor manera de llevar vuestros proyectos a buen puerto.

sábado, 16 de junio de 2012

¿Qué es OAuth y por qué es importante?


Oauth es un estándar abierto que fue lanzado hacia finales de 2007 que define un mecanismo para que una aplicación web (cliente) pueda acceder a la información de un usuario en otra (proveedor) sin tener que informar a la primera del usuario y contraseña.

Imaginemos que queremos programar una aplicación tipo "página de inicio para el usuario", en la que este pueda añadir sus fotos de Flickr. Para ello utilizaremos el API de Flickr, le pediremos el nombre de usuario y contraseña al usuario y armaremos dicha página. En este tipo de situaciones es en el que Oauth tiene sentido, comunicaciones entre aplicaciones web en la que hay acceso a datos de usuario. La idea es que la aplicación cliente (en este ejemplo nuestra página de inicio) no tenga acceso al nombre de usuario y contraseña del usuario. Dicho de otro modo, Oauth es una metodología para identificación mediante APIs genérica y de implementación gratuita. Si estas cansado de servicios que te piden el usuario de Gmail o Hotmail para proveerte de tal o cual funcionalidad, ya puedes ir viendo por donde puede estar la utilidad de un protocolo como Oauth.

Por supuesto ya hay un montón de estándares cerrados que hacen esto, por ejemplo Google AuthSub o las APIs de Flickr y Facebook, pero la idea tras Oauth es unificar en un estándar abierto de forma que este tipo de comunicaciones entre aplicaciones web (bueno, el cliente puede ser web o de escritorio) no se articulen mediante protocolos propietarios.

Inmediatamente uno piensa en OpenId, pero Oauth no sustituye este estándar para identificación de usuarios, sino que lo complementa. De hecho, los usuarios nunca "ven" nada relacionado con Oauth, situado en el nivel de comunicación entre aplicaciones. De hecho, gran parte de la gracia de Oauth es que el usuario controle a qué datos acceden terceras aplicaciones. Siguiendo con el ejemplo de Flickr, se podría establecer qué tipo de fotos sí y cuáles no desde el servicio proveedor y los clientes no podría obtener nada más.

Como dato curioso, detrás de Oauth están Pownce, Twitter, SixApart, Jaiku, Flickr, Ma.gnolia y Google, entre otros.

Más información en su sitio oficial, que tiene blog.



jueves, 14 de junio de 2012

Permisos en Android



Permisos en Android

 |  | 4 Comentarios
Hoy en día, las aplicaciones de cualquier entorno (web, escritorio, móvil) piden la autorización explícita de los usuarios para accesar a determinada información que puede resultar delicada para el usuario.
En Android, las aplicaciones también requieren de permisos para leer y escribir sobre la información contenida en el dispositivo. El sistema de permisos de Android resulta útil en escenarios “simples” como el manejo de la información de contactos, hasta el uso más complejo de content providers y servicios que requieran de información suministrada de fuentes externas al dispositivo, sobre todo de Internet dónde el escenario de ataques es más amplio.
Nosotros, como Android developers, debemos asegurarnos de que nuestras aplicaciones tienen los permisos adecuados para hacer lo que queramos con la información de otras aplicaciones. De la misma forma, podemos definir permisos para las otras aplicaciones que en determinado momento necesiten consultar nuestra información o servicios, esto claro si decidimos hacerlos disponibles desde otros componentes de Android.

Pidiendo permiso a otras aplicaciones o servicios
Para poder utilizar la información o servicios de otras aplicaciones hacemos uso del famoso archivo AndroidManifest.xml en dónde definiremos un elemento <uses-permission>. Podemos tener cero o muchos elementos de este tipo, definiéndolos todos como hijos directos del elemento raíz del archivo.
El elemento <uses-permission> requiere de la definición de un solo atributo,android:name, dentro del cual definimos el nombre del permiso que requiere nuestra aplicación. Por ejemplo:
<uses-permission android:name=”android.permission.ACCESS_LOCATION” />
Todos los permisos del sistema empiezan con android.permission y se enumeran en ladocumentación oficial del SDK para la clase Manifest.permission. Las aplicaciones de terceros pueden tener sus propios permisos, para los casos en los que deberás consultar su documentación para poder utilizarlos dentro de tus aplicaciones Android. De forma general te describo brevemente algunos de los permisos más utilizados:
  • ACCESS_WIFI_STATE. Le permite a nuestras aplicaciones accesar a la información de las conexiones WI-FI.
  • INTERNET. En caso de que nuestra aplicación desee accesar a Internet para descargar algún dato o para hacer uso de un widget WebView deberemos utilizar este permiso.
  • READ_CALENDAR, READ_CONTACTS. Y todos los permisos con el prefijo READ_ le permiten a nuestras aplicaciones leer la información de los content providersincorporados en Android.
  • WRITE_CALENDAR, WRITE_CONTACTS. Y todos los permisos con el prefijo WRITE_ le permiten a nuestras aplicaciones modificar la información de los content-providersincorporados en Android.
Los permisos se confirman en el momento en que la aplicación se instala en el dispositivo. Para esto, se le pedirá al usuario su confirmación para que la aplicación pueda hacer uso de los permisos que necesita. Por lo tanto resulta importante que selecciones sólo los permisos que realmente necesita tu aplicación y justificar la petición para hacer más sencilla la instalación de la aplicación. Si te encuentras probando tus aplicaciones únicamente en el emulador del SDK, este mensaje no aparece, solamente cuando se requiere instalar en un dispositivo real.
Se puede dar el caso en el que no recibamos la autorización para hacer algo que necesita la aplicación, en los cuáles deberemos manejar una excepción de tipo SecurityExceptionque nos informará del permiso faltante, resaltando que no siempre podrá ser predecible. De todas formas hay que tomar en cuenta que los errores provocados por la falta de verificación de un permiso se dan únicamente si olvidamos pedirle el permiso al usuario; ya que resulta imposible que una aplicación se ejecute si no se le han otorgado los permisos necesarios.

Protegiendo el acceso a nuestras aplicaciones
El otro aspecto que hay que aprender de los permisos tiene que ver con la forma en la que protegeremos el acceso de otras aplicaciones hacia nuestra aplicación. Si nuestra aplicación se conforma únicamente de actividades y de intent receivers, se implementará la seguridad hacia afuera que abarca aspectos relacionados con las solicitudes para recibir el derecho de utilizar recursos de otras aplicaciones.
Si por el contrario, nuestra aplicación utiliza content providers y servicios, deberemos implementar la seguridad hacia adentro para controlar cuáles aplicaciones pueden hacer tal cosa con la información que consulten de nuestra aplicación.
Hasta este punto debemos tener claro que la cuestión de seguridad no va tanto enfocada hacia el hecho de que otras aplicaciones puedan estropear los datos, sino más bien sobre la privacidad de la información del usuario y del uso de servicios que podrían incurrir en gastos. Es aquí donde se concentran los permisos integrados en Android: si podemos leer o modificar los contactos del teléfono, mandar mensajes, etc. Hay que tener muy en claro si las aplicaciones que construyamos almacenarán información y en caso de que así sea, el grado de delicadeza que necesitan esos datos para analizar la estructura de seguridad prudente.
El primer paso para asegurar nuestras aplicaciones es definir los permisos dentro del archivo AndroidManifest.xml. En este caso, en lugar del elemento <uses-permission>utilizamos el elemento <permission> pues lo estamos definiendo. De nueva cuenta, podemos definir de cero a varios permisos, poniendo atención en que sean elementos hijos del elemento raíz del archivo.
La declaración de un permiso es un poco más complicado que usar un permiso. Para esto, necesitamos proporcionar tres datos:
  • El nombre simbólico del permiso. Para evitar que nuestro permiso coincida con el de alguna otra aplicación, se recomienda utilizar el espacio de nombres de las clases Java nuestra aplicación. Por ejemplo: com.androideity
  • Una etiqueta para el permiso. Un nombre corto que se entendible para el usuario.
  • Una descripción del permiso. Un texto un poco más extenso que sea entendible para el usuario.
Ejemplo:
Hay que mencionar que esta definición no forzará de ninguna forma a cumplir con el permiso. Por el contrario, lo único que hacemos es indicar que se trata de un posible permiso. Posteriormente, nuestra aplicación deberá marcar las violaciones de seguridad a medida que ocurran.
Existen dos formas para hacer que nuestra aplicación haga cumplir con los permisos definidos, dictando en dónde y bajo cuáles circunstancias son requeridos. Se puede hacer desde el código o en el manifiesto (que es la forma más sencilla).

Solicitar permisos de apps externas desde el AndroidManifest
Dentro de las actividades, los servicios y los intent receivers podemos definir un atributo llamado android:permission, cuyo valor es el nombre del permiso necesario para accesar a ese elemento. Por ejemplo:
De esta manera, sólo las aplicaciones que hayan solicitado el permiso indicado podrán accesar al componente de forma segura. En este contexto, el “acceso” se entiende como:
  • Las actividades no podrán ejecutarse sin el permiso.
  • Los servicios no podrán arrancarse, detenerse o vincularse a una actividad sin el permiso.
  • Los intent receivers ignorarán los mensajes enviados a través del métodosendBroadcast() a menos que el remitente tenga el permiso.
Los content providers ofrecen dos atributos distintos: readPermission ywritePermissioncomo se muestra a continuación:
En este ejemplo, android:readPermission controla el acceso para consultar al content provider, y android:writePermission controla el acceso para insertar, actualizar o borrar información en el content provider.

Solicitar permisos de apps externas desde el código
En el código Java, existen dos formas de asegurarnos de que las aplicaciones externas están solicitando los permisos necesarios:
  • Los servicios que utilices pueden verificar los permisos en función de cada llamada hecha al método checkCallingPermission(). Este método retornaPERMISSION_GRANTED o PERMISSION_DENIED, dependiendo de si la aplicación tiene el permiso o no. El valor que se le pasa como parámetro es el nombre del permiso que se quiere verificar.
  • Podemos incluir un permiso a la hora de llamar al método sendBroadcast(). De esta forma sólo los receptores con el permiso podrán recibir la información solicitada. Por ejemplo, el subsistema de Android incluye el permiso RECEIVE_SMS para saber cuando un nuevo mensaje ha sido recibido en el teléfono. De esta forma se restringe los receptores que pueden tener acceso a esta información.

Consideraciones extras
Para terminar este tema, tienes que saber que no existe un mecanismo que detecte los permisos que necesita la aplicación en tiempo de compilación; todas las fallas de los permisos se producen en tiempo de ejecución. Por lo tanto, es importante que documentes todos los permisos necesarios para utilizar alguna API pública que hayas creado, incluyendo los content providers, servicios y actividades que se requieren para que se puedan ejecutar otras actividades. De otra forma, los desarrolladores que intenten interactuar con tus aplicaciones deberá realizar una labor titánica sacrificando tiempo en descubrir los permisos que necesita.
De la misma forma, toma en cuenta que los usuarios más técnicos confirmarán que tu aplicación esté haciendo uso de los permisos que dijo necesitar. Así que trata de documentar muy bien los permisos de tal forma que los usuarios entiendan qué tipo de aplicación están instalando para que no se sientan vulnerables a alguna aplicación maliciosa.

Este es un tema fascinante y que debes de dominar al 100% si quieres crear aplicaciones robustas y con una gama de funciones interesantes. Espero que te haya sido de utilidad la información.

FUENTE: http://androideity.com  sitio web muy recomendable para Aprender Android, como usuario o developer.