Designoptionen für eine iPhone-App mit zahlreichen (~50) Bildschirmen, alle mit demselben Hintergrund

Question

Ich schreibe eine iPhone-App (die meine erste iOS-App sein wird), die etwa 50 Bildschirme hat, von denen jeder den gleichen Hintergrund hat - wobei der Hintergrund ein Bild ist, das die gesamte Bildschirmfläche bedeckt, und ein weiteres Bild am oberen Rand als Banner.

Jeder Bildschirm enthält einen Text und die Schaltflächen 0, 1, 2 oder 3, die unter dem Bannerbild erscheinen.

Welches ist das beste Design für die Zusammenstellung?

Die Optionen, die mir einfielen, waren (in jedem Fall plante ich einen Root-Controller, der für die Anzeige der einzelnen Ansichten verantwortlich ist). 1) Haben Sie 50 separate Bildschirme als xibs (und zugehörige Ansicht-Controller), von denen jeder die zwei Hintergrundbilder plus wie viele Tasten jeder bestimmten Bildschirm benötigt enthält.

2) Sie haben 4 Superklassen als xibs - (die keine Schaltflächen, 1 Schaltfläche, 2 Schaltflächen und 3 Schaltflächen darstellen) und jede von ihnen enthält die Hintergrundbilder und so viele Schaltflächen wie nötig. Dann haben Sie 50 Unterklassen, die einfach nur den Text und den Inhalt der Schaltflächen mit Hilfe der Instanzvariablen Ausgänge der Oberklassen einstellen.

3) Der Root-Controller hat eine Ansicht, die die beiden Hintergrundbilder enthält, die permanent vorhanden sind, und jede der 50 Ansichten zeigt ihren Text und ihre Schaltflächen darüber an.

4) (Wenn dies möglich ist, muss ich prüfen, ob ein Fenster Bilder haben kann). Gleich wie 3, außer dass der Root-Controller keine Ansicht hat, das Hauptfenster zeigt die Hintergrundbilder an und jede Klasse zeigt ihren Text und ihre Schaltflächen oben darauf an. Jeder View-Controller müsste also die Text- und Schaltflächenobjekte mit Code laden und anzeigen (in diesem Fall macht es wenig Sinn, xibs für sie zu haben).

Gibt es eine andere Lösung? Ist eine von ihnen die "beste" Lösung?

Wenn ich mit 3 ging, wäre es nicht möglich, die Position Text und Schaltflächen in einer xib zu definieren? (weil, um dies zu tun, sie eine übergeordnete Ansicht benötigen würde, um sie in Interface Builder zu positionieren, aber wenn das der Fall war, dann, wenn die Ansicht gezeichnet wird der Hintergrund nicht sichtbar sein würde).

Wenn 4 möglich ist, dann der Root-Controller hat keine Ansicht, daher muss es noch von UIViewController abgeleitet werden, oder könnte es einfach von NSObject abgeleitet werden?

Ich denke, im Moment neige ich zu Option 2), da ich auf diese Weise alle Ansichten visuell als xibs entwerfen kann, aber es gibt nur 4 von ihnen. Es sei denn, es gibt eine bessere, elegantere Lösung.

TIA

Answer 1

Was Sie tun können, ist ein XIB mit allen Tasten und dann würden Sie dann versteckt entsprechend eingestellt. Obwohl es würde Sie ein bisschen zu binden. Die Option 2) ist flexibler. Die 3) ist auch in Ordnung. Sie könnten einen RootViewController haben, nur um die Bilder zu halten und dann könnten Sie etwas wie dieses:

[rootViewController.spaceForMyChildView addSubview: myNewViewController.view];

Der "spaceForMyChildView" wäre eine Ansicht, die Ihre untergeordneten Ansichten enthalten würde.

Ich würde wahrscheinlich eine Fusion zwischen 2) und 3) machen.

Answer 2

UIWindow erbt von UIView, kann also alles darin enthalten. So (4) ist machbar, obwohl Sie beginnen, in schwieriges Wasser zu bekommen, wenn Sie jede Art von Ansicht Rotation unterstützen möchten.

Ich würde denken, eine umgekehrte (2) wäre die einfachste Sache - haben eine einzige Superklasse, die auf viewDidLoad fügt den Hintergrund und das obere Banner programmatisch hinzu. Lassen Sie Ihre spezifischen Controller davon erben und gestalten Sie sie grafisch so, dass sie alles enthalten, was Sie wollen, wobei Sie bedenken, dass das Bild und das Banner später hinzugefügt werden.

Wenn Ihre Ansichten jedoch wirklich so einfach sind wie ein einziger Textbereich und bis zu drei Schaltflächen mit festen Positionen, dann ist eine einzelne Ansicht, die ihre Felder aus einer Datenquelle auffüllt, wie Jacky Boy vorschlägt, wahrscheinlich die klügste Lösung.