Struktur einer Applikation

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Aufgrund der Corona-Krise: Die Veröffentlichung von Stellenangeboten und -gesuchen ist bis 31.12.2020 kostenfrei. Das beinhaltet auch Angebote und Gesuche von und für Freischaffende und Selbstständige.

  • Struktur einer Applikation

    Hallo OS X Community,

    ich möchte eine Applikation entwickeln, mit der man Profile von einem Server abrufen kann. Ich hab schon paar kleinere Apps mit UIElementen entwickelt und wäre dankbar, wenn Ihr mir hierbei den Einstieg durch Ratschläge erleichtern könntet.

    Lifecircle:
    Zu Begin soll der User beim App-Start den Login Screen sehen. Nachdem sich der User angemeldet hat (und nach jedem weiterem App-Start) wird dieser weitergeleitet zu einem Menü. Dieses Menü besteht aus einer TabBar sprich mit drei Tabs (User, Profile, Options).
    User: Verwaltung des eigenen Profils
    Profile: Übersicht der anderen Profile
    Options: Optionen die momentan noch nicht relevant sind. (z.b.: Interface ändern)
    (Ich verwende aus Platzgründen keine NavigationBar!)

    Stand:
    Nun bin ich mir nicht sicher, ob meine Vorgehensweise korrekt/elegant ist. Hier mein derzeitiger Stand:
    Ich hab eine leere Application erstellt, die nur das AppDelegate-File beinhaltet. Danach hab ich vier UIViewController (userController, profilController,optionController, loginController) + vier UIView (userView, profilView,optionView,loginView) + UITabBarController (tabBarController) erstellt.

    Im Delegate in der Methode "application didFinishLaunchingWithOptions" erzeuge ich nun jeweils ein Objekt von meinen Controller-Klassen und weise die einzelnen ViewController meinem TabBarController zu. Danach folgt eine Abfrage nach dem Login und es wird gegenenfalls der loginController erzeugt.

    Jeder UIViewController hat als Property die dazugehörige UIView - sprich loginController hat als Property loginView,etc. Beim Erzeugen der Controller wird sogleich die View in der Controller-Methode "loadView" alliiert und die Framegröße festgelegt.

    In den UIView- Klassen wird beim Initialisieren des Frames gleichzeitig alle Buttons und Images erzeugt und ausgerichtet. Zum Testen hab ich den Hintergrund unterschiedlich eingefärbt.


    :!: Soweit so gut. Das Login kommt beim Starten und wechselt zum Menü. Die TabBar funktioniert auch ohne Probleme.

    :?: Ist diese Struktur der Applikation sinnvoll? Sollte man daran etwas verbessern um spätere Fehler zu vermeiden? Ist es sinnvoll Subklassen zu erstellen (jede View hat andere Buttons, Images, Texteingabefelder, etc)? Sollte man die TabBar mit allen dazugehörigen Controllern erst nach dem Login erzeugen und nicht schon im Hintergrund? Performance Probleme?


    Mfg,
    MrOSX

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von MrOSX ()

  • Ich verwende den Interface Builder überhaupt nicht.
    Storyboard wäre interessant gewesen, setzt jedoch iOS 5.0 voraus und ich möchte aber 4.0 verwenden.

    Ist es notwendig eine Subklasse von UIView zu erstellen? Würde es reichen, wenn ich in der "loadView" Methode der Controller eine UIView + UIButtons und alle anderen UI Elemente allokiere? UIView, UIButton, etc könnte ich als Instanzvariablen des jeweiligen Controllers angeben oder?
  • also ich denke nicht dass du UIView subclassen musst, wenn du den UIView in der loadView Methode hinzufügst und dann andere UI Elemente als subViews des UIViews deklarierst, aber mit iOS 4.0 kannst du ja dennoch den Interface Builder benutzen, nimmst halt dann anstelle von Storyboard ganz normal xib Dateien, dann musst du auch nicht alle UI Elemente programmatisch erstellen
    [window close]