¿Monotouch.Dialog es un reemplazo adecuado para todas las UITableviews?

Question

Esta pregunta está dirigida principalmente a Miguel como el creador de MT.Dialog, pero me gustaría escuchar opiniones de otros también. Actualmente estoy refactorizando un proyecto que tiene muchas vistas de tabla. Me pregunto si debería reemplazarlos a todos con MT.Dialog.

Mis ventajas son:

• fácil de usar
• código simple
• esperanza de que Xamarin lo ofrecerá plataforma transversal, uno día

Contras:

• mi las células están completamente hechas a medida. ¿Tiene sentido en ese caso?
• rendimiento? ¿Es eso un problema?
• romper los paradigmas MVC (de origen ya no separadas de la vista y el controlador)

es en general mejor que sólo tiene que utilizar MT.Dialog o heredar de ella para los casos de uso específicos? ¿Cuáles son tus experiencias?

Answer 1

utilizo MonoTouch.Dialog (y es hermano de QuickDialog objc) más o menos cada vez que utilice un tableview. Ayuda mucho simplificar el código y ofrece una mejor abstracción de una tabla.

Hay una excepción, sin embargo, que es cuando la mesa tendrá miles y miles de filas, y los datos están en una base de datos. MT.D/QD requiere que cargue todos los datos por adelantado, para que pueda crear las secciones, y eso es simplemente demasiado lento si aún no tiene los objetos en la memoria.

En cuanto a "romper MVC", que tipo de acuerdo con usted. Realmente nunca utilizo los enlaces de reflexión en MT.D por ese hecho. Por lo general, termino creando la raíz desde cero en el código, o uso algo como JSON (en mi fork https://github.com/escoz/MonoMobile.Forms), para que mis objetos de dominio no necesiten saber acerca de MT.D.

Answer 2

Para resolver algunas de sus preguntas.

La principal diferencia entre MonoTouch.Dialog y UITableView es que con el primero "carga" todos los datos que desea mostrar por adelantado, y luego se olvida de ello. Dejó que MonoTouch.Dialog se encargue de representarlo, impulsando vistas y cuidando secciones/elementos. Con UITableView es necesario proporcionar métodos de devolución de llamada para devolver el número de secciones, los títulos de las secciones y los datos en sí.

UITableView tiene la ventaja de que para renderizar, por ejemplo, un millón de filas con el mismo tamaño y las mismas celdas, no es necesario cargar todos los datos por adelantado, solo puede esperar a que se le devuelva la llamada. Dicho esto, esto se rompe rápidamente si usa celdas con diferentes alturas, ya que UITableView tendrá que consultar los tamaños de todas sus filas.

Así que en resumen:

(1) sí, incluso si utiliza células personalizados, que se beneficiarán de código más corto y un modelo de programación más simple. Ya sea que use las otras características o no, depende de usted.

(2) Para obtener un rendimiento, el problema se reduce a la cantidad de filas que tendrá.Como mencioné antes, si está explorando un conjunto de datos potencialmente grande, tendría que cargar todas esas celdas en la memoria por adelantado, o como TweetStation, agregar características para cargar "a pedido".

La realidad es que consumirá más memoria, porque necesita cargar sus datos en MonoTouch.Dialog. Su mejor técnica de optimización es mantener sus elementos muy ligeros. Tweetstation, por ejemplo, utiliza un "TweetElement" que simplemente contiene el ID del tweet y carga los contenidos reales a pedido para mantener el tamaño del TweetElement en la memoria muy pequeño.

Con UITableView, no paga por ese precio. Pero si no está utilizando una base de datos de algún tipo, los datos aún estarán en la memoria.

Si su aplicación requiere que los datos estén en la memoria, entonces también podría mover los datos para que sean elementos y usarlos como su modelo.

(3) Esto es un poco de un hombre de paja. Su "fuente" de datos nunca es realmente independiente de UIKit. Sé que a la gente le gusta hablar sobre estos modelos como reutilizables, pero en la práctica, nunca podrá reutilizar una UITableViewSource como fuente para nada más que una UITableView. Su uso principal es admitir controles escalables que no requieren que los datos se carguen en la memoria por adelantado, en realidad no se trata de separar el Modelo de la Vista.

Lo que realmente tiene es una clase de adaptador que une el mundo de UITableView con su modelo de datos real (una base de datos, una lista XML, una matriz en memoria, una conexión Redis).

Con UITableView, su código de adaptador reside en el constructor y el UITableViewSource. Con MonoTouch.Dialog, su código adatpro reside en el código que rellena el RootElement inicial en DialogViewController.

---

por lo que hay razones para usar UITableView sobre MonoTouch.Dialog, pero no es ninguna de esas tres contras.