2012-05-18 20 views
5

¿Cuál sería la mejor práctica para compartir el código de lógica de negocio bus c entre MonoTouch y Mono para proyectos de Android?Intercambio de código entre MonoTouch y MonoForAndroid

Editado: Inicialmente, mi pregunta era sobre el uso compartido de archivos físicos:

  1. ¿Qué propone utilizar: el intercambio de archivos de red o algún control de versiones de código (Git, SVN)? En mi caso, estoy usando dos estaciones de trabajo: Mac (MonoDevelop con MonoTouch) y PC (Visual Studio con MonoDroid).
  2. ¿Qué hay de la estructura de la carpeta Solución/Proyecto? En "Publicación de blog: Xamarin Mobile World Congress 2012 Unofficial Conference App Released!" la estructura de ejemplo es bastante confusa: varias soluciones en una carpeta y luego diferentes proyectos de plataforma en una subcarpeta con diferentes nombres de carpeta y proyecto. No se puede realizar nativly con IDE. ¿Están editando el contenido de los archivos de la solución y los nombres de las carpetas de forma manual fuera del entorno IDE?
  3. Y para proyectos de código común qué tipo de perfil (plantilla) usar ? Monotouch tiene varios: Proyecto vacío, MonoTouch Library Project y MonoTouch Binding Projects? En Android supongo - biblioteca de clase de Android?
+0

¿se puede expandir? ¿Qué quieres decir con "lógica de negocios"? – Stuart

+0

Todos los códigos C# excepto la IU específica de la plataforma. – Arvis

Respuesta

12

Esta es una pregunta muy general, pero aquí hay algunos recursos que pueden ayudar a empezar:

  1. vídeo: Cross-platform Mobile Development
  2. en blog: Shared Libraries For Windows Phone 7, MonoDroid and Beyond
  3. libro: Mobile Development with C#
  4. Publicación del blog: Xamarin Mobile World Congress 2012 Unofficial Conference App Released!

Editar (para responder a sus nuevas preguntas)

  1. La idea detrás de la vinculación de archivos a través de proyectos es que sólo hay una copia real del archivo, en lugar de tener que gestionar copias múltiples y manténgalas sincronizadas usted mismo. El archivo realmente existirá en un solo proyecto y se vinculará con los demás, pero cuando los proyectos se compilan, trata el archivo como si realmente estuviera allí.

  2. No puedo decir exactamente cómo crearon su estructura de carpetas, pero sé que hubo muchos casos en los que editaría manualmente archivos de proyecto o solución para obtener la estructura de carpetas que quiero, porque no había forma de obtener lo que quería a través del IDE solo. Esto realmente se reduce a preferencias personales sobre cómo desea que se estructuren sus carpetas.

  3. Al final, lo que necesita es un proyecto de biblioteca de clases para cada plataforma que desee orientar. Al ir con el enfoque de archivo vinculado, depende totalmente de usted dónde coloca los archivos físicos. Un enfoque que uso a menudo es crear una biblioteca de clases .NET 4.0 estándar, colocar los archivos allí y luego vincularlos a mis bibliotecas de clases Mono para Android y MonoTouch. Si todo lo que le importa es apuntar a iOS y Android, eso puede ser más problemático de lo que vale, y puede simplemente dejar que los archivos vivan en un proyecto y vincularlos en el otro.

+0

Te habría dado +1 si hubieras mencionado algunos otros libros también :) – Stuart

+1

Eek - ¡sonaba diferente de lo que pretendía! +1 de todos modos. ¡Culpo a los viernes! Lo siento :) – Stuart

+0

¿Tiene alguna sugerencia para mi adición a la pregunta? – Arvis

8

responsabilidad: Tengo un particular Mvvm methodology que utilizo para compartir código a través de proyectos multi-plataforma ...

A pesar de esto, yo realmente no creo en "una talla para todos "frameworks: creo que debe tener cuidado de elegir el enfoque que mejor se adapte a su proyecto, a sus desarrolladores y a su organización.

Dicho esto, algunas de las herramientas que puede utilizar dentro del enfoque de desarrollo Mono son:

  • usando Portable Class Libraries compartir exactamente el mismo código entre plataformas
  • usando bibliotecas de clases específicas de plataforma para compartir código entre plataformas, vinculándolas usando Project Linker tool de Microsoft
  • usando el código #define dentro de sus bibliotecas de clase para proporcionar implementaciones específicas de la plataforma de los proyectos (personalmente trato de evitar este enfoque, pero a menudo proporciona la ruta más rápida al mercado)
  • utilizando técnicas DI/IoC para proporcionar componentes para aquellas ocasiones en las que realmente se requieren implementaciones específicas de la plataforma.
  • utilizando un conjunto de enlaces para proporcionar IoC, p. esto es lo que Xamarin MobileAPI hace
  • usando la lógica basada en el servidor para la funcionalidad compartida genuina - p. utilizando los servicios REST o SOAP en XML para implementar la lógica
  • pruebas de puesta en común (por ejemplo, NUnit) entre plataformas para asegurar la calidad de su lógica
  • utilizando técnicas de códigos compartidos - MVC (MonoCross) o MVVM (MonoMobile.Views o MvvmCross) para la interfaz de usuario " lógica del controlador; MonoTouch.Dialog y MonoDroid.Dialog para abstracciones "a nivel de vista"; CrossGraphics para UI "dibujo"; SQLite.Net para la base de datos; etc.

Estoy descubriendo que las herramientas MonoTouch, MonoDroid y Microsoft brindan beneficios reales y significativos en el desarrollo de código multiplataforma, pero usted tiene que trabajar y pensar para lograr esto.

Cuestiones relacionadas