2011-01-02 10 views
37

¿Hay una forma preferida de hacerlo?conecte una aplicación iOS (iPhone) a mac?

La aplicación en cuestión no es demasiado grande. . . juego para un solo jugador que escribí en el transcurso de un par de meses.

EDITAR: Debo añadir que no tengo experiencia con el desarrollo de mac. . . fuera de lo que viene naturalmente con ser un desarrollador de iOS.

EDITAR: Clases muy utilizadas en el juego: subclases de NSObject, UIView y UIViewController. No sé mucho sobre NSView, pero estoy bastante seguro de que todas las cosas de UIView funcionarán en esa clase. También algo de uso de UITableViewController. También tengo Game Center, pero puedo dejar esa parte por ahora. No hay multi-touch.

EDIT: Mis gráficos son todo lo que está en los frameworks QuartzCore y CoreGraphics. Tengo una jerarquía de vista moderada.

EDIT: Si usted está haciendo un puerto de este tipo, también puede estar interesado en el tema de la memory management

+1

¿Qué tecnologías usó para escribir el juego? ¿Cuán dependiente de las clases u objetos de UIKit es usted? –

+1

Solo recuerde que, a pesar de los trackpads, Touch ya no es el método de entrada principal. – BoltClock

Respuesta

25
  1. No hay manera fácil. Es así de simple. Deprimiendo, simplemente tienes que convertirte en bueno en la programación de la Mac.

  2. "Estoy bastante seguro de que todas las cosas de UIView funcionarán en esa clase" - desafortunadamente, no. Todo es diferente, basta con trabajar duro.

No es un concierto divertido. Asegúrate de realmente pensar que vale la pena financieramente.

Aparte de todo lo demás, tenga en cuenta que el problema de las "vistas de hermanos no funciona en OSX" si acumula muchas vistas en su aplicación de iOS. Básicamente, tendrá que cambiar a usar capas (en lugar de simplemente vistas) en la Mac si confía en jerarquías anidadas de puntos de vista aquí y allá en el teléfono.

Haga clic en este enlace: Is there a proper way to handle overlapping NSView siblings? para los detalles sangrientos sobre ese problema en particular!

+0

Sí, a veces me olvido de lo maravilloso que es que UIKit conecte a UIViews con CALayers tan limpiamente. Convertir vistas en capas cuando las cosas empiezan a romperse en OSX no es divertido. –

+0

¿Qué es "las vistas de hermanos no funcionan en el problema de OSX"? Un poco de Google no me ayudó. –

+0

OK, supongo que te refieres al problema al que se hace referencia en [esta pregunta] (http://stackoverflow.com/questions/466297/is-there-a-proper-way-to-handle-overlapping-nsview-siblings) –

4

Es posible que tenga mucho trabajo por delante. Si bien las clases puramente algorítmicas se exportarán sin ningún cambio, todo lo que toque a UIKit probablemente deba ser reescrito o muy adaptado. El patrón de diseño de clase de UI en OSX es el de una relación entre vistas, donde su código es responsable de administrar los controladores; mientras que en iOS es uno de una relación entre los controladores de vista, donde la administración de vistas es implícita.

Por supuesto, como mencionó BoltClock, tiene el problema de la interacción. Como el toque ya no funciona, probablemente tendrá que trabajar primero en su modelo de interacción, incluso antes de comenzar a portar.

2

Existe una biblioteca de fuente abierta (BSD) UMEKit que puede ayudar a portar algunas clases de UI, pero es posible que tenga que volver a escribir una buena cantidad de la interfaz de usuario para manejar mejor la interfaz gráfica de usuario del mouse/teclado/múltiples ventanas ambiente. Los NSObjects básicos, y algunos renderizados de gráficos Open GL y Quartz, pueden portarse con solo retoques menores.

2

Como dicen otros, portar puede ser una tarea ardua. Las técnicas generales funcionan, sin embargo. Se rediseña la interfaz en Interface Builder (donde corresponda) y se comprueba cómo se llaman los diferentes controles (CocoaTouch solo tiene un pequeño subconjunto de controles de escritorio típicos). UI * normalmente se convierte en NS *.La delegación de Tableview es similar, por lo que probablemente sea fácil.

Tendré que recomendar el libro de Aaron Hillegass como de costumbre. Es una gran introducción al desarrollo de Mac, y conocer el desarrollo de iOS te da una ventaja.

Dado que es un juego, probablemente deba considerar cómo hacer el modo de pantalla completa. El juego ya no ocupará toda la pantalla, y no deberías forzarlo. Un nuevo conjunto de preferencias será ahora necesario. Por supuesto, hay algo de "diversión" involucrada ahora que hay nuevas formas de manejar la lista de resolución/cambio con Snow Leopard (con las formas anteriores de advertencias de desaprobación).

simplemente aceptar que habrá un período de transición muy largo, posiblemente, hasta que todo se haga "clic" :)

Cuestiones relacionadas