Mobiler Einkaufszettel - allgemeine Fragen

[werdas34]

Hallo,
ich soll für das Studium eine Android App schreiben. Separation-of-Concerns und MVVM sollen eingehalten werden. Ich habe bezüglich App Entwicklung keine Erfahrung und erhoffe mir durch diesen Post neue Ideen und hilfreiche Tipps zur Bewerkstelligung der Aufgabe.
Das Thema ist Mobiler Einkaufszettel.
Must have Anforderungen:
- Anlegen, bearbeiten und löschen von Listen und einzelnen Einträgen (+ abhaken).
- Produkte die einmal in der Liste abgelegt wurden, sollen als Art "Autovervollständigung" bei erneuter Suche auftauchen.
- Speichern der Daten über SQLLite oder Firebase.
Paar optionale Erweiterungen:
- einzelne Liste mit anderer Person sharen (Firebase sinnvoller oder?)
- Einbinden von Produktfotos
- Liste mit Tags versehen, nach denen gefiltert/sortiert werden kann
- Barcode Scanner

Meine allgemeine Fragen:
1. Gibts noch andere nützliche Features die man einbauen kann? Oder habt ihr allgemein Tipps, die ich befolgen sollte.
Ich tendiere die ersten drei Punkte der optionalen Anforderungen mit aufzunehmen. Je nachdem wie zeitintensiv auch weniger.
2. Gibt es Artikel, Blog etc die ihr empfehlen könnt? Z.B. Tipps wie man schnellsten Schwachstellen in der UI findet? Allgemein alles was mir hilft eine gute App zu entwickeln. Auch Tipps zu MVVM Tasks usw sind jederzeit willkommen.
3. Uns wurde die Wichtigkeit des Lifecyle erklärt. Ich habe diesen verstanden, wo ich mich noch schwer tue ist, wann ich diese implementiere?
Was rufe ich in einer onRestart() Methode auf? Das selbe wie in onCreate()? Und was schreibe ich in die onDestroy() hinhein?
Ich habe schon paar Sachen getestet (Listview, Intent, etc) und habe nur die Standard onCreate() verwendet. Und die App funktioniert problemlos. Sind die anderen Methoden fürs Feintuning?

Konkrete Frage:
Man hat in Android Studio den "Scenebuilder" für die einzelnen Activitys. Dieser ist von der Layoutgröße unpassend zu meiner mobilen Hardware. (Wir sollen die App explizit für diese Hardware schreiben). Wie passe ich das Layout an, damit die Buttons/Textview usw in Android Studio und am Smartphone an der selben Stelle sind?

mfg werdas34

 

[Robertop]

Wenn ich eine App für genau ein Gerät entwickele, dann mache ich das meistens so, dass ich mir das erstmal in AVD einrichte, danach kann man das im Layouteditor bei Android Studio als Gerät auswählen sollte genau das sehen, was auch auf dem Gerät zu sehen sein wird.

Was für ein Layout verwendest du, dass in Android Studio gut aus sieht, aber auf dem Gerät nicht? Was meinst du mit derselben Stelle? Je nachdem, ob das Gerät größer oder kleiner ist als die Vorschau und ob es eine größere oder kleinere Auflösung hat, als die Vorschau, kann es passieren, dass die Sachen unterschiedliche Größen haben oder der Bildschirm weniger oder mehr gefüllt ist. Aber die relative Position sollte bei den meistens Layouts eigentlich gleich bleiben.

 

[Oneixee5]

1. Gibts noch andere nützliche Features die man einbauen kann?

Evtl. eine Möglichkeit die Preise zu speichern, um später vergleichen zu können.

 

[Jw456]

Hallo viele Fragen die du hast.

Wenn auf den Einkaufzettel andere User, Geräte auch zugriff haben sollen würde ich immer zu einer online DB greifen. zB Firebase.

Lifecyle da schaue dir doch mal die Doku an.
onRestart wird aufgerufen wenn die Activity gestoppt wurde vom User oder System. Das kann man nicht so einfach beantworten kommt immer darauf an was du in der Activity machst.

The activity lifecycle | Android Developers

An Activity is an application component that provides a screen with which users can interact in order to do something, such as dial the phone, take a photo, send an email, or view a map. Each activity is given a window in which to draw its user interface…

developer.android.com

der „Scenebuilder" wie für JavaFX geht unter Android nicht. Dafür gibt es den Layouteditor.
Wenn es für viele Geräte mit verschienen Auflösungen gehen soll würde ich zu dem Constrainlayout oder wenn dir das nicht liegt zum Relativlayout greifen.

 

[Jw456]

Wenn ich eine App für genau ein Gerät entwickele, dann mache ich das meistens so, dass ich mir das erstmal in AVD einrichte, danach kann man das im Layouteditor bei Android Studio als Gerät auswählen sollte genau das sehen, was auch auf dem Gerät zu sehen sein wird.

Was für ein Layout verwendest du, dass in Android Studio gut aus sieht, aber auf dem Gerät nicht? Was meinst du mit derselben Stelle? Je nachdem, ob das Gerät größer oder kleiner ist als die Vorschau und ob es eine größere oder kleinere Auflösung hat, als die Vorschau, kann es passieren, dass die Sachen unterschiedliche Größen haben oder der Bildschirm weniger oder mehr gefüllt ist. Aber die relative Position sollte bei den meistens Layouts eigentlich gleich bleiben.

Da wird er wohl das Constrainlayout benutzt haben und keine Ankerpunkte gesetzt haben.

Tipp man kann auch mit Prozentualen Hilfslinien arbeiten bei einen Constrain.

 

[werdas34]

Evtl. eine Möglichkeit die Preise zu speichern, um später vergleichen zu können.

Sowas ähnliches habe ich auch schon im Kopf gehabt.
Meine Idee war es von jedem Produkt den Preis zu speichern und dann zu zeigen, wie teuer die Einkaufsliste war mit Datum.
Aber für jeden Artikel den Preis einzutragen während dem Einkaufen ist zu viel Aufwand.
Das einzige was ich als sinnvoll erachte ist, den Kassenzettel danach zu scannen und die Preise mit OCR zuzuordnen. Aber ob sich das für den Aufwand lohnt. Zudem wird der Bon immer weniger und die Zuordnung kann problematisch werden. Falls auf der Liste "Joghurt" steht und auf dem Kassenbon nur der Markenname des Produkt, dann kann man das nicht zuordnen.

Hallo viele Fragen die du hast.

Stimmt. Die nächste kommt. Gibt es bestimmte Konventionen, die einzuhalten sind?
Ich habe mich jetzt viel mit Intents beschäftigt und wenn man über putExtra() Informationen weitergibt, werden oft statische Konstanten benutzt, selbst wenn ich einen expliziten Activty-Wechsel innerhalb meiner App vornehme. Bei Ressourchen von Android (Kamera, Map) kann ich die Konstanten nachvollziehen.

Wenn auf den Einkaufzettel andere User, Geräte auch zugriff haben sollen würde ich immer zu einer online DB greifen. zB Firebase.

Ja denke ich mir. Ich muss auch fast ein Loginsystem oder zumindest für den einfachen Fall eine Inputbox für ne BenutzerID haben. Sonst kann ich nicht festlegen an wen ich die Liste share...

Das kann man nicht so einfach beantworten kommt immer darauf an was du in der Activity machst.

Das verstehe ich. Also wird man selten alle Methoden in einer Activity verwenden. Eher ein paar wenige. Natürlich kommt es auf doe App an. Eine mit hohen Sicherheitsstandard wie BankingApps werden auch die onStop() Methode implementieren.

der „Scenebuilder" wie für JavaFX geht unter Android nicht. Dafür gibt es den Layouteditor.
Wenn es für viele Geräte mit verschienen Auflösungen gehen soll würde ich zu dem Constrainlayout oder wenn dir das nicht liegt zum Relativlayout greifen.

Genau den Layouteditor meine ich, der von AndroidStudio frei Haus geliefert wird.
Wir sollen nur für unsere eigene Hardware sprich eine Auflösung das implementieren. Alles andere ginge zuweit.
Ich habe bisher das RelativeLayout genutzt, da mir dieses als Einsteiger empfohlen wird.
Mir gehts darum, ich möchte beim Layouteditor, das Design erstellen udn wenn ich die App dann auf meinen Smartphone teste, soll diese möglichst genauso aussehen.
Ich hatte da das Problem. Zwei Button direkt untereinander und mittig. Bei meinem Smartphone ist der untere Button plötzlich nach links versetzt.
Kann man das nicht an eine Auflösung festnageln?

 

[Jw456]

Dann zeige mal dein layout XML.
Und stelle im LayoutEditor auch deine Handy Display Größe ein.

 

[werdas34]

[CODE lang="xml" title="Layout.xml"]<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".NewDrive">


<Button
android:id="@+id/btnSaveAndReturn"
android:layout_width="310dp"
android:layout_height="wrap_content"
android:layout_alignParentStart="true"
android:layout_alignParentTop="true"
android:layout_centerHorizontal="true"
android:layout_marginStart="46dp"
android:layout_marginTop="197dp"
android:text="Übernehmen und zurück" />

<EditText
android:id="@+id/textInputLocation"
android:layout_width="311dp"
android:layout_height="wrap_content"
android:layout_alignParentStart="true"
android:layout_alignParentTop="true"
android:layout_marginStart="47dp"
android:layout_marginTop="58dp"
android:ems="10"
android:inputType="textPersonName"
android:minHeight="48dp"
android:text="Ort" />

<Button
android:id="@+id/btnShowCurrentLocation"
android:layout_width="310dp"
android:layout_height="60dp"
android:layout_alignParentTop="true"
android:layout_alignParentEnd="true"
android:layout_marginTop="114dp"
android:layout_marginEnd="54dp"
android:text="aktuellen Standort anzeigen" />
</RelativeLayout>[/CODE]

Ich habe nur die Elemente hineingezogen und geschaut das ich keine Fehlermeldung bekomme. So hab eich auf nichts geachtet, außer das sie in der Preview schön ausgerichtet sind.

Ahh. Jetzt habe ich anscheinend die Funktion für das Layout gefunden. Habe dies zuvor nicht gefunden. Ich werde morgen mal testen ob das funktioniert. Habe nämlich grade die Maße nicht da.
Kann man nur die Pixel Geräte wählen oder sind über ein Plugin/Addon auch andere Herstellergeräte verhanden? Ist das überhaupt notwendig. Bilden die Pixel alle möglichen Auflösungen ab?

 

[Jw456]

Du richtet ja alle View Elemente am parent aus und nicht untereinander. Mit zb below und der id.
Button1 zb oben am Eltern Layout. Textview nach dem Button1
Button2 nacht der Textview.

Du richtet jedes Element mit
android:layout_alignParentTop="true
Am oberen Rand aus. Nicht gut.

Relativ heißt eine Anordnung relativ zu einen anderen Element nicht alles zum Rand.

Den ersten Button hast du die Eigenschaft das er dich in der Mitte zentrien soll gegen was sicherlich auf alle Geräte auch genau so sein wird.

Den Rest versuchst du mit dem margin auszurichten was dann natürlich wider Display Größe und dpi Auflösung abhängig ist.

 

[Jw456]

Um eine ziemliche genau Vorschau zu haben ist die Display Größe Zoll und die dpi Auflösung wichtig.

Develop a UI with Views | Android Studio | Android Developers

In the Layout Editor, you can quickly build layouts by dragging UI elements into a visual design editor instead of writing the layout XML by hand.

developer.android.com

Relative Layout | Views | Android Developers

RelativeLayout is a view group that displays child views in relative positions. The position of each view can be specified as relative to sibling elements (such as to the left-of or below another view) or in positions relative to the parent RelativeLayout…

developer.android.com

 

[werdas34]

Das war mir bewusst, das man da viel verbessern kann. Da aber das Layout nur auf einer Hardware laufen muss, sollte es für mich so einfach wie möglich sein. Die App kommt ja nicht in den App Store. Nach der Prüfung wird sie nie wieder angeschaut. So ist das.
Klar könnte man jetzt als extra Feature das responsive Design anbringen. Aber bei uns geht es mehr um funktionale Features als um das eigentliche Design. Allein das Design ist eine Wissenschaft für sich und je nachdem welche Absicht du hast, kann es sinnvoll sein die Ecken des Button abzurunden oder nicht.

Danke für den Tipp mit der Display Größe und der dpi Auflösung.
Wenn ich jetzt eines dieser Referenzgeräte privat besitzen würde, also z.B. das Pixel 3 XL, dann müsste das Layout in der App genauso aussehen wie auf der Preview oder?

 

[werdas34]

Ich habe einen Skin von der offiziellen Hersteller Seite gefunden und eingerichtet. Die erste Preview sieht genauso aus wie auf der konkreten App.
Ich werde dies morgen ausführlich testen.

 

[Jw456]

Mag sein das die App nur einmal angesehen wird. Für mich suchst du zu viele ausreden.

Du wolltest wissen warum dein Layout in der Vorschau anders ausschaut als auf dem echten Gerät. Den Grund weißt du nun.
Ändern willst du es nicht deine Sache.
Merkwürdiges vorgehen bei Problemen.

Vorschau im Editor und Emulator und echtest Gerät sind oft underschidlich.
Nicht nur beim Layout sonder auch maschmal beim Verhalten im Code.

 

[Robertop]

Ich habe bisher das RelativeLayout genutzt, da mir dieses als Einsteiger empfohlen wird.

Ich finde es mit dem ConstraintLayout tatsächlich einfacher, Layouts zu gestalten.

Klar kann man sich immer denken, dass es ja nur für ein einziges Gerät Gedacht ist, aber das ist bei Android Apps aus meiner Sicht keine gute Praxis. Wenn man das ein Mal richtig designed hat, dann sieht das auf den meisten Geräten gut aus und man braucht sich keine Gedanken mehr darum zu machen, welches Gerät man bei der Vorschau verwendet. Du merkst ja schon, dass es da selbst beim selben Gerät Unterschiede geben kann, wenn man die Layouts nicht so verwendet, wie sie Gedacht sind.

Ich weiß noch, dass ich auch mal eine App für ein bestimmtes Gerät designed hatte, aber der Anwender sich dann ein paar Wochen später das neue Modell des Telefons gekauft hat, das dann einen 4K Bildschirm anstatt nur Full-HD hatte. Und dann ging das Layouten von Vorne los...

 

[werdas34]

Zu den Layout was besser für Einsteiger geeignet ist kann ich nicht beurteilen.

Ich gebe euch Recht. Man sollte den Fokus darauf richten, dass es auf möglichst vielen Geräten optisch ansprechend aussieht.
In meinem Fall wird die App als Prüfungsleistung erstellt und das Design wird mit 5% bewertet (stimmiges Design, Bild von Kuh auf Fittnesapp wäre nicht stimmig, sonst keine weiteren Anfroderungen an Design). Es macht für mich bezogen auf die Prüfungsleistung keinen Sinn, mich mehrere Stunden mit responsive Appdesign zu beschäftigen, wenn diese in der Bewertung quasi keine Rolle spielt.
Da fokussiere ich mich lieber auf andere Features.

Und plötzliche Hardwareänderungen kann ich kontrollieren, da es sich um meine eigene Hardware handelt.

 

[Jw456]

Wenn dir hier und da 5 Prozent gegal sind würde ich später kein Programm von dir kaufen.

Vielleicht ist dann ein Linearlayout besser für dich.

 

[Jw456]

Wenn du nur ein Handy benutzt wozu
Soll dann die Liste auch auf einen anderen Handy verfügbar sein.

Habt ihr alle das gleiche Handy. Tauscht ihr es auch alle zur gleichen Zeit.
Na gut du wirst es schon wissen.

 

[Robertop]

Naja, du musst ja auch die Zeit bedenken, die du eventuell noch darein investieren wirst, das Layout anzupassen, weil es im Editor anders aussieht als auf der Hardware. Und bist du wirklich ganz sicher, dass es am Ende nicht heißen wird "Schickt mir die APK, ich schau mir das dann zu Hause an"?

Für was für einen Kurs brauchst du das eigentlich? Wenn es eher um Programmierung an sich geht, kann ich verstehen, dass das Design nicht so wichtig ist. Aber wenn es allgemein um App-Entwicklung geht finde ich 5% doch sehr knapp bemessen. Das Design ist schließlich das Erste, was ein potenzieller Benutzer sieht.

PS: Eine Fitness-App mit einer Kuh klingt doch gar nicht so schlecht. 😂 So Eiweiss-Shakes sind doch mit Milch gemacht, da könnte man sich bestimmt irgendein kuhles Maskottchen zu ausdenken. 🐄

 

[werdas34]

Ich werde mal beim Prof nachhaken, wie es genau mit dem Layout aussieht. Aber so wie er es rübergebracht hat, sollen wir uns um das Design keine allzu großen Gedanken machen.
Es gibt schließlich Studiengänge die sich nur um das Design von Programmen und Apps beschäftigen z.B. IT-Design. Und wir beschäftigen uns mit der Business Logic. Wenn man das auf das MVVM Modell bezieht, dann beschäftigen wir uns mit dem Model und die Designer mit der View.

Dazu hatten wir in der VL auch keine einzige Minute über Layouts verloren. Dalvik VM, MVVM usw schon.

Der Prof wird sich den Quellcode ansehen, aber Fokus auf richtige Datenstrukturen verwendet, Separation of Concern beachtet, Pattern usw. Design wurde nicht erwähnt. Aber wie gesagt ich frage mal nach.

Jetzt kurz ein anderes Thema:
Wir hatten bei MVVM auch das Thema Daten cachen (https://developer.android.com/jetpack/guide). Jetzt sehe ich, dass diese Room Datenbank nur in Kotlin verhanden ist. Verstehe ich das richtig? Würde zumindest erklären warum in der Doku kein Sourcecode Beispiel in Java vorzufinden ist.
Möchte ich also die Firebase-Daten cachen, dann müsste ich das über sqlite machen?

 

[Jw456]

Hallo
Room nur unter Kotlin stimmt nicht.
Geht auch mit Java.
Da Google Kotlin jetzt zur offiziellen Android Sprache gemacht hat findest du halt oft auf den ersten Blick nur Kotlin.
Room gab es schon lange unter Java.

Die Room Lib nutzt auch nur die in Android vorhandene Sqlite Datenbank.

Firebase-Daten Cache, wiso das ist doch eine echtzeit DB. Die sich auch darum kümmern kann wenn User zur gleichen Zeit Daten verändern.

 

[werdas34]

Ah ok. Danke.
Hätte ich noch erwähnen sollen. Offline Cache, wenn man keine Internetverbindung hat, damit die zuletzt geladenen Inhalte gecacht werden und dennoch angezeigt werden können.

Denn unser Prof hat während der MVVM-VL auf das Beispiel von der Dokumentation angesprochen und wir haben dann im nachhinein noch über das cachen geredet. Ging jetzt davon aus das bei dem Projekt, was wir machen, wenn man Firebase nutzt, den Offline-Cache implementieren muss. War deswegen etwas irritiert.

 

[werdas34]

@Jw456, @Robertop

Hallo,

ich habe gerade das Layout skizziert und habe mir Gedanken zur Datenstruktur in Firebase gemacht. Der Punkt mit dem sharen bereit mir jedoch Kopfzerbrechen.
Hier mal meine bisherige Struktur:

- user_0
    - list_0
        - entry_0
        - entry_1
        - entry_2
    - list_1
        - entry_0
    - list_2
    - products
        - "Apple"
        - "Pizza"

- user_1
    - list_0
        - entry_0
        - entry_1
    - products
        - "Milk"
        - "Sugar"

Ich als User gebe in einer bestimmten Liste an, dass ich diese sharen möchte. Dazu gebe ich die user_id an mit der ich diese Liste teilen möchte.
Somit ist bekannt:
user_0 (ich) shared list_1 an user_1.

Wie stelle ich das vernünftig da in der Datenbank?
Zuerst habe ich überlegt, nicht den User eine Liste zuzuordnen, sondern die Liste einem/mehreren Usern.
Die List-Objekte hätten Attribute owner und shared oder so in der Art bekommen.
Problem nur: ich müsste beim Einlesen der Daten, den gesamten Inhalt der DB laden und nicht userspezifisch, da ich bei der Abfrage, keine Unterscheidung zwischen Owner/shared und nicht-Nutzer treffen kann.

Ich müsste irgendwie von user_0, die share-Informationen an user_1 weiterleiten? Ich komme aber nicht auf einen performanten Weg.

Habt ihr oder andere eine Lösung/Idee, wie ich das angehen kann?
Vielleicht kenne ich ein Feature von Firebase noch nicht.

---
Ich soll bereits eingetragene Produkte speichern und als Suchvorschlag anbieten, selbst wenn sie bereits gelöscht sind?
Hat da jemand eine bessere Idee als die Produktbezeichnungen extra abzuspeichern?
Ist halt quasi doppelt..



mfg werdas34

 

[werdas34]

Ich habe mir nun paar Gedanken gemacht, wie das Design sein könnte + Vor und Nachteile.
Ich weiß für meinen Anwendungsfall, ist das Design eigentlich irrelevant, da nicht viele Daten zusammenkommen.
Der Prof. bewertet aber eben Struktur Sachen auch, deswegen möchte ich ein DB-Schema welches gut skalierbar ist und dennoch performant.

1. Eigener sharer-Block. Extra Knoten in dem nur die sharer-Infos drinstehen.
+ einfaches hinzufügen der sharer infos
+ keine extra Abfrage für Produkte
+ nicht alle Knoten müssen betrachtet werden
- extra Abfrage für Sharer Infos
- weiterere Abfrage für sharer-Listen (?) - pro shared-Liste, eine Abfrage zusätzlich

- user_0
    - list_0
        - entry_0
        - entry_1
        - entry_2
    - list_1
        - entry_0
    - list_2
    - products
        - "Apple"
        - "Pizza"
- user_1
    - list_0
        - entry_0
        - entry_1
    - products
        - "Milk"
        - "Sugar"
- sharer
    - user_0
    - user_1
        - user_0
            - list_1

2. Abfrage nach user_name. Jede Liste hat ein Attribute in der die gesamten User festgehalten werden
+ eine Abfrage und alle Daten
+ einfach sharer Infos unterbringen - Namen in Liste hinzufügen
- extra Abfrage für Produkte
- Query über alle DB Knoten

- list_0 [user_0]
    - entry_0
    - entry_1
    - entry_2
- list_1 [user_0, user_1]
    - entry_0
- list_2 [user_1]
    - entry_0
    - entry_1
    - entry_2
- products
    - user_0
        - "Apple"
        - "Beer"
    - user_1
        - "Soda"
        - "Pizza"

3. shared-Info wird als Attribute in der Liste festgehalten
+ keine extra abfrage für produkte
+ User-Content easy abfragen
- shared-Content nur durch alle Knoten durch iterieren

- user_0
    - list_0
        - entry_0
        - entry_1
        - entry_2
    - list_1 [shared to user_1]
        - entry_0
    - list_2
    - products
        - "Apple"
        - "Pizza"
- user_1
    - list_0
        - entry_0
        - entry_1
    - products
        - "Milk"
        - "Sugar"

Wie man sieht habe ich verschiedene Lösungsansätze. Die Frage die ich mir stelle, sind viele DB-Abfragen (1.) performantechnisch kritisch oder potenziell über sehr viele DB-Elemente zu iterieren und nach user_name zu suchen (2., 3.).

Ich bin da sehr unschlüssig. Was sagt ihr? Oder ist ein anderes Schema sinnvoller?

 

[Jw456]

Hallo muss es den unbedingt die Realtime Database sein.

Schaue dir das mal an
https://betterprogramming.pub/using-firestore-with-android-and-architecture-components-cb3b5364027e

Die neuere Firestore Database finde ich für dein Vorhaben auch besser.

Wenn du bei Github auch nach der Programmiererin suchst wirst du das Projekt auch finden.

 

[werdas34]

Hallo,

Firestore ist der Nachfolger von Realtime.
Ich könnte mich auch mit ihr anfreunden. Der große Unterschied ist, dass statt ein JSON-Tree, ein System auf Documents und Collections verwendet wird. Dies erlaubt mir effizientere Abfragen. Aufgrund der Unter-Collections.

Das Schema unter Firestore ist mir auch noch nicht ganz klar.
Das einzige was klar ist:
Informationen einer Liste (Document) -> Entry dieser Liste sind dann in der Unter-Collection.
Wie ich die User und Sharer Informationen verwalte ist mir da noch nicht klar.

Im Blog Beitrag wird nur der simple Fall ohne das sharen gezeigt.

Wie würdest du das unter Firestore umsetzen?

 

[Jw456]

Für die User benutze das Firebase Authentication. Und erstelle sinnvolle Rules oder Regeln für den Zugriff der Daten.

Natürlich ist das Beispiel nur eine Anzeige der Daten die in dem Repository referenziert werden in einer liste . Aber wenn du die Daten in der Liste in der Konsole änderst wirst du es gleich in der App sehen. Da ja in der App ein Listener benutzt wird der ein Event auslöst und die Daten der Liste werden aktualisiert , ohne das du in der App was machen musst.


Eingaben Löschen der Daten auf der DB ist natürlich noch nicht vorhanden das musst du machen.
Es zeigt dir nur wie du die Daten abhorchen kannst wenn du auch die rechte daran hast.


Da du bestimmt deine DB Rules öffentlich für alle hast braucht du natürlich keine User Steuerung . Das willst du bestimmt nicht, also schaue dir Authentication und Rules an.