Kurzbeschreibung



Meetify soll zur Unterstützung von Meetings an Unternehmen dienen. Programmiert wurden Funktionen, die das gemeinsame Meeting verbessern und vereinfachen. Sie soll dem Meetingleiter mehr Kontrolle über das Geschehen geben und einen strukturierten Ablauf fördern. Die App wird auf der Plattform Android Studio programmiert und es existiert bis jetzt nur eine Android Version.

Die vollständige App mit der ganzen Dokumentation findet sich unter https://gitlab.ldv.ei.tum.de/app/meeting.
Das Repository ist jedoch im Moment noch privat, Zugang kann bei Herr Röhrl angefragt werden.

Beginn des Projektes

Entwicklungsumgebung für das Projekt ist Android Studio, eine von Google speziell für Android Apps zur Verfügung gestellte IDE. Genutzt wird die Version 3.0.1. Installiert sind die AndroidSDK Versionen 5.0 (Lollipop) bis 8.0 (Oreo) und die Android API 27. Mit dem SDK Manager können die verwendeten SDKs bearbeitet werden, oder weitere SDK's nachinstalliert werden. Dazu werden unter Umständen Administratorrechte benötigt.

Aufbau der App

1. MeetingListFragment - SetupActivity

Wird die App gestartet so gelangt man auf eine der zwei Activities, die SetupActivity. Auf ihr wird zu Beginn ein Fragment angezeigt, welches eine Liste mit aktuell laufenden und bereits beendeten Meetings angezeigt. Zu jedem Meeting steht der Name des Erstellers, das Datum und das Thema dabei.   
Über den new Meeting Button werden neue Meetings erstellt. Zuerst werden ein Thema und das voraussichtliche Datum benötigt, anschließend gelangt man nach Abschluss in die MeetingActivity.
Im MeetingListFragment ist es über den FloatingActionButton (FAB) in der rechten unteren Ecke möglich einem bereits erstellten Meeting beizutreten. Es gibt zwei Möglichkeiten dies zu tun, einerseits kann man die zugeteilte MeetingID direkt eingeben, andererseits den dazu erstellten QR-Code scannen.

2. NavigationDrawer - SetupActivity

Über einen Button in der Actionbar oder einer Wischgeste am linken Rand gelangt man in den NavigationDrawer. In dem NavigationDrawer ist das aktuell angezeigte Fragment hervorgehoben und es sind weitere Fragmente aufgelistet, zum einen Kontakte und zum anderen ein Fragment für die Settings.   
In dem ContactsFragment sind eine Liste mit den Kontakten und ein Button zum Hinzufügen weiterer Kontakte dargestellt.     
Das SettingsFragment enthält Preferences zum Ändern der Einstellungen, bisher ist es hier nur möglich den Nutzernamen zu setzen bzw. zu bearbeiten


3. Meeting ID Dialog - MeetingActivity

Die MeetingActivity wird für das eigentliche Meeting genutzt, auf ihr werden beim Start das AgendaFragment und ein Dialog mit der vom Server zugeteilten MeetingID und dem erstellten QR-Code angezeigt. Der Dialog ist weiterhin über die Actionbar aufrufbar, um die ID mit weiteren Nutzern zu teilen.

4. AgendaFragment - MeetingActivity

Im Agendafragment können über das Textfeld neue Punkte hinzugefügt werden. Wird ein Item geklickt und nach links oder rechts gewischt, wird es gelöscht. Über Drag & Drop kann die Reihenfolge der Items verändert werden.           
Über die Floating Action Buttons können die anderen Fragmente wie Live Polls und Text Chat gleichzeitig mitangeordnet werden. Durch einen erneuten Klick wird das Fragment wieder geschlossen.

5. AgendaFragment/LivePollFragment/ChatFragment - MeetingActivity

Die Fragmente können beispielsweise wie hier angeordnet werden.           
Das LivePollFragment zeigt bereits erstellte Polls an und bietet die Möglichkeit für Antworten zu stimmen. Nach eigenem Vote kann der Ersteller des Live Polls diesen auch wieder beenden. Das Ergebnis wird hier dann aktualisiert und angezeigt.     
Das ChatFragment beinhaltet einen Text Chat wie man ihn aus anderen Apps kennt. Eigene Nachrichten werden rechts angeordnet, Nachrichten andere Teilnehmer links mit dem Namen über den Nachricht.



6. CreateLivePollFragment - MeetingActivity

Das CreateLivePollFragment ist über die Actionbar (Radio Tower mit Plus Symbol) verfügbar. Hier werden eine Frage und mindestens zwei Antworten benötigt um einen LivePoll zu erstellen. Der Poll wird nach Klicken des Start Live Poll Buttons gestartet und bei allen Nutzern in dem LivePollFragment angezeigt.

7. QandAFragment - MeetingActivity

Über das Menü in der Actionbar ist das QandAFragment zugänglich. Hier können Fragen und Antworten erstellt werden. Nach einem langen Klick auf eine Frage oder Antwort öffnet sich ein Dialog, welcher Fragt ob das gewählte Element gelöscht werden soll.

8. OptionsMenu - MeetingActivity

Über das ausklappbare Menü in der Actionbar sind das QandAFragment, der ID Dialog und das SettingsFragment aufrufbar.       
Mit dem Finish Meeting Button wird das Meeting beendet und der Server schließt die Verbindung. Das Meeting wird anschließt als beendet markiert und kann in dem MeetingListFragment nur nach angesehen, nicht mehr bearbeitet, werden.

Struktur des Projektes

Die Aufteilung der App in zwei Activites erlaubt es uns alles was mit einem Meeting an sich zu tun hat in der MeetingActivity zu behandeln, und alles andere in der SetupActivity. Das Nutzen von Fragmenten für jede der Komponenten erlaubt es uns auch die Settings sowohl in der SetupActivity als auch in der MeetingActivity anzuzeigen ohne zusätzlichen Aufwand.

Das Projekt ist auf mehrere Packages verteilt, im Fragments-Package befinden sich alle und nur Fragmente, jedes Fragment stellt jeweils seine eigene GUI bereit und kann in eine Activity geladen werden. In den Views finden sich einige Custom-Views welche einfach nur Erweiterungen von bereits bestehenden Android-Views sind, um ein spezielles Design oder zusätzliche Features zu verwirklichen. Im Support finden sich allerlei nützliche Hilfsklassen welche bestimmte Funktionen für die restlichen Teile der App bereitstellen. Das Wrapper-Package enthält alle Klassen welche nur dazu dienen eine Menge von Daten einzukapseln, z.B. ein LivePoll enthält eine Frage, eine Liste mit Antworten, et cetera. Zuletzt findet sich im Network-Package alles was mit dem Server und der Verbindung zu diesem, sowie allen Anfragen und Befehlen zu tun hat.

Die vordefinierten GUI-Elemente finden sich unter res/, dort sind alle für das Projekt relevanten Ressourcen gespeichert. Der Großteil der GUI ist im Unterverzeichnis layout als XML-Dateien definiert, diese können dann später im Code als Anzeigeelement einer Activity bzw. eines Fragmentes verwendet werden. Oder direkt inflated werden um z.B. in einem RecyclerView dargestellt zu werden. Im Verzeichnis drawable befinden sich einige der in der App genutzten Grafiken, z.B. das Icon. Der values-Ordner enthält die zum einen die strings.xml in welcher alle in der App verwendeten Strings in englisch vorliegen. Sonst sind dort einige wichtige Design-Kennzahlen und Muster, z.B. Dimensionen und Theme, festgelegt.

Server

Der Server ist ein einziges C-Programm welches in einzelne Module aufgeteilt ist und mithilfe eines Makefile zusammengefügt wird. Er wurde zum größten Teil mit Notepad++ und Atom entwickelt, jedoch könnten in der Zukunft beliebige IDEs genutzt werden. Es müsste jedoch immer eine Möglichkeit bestehen die Quellcodedateien für die jeweilige Serverarchitektur (ajax-der-kleine) zu cross-kompilieren.
Die Module haben eine Quellcodedatei (.c) welche die eigentlichen Funktionen enthält, einen Header (.h) welcher Includes, Datenstrukturen und Funktionsköpfe beinhaltet. Das Makefile erstellt zu jedem Teilmodul ein kompiliertes Object-File (.o), diese sind maschinenspezifisch und sollten niemals per Hand editiert werden. Der Server besteht aus den folgenden Modulen.


-Server.c:

Das Servermodul ist das Herzstück des Servers und enthält das Big-Picture was die Logik betrifft. Er besteht im Wesentlichen aus dem Haupt-Thread welcher durchgehend mit accept() auf neue Anfragen (REQUEST) wartet und diese bearbeitet. Und dem MeetingThread welcher immer jeweils ein Meeting verwaltet und sich um alle Änderungen kümmert. Innerhalb des MeetingThread warten wir auf Änderungen (CMD) von den Clients, z.B. neues Agenda-Item. Er verarbeitet diese und leitet die Änderungen an alle Clients weiter die sich aktuell in dem Meeting befinden. Zum Überwachen von allen aktuellen Client-Verbindungen wird der Systemaufruf poll() verwendet.


- Network.c:

Das Netzwerkmodul stellt 2 wichtige Funktionalitäten bereit:

  1. Das Initialisieren eines neuen Server-Socket welches auf eingehende Verbindungsanfragen von Endgeräten wartet.
  2. Ein passendes Recv/Send Gegenstück zu den Send/Recv Methoden des ConnectorSocket

Die im C-Standard verfügbaren Funktionen arbeiten nur mit Byte-Arrays und garantieren
nicht, dass alle Bytes aus einem gegebenen Buffer verschickt werden. Um diesen beiden
Probleme einzukapseln stellt das Netzwerkmodul neue Send/Recv Funktionen bereit welche
einen MemBuf komplett verschicken, und empfangene Daten korrekt in einem gegebenen MemBuf speichern. Es wird eine Symmetrie zwischen einem Send und einem Recv-Aufruf, insofern dies möglich ist, garantiert.


- MemBuf.c:

Da häufig das Problem auftritt komplexere Daten wie Integer und Strings als Bytes zu speichern werden diese Funktionen von dem MemBuf bereitgestellt. Dieser bietet die Möglichkeit Strings beliebiger Länge und Integer beliebiger Wortbreite zu speichern, ohne über Bufferüberläufe oder Endianness nachdenken zu müssen. Der Buffer wächst bei Bedarf automatisch, alle Integer werden als Big-Endian gespeichert und alle Strings im UTF-8 Format.


-ArrayList.c:

Das Speichern und Verwalten von einer großen Menge Daten variabler Größe und Zahl wird über eine ArrayList realisiert. Diese ist im Prinzip nichts weiter als ein Array, stellt jedoch die für eine Liste typischen Funktionen (add, insert, remove, etc.) zusätzlich zu Verfügung. So kann die Effizienz eines Arrays mit der Bedienbarkeit einer Liste verbunden werden. Darüber hinaus werden oft sogenannte flexible array members genutzt um in einer C-struct zusätzlich einen String zu speichern, so z.B. bei einem AgendaItem oder einer ChatMessage, dadurch verbessert sich die Speicherlokalität des Servers.

- Meeting.c:

Alle wichtigen Datenstrukturen für ein Meeting sind hier definiert, zusätzlich gibt es noch einige Hilfsmethoden zu Umgang mit diesen.


- Security.c:
Alle sicherheitstechnischen Funktionen werden in diesem Modul implementiert. Zurzeit ist das nur die ChallengeResponse, alle weiteren Funktionen, z.B. zur Verschlüsselung sollten hier platziert werden.


- Protocol.h:

Hier sind alle wichtigen Konstanten die im Protokoll verwendet werden definiert, die meisten Änderungen in dieser Datei sollten Änderungen in Protocol.java nach sich ziehen.


- Support.h:

Einige nützliche Funktionen sind hier untergebracht, z.B die malloc-Familie mit bereits geprüften Rückgabewerten. Es können weitere allgemeine Funktionen hier eingebaut werden.


- ManagedMemoryArrayList.c:

Eine modifizierte ArrayList welche, anstatt nur Referenzen zu verwalten, ihren Inhalt kopiert und bei einem remove/delete wieder löscht. Das kann hilfreich sein um Memory-Leaks zu vermeiden. Im Moment ist diese Modul aber noch ungenutzt.


Anhang

Der Source-Code aus dem zum Beginn verlinkten Repository ist zu umfangreich um hier genauer dokumentiert zu werden. Es sind jedoch alle wichtigen Stellen in den einzelnen Source-Dateien kommentiert.

  • Keine Stichwörter