2009-04-22 5 views
3

Ich entwickle eine iPhone-App für einige süße under Forschung, an der ich gearbeitet habe. Leider bietet meine Schule keine Software Engineering/Design Kurse an, also wenn es um Fragen zu Best Practices in OO Design geht, lese ich viel.Anwendungsdesign und AppDelegate

Mein Dilemma:

Meine Anwendung lädt eine Ansicht (v1), wobei auf Benutzer-Schaltfläche klicken, Controller Klasse v1 eine Aktion Methode ausführt. Diese Aktionsmethode sollte ein Array mit Objekten füllen. Danach führt der Benutzer die Aktion entweder erneut aus oder klickt auf eine andere Registerkarte, um eine andere Ansicht zu laden. Andere Ansichten in der Anwendung verwenden das Array, das von v1 ausgefüllt wurde.

Also, wo sollte dieses Shared Array deklariert werden? Im Moment ist es in der AppDelegate-Klasse, als ich Funktionen ohne GUI getestet habe. Soll ich den AppDelegate Singleton greifen und ihm im v1ViewController Elemente hinzufügen? Sollte es als statisch deklariert werden?

Danke für die Hilfe!

^Buffalo

EDIT:

Follow-up-Frage: Wenn es mit einem Singleton interagieren, was der bessere Weg, um es zu sprechen ist:

[[MyAwesomeSingleton sharedInstance] gimmeSomePizza]; 

oder

MySingleton *s = [MySingleton sharedInstance]; 
[s gimmeSomePizza]; 

Ich denke, was ich frage mich ist, machen Sie die SharedInstance-Methode jedes Mal aufrufen oder y Oder definieren Sie einen Zeiger auf sharedInstance und verweisen Sie dann auf den Zeiger?

Antwort

4

Die Verwendung des App-Delegaten zum Speichern von Daten, die zwischen Ansichten und View-Controllern freigegeben sind, ist angemessen und angemessen.

In meinen Apps betrachte ich den App-Delegaten als Controller-Teil von MVC, wobei UIViews und View-Controller alle Teil der "Ansicht" sind. Ich bevorzuge eine MVC-Variante namens Passive View, die das Modell und die Teile meiner App strikt voneinander trennt und nur den Controller enthält, der sie verbindet.

Ich gehe davon aus, dass das Array von Objekten, die Sie speichern, das Modell Ihrer App ist. Daher ist es sinnvoll, sie auf Ihrem App-Delegaten zu speichern. Wie Daniel D gesagt hat, besteht keine Notwendigkeit, es statisch zu machen.

Der App-Delegierte ist wirklich das Herz Ihres Programms. Sie erstellen und initialisieren Ihr Modell und Ihre Ansichten in Ihrer -applicationDidFinishLaunching:-Methode und speichern Ihre Modelldaten und den Ansichtszustand in -applicationWillTerminate:. Wenn Ihre Ansichts-Controller Ereignisse empfangen, die Ihr Modell ändern, können Sie Methoden auf Ihrem App-Delegaten aufrufen, um diese Änderungen vorzunehmen.

+0

Follow-up-Frage: Wenn es mit einem Singleton interagieren, was der bessere Weg, um es zu sprechen ist: [[MyAwesomeSingleton sharedInstance] gimmeSomePizza]; oder MySingleton * s = [MySingleton sharedInstance]; [s gimmeSomePizza]; Ich denke, was ich frage mich ist, machen Sie die SharedInstance-Methode jedes Mal aufrufen oder definieren Sie einen Zeiger auf die sharedInstance und dann den Zeiger verweisen? – Buffalo

+0

Jeder Weg ist in Ordnung. Im Allgemeinen gibt es keinen nachweisbaren Leistungsunterschied zwischen den beiden. Wählen Sie die Methode, die Lesevorgänge für Sie verbessert. –

0

Sie könnten es in einem ivar im App-Delegaten speichern. Sie müssen es nicht statisch machen, da der App-Delegat ohnehin ein Singleton ist (es gibt nie mehr als eine Instanz).

Wenn der Anwendungsdelegat etwas kompliziert wird, können Sie den Datenspeicher in ein separates Modellobjekt ausklammern oder Kerndaten verwenden.