digilist / oose-banking Goto Github PK

Im Landscape Modus funktioniert die Navigation aktuell nur auf dem Dashboard. Dies muss für alle Views funktionieren.

Standard Formular anlegen, um eine Überweisung durchzuführen. Beim Absenden der Überweisung wird eine Tan abgefragt und nach einer erfolgreichen Transaktion wird diese in die Liste aller Transaktionen übernommen.

Es muss eine grundsätzliche Softwarearchitektur herausgearbeitet werden, die vorgibt, wie wir Views, Controller, Entitäten usw. strukturieren.

Hierbei handelt es sich mehr um Vorgaben als um Implementierungen. Daher muss dieser Schritt gut dokumentiert und für alle Verständlich, nachvollziehbar und nachlesbar sein, damit wir durch den Projektverlauf wenig Diskussionen hierzu haben.

Implementierung der Diagramme auf dem Dashboard.

Vorher muss nochmal eindeutig festgelegt werden, welche Werte wir dort nun in Diagrammen darstellen wollen. In der Mockup-Phase haben wir das nicht endgültig definiert.

Einige Features der App dürfen erst nach Authentifizierung durch die Kontodaten vollständig genutzt werden.

Als ersten Schritt muss das Gerät bei der Bank registriert werden. Im Login Screen erscheint daher eine Meldung und direkt ein Eingabefeld in dem ein Freischaltcode eingegeben werden kann. Nach erfolgreicher Eingabe erscheint dann der normale Login mit Kennung und Passwort.

Unter dem normalen Login-Formular soll auch ein Button/Link "Passwort vergessen?" gezeigt werden. Dort sollen die Schritte hinterlegt werden, die nötig sind um das Passwort zurück zu setzen. Ich schätze mal, man muss sich beim Berater melden, kA ob persönlich oder per Telefon. Vorschläge sind willkommen.

Eine kleine Tabelle, in der die letzten Transaktinoen dargestellt werden. Daneben / Dadrunter / Whereever einen Link zu allen Transaktionen.

Die Mockups müssen nochmal weitergeführt und zu Ende gedacht werden. An einigen Stellen sind bestimmt auch noch verfeinerungen / verbesserungen möglich.

Wichtig ist, dass der App Flow gut geplant und durchdacht wird. Also z.B. was passiert, wenn man auf ein Navigationselement klickt. Wohin führt welcher Button? Muss es einen Zurück-Knopf geben? Usw. (dies natürlich nicht nur im Mockup, sondern auch textuell o.ä.)

Es muss ein User DAO erzeugt werden, der es erlaubt den Login zu prüfen und später innerhalb der App den aktuellen User zur Verfügung stellt.

Hier ist zu überlegen, ob der DAO einen Status haben sollte (und den User speichert) oder ob dies eher eine separate Klasse (ein Service) übernimmt und der DAO wirklich nur der Datenkommunikation vorbehalten ist.

In diesem Schritt sollen dann auch die Mock-Objekte zu diesem Feature erstellt werden.

Bei diesem Feature soll die App mit der Bank verknüpft werden. Erst nach der Authentifizierung dürfen alle Features der App genutzt werden.

Die View soll so aussehen, dass man ein großes Textfeld angeboten bekommt, in dem man einen Bestätitgungscode der Bank eingeben muss. Diesen Code bekommt man bei einem Vor-Ort-Termin.

Während der Eingabe wird der Code laufend validiert. Sobald die Eingabe gültig ist, erscheint ein grüner Haken neben dem Eingabefeld und ein Button zum Abschicken.

Damit die Eingabe möglichst einfach von statten geht, sollte hier ein Zahlencode verwendet werden. Die Validierung könnte man simpel so bauen, dass die Quersumme der eingegebenen Ziffern z.B. 3 sein muss.

Über dem Eingabefeld muss ein kleiner Hinweistext sein, der diese Funktion erklärt.

Zu jeder Entität muss eine Menge an Mock-Objekten angelegt werden, um bei der Bedienung der App einige vernünftig Werte anzeigen zu können. Dieser Schritt sollte frühzeitig nach der Definition der Entitäten erfolgen, da wir hiermit im weiteren Verlauf elegant arbeiten können.

• Welche Objekte benötigen wir?
• Welche Relationen haben sie?

Hier sollen die Objekte noch nicht implementiert werden. Es muss keine formale Darstellung (mit UML) erfolgen, die grundsätzlichen Überlegungen sollten reichen.

Mockups mit Balsamiq

• Struktur / Aufbau
• Design
• Effekte (zumindest schon erste Überlegungen, lassen sich in Balsamiq ja nicht visualisieren)
• Interaktionsfluss
• .....

www.paintcodeapp.com
Hab ich bereits mit gearbeitet.
Würde sicherstellen, dass unsere App einen individuellen "Look" bekommt.

Um die Datenübertragung zu abstrahieren, benötigen wir eine Möglichkeit die einzelnen Abfragen durch Mock-Objekte zu ersetzen.

(Im Fachjargon: Wir benötigen einen Dependency-Injector).

Kurze Erklärung, für die das nicht kennen:
Es gibt für jeden Service, der Daten überträgt bzw ein unterschiedliches Verhalten in der Demo bzw. Produktivversion zeigen soll, zwei Implementierungen. Zum einen eine, die Daten überträgt und eine, die nur Mock-Objekte zurückgibt.
Um dies zu ermöglichen, müssen die Services gegen ein Interfaces (unter umständen evtl eine abstrakte Klasse) implementiert werden.

Ein weiterer Service (der Dependency Injector) hat dann die Aufgabe, uns eine Instanz eines bestimmten Service zu geben, jenachdem was für ein Environment wir gerade haben.

Implementierung einer GUI, die die passenden Werte abfragt und anschaulich darstellt.

Im Hintergrund ein Rechner, die die tatsächlichen Kosten ausrechnet.

Um uns allen die Arbeit zu erleichtern, wäre eine Übersicht über die gängigen Shortcuts und Features in Xcode gut, um uns die Arbeit zu erleichtern. Bitte eine Übersicht im WIki anlegen.

Umfasst folgende Punkte:

• Navigation auf der linken Seite („Master“)
• Detail-Pages
• Startseite

Es muss ein DAO für die Transaktionen angelegt werden. Dieses generiert die Mock-Objekte und nimmt neue Elemente entgegen, gibt die existierenden zurück usw. Hiermit arbeiten dann die einzelnen Banking Features, um an ihre Inhalte zu kommen.

http://robots.thoughtbot.com/xcode-and-git-bridging-the-gap

Der Filialfinder soll natürlich die Filialen in der Umgebung anzeigen. Hierzu muss die aktuelle Position des Gerätest abgefragt werden.

Sollte die Positionierung nicht möglich sein, soll dem Nutzer ein Eingabefeld für seine PLZ ermöglicht werden.

Erster Wurf des Dashboards. Eine kleine HTML View mit Beispiel-Pie-Charts und minimalem Design mit Bootstrap.

Ich hab da ja so eine Liste mitgeschrieben....

Es muss geplant werden, welche Entitäten mit welchen Informationen wir benötigen. Hierzu bitte ein ER-Diagramm erstellen.

Dies sollte soweit erledigt werden, dass wir schonmal einen groben Überblick über alle Entitäten haben. Wir haben die App ja noch nicht bis ins letzte Detail geplant und ausdiskutiert, aber wir haben ja viele Entitäten, die wir sicher brauchen (Konto, Account, Berater etc.)

Nachdem das Diagramm soweit steht, dies bitte zur Diskussion freigeben. Anschließend sollen die Klassen direkt implementiert werden.

Es muss einen kleinen Code-Styling-Guide geben. Hier muss für jeden ersichtlich sein, wie unser Code auszusehen hat.

Ich denke hierüber müssen wir nicht soviel diskutieren, wichtig ist, dass wir einen Guide haben und der Code ist einheitlich. Ich stelle mir darin gerade folgende Punkte vor:

• Codesprache (Englisch)
• Funktionsnamen mit camelCase
• Konstrukturen mit init-Prefix
• Parameter mit camelCase
• Einrückung mit 4 Spaces (ich glaub is xCode Default)
• Bennung aller anderen Elemente
  ....

und was es halt so gibt, damit der Code möglichst einheitlich ist.

Wie in @Krautfinne's Mockups (Siehe Commit 4448ad) beschrieben soll eine Umsatzanzeige über letzte Transaktionen her. Implementierung mit HTML/JS/CSS.

Eine Übersicht über letzten Transaktionen (letzte 90 Tage oder wie auch immer). Dies hier muss wohl in langweiliger tabellarischer Form erfolgen.

Als erstes muss entschieden werden, wie das Dashboard genau aufgebaut wird.

Corny hatte den Vorschlag, dies in HTML zu bauen und über eine WebView einzubinden. Hier sollten also nochmal die generellen Möglichkeiten für Diagramme etc. abgewägt werden und dann entschieden werden, ob wir es native oder mit HTML bauen.

Links eine Navigation, Rechts der Inhalt

Wie das dann im Detail aussieht, müssen wir noch überlegen.

Evtl. sollten wir uns auch die Möglichkeit offen halten, Unterpunkte in der Navigation zu haben. Wenn man z.B. auf Banking klickt, sollen dann Punkte für Überweisung, Vorlage, Dauerauftrag etc. erscheinen.

Laufender Projektbericht.

Es sollen Auswertungen über alle ausgehenden Transaktionen erfolgen. (Ich denke eingehend ist langweilig, das weiß man, es geht ja um privates Banking und nicht die Geschäftskonten).

Hier geht es auch nur um Darstellung, der einzelnen Kategorien und die Summe der Ausgaben. Klickt man auf eine Kategorie, erscheint eine Detailansicht der erfassten Ausgaben. Irgendwo auf dem Bildschirm soll man die Möglichkeit haben, den angezeigten Zeitraum zu wählen.

Die Daten sollen auf einem Server erfasst und ausgewertet werden. Unsere App übernimmt also nur die Darstellung, nicht jedoch die Auswertung.

(Ob wir dies Feature jetzt wirklich implementieren, müssen wir nochmal überlegen, ich nehm es erstmal auf)

Hier soll die GUI gebaut werden, die aus einer großen Google Apple Map besteht. Auf der Map sollen mit Markern die umliegenden Filialen und Geldautomaten angezeigt werden.
Bei einem Klick auf einen Marker werden Details angezeigt (Adresse, Öffnungszeiten, was so relevant ist). Zusätzlich soll ein Button zur Routenplanung angezeigt werden.

Die Filiale des Kunden (wo auch sein Berater sitzt) soll besonders hervorgehoben werden (anderer Marker). Zusätzlich würd ich vorschlagen, über der Map drei "Checkboxen" anzubieten, mit der man die Suche personalisieren kann (Filialen, Geldautomaten, aktuell geöffnet)