Ok, ich entwerfe eine App mit einem sehr einfachen Layout von 62 Inhaltsbildschirmen, auf die über 27 Menübildschirme zugegriffen werden kann. Insgesamt sind dies 89 Aktivitäten.
Momentan ist jeder Inhaltsbildschirm eine Aktivität, die nur ein XML-Layout (einige Texte, Schaltflächen und Bilder) aufruft und einige onClick-Funktionen hinzufügt.
Jeder Menübildschirm ist eine ListActivity. Wenn Sie auf jedes Element in der Liste drücken, wird die Aktivität dieses Elements geöffnet (sei es ein anderer Menübildschirm oder ein Inhaltsbildschirm).
Momentan teste ich es mit 3 Menü Screens und einem Content Screen. Es ist in Ordnung, durch alle zu scrollen, aber ich bin besorgt, dass wenn ich die App beende, wird es zu viele Aktivitäten haben und die App langsam und slogish machen. Bei einer durchschnittlichen Nutzung der App stelle ich mir vor, dass der Benutzer nicht mehr als 10 Aktivitäten verwenden würde, aber ich bin mir nicht sicher, ob Android die anderen ungenutzten Aktivitäten oder was sonst noch plant.
Eine andere Möglichkeit, dies zu implementieren, wäre, nur ein paar Aktivitäten zu haben (vielleicht 1 für ein MainMenu, 1 für ein SubMenu und 1 für einen ContentScreen), die nur herausfinden, welches Layout angezeigt werden soll. Aber ich denke, das würde bedeuten, dass jede Aktivität viel mehr Arbeit zu tun hat und ich die Funktionalität des Zurück-Knopfes verliere, der den Benutzer durch die Menü-Hierarchie zurückbringt (und eine Ersatz-Zurück-Taste auf jedem Bildschirm kodieren würde) involvieren Sie einen massiven Fall für das onClick, das jedes einzelne mögliche Layout mit einbezieht, alle 89 von ihnen!).
Was wäre der beste Weg, um über diese App zu gehen?
Jede Hilfe wird sehr geschätzt
Wenn sich Layouts und Verhaltensweisen nicht wesentlich zwischen Menüaktivitäten und Inhaltsaktivitäten unterscheiden, würde ich mit "Nur ein paar Aktivitäten" fortfahren.
Zurück-Taste wird nicht unterbrochen, Android verfolgt Ihren Rückstand.
Brauchen Sie wirklich 89 verschiedene Layouts? Wenn es hauptsächlich Inhalt ist, was zwischen ihnen liegt, speichern Sie Inhalt in einer Datenbank oder Datei oder in /res/ , verwenden Sie Layouts erneut und füllen Sie Inhaltsbereiche des Layouts zur Laufzeit.
Aktualisierungen:
Wäre es nicht einfacher, eine Aktivität pro Inhaltsseite einzurichten, die in onCreate () das Layout mit dem entsprechenden Inhalt ausfüllt?
Hängt davon ab, wie unterschiedlich Ihr onCreate() -Code sein wird. Wenn Ihr onCreate() ein riesiger switch mit 62 sehr unterschiedlichen case -Klauseln ist, dann ist es wahrscheinlich besser, mit separaten kleinen Aktivitäten zu gehen, keine große. Wenn Sie den onCreate() -Code verallgemeinern und unter 100 Zeilen und 10 Verzweigungsanweisungen belassen können, wäre das ein guter Weg.
Um ein Beispiel zu geben, habe ich vor einiger Zeit eine einfache App erstellt, die eine Sammlung von Prüfungsfragen enthält und diese zufällig dem Benutzer präsentiert. Jede Frage hat einen Fragetext, eine Illustration und 2-4 Antworten. Es gab ungefähr 500 verschiedene Fragen. Hier ist der Code, der eine Frage aus der Datenbank lädt und das Layout aktualisiert. Beachten Sie, dass es eine variable Anzahl von Antworten und die Möglichkeit, dass einige Fragen keine Illustration haben, behandelt.
%Vor%Was meinen Sie mit: Zurück-Schaltfläche wird nicht unterbrochen, Android verfolgt Ihren Rückstand?
Wenn der Benutzer von Aktivität zu Aktivität, über Anwendungen, die Android-System behält eine lineare Navigation Geschichte der Aktivitäten der Benutzer hat besucht. Dies ist die Aktivität Stapel, auch bekannt als der hintere Stapel. Im Allgemeinen, wenn ein Benutzer ein neues startet Aktivität, wird es der Aktivität hinzugefügt stapeln, so dass das Drücken von ZURÜCK angezeigt wird die vorherige Aktivität auf dem Stapel.
(aus Richtlinien zum Erstellen von Aktivitäten und Aufgaben )
Sie können Ihr Layout wiederverwenden und können die Methoden startAcitity und startActivityForResult verwenden, um die Aktivitätseffektivität zu verwalten.
Tags und Links android android-layout android-activity