Beiträge von Marco Feltmann

    Das wird aber nix mit einem Timer allein.
    Du könntest den eigentlichen Timer mit in den Service werfen und von der App aus alle x Sekunden eine Methode des Services fragen, wie lange er denn schon läuft.


    Alternativ legst Du nur den Zeitstempel des Starts über eine Methode in den Service und startest bei Aufruf der App den Timer. Dann addierst Du die vergangene Zeit des Zeitstempels bis zum Start des Timers zu jeder Sekunde hinzu.


    Oder Du packst Start- und Endzeitstempel der einzelnen Läufe in eine Datenbank und rödelst mit einem ContentProvider drüber.

    Und das Ganze lässt sich dann noch mit Widgets aufhübschen…
    Zitat des Tages auf dem Home Screen. Wenn jemand aus den Kontakten Geburtstag hat ein Geburtstagszitat präsentieren mit der Option es direkt demjenigen als Geburtstags-SMS oder Mail zu schicken. Für Besprechungen zu einem Thema drei bis fünf passende Zitate anzeigen…


    Oder, um beim Rad zu bleiben:
    Statt Vollstein Vollholz, dann Speichen rein, Metallbeschlag um den Radkranz drum, Gummipelle drüber, statt Holz mit Speichen leichteres Metall mit Speichen, Gummipelle mit einem Schlauch ausfüllen, bessere Gummipelle ohne Schlauch drüber, Kugellager in die Nabe… man wird nie fertig, selbst wenn man das Rad nicht neu erfinden sondern lediglich verbessern möchte. ;)

    Meine Meinung:
    Ja, kann. Sollte aber nicht. :P


    Umsetzung:
    Gut, um einen Webservice mit PHP/MySQL wirst Du nicht umhin kommen.


    Doch von PhoneGap würde ich wirklich die Finger lassen, wenn Du irgendwann mal aufhören solltest Räder nachzubauen und statt dessen einen Hover-Antrieb entwickeln willst. Der durchschnittliche Smartphone-Benutzer wartet nur sehr sehr ungern. Apps, die von PhoneGap in ein *.apk gepresst wurden, sind sehr sehr langsam. Ich werfe die Dinger immer sofort von meinem Gerät, selbst wenn es die einzige App ihrer Art ist wie beispielsweise MobileRunner
    Vergleich einmal vorher, ob Dir diese App (die nun echt nicht viel macht) schnell genug ist. Ich bezweifle es.


    Idee:
    Es ist immer prima ein paar Räder zu kopieren bevor man sie verbessert. Was mir daran missfällt:
    • permanente Internetverbindung, wenn auch nur einmal täglich -> wirkt ein bisschen nach Spionage-App
    • Internet-Pflicht für keinerlei Mehrwert -> eine Zitatedatenbank kann man auch lokal vorhalten
    • Login-Prozess einerseits für den User zu aufwendig, andererseits viel zu unsicher


    Verbersserungsvorschläge/Angepasste Ideen
    • App funktioniert komplett offline -> immer
    • Hinzufügen von Daten -> Autor eines Zitats sollte da keine Pflicht sondern Kür sein.
    • Share-Funktion (vor Allem G+, Twitter, Facebook! Wo wirft man sonst mit Zitaten um sich?)


    Zusatzfunktionen wenn gewünscht
    • Aktualisierung der Daten auf Wunsch.
    Der User soll selbst einstellen können ob und wann er die Aktualisierung wünscht oder selbst auf 'aktualisieren' klicken. Dazu ist absolut kein LogIn erforderlich.


    • Verknüpfung mit einem Konto zum Login, beispielsweise via OAuth.
    Du kannst das LogIn dann via Twitter, Facebook, G+, OpenID oder sonstwas verknüpfen. Einerseits hast Du dann für das Sharing schon ein paar Informationen, andererseits hältst Du keinerlei Daten Deiner Nutzer vor. Sie loggen sich bei etwas ein, dass sie eh schon kennen und müssen sich nicht noch mehr Userdatenwust merken. Um die Sicherheit der Daten musst Du Dich dann auch nicht mehr kümmern.


    • Upload nur für verknüpfte Konten.
    Hier solltest Du auf jeden Fall sämtliche Uploads überprüfen. Ein Zitat ohne Autor sollte beispielsweise überhaupt nicht hochgeladen werden können, da auch Zitate durchaus einem Lizenzrecht unterliegen können. Vor Upload sollte eine Auswahl der hochzuladenden Zitate getroffen werden können und Zitate ohne Autor als inaktiv dargestellt werden, immer mit der Möglichkeit des Users, einen Autoren nachzutragen.


    Fazit
    Ein einfaches 'Hello World!' kann mit Verpackung, Dokumentation, Marketing und Tests drei Monate in Anspruch nehmen. Dein Projekt kannst Du innerhalb eines halben Tages oder innerhalb eines halben Jahres realisieren, je nachdem, wie viel Mühe Du Dir mit den Details machst.


    Und ehe Du Dich versiehst ist aus deiner kleinen Zitate-Sammlungs-App ein wissenschaftlicher Literaturnachweis geworden. ^^

    Mit _id meine ich den eindeutig identifizierbaren Primärschlüssel Deiner Datensätze.


    Beispiel: eine Handball-App in der Du mindestens vier Tabellen hättest.

    Code
    Verein  [_id | name]
    Spiel   [_id | heimmannschaft_id | gastmannschaft_id | spiel_datum]
    Spieler [_id | vorname | nachname | verein_id ]
    Torwurf [_id | trefferzone | hat_getroffen | spielminute | spiel_id | spieler_id]


    Gehen wir weiter davon aus, Du zeigst gerade alle Spieler einer Mannschaft in einer Liste an. (Natürlich nur Vorname und Nachname)
    Gehen wir außerdem davon aus, Du möchtest mit einem Longpress auf eine Zeile der Liste die Torwurfübersicht dieses Spielers haben.


    Dann packst Du die _id des Spielers an dieser Position in ein Extra des Intents und in der neuen Activity liest Du dann die Daten aus der Torwurftabelle:

    Java
    "SELECT trefferzone, hat_getroffen, spielminute FROM Torwurf where spieler_id="+getExtra("SpielerID");


    (Natürlich müsstest Du Maßnahmen treffen, was passieren soll, wenn keine SpielerID in den Extras übergeben wurde.)


    Das ganze lässt sich auch beliebig erweitern, beispielsweise wenn Du alle Tore aus einem speziellen Spiel nachschaust.

    Java
    "SELECT trefferzone, hat_getroffen, spielminute FROM Torwurf where spiel_id="+getExtra("AktuellesSpielID");


    Oder wenn Du wissen möchtest, wie ein bestimmter Spieler in einem bestimmten Spiel abgeschnitten hat.

    Java
    "SELECT trefferzone, hat_getroffen, spielminute FROM Torwurf where spieler_id="+getExtra("SpielerID")+" AND spiel_id="+getExtra("AktuellesSpielID");

    Du solltest keine Objekte übergeben*. Im Falle von Datenbankzugriffen wäre es sinnvoller, Du übergibst die _id des Eintrags.


    Das packst Du dann in ein Extra und übergibst das an das Intent, das Du aufrufen möchtest.


    *) Falls es doch irgendwie sein muss: Du kannst jedes Objekt als Extra in das Intent stopfen, dass Parcable unterstützt. Ist aber meiner Meinung nach viel zu viel Overhead und Ressourcenverlust, da Dein Objekt gepackt, transferiert und entpackt wird - da kannst Du lieber eine neue Instanz aus der Datenbank ziehen.

    Das Video sieht echt klasse aus. :)


    Allerdings würde ich mir eine etwas... touchlastigere Steuerung überlegen.
    Diese scheinbar sehr kleinen Buttons drücken zu müssen finde ich ziemlich schwerig.


    Wenn ihr nur viel Elemente für die Steuerung nutzt, könnt ihr da nicht den Touchscreen vierteln und dort drin die Steuerungstasten implementieren?


    Auch vorstellbar wäre eine Gestensteuerung oder dass man mit dem Finger irgend ein sich bewegendes Dinges im Gleichgewicht halten muss - so wie die Skalen beim Grinden in THPS, die man mit den Schultertasten mittig halten musste.

    Es reicht, wenn Du für den ViewPager einen eigenen Adapter baust, der die Methode implementiert.


    Allerdings sehe ich nicht, wo das Ganze dann landen sollte.
    Schließlich hast Du ja keinerlei Texte oberhalb Deiner Fragmente.


    In dem Fall könntest Du onPageSelected(int) Deiner Activity überschreiben.
    (Davon ausgehend, dass Du 4.0+ only entwickelst.)

    Java
    @Override
            public void onPageSelected(int position) {
                mActionBar.setTitle(pagesAdapter.getTitle(position));
            }


    Zusammengeklaubt von:
    http://developer.android.com/r…rt/v4/view/ViewPager.html
    http://developer.android.com/r…ndroid/app/ActionBar.html

    Laut Dokumentation:

    Zitat

    The system calls this method as the first indication that the user is leaving the fragment (though it does not always mean the fragment is being destroyed).


    Das liest sich für mich halt so, dass es aufgerufen wird, sobald das Ding seinen Fokus verliert.