Konzept

[rleh]

Zusammenfassung dieses "Issues":

• Eine MyTFG App soll entwicklelt werden.
• Die App soll nativ laufen, d.h. keine Crossplattform Frameworks, vor allem keine gewrappte WebApp (wie mit Apache Cordova)
• Eine Android App, evtl. später iOS (wer auch immer...)
• In diesem Repo
• Coding-Standard: https://google-styleguide.googlecode.com/svn/trunk/javaguide.html
• Vorher ein Konzept entwickeln

[rleh]

Zum Konzept:

@Kryptur: Was ist denn für dich ein Konzept? Objekthierarchie? Grafik?

@Harry-R: Konzept wäre für mich eine grobe Beschreibung der Activitys, was Funktionen und UI-Aufbau angeht (Für jede Activity eine Wikiseite?). Wie genau das umgesetzt wird, können wir dann ja jeweils konkret diskutieren.

Ich denke das Konzept sollte grob folgendes beinhalten:

• Struktur der Bedienoberfläche (Aufteilung in Activities)
• Design der Oberfläche
• Namenskonventionen
• Einheitlicher (abstrahierter) API-Zugriff (wie?)
• Push-Benachrichtigung (?)

[lennart-bader]

Namenskonventionen sind generell im Kodingstandard mit drin.

Pushbenachrichtigungen find ich gut.

Für den abstrahierten API Zugriff könnte ich in Java was machen. Also ein schönes subpackage dafür entwerfen

[rleh]

Ok, den Codingstandard hab ich noch nicht komplett gelesen.

Push Benachrichtigungen mittels GCM müssten dann in MyTFG noch entsprechend implementiert werden. (z.B. mit dieser Lib).

Beim Git-Branching würde ich vorschlagen, dass wir uns an dieses Modell halten.

[lennart-bader]

Sieht gut aus. Wenn die jetzt hier vom Mergen reden: Ich wäre für rebasen^^

Und generell was den Master angeht (bzw. den Development Branch): Pull-Request?

Wie siehts mit nem Build-Server aus? Der kann Checkstyle, javadoc, junit wenn es das für Android Development gibt usw. ausführen und schöne Fehler ausspucken.

Kann man doch bestimmt einen Server in der Schule oder einen von 1&1 für nehmen.

[rleh]

Wie rebasen? Die Feature-Branches in den develop-Branch rebasen, oder vor dem mergen den develop-Branch in den jeweiligen Feature-Branch rebasen?

Was meinst du mit Pull-Request? Jeder forkt dieses Repo und macht dann Pull-Requests gegen (den development Branch) dieses Repo(s)? Oder Merge-Requests aus "eigenen" Branch stellen und die mergen lassen?

Bzgl. Build-Server: Ich würde vorschlagen Travis CI zu nutzen, da kann man dann auch direkt APKs Builden lassen (immer mit dem selben Signing-Key, sonst muss man immer beim Installieren die App-Daten löschen) und z.B. auf GIthub Releases hochladen lassen :)

Alternativ könnten wir versuchen das über https://ci.jufo.mytfg.de/ laufen zu lassen, da drauf kann man auch Android Linten und Builden. Die 1und1 VServer sind glaube ich nicht leistungsstark genug zum Builden...

[rleh]

Noch eine Frage: Wollen wir das Wiki zu diesem Repo nutzen? Derzeit ist das Wiki hier deaktiviert, ich wäre dafür stattdessen Markdown Dokumente im Repo zu nutzen.

[lennart-bader]

Rebasen: development in die Features immer mal, dann ist es nicht so ein kuddelmuddel.

Entweder forks oder interne Pull Request / merge Request. Auf jeden Fall nicht einfach ohne Zustimmung. Es müssen der build Server und die anderen zustimmen bzw den Pull / merge bearbeiten, bevor er gemerged wird.

Build Server klingt gut! Ich glaube, dass die 1&1 Server das schon schaffen würden, aber eher lahm. Wobei github das auch gerne etwas verkackt und andauernd irgendwelche rebuilds veranlasst.

Bin auch für markdown.

[Harry-R]

Das Branchingmodell klingt auf jeden Fall sinnvoll. Ich finde das Wiki aber garnicht so schlecht, da hat man alles schön übersichtlich und geornet. Der Programmierer stellt dann einfach eine pull / merge request und die anderen schließen den merge dann ab. So ist sichergestellt, dass mindestens ein Person nochmal drüberguckt.

[Harry-R]

Was für eine .gitignore nehmen wir? @rleh ich fand die aus iBis eigentlich nicht schlecht.

[rleh]

Ich finde Markdown Dateien im Repo schöner, weil man die auch direkt auf dem PC (in Android Studio) sieht und bearbeiten kann. In den Markdown Dateien kann hat man die selben Gestaltungsmöglichkeiten (Links, Bilder, Tabellen, etc.) wie im Wiki.

Also diese gitignore-Datei: https://jufo.mytfg.de/ibis/app/blob/master/.gitignore ? Sind soweit ich weiß die Standard- und die JetBrains- gitignore-Dateien kombiniert.

[lennart-bader]

Sehe ich auch so. Kann jemand demnächst mal die Sachen hier reinpushen? Dann könnte man da schonmal experimentieren.

[rleh]

Welche Sachen rein pushen?

[lennart-bader]

gitignore und vlt eine Ordnerstruktur. Wenn ihr schon ne App entwickelt habt, habt ihr da vlt was schönes.

[rleh]

Mache ich.

Packagename ist de.mytfg.app.android, ok? Sonst bitte sehr schnell Einspruch einlegen ;)

[lennart-bader]

Sehr gut :+1:

[rleh]

Done :smiley:

[lennart-bader]

Ich würde das hier vlt nochmal fortführen. Es fehlen noch: Farbkonzept

• Farben sind als Ressourcen angelegt
• Akzent: Orange
• Hintergrund: Hellblau, Elemente mittelblau, Header dunkelblau
• Diskussion?

Bedienkonzept

• Fragmente
• Landscape View erlauben?

Klassen- und Paketstruktur

• Für jedes "Modul" / Fragment wird eine entsprechende XYFragment.java im Package slidemenu erstellt, vererbt von AbstractFragment!
• Außerdem im slidemenu.items Package ein entsprechendes Item.
• Item zur Navigation (sichtbar / unsichtbar) hinzufügen

Die eigentliche Funktionalität (z.B. API Zugriff) sollte größtenteils ausgelagert werden. Hierzu für jedes Fragment ein Package in modules erstellen, dort dann eine / mehrere Klasse(n) implementieren.

Hier mal so zusammengefasst, was mir spontan eingefallen ist.

[rleh]

Farben finde ich gut bisher, aber wir haben das ja auch quasi mündlich diskutiert.

Das grobe Bedienkonzept ist ja jetzt auch quasi festgelegt. Bin ich auch mit einverstanden. Landscape orientation finde ich persönlich nicht wichtig, aber sauberer wäre es schon wenn das auch klappt. Gerade auf Tabletts ist das IMHO interessant. Bei Langeweile kann bestimmt noch einige Optimierungen (zwei spalten Ansicht, ...) für Landscape vornehmen.

Die klassenstrukur hört sich für mich auch sinnvoll an :wink: