site - iphone store

Aplicaciones de iPhone: ¿Webapps o nativo? (3)

Puedes tomar el pastel y comértelo también.

Puede mezclar fácilmente aplicaciones web y nativas mediante el uso de instancias de UIWebView , por ejemplo, implementar partes sensibles al rendimiento en el código Cocoa / Objective-C, e insertar vistas de WebKit en partes que requerirían demasiado tiempo para reescribirlas como nativas.

Incluso puede envolver toda la aplicación web en un paquete nativo, si desea la distribución de la App Store, consulte PhoneGap .

También puede desarrollar aplicaciones web puras que no se verán como lanzadas a través de Safari, si el usuario agrega su página a su pantalla de inicio, consulte jQTouch .

Inconvenientes:

Las aplicaciones web pueden no ser tan rápidas como las aplicaciones nativas, aunque con la compatibilidad con HTML5 sin conexión y las extensiones específicas de WebKit, como transiciones y animaciones, puede llegar muy lejos. Asegúrese de utilizar eventos táctiles : retrasos de Safari al hacer onclick .

Es difícil hacer que la aplicación web pura se sienta como una aplicación nativa adecuada. Por ejemplo, Mobile WebKit no es compatible con la position:fixed necesita position:fixed corrección para replicar la barra de navegación superior, y las vistas web tienen una velocidad de desplazamiento diferente a la de las vistas de tabla. Es reparable, pero requiere toneladas de JavaScript.

Ventajas:

Desarrollo rápido. Realmente aprecié la utilidad de CSS / HTML para diseños complejos cuando tuve que replicar aplicaciones en UIView s (InterfaceBuilder está bien solo para el diseño semi-fijo).

Estás asegurado contra Apple que de repente odia y prohíbe otra cosa. Si eliminan su aplicación de AppStore, puede permitir que los usuarios accedan a ella a través de la web (Google lo hizo con las aplicaciones de voz y Latitude).

Es más fácil portar aplicaciones web a Android y a otros (WinMo, HP Pre, últimas BlackBerries, etc.) Apple es la número 1, pero su capacidad mental no es proporcional a la cuota de mercado. Otros se están poniendo al día.

Si eliges nativo

Tienes que hacerlo a la manera de Apple: Objective-C y Cocoa (puedes hacer partes de la aplicación en C o C ++). Hay muchos tutoriales y libros sobre el tema, así que no los repetiré aquí. Solo algunos consejos al azar:

Los usuarios, a pesar de ser un formato de iPhone "nativo", no son los mejores para la comunicación cliente-servidor. Las listas XML tienen una sobrecarga elevada incluso para estándares XML, y las listas binarias pueden ser difíciles de generar y depurar. JSON es realmente más rápido y, por lo general, es más fácil trabajar con él.
Si solo busca pequeñas NSConnection de información, NSConnection solo complica las cosas. Simplemente puede usar [NSData dataWithContentsOfURL:] en el método iniciado a través de performSelectorInBackground:
Las notificaciones no se entregan mientras UITableView está desplazando. Si desea imágenes cargadas de forma diferida en su tabla, cárguelas y configúrelas mediante devoluciones de llamada.

Estoy planeando crear una versión de aplicaciones para iPhone para nuestras aplicaciones web en línea. Todavía soy nuevo en el desarrollo de aplicaciones de iPhone, así que no sé si elegir iPhone nativo o una aplicación de Internet que se ejecute en el navegador de iPhone.

El requerimiento es realmente bastante básico. Las aplicaciones de iPhone necesitan enviar datos y obtener datos de la base de datos que también usan los webapps. El usuario tendría el mismo acceso a las aplicaciones web, solo quiero que sea específico para iPhone, ya que la experiencia del usuario sería diferente usando aplicaciones de webapps y iPhone. También estoy interesado en vender la aplicación en la tienda de Apple.

Según su experiencia, ¿qué sería mejor para este tipo de requisitos, iPhone nativo o webapps? ¿Cuáles son los inconvenientes de construir aplicaciones de un iPhone nativo y aplicaciones web que se ejecutan en el navegador del iPhone? Además, ¿solo estoy limitado a Objective-C para crear aplicaciones nativas para iPhone? ¿O hay algún otro marco para eso?

Por favor sé amable conmigo, no estoy empezando una guerra de llamas.

Si desea tener una aplicación en la App Store de iTunes, debe escribir la aplicación en Objective-C. Aquí hay una cita del acuerdo de desarrollador de iPhone OS 4.0 extraído de Daring Fireball . He resaltado la sección más relevante.

3.3.1 - Las aplicaciones solo pueden usar API documentadas de la manera prescrita por Apple y no deben usar ni invocar ninguna API privada. Las aplicaciones deben escribirse originalmente en Objective-C, C, C ++ o JavaScript tal como se ejecutan en el motor WebKit de iPhone OS, y solo el código escrito en C, C ++ y Objective-C puede compilar y enlazar directamente con las API documentadas (por ejemplo, Se prohíben las aplicaciones que enlazan a API documentadas a través de una capa o herramienta de traducción intermedia o de compatibilidad).

Esto, por supuesto, no se aplica a OS 3.1 o 3.2 y actualmente se desconoce si una vez que sale OS 4.0, Apple eliminará retroactivamente cualquier aplicación existente que haya hecho uso de tales herramientas. En teoría, si logras sacar la aplicación de la puerta antes de que salga 4.0 y tienes suerte, entonces quizás puedas utilizar algo como PhoneGap, pero parece ser una gran apuesta pasar tiempo usando ese tipo de herramientas en este punto. .

Dicho esto, Objective-C realmente no es tan difícil de aprender, su sintaxis primaria es [someObject doSomething]; o [someObject doSomethingWith:thisObject]; Tengo muy poco conocimiento sobre el desarrollo web, por lo que no puedo hablar de sus ventajas o desventajas, pero si tiene todo configurado en una aplicación web, es posible que desee inclinarse hacia la opción híbrida mencionada anteriormente o sobre la base puramente web.

PhoneGap , que menciona Noah, es definitivamente una ruta que puede tomar para hacer el desarrollo de HTML + javascript y aún empaquetarlo para su distribución, así como aprovechar varias de las excelentes características nativas del iPhone.

El resto depende de algunos elementos que no has compartido. ¿Qué tan rápido y sencillo quieres que sea la respuesta de la interfaz de usuario / Búsqueda? Ese es un lugar donde la latencia de una aplicación web, incluso a través de 3G, podría alentarlo a buscar una alternativa para presentarla de manera más rápida localmente (usando todas las opciones locales, o incluso Objective-C).

Los otros lugares, que no suenan como si estuvieran en su camino, para buscar dónde podría querer hacer Objective-C directamente son gráficos más pesados y manipulaciones en torno a la animación (aunque javascript + Canvas y HTML5 tratan de hacerme mentiroso) allí), usando la cámara y / o el micrófono para grabar multimedia, o algo que requiera una cantidad razonablemente grande de procesamiento intensivo. Y el último es realmente una pregunta de dónde puedes y quieres tener ese trabajo hecho. En los servidores (opción de estilo de Google típica) o en el dispositivo?