¿Cuál es la mejor manera de reorganizar elementos en una vista después de la rotation?

Tengo una subvista con (además de otros controles estándar de Cocoa Touch) 6 botones y tags dentro de él.

introduzca la descripción de la imagen aquí

Estoy rotando y cambiando el tamaño de estos botones y tags en el evento de rotation con este código desorderado.

- (void) updateLayoutForNewOrientation: (UIInterfaceOrientation) orientation { if (UIInterfaceOrientationIsPortrait(orientation)) { button1.frame = CGRectMake(20, 59, 130, 80); button2.frame = CGRectMake(170, 59, 130, 80); button3.frame = CGRectMake(20, 176, 130, 80); button4.frame = CGRectMake(170, 176, 130, 80); button5.frame = CGRectMake(20, 293, 130, 80); button6.frame = CGRectMake(170, 293, 130, 80); label1.frame = CGRectMake(20, 147, 130, 21); label2.frame = CGRectMake(170, 147, 130, 21); label3.frame = CGRectMake(20, 264, 130, 21); label4.frame = CGRectMake(170, 264, 130, 21); label5.frame = CGRectMake(20, 381, 130, 21); label6.frame = CGRectMake(170, 381, 130, 21); } else { button1.frame = CGRectMake(20, 59, 130, 60); button2.frame = CGRectMake(20, 155, 130, 60); button3.frame = CGRectMake(177, 59, 130, 60); button4.frame = CGRectMake(177, 155, 130, 60); button5.frame = CGRectMake(328, 59, 130, 60); button6.frame = CGRectMake(328, 155, 130, 60); label1.frame = CGRectMake(20, 127, 130, 21); label2.frame = CGRectMake(20, 223, 130, 21); label3.frame = CGRectMake(177, 127, 130, 21); label4.frame = CGRectMake(177, 223, 130, 21); label5.frame = CGRectMake(328, 127, 130, 21); label6.frame = CGRectMake(328, 223, 130, 21); } } 

Eso es un poco desorderado, pero funciona bien y tengo un control preciso de la position de los elementos en la vista .

introduzca la descripción de la imagen aquí

Por cierto , me pregunto si tener dos vistas diferentes y voltearlas en rotation es más eficiente con respecto a la "potencia de la CPU" y el consumo de memory (creo que tener una sola vista en lugar de dos es mejor para la memory, pero podría estar equivocado, Soy bastante nuevo en la progtwigción de ios).

Gracias por cualquier sugerencia!

En este momento estoy trabajando en un código similar a lo que escribiste. El proyecto es muy grande, difícil de seguir, qué dónde modificar. Fue escrito para iOS 3 y ahora el cliente necesitaba algunas modificaciones. No sería tan grande el problema, si el iOS no cambiara el pushModal y quedaría en desuso en iOS6 … En mi caso tenía que volver a escribir el esqueleto GUI, y tenía los requisitos de Portait / Landscape. Marque algunos enlaces si lo desea: question1 question2 question3 question4

Para un cambio de iOS no previsible, será difícil generalizar ese código, especialmente después de 2 años. No repetiría ese error del progtwigdor que ha trabajado antes.

En tu caso, es mi elección de diferentes soluciones (pero seguro que no):

Solución 1: Cree diferentes xib para paisaje y portait. Tiene la ventaja de la modularidad: más adelante, si no necesita Landscape por diversas razones, es fácil desvincularlo de su código. Tiene la desventaja de crear una nueva vista (bien puede ser almacenada en caching), pero sigue siendo un object diferente y necesita sincronizar datos, entre el controller model-View2.

Solución 2: use solo 1 file xib y distribuya automáticamente los componentes configurando sus properties en el inspector de tamaño (quinta pestaña). Muy difícil de configurar

Solución3: dentro de ese file xib, cree componentes-paisaje y distribuya esos componentes para machacar el layout esperado, el tamaño, y en Runtime, leerlos y establecerlos, como ahora, pero que pueden editarse visualmente.

Storyboard o xib, es casi lo mismo para mí, puede haber 2 UIViewController y pop / push the Portait / Landscape para no llenar la stack con rotaciones 🙂

Velocidad de c es la mejor si no gira, pero si todavía quiere, tal vez el 2 componente en 1 xib, porque no necesita cambiar la visibilidad de 2 a 4 veces, lo que disparará muchas llamadas de function: viewwillappear, wiewdidapear, viewwilldisapers y así sucesivamente.

Usted pregunta:

Por cierto, me pregunto si tener dos vistas diferentes y voltearlas en rotation es más eficiente con respecto a la "potencia de la CPU" y el consumo de memory …

Creo que lo opuesto es cierto. Es mucho más eficiente tener una sola vista para la que simplemente viewWillLayoutSubviews tu método desde viewWillLayoutSubviews (en iOS 5, en iOS 4 generalmente uso willAnimateRotationToInterfaceOrientation ). El aumento de la eficiencia es modesto, pero si la eficiencia es su objective, creo que una única vista es el path a seguir. Es posible que desee utilizar las vistas separadas si son radicalmente diferentes y, por lo tanto, su código sería difícil de administrar con una sola vista, pero de lo contrario me quedo con una vista. Personalmente, también creo que es una interfaz de usuario más fuerte para que los controles se animen en su lugar a medida que gira el dispositivo.

Personalmente, cuando tengo contenido que se reorganiza en cambios de orientación como este, trato de abstenerme de usar coorderadas codificadas, pero más bien uso las dimensiones de la vista para determinar algorítmicamente el layout de mis controles (por ejemplo, cuántos por fila) y de allí, determine sus coorderadas. De esta forma, se encarga no solo del paisaje que del retrato, sino que también hace que las aplicaciones universales (especialmente si hay otros dispositivos con diferentes tamaños de pantalla en el futuro) también sean más fáciles. Creo que también podemos esperar que iOS 6 también ofrezca algunas mejoras agradables a los controles (aunque pasará un time antes de que nos sintamos cómodos desarrollando aplicaciones que requieren iOS 6).