Monotouch.Dialog è un sostituto adatto per tutte le UITableviews?

Question

Questa domanda è rivolta principalmente a Miguel come creatore di MT.Dialog, ma mi piacerebbe sentire anche le opinioni degli altri. Attualmente sto refactoring un progetto che ha molte visualizzazioni di tabella. Mi chiedo se dovrei sostituire tutti con MT.Dialog.

miei pro sono:

• facile da usare
• semplice codice
• speranza che Xamarin lo offrirà cross platform uno giorno

Contro:

• mia le celle sono complete su misura. Ha senso in quel caso?
• prestazioni? È un problema?
• rompere i paradigmi MVC (fonte non più separati dalla vista e il controller)

E 'in generale meglio utilizzare solo MT.Dialog o ereditare da esso per specifici casi d'uso? Quali sono le tue esperienze?

Answer 1

Io uso MonoTouch.Dialog (ed è fratello QuickDialog per objc) praticamente ogni volta che utilizzo un tableview. Aiuta molto semplificare il codice e ti dà una migliore astrazione di un tavolo.

C'è un'eccezione, tuttavia, che è quando la tabella avrà migliaia e migliaia di righe e i dati sono in un database. MT.D/QD richiede di caricare tutti i dati in anticipo, quindi è possibile creare le sezioni, e questo è semplicemente troppo lento se non si hanno già gli oggetti in memoria.

Per quanto riguarda la "rottura di MVC", sono d'accordo con te. A causa di questo, non uso mai realmente i binding reflection in MT.D. Di solito finisco per creare la radice da zero nel codice, o usare qualcosa come JSON (nella mia forcella https://github.com/escoz/MonoMobile.Forms), in modo che i miei oggetti di dominio non abbiano bisogno di sapere su MT.D.

Answer 2

Per rispondere ad alcune delle vostre domande.

La principale differenza tra MonoTouch.Dialog e UITableView è che con il primo si "caricano" tutti i dati che si desidera visualizzare in anticipo e poi si dimenticano. Lascia che MonoTouch.Dialog si occupi di renderlo, spingere viste e prendersi cura di sezioni/elementi. Con UITableView è necessario fornire metodi di callback per restituire il numero di sezioni, i titoli per le sezioni e i dati stessi.

UITableView ha il vantaggio che per rendere dicono un milione di righe con le stesse dimensioni e le stesse cellule, voi non hanno veramente a caricare tutti i dati in anticipo, si può solo aspettare di essere richiamato. Detto questo, questo si interrompe rapidamente se usi celle con altezze diverse, dato che UITableView dovrà interrogare per le dimensioni di tutte le tue righe.

Così, in breve:

(1) sì, anche se si utilizzano le celle personalizzate, potrete beneficiare di codice più corto e un modello di programmazione più semplice. Che tu ne usi o meno le altre caratteristiche, dipende da te.

(2) Per prestazioni, il problema si riduce a quante righe si avrà.Come ho detto prima, se stai navigando su un set di dati potenzialmente di grandi dimensioni, dovresti caricare tutte quelle celle in memoria in anticipo, o come TweetStation, aggiungere funzionalità per caricare "su richiesta".

La realtà è che consumerà più memoria, perché è necessario caricare i dati in MonoTouch.Dialog. La tua migliore tecnica di ottimizzazione è di mantenere i tuoi elementi molto leggeri. Tweetstation ad esempio utilizza un "TweetElement" che tiene semplicemente l'ID al tweet e carica i contenuti effettivi su richiesta, per mantenere la dimensione di TweetElement in memoria molto piccola.

Con UITableView, non si paga per quel prezzo. Ma se non si utilizza un database di qualche tipo, i dati saranno ancora in memoria.

Se l'applicazione richiede che i dati siano in memoria, è possibile spostare i dati come elementi e utilizzarli come modello.

(3) Questo è un po 'un uomo di paglia. La tua "fonte" di dati non è mai realmente indipendente da UIKit. So che alle persone piace parlare di questi modelli come riutilizzabili, ma in pratica non si sarà mai in grado di riutilizzare UITableViewSource come sorgente per qualcosa di diverso da UITableView. L'uso principale è quello di supportare controlli scalabili che non richiedono il caricamento immediato dei dati in memoria, non si tratta di separare il modello dalla vista.

Quindi quello che realmente si ha è una classe di adattatori che collega il mondo di UITableView con il modello di dati attuale (un database, un elenco XML, un array in memoria, una connessione Redis).

Con UITableView, il codice dell'adattatore risiede nel costruttore e in UITableViewSource. Con MonoTouch.Dialog il tuo codice adatpro risiede nel codice che popola il RootElement iniziale a DialogViewController.

---

quindi non ci sono ragioni per usare UITableView sopra MonoTouch.Dialog, ma è nessuna di queste tre Cons.