Grundsatzfragen: App Lifecycle - Wo wird das Data Model initialisiert

Unter Android gibt es eine Application-Klasse,

diese kannst du ableiten und das wäre dann auch dein Hauptsttartpunkt für Init. Diese App Klasse kannst du auch als globalen Singelton betreiben und dort alles reinpacken was Applikationsweit verfügbar sein soll.

Seit der Einführung von Fragmenten brauchst du auch nicht mehr so viele Activities. Man kann auch alles in die Hauptactivity packen und nur die Fragmente austauschen, da ist man vollkommen frei.

http://www.intertech.com/Blog/androids-application-class/

http://tausiq.wordpress.com/20…lass-as-singleton-object/

Hey das komplette Model lädst du niemals komplett in den Speicher, das wäre vollkommen falsch. Für die von dir genannten Anwendungsfälle gibt es die ContentProvider die den Zugriff auf die Datenbank regeln. Von der Application Klasse sollte man idR. die Finger lassen. Und der maximale Payload für einen Intent sind auch irgendwas um 1mb...

Schau dir diesen Artikel mal an: http://www.vogella.com/tutorials/AndroidSQLite/article.html

ContentProvider sind im Prinzip eine Abstraktionsschicht der Datenbank. Du sagst was du haben willst, z.B. eine Liste aller Angestellten und der ContentProvider liefert dir einen Cursor zurück über den du dann iterieren kannst. Genauso kannst du über ContentProvider Datensätze erstellen/bearbeiten.

Außerdem bietet Android schon fertige CursorAdapter um die Daten des Cursors z.B. einer ListView darzustellen.

@Override
    public Loader<Cursor> onCreateLoader(int id, Bundle bundle) {
        CursorLoader cursorLoader = null;


        switch (id) {
            case LOADER_LIST:
                cursorLoader = new CursorLoader(this, TaskProvider.CONTENT_URI, null, null, null, null);
                break;
        }


        return cursorLoader;
    }


    @Override
    public void onLoadFinished(Loader<Cursor> cursorLoader, Cursor cursor) {
        switch(cursorLoader.getId()) {
            case LOADER_LIST:
                mListView.setAdapter(new SimpleCursorAdapter(this, android.R.layout.simple_list_item_1, cursor, new String[]{Task.NAME}, new int[]{android.R.id.text1}, 0));
                break;
        }
    }

Moin,

leider sind Activities weniger wie ViewController in iOS sondern mehr wie Window Controller.
Das Äquivalent zu ViewControllern wären die genannten Fragmente.

Da Android es verpasst hat, eine sinnvolle Modellverwaltung a lá CoreData anzubieten, musst Du Dich leider mit ContentProvidern herumschlagen.
Der einzige Trost: egal ob du das in SQLite oder ein eigenes File speicherst, der Zugriff auf die Schnittstelle ist dann immer gleich.

Du solltest dein komplettes Wissen über iOS über Board werfen, wenn Du mit Android arbeiten möchtest. Hier funktioniert alles komplett anders.
Es gibt kaum bis keine Möglichkeit auf andere Instanzen von Objekten zuzugreifen. Also mal eben den ManagedObjectContext mitschleifen oder das anzuzeigende Objekt übergeben ist nicht drin. Fall 1 fällt in dem Fall also flach.
Statt dessen muss sich jedes Fragment seine Daten selbst besorgen.

Es sieht eher so aus.
Fall 1:
- App wird über Haupt-Icon gestartet und dafür die Haupt-Activity "EmployeeList" gestartet.
- Für die Anzeige der Abgestellten müssten diese natürlich erst einmal geladen werden -> Laden der Liste aus einer Datenbank
- Anzeigen der Liste
- Wechsel zur Payments-Activity. Diese benötigt ebenfalls die Liste der Angestellten und muss sie sich selbst besorgen

Fall2 :
- Start der App über ein Zweiticon das direkt die Payments-Activity startet.
- Die Liste der Angestellten wurde nicht mit übergeben, diese muss also auch hier selber geladen werden.

Und dieser App-Aufbau macht eigentlich überhaupt keinen Sinn. Ich meine, ich habe eine Liste mit Angestellten, wechsle die Ansicht und bekomme eine Liste mit Angestellten. Wozu habe ich dann die Ansicht gewechselt? Die Liste der Angestellten sollte doch eher Ausgangspunkt für alles Andere sein.
Angestellten antippen -> Detailseite mit Kontaktdaten und ein Button zum Aufrufen der Payment Informationen. Vielleicht noch ein Settings-Knopf zum Bearbeiten der Kontaktdaten.
Angestellten lange antippen -> Aufrufen der Payment Informationen

Fall 1:
- App wird über Haupt-Icon gestartet und dafür die Haupt-Activity "EmployeeList" gestartet.
- Für die Anzeige der Abgestellten müssten diese natürlich erst einmal geladen werden -> Laden der Liste aus einer Datenbank
- Anzeigen der Liste mit Vorname, Nachname und Abteilung des Angestellten
+ Fall 1a:
+- Tippen auf einen Angestellten wechselt zur Detailansicht. Übergabe der ID des Angestellten an die Activity.
+- Diese besorgt sich sämtliche Kontaktdaten des Angestellten und stellt sie entsprechend dar.
+- Tippen auf den 'Payments'-Button wechselt zur Payments-Activity. Übergabe der ID des Angestellten an die Activity.
+ Fall 1b:
+- Langes Tippen auf einen Angestellten wechselt zur Payments-Activity. Übergabe der ID des Angestellten an die Activity.
- Die Payments Activity besorgt sich die sämtliche Payment-Informationen zum Angestellten mit dieser id.

Fall2 :
- Start der App über ein Zweiticon das direkt die Payments-Activity startet.
- Eine Angestellten-ID wurde nicht übergeben. Die Activity läd sich sämtliche Payment-Informationen aller Angestellten und gruppiert sie der Übersicht halber nach dem Nach- und Vornamen des Angestellten.