Nein, immer noch kein Code.
Erst testen, dann bauen. 
Außerdem ist es schon spät...
Ihr könnt euch ja schon mal mit den Testing Trainings von Android vertraut machen.
Da wir zunächst nur testen werden, ob der Button sich bei einem Klick ändert, beginnen wir mit UI Tests.
https://developer.android.com/…ing/ui-testing/index.html
Bevor wir nun anfangen irgendwelchen Code zu tippen, UIs zu designen, uns in Ideen zu verrennen und ein schwaches Produkt abzuliefern machen wir uns erst einmal Gedanken darüber, was die App können soll.
Und zwar einen Schritt nach dem Anderen.
In erster Linie soll die App unsere Kommen- und Gehen Zeiten aufzeichnen.
Nichts leichter als das, da fällt mir sogar schon ein Layout für ein - doch was ist, wenn das Layout zu kompliziert wird?
Wenn die App dadurch schwer zu nutzen ist? Niemand möchte sich in seiner Produktivität gebremst fühlen.
Wie also bekommen wir heraus, ob unser Layout funktioniert ohne es zu programmieren und auszuprobieren (und dann schlussendlich bei der weniger guten Lösung zu bleiben, weil wir da schon drei Stunden dran gefeilt haben)?
Die "Bösen" aus Cupertino predigen seit Jahren "Fake It 'Til You Make It". Ihre Präsentationsapp kann auf iPhone Größe eingestellt werden und speziell zugeschnittene Präsentationen auf dem Gerät so wiedergeben, als wäre man in der App - die es gar nicht gibt.
Ich bediene mich Googles Präsentationsdienst, weil sich die Sachen hier prima verlinken lassen und so wirklich schützenswert sind die Ideen eh nicht.
Also frisch ans Werk!
Entwurf #1 ist fertig.
(Auf dem iPhone würde jetzt nach jedem Tab der nächste Screen kommen, tabbt man also ungefähr auf die Eingabeelemente bekommt man ein Gefühl dafür, wie das Ganze laufen könnte.)
Hier sehen wir gleich, das Konzept taugt nicht. Tab, eingeben, Tab, eingeben, dynamisch wachsende Liste - alles sehr unübersichtlich.
Eigentlich brauchen wir die Details auch gar nicht auf dem ersten Screen, Auswertungen und Bearbeiten soll über eigene Screens geschehen.
Entwurf #2 ist fertig.
Irgendwie noch nicht das Gelbe vom Ei. Wir zeigen zwar die notwendigen Informationen, aber an Hand der Screens ist ersichtlich, das niemand weiß in welchem Modus er gerade ist.
Schöner wäre es, der Button wüsste was wir vorhaben.
Entwurf #3 gefällt mir da am Besten.
An Hand des Buttons erkennt man, ob man gerade angekommen (Dreieck) oder gegangen (Kreis) ist.
Ich kann mich nur nicht entscheiden, ob relative Dauer (Noch 6 Stunden...) oder absolute Uhrzeit (Mindestens bis 14:00 Uhr...) sinnvoller ist.
Aber ich gehe davon aus, dass diese Vorliebe vom Nutzer abhängt. Also wird das in die Settings übernommen.
(Genauso wie Wochenarbeitszeit, Arbeitstage die Woche, zulässige prozentuale Anzahl Überstunden... Doch dazu später mehr.)
Da wir nun ungefähr wissen, wie das UI funktionieren soll, wäre es doch prima, wir fingen gleich damit an.
tl;dr:
Repository URL: https://github.com/marcofeltmann/TimeTracker/
Fragen, Wünsche, Anregungen: Fragen zum Projekt 'Eine App entsteht'
Hallo,
angestachelt von der Frage nach einem Zeiterfassungssystem möchte ich das nicht nur so umsetzen, wie ich es für richtig halte, sondern auch gleich noch aufzeigen, wie ich an so eine Sache herangehe.
Dazu vorab ein paar Informationen für Interessierte.
Soweit zu den Vorworten, legen wir gleich los.
Und zwar mit einer Designentscheidung.
Ich mach mir mal Gedanken zum Thema.
Irgendwie reizt mich das jetzt doch.
Die Dependencies sind kein Problem. Die werden halt nur mitgebaut falls nötig.
Interessanter ist die Frage, was Du importierst.
Eine weitere App zur Pomodoro Technik ist hier aber wohl nicht gemeint, so wie ich Andy61 verstanden habe.
Das ist mir klar. Ich wollte nur veranschaulichen, was ich unter 'einfach zu bedienen' und 'optisch ansprechend' verstehe, vor Allem im Hinblick auf die Auswertungen.
So'n bisschen kribbelt es mir ja jetzt schon in den Fingern, aber da das ach so tolle cross-platform Android SDK nicht auf 64Bit only Linux läuft wird das wohl nix. 
Sieht aber unspannend und auch viel zu kompliziert aus. Je mehr man eintippen/auswählen muss, desto mehr Fehler können passieren. Bei einer Arbeitszeiterfassung soll genau das aber vermieden werden.
Vor Allem kann es eigentlich nicht Sinn der Sache sein, dass man 5 Minuten Arbeitszeit für die Erfassung aufwendet. 
Du solltest Dir auf jeden Fall mindestens ein Alleinstellungsmerkmal überlegen.
Die meisten Apps sind kompliziert in der Handhabung.
Cool wäre es beispielsweise, den NFC Reader zu nutzen um ein Tag zu lesen und dann über bestimmte Annahmen zu erkennen, ob man kommt, geht, Pause macht...
Eventuell noch konfigurierbare Tags zum Beispiel am Auto, um Reisezeiten mit zu erfassen.
Vielleicht als In App Purchase...
Die Möglichkeit nachträglich die Art der Unterbrechung zu notieren (Raucherpause, Geschäftsessen, Arztbesuch, Firmenbesorgung) könnte auch spannend sein.
Andere wollen vielleicht auch noch eine Schnittstelle zu deren existierende firmenweite Zeiterfassung. Da kannst Du auch eine Menge Arbeit reinstecken um Nutzer zu finden.
Aber den meisten Eindruck schindest Du natürlich neben der einfachen Benutzung mit hammergeilen Auswertungen, Diagrammen und Übersichten.
Meine Lieblingsapp aus dem Bereich der Pomodoro Technik ist da Clockwork Tomato
Supersimpel, ohne Überladung mit Projektkrams, hoch konfigurierbar, sehr übersichtlich und großartige Auswertungen.
Du arbeitest 73.000 Einträge zeilenweise ab, gibst 73.000 Logausgaben aus, erstellst 73.000 Arrays über eine String-Methode und erzeugst 73.000 Datenbankeinträge.
Ist Dir schon einmal der Gedanke gekommen, dass das ganz eventuell ein kleines bisschen Zeit braucht?
Deutlich weniger als von Hand, aber trotzdem.
Das LG G3 ist auch etwas betagt und daher etwas langsam.
Ich mein ja nur. 73.000x nix machen mit der Low-Level-Sprache C auf einem 1.6GHz Quadcore it 8GB RAM braucht ungefähr 0.02 Sekunden.
#include <stdio.h>
#include <time.h>
int main ( int argc, char ** args ) {
clock_t start = clock();
static int dummy = 0;
for( int i=0; i<=73000;i++) {
// Schleife leer lassen bringt nix, sonst wird die knallhart wegoptimiert.
dummy = i * 2;
printf(".");
}
clock_t end = clock();
printf("\n\nDauer: %f", ( difftime(end, start) / CLOCKS_PER_SEC ) );
return 0;
}ZitatDauer: 0.024070
(Bei leerer Schleife ohne statische Variable 0.000355...)
Bau sowas mal in Java nach und teste das mal direkt auf Deinem Ubuntu und dann auf Deinem LG G3.
Optimierungspunkt 1)
Nimm irgendwie die Datenbankzugriffe raus. Vermeide Operationen auf dem Dateisystem generell.
Du könntest beispielsweise Dateneinträge sammeln und alle 100 Durchläufe im Pulk senden. (Zu langes Sammeln frisst Dir den Speicher weg.)
Optimierubgspunkt 2)
Importier den Kram mal in Excel, LibreOffice Calc oder eine ähnliche Anwendung. Da wartest Du auch ein bisschen.
Leb also einfach damit, dass das dauert und pack den Vorgang in den Hintergrund. Du kannst ja nen unbestimmten Fortschrittsbalken anzeigen und am Ende eine Notification senden.
Moin aus Bochum! (Unfreiwilligerweise)
Moin in die Hauptstadt!
Meiner Einschätzung nach solltest Du das über einen ContentProvider und entsprechendem Loader lösen.
Damit hast Du persönlich freie Hand, ob Du direkt über die Datenbank oder über Platzhalterobjekte arbeiten möchtest - und zwar ohne dass Du Dich permanent darum kümmern musst, welchen Zugriff Du gerade hast.
Alles abstrahiert und gekapselt im ContentProvider.
Gab es nicht die Möglichkeit, einen Identifier an den Handler zu packen, so dass dieser nur dann gestartet wird, wenn kein Thread mit diesem Identifier läuft?
Falls nicht statt Runnable einen Thread nehmen und einen Konstruktor mit aktionsspezifischem Namen aufrufen.
Dann kannst Du in der onCreate prüfen, ob es bereits einen Thread mit diesem Namen gibt.
Falls ja kannst Du auch überprüfen, ob der bereits läuft und ihn gegebenenfalls neu anstoßen.
Ich verstehe übrigens nicht, warum ein Thread im Hintergrund permanent laufen soll.
Was machst Du denn da die ganze Zeit?
Ich denke, es ist zunächst sinnvoll zu filtern und dann zu sortieren.
Man muss sich nur immer vor Augen halten, dass das alles nicht unbedingt ultra genau ist.
Üblicherweise erledigt man solche Dinge mit Datenbanken und nicht mit Listen.
Die sind auf das Durchsuchen spezialisiert.
'Sortiert ablegen' ist auch eine sehr lustige Idee. Wonach möchtest Du denn bitte Geokoordinaten sortieren?
(Ich gehe mal davon aus, dass es Geokoordinaten sind. Kartesische Koordinaten oder Gauß-Krüger-Koordinaten stellen Dich aber vor dasselbe Problem.)
Alphabetisch?
Nach Latitude aufsteigend und Longitude absteigend?
Entfernung zum Koordinatenursprung (und in dem Fall: erst negative oder erst positive oder wie oder was)?
Entfernung zur obersten linken Ecke (und warum in dem Fall nicht zur untersten linken Ecke)?
Ach ja, die Welt hat ja mindestens drei Dimensionen - wie bauen wir denn in die Sortierung noch die Altitude mit ein? Aufsteigend ab Meeresspiegel? Was passiert dann mit Unterwasserpositionen von GeoCaches?
Puh...
Entfernung von einem bestimmten Punkt - wie berechnest Du die denn?
1° in Äquatornähe sind dann ungefähr 111km während 1° nahe den Polkappen ungefähr 9km sind.
(Direkt an den Polkappen ist 1° übrigens so ziemlich genau 0mm)
Und selbst dann hast Du die Luftlinie ohne Berücksichtigung der Höhenangaben an sich und dem Höhenprofil der Erdabschnitte - von der Bebauung von Straßen reden wir gar nicht erst.
Geoinformatik ist ein ausgesprochen interessanter aber auch hochgradig rechenintensiver Bereich.
Am Einfachsten ist es wirklich, wenn Du die Liste in eine SQLite Datenbank packst und Abfragen mit einer Abweichung von sagen wir 0.005 für die Suche wählst - natürlich in alle vier Richtungen.
(Die Geokoordinaten beginnen bei -90 Latitude, -180 Longitude und gehen bis 90 Latitude, 180 Longitude)
Mir persönlich fehlt bei den Kontra-Argumenten bezüglich Abonements ein ganz einscheidender Punkt, welcher mir bereits bei Spotify und Netflix sauer aufgestoßen ist: Wann immer der Anbieter (oder irgend eine intransparent dahinter stehende Instanz) es für sinnvoll hält, fliegen einzelne Stücke aus dem Abonnementangebot.
(Spotify: ein gesamtes Album von ASP; Netflix: die kompletten LOST Staffeln)
Sei es weil der Künstler seine Einwilligung der Nutzung der Werke zurückzieht, sei es weil der Anbieter aus Kapazitätsgründen 'unbeachtetes' wegwirft, sei es weil irgend welche App Store Richtlinien ein Programm auf Grund irgend eines Vertragsbruchs rausschmeißen.
Ich nutze Abonements zum Kennen lernen. Wenn ich es für längere Zeit behalten will, dann kauf ich es.
Und bevor jetzt Apple irgendwelche dusseligen Game-/App-Abos anbietet sollten sie einfach mal Demos zulassen, die alten Saftnasen.
(Wobei man ja im Prinzip eine komplette App mit zwei Leveln hochladen und das Spiel mit restlichen Level als InApp Purchase zur Vollversion machen kann...)
Als erstes würde ich ja mit dem Date Objekt arbeiten.
Irgendwie ist synchrone Kommunikation nicht so meins und auf Facebook bin ich auch nicht.
Moin!
Tja, also so ein Vorhaben geht eigentlich nur mit Android.
Du solltest Dir dazu ein eigenes Android kompilieren und dann die Änderungen einbinden.
(Also Logo, was ja jeder Hersteller macht. Und Start App, was LG für die Darstellung seines vereinfachten Homescreens nutzt.)
Auf jeden Fall verlassen diese Anforderungen bereits den normalen Entwicklerbereich und schwappt zum Embedded Development rüber.
Für einen Prototypen sollte es reichen eine App als Launcher einzurichten.
Wobei, vielleicht reicht das auch insgesamt.
4) Das ist ein eigenes ROM und bringt Dir nix.
5) Ja. Nur auf Android bekommst Du das hin.
Wenn die Texturen nicht allzu kompliziert sind ist eine 9-Patch nehmen.
Das performt einfach besser.