¿Hay alguna ventaja en separar clases de iPhone y iPad en una aplicación Universal?

Tengo una aplicación Universal (para iPhone y iPad).¿Hay alguna ventaja en separar clases de iPhone y iPad en una aplicación Universal?

¿Hay alguna ventaja en separar el iPad de las clases de iPhone en la estructura de carpetas?

Aquí es un ejemplo de lo que quiero decir:

- MyApp 
    - Resources 
    - Classes 
     - iPad 
      - SomeUniqueClassOnIPad.h 
      - SomeUniqueClassOnIPad.m 
     - iPhone 
      - SomeUniqueClassOnIPhone.h 
      - SomeUniqueClassOnIPhone.m 
    - SomeUniversalClass.h 
    - SomeUniversalClass.m

es tan común en los proyectos de Objective-C?

Fuente

2012-04-30 Daniel Ribeiro

Si su clase no tiene nada que ver con vistas (que podrían modificarse), pero implemente alguna lógica, entonces no creo que haya necesidad de separar la clase. Aquí hay un enlace que podría ayudar: http://stackoverflow.com/questions/7315551/iphone-vs-ipad-development-process-differences-and-similarities – superM

Ese enlace me da aún más dudas: http: // stackoverflow. com/a/7315777/807239. Como una aplicación de iPad se usa más que una aplicación de iPhone, debería reconsiderar todo el proceso detrás de la IU y cómo los administran ... ¿Es así? –

Básicamente, la interfaz de usuario del dispositivo al dispositivo cambia mucho más que la lógica. Si su aplicación no es "pesada", no rediseñaría todo el procesamiento. Tengo muy poca experiencia en el desarrollo de iOS (más con Android), pero rara vez he visto que la lógica se implemente separadamente para diferentes dispositivos. Lo mismo es con Android) – superM

Una de las reglas dentro de la codificación es no tener código duplicado, por lo que si las vistas son diferentes o si los datos se manejan de forma diferente dependiendo de si es un iPad o iPhone (por ejemplo, diferentes fuentes de datos) definitivamente estar en diferentes clases, si no ... entonces no. Usa una y la misma clase.

Una cosa que es común y que podría implementarse en tal caso es un tipo de ayudante, una clase de delegado, si lo desea, que maneja todos los métodos y acciones comunes que tienen lugar en su código.

Regla de oro: ¡Escriba la menor cantidad de código posible! Menos código == más mantenible y tiene una calidad superior. Así que escriba el código más pequeño posible sin afectar sus requisitos. Además, divida el código para que sea más fácil de probar (unidad) y, por lo tanto, más fácil de reutilizar.

Espero que haya respondido a su pregunta.

actualización
Sé que hubo una terminología para esto, sólo podía pensar en él. Tener un código duplicado se llama "una violación DRY". DRY significa Do not Repeat Yourself, que es un principio del desarrollo de software dirigido a reducir la repetición de información de todo tipo, especialmente útil en arquitecturas de varios niveles.
Más información: DRY on Wikipedia

Fuente

2012-04-30 13:35:37

Para mí, depende de la similitud entre las vistas de iPhone y iPad. Si hay archivos xib separados pero ambos contienen los mismos elementos, es fácil decidir usar la misma clase.

Si los archivos xib de iPhone y iPad tienen elementos únicos, entonces separar las clases podría ser mejor.

Otra opción es crear una clase base que las clases de iPhone y iPad compartan para los casos en los que desee separarlas. La clase base contendría el código que es común entre ellos, por ejemplo, iniciar solicitudes de datos o una vista personalizada común.

Fuente

2012-04-30 13:40:17 bbarnhart

¿Hay alguna ventaja en separar clases de iPhone y iPad en una aplicación Universal?

Respuesta

Cuestiones relacionadas