switch guidelines bars iphone xcode

guidelines - ¿Cuál es la forma estándar de organizar el código MVC del iPhone en XCode?



picker ios (7)

Tengo una aplicación para iPhone que contiene varias vistas y sus controladores asociados. Al observar el código de muestra, he visto diferentes formas de organizar estos archivos: o bien tienen todas las vistas agrupadas, luego todos los controladores agrupados o agrupan las vistas y los controladores por funcionalidad.

Opción 1 - Vistas y controladores agrupados por separado

-Views | - EditItemView.h - EditItemView.m - AddItemView.h - AddItemView.m -Controllers | - EditItemViewController.h - EditItemViewController.m - AddItemViewController.h - AddItemViewController.m

Opción 2 - Artículos agrupados por funcionalidad

-AddItem | - AddItemViewController.h - AddItemViewController.m - AddItemView.h - AddItemView.m -EditItem | - EditItemViewController.h - EditItemViewController.m - EditItemView.h - EditItemView.m

La opción 1 parece tener más sentido desde el punto de vista de MVC: el código está agrupado, pero me pregunto a medida que la aplicación crece a más de 10 vistas y controladores, ¿es el más lógico y fácil de mantener? ¿Hay alguna recomendación de mejor práctica alrededor de esto? Actualmente, seré el único que mantendrá la aplicación, pero si habrá o no múltiples desarrolladores, quiero usar las mejores prácticas tanto como sea posible. ¿Hay normas publicadas sobre esto?

A veces, la mejor práctica es hacer lo que más te convenga. Personalmente, me gusta la agrupación por funcionalidad, pero en cualquier caso puede resultar difícil de manejar si no tiene en cuenta los nombres significativos y los nombres de refactorización cuando ya no describen la funcionalidad.

Estoy trabajando en un gran proyecto xCode ahora mismo. No es para el iPhone, pero no creo que eso importe por el diseño de la estructura de archivos :)

Comencé con la opción # 1 y luego me moví a algo como la opción # 2 cuando la cantidad de archivos aumentó. Tiendo a agrupar las cosas por "interfaces", es decir, a todas las fuentes asociadas con un área particular de funcionalidad dentro de la aplicación, y luego creo subgrupos para secciones más grandes si es necesario.

En cuanto a los nombres, prefiero identificar el Modelo, la Vista y el Controlador usando la menor cantidad posible de bienes raíces para el nombre de la clase, por lo que mis nombres de clase son similares a

AM_DillPickle // model class AV_Sasquatch // view class AC_DirtBike // controller class

Esto todavía permite una verificación visual rápida para ver el tipo de una clase (M, V o C) pero deja más espacio para la parte descriptiva del nombre.

También me ha resultado útil especificar algunas clases que no encajan en el patrón MVC (¡ jadeo !):

AU_Helper // utility class (text formatting, high-level math, etc.) AD_Widget // device class (used to represent hardware drivers)

De todos modos, eso ya es más información de la que pediste, pero creo que el problema de los nombres es relevante para el problema de diseño, ya que la pregunta real es: ¿cuál es la mejor manera de organizar mi código para un proyecto grande de XCode?

Espero eso ayude. Aquí es cómo se ve todo cuando se ponen juntos:

[+] Project [-] Target One [+] Target Two [-] Preferences [-] Login [+] Main Window # MainWindow.XIB # AC_MainWindow.h # AC_MainWindow.m # AC_DisplayScreen.h # AC_DisplayScreen.m [-] Home Screen # HomeScreen.XIB # AC_HomeScreen.h # AC_HomeScreen.m # AV_FancyDisplay.h # AV_FancyDisplay.m [+] Widget Screen [+] Other Screen

La estructura de carpetas estándar de Xcode MVC es la siguiente.

  1. CoreData: Contiene DataModel y Entity Classes.

  2. Extensión: contiene una clase (extensiones de clase de Apple por defecto + extensiones de clase de proyecto).

  3. Ayudante: contiene clases / marcos de terceros (por ejemplo, SWRevealController) + clases puente (por ejemplo, clase Obj C en un proyecto basado en Swift)

  4. Modelo: Cree una clase singleton (por ejemplo, AppModel - NSArray, NSDictionary, String, etc.) para guardar datos. La respuesta del servicio web analiza y almacena los datos también se realiza aquí.

  5. Servicios: contienen procesos de servicio web (por ejemplo, verificación de inicio de sesión, solicitud / respuesta HTTP)

  6. Ver: Contiene el guión gráfico, LaunchScreen.XIB y clases de vista. Crear una subcarpeta de celdas: contiene UitableviewCell, UICollectionView Cell, etc.

  7. Controlador: contiene lógica o código relacionado con UIElements (p. Ej., La referencia de UIButton + acción presionada)

Consulte:

https://github.com/futurice/ios-good-practices#common-libraries http://akosma.com/2009/07/28/code-organization-in-xcode-projects/

Nota: he mencionado las clases de AppModel y AppController (son clases singleton como AppDelegate)

La opción 2 tiene más sentido para mí. Piensa en ello, mientras estás codificando, siempre estás editando alrededor de la "vista" y su controlador, la opción 2 te hace encontrar los archivos adecuados de la manera más eficiente.

La segunda opción tiene mucho más sentido a medida que tu proyecto crece.

Además, el proyecto predeterminado tiene archivos xib que van a los "recursos", pero nuevamente a medida que el proyecto crece, tiene mucho más sentido mover los archivos relacionados a un grupo lógico para alguna pantalla u otra funcionalidad.

Un arreglo de agrupación a modo de ejemplo sería:

3rdParty (for something like regex) Utilities (for category additions to classes like UITableViewCell) Tab1Classes --Screen1 --Screen2 Tab2Classes Tab3Classes Data (for holding plists or other data you may want to load during an app run) Resources (still here for random images it makes sense to keep central)

El delegado de la aplicación podría colgarse en Utilidades, o tal vez simplemente flotando sobre todos los grupos en Clases.

No sé que exista una organización estándar en XCode, especialmente porque la organización de proyectos dentro del IDE a menudo no se traduce como organización de archivos en el disco.

Dicho esto, generalmente hago algo similar a su Opción 1, por ninguna razón mejor que la que más se asemeja a la estructura de carpetas en Rails, que es a lo que estaba más acostumbrado cuando comencé a jugar con el iPhone.