Beiträge von Marco Feltmann

Der Counter selbst tut ja nicht viel. Er sollte nur anzeigen, wie viele Buttonclicks Du schon gemacht hast.
Natürlich kannst Du die Button Clicks an ein eigenes Objekt auslagern, das sich dann um das Verwalten der Klicks kümmert und bei entsprechenden Anzahlen Callbacks aufruft.

Noch eleganter wäre es vermutlich, wenn Du für jedes zu implementierende Ding ein Objekt hättest und sich ein Observer auf den Click-Counter einrichten ließe. Also dass die Objekte immer informiert werden, wenn sich der 'Klickwert' geändert hat.
So kann jedes Objekt für sich selbst entscheiden wann es etwas freischalten möchte und wann nicht. Und es macht Dich unabhängig vom Button, weil Du den Counter ja auch anderweitig hoch und runter setzen kannst.
Weiterhin kann dann auch jedes Objekt für sich entscheiden, ob es einmal (Menüpunkt anzeigen) oder immer und immer wieder (Menüeintrag de/aktivieren) auf einen bestimmten Counterwert reagieren muss.

Unter iOS würde ich da Key-Value-Observer benutzen, aber wie das in Java heißt fällt mir gerade nicht ein.
(Ab nächsten Monat bin ich wieder tiefer im Android-Geschehen drin. ^^)

Du hast user nirgends instanziert.
Nur einmal oben deklariert aber nie einem Wert zugewiesen. Also ist user == NULL und NULL.add(mapUser); stürzt ab.

+hihihi+
Das klingt albern und sinnlos – das gefällt mir.

Also zunächst einmal brauchst Du eine genaue Vorstellung von dem, was Du da machen willst.
Dann musst Du Dir überlegen, wie das Userinterface aussehen soll, wenn Du alles freigeschaltet hast.
Dieses kannst Du dann gestalten und alle Teile ausblenden, die zu Anfang halt noch nicht sichtbar sind.

Spannend wird eigentlich nur die Umsetzung des Buttonklicks. Der Counter macht ja nicht allzu viel.
Jedes Mal, wenn der Button geklickt wird, solltest Du eine Zwischenfunktion aufrufen, die entsprechende Callbacks handhabt.

Beispiel:

int counter = -1;
void abstractOnClickMethod() {
  checkEventsForCounterState(++counter);
}


void checkEventsForCounterState(int counter) {
  switch(counter) {
    case 0:
      showCounter();
      break;
    case 10:
      showButtonSkinMenu();
      enableNextButtonSkin();
      break;
    case 20:
      enableNextButtonSkin();
      break;
    case 50:
      showShareMenu();
      enableNextShareItem();
      break;
    case 100:
      showMiniGameMenu();
      enableNextMiniGame();
      break;
    case 125:
      enableNextShareItem();
      break;
    case 1000:
      showAchievementMenu();
      enableAchievement(Achievement.Unlocked);
      break;
  }
}

Ein ähnliches Projekt ist übrigens damals™ mit Candybox entstanden, allerdings für Web.
Eventuell kannst Du Dich vom Code ein wenig inspirieren lassen.

Zeile 229 in der MainActivity finde ich irgendwie nicht.

Moin nach Württemberg!

Wir versuchen gern Dir zu helfen.

Du wirst um einen entsprechenden Cursor Adapter nicht umhin kommen.
Allerdings sollte Deine Lösung auf jeden Fall einen Zwischenschritt über ein PHP Formular beinhalten.
Ansonsten lassen sich ruckzuck die Zugangsdaten zur PostgreSQL Datenbank holen und dann Gute Nacht Marie.

Vielen Dank für die Info.
Also ist es als Zeitgeber für mich eher uninteressant.
Das permanente Auf-nen-Knopf-drücken-zum-Uhrzeit-lesen nervt mich bei meiner binären Armbanduhr schon gewaltig – und einmal im Jahr die Batterien auswechseln lassen ebenfalls.

Wenn sie die Dinger irgendwann so hinbekommen, dass das elektrische Feld des (tragenden) Körpers die Geräte induktiv mit permanenter Spannung versorgt können wir noch einmal darüber reden.

Moin aus Hamburch nach Trier.

Ich frage mich ja immer, wofür man solche Gadgets braucht.
Kamera an der Uhr?

Wie lange ist denn die Akkulaufzeit des Geräts?

Danke für Deinen Erfahrungsbericht.

Mich würde die Geschwindigkeit dieser Anwendungen interessieren.

Davon ab: es hat so ein bisschen was von den Homepagebaukästen Anno 2000. Beepworld und wie sie alle hießen.
Jede App sieht gleich aus und fühlt sich gleich an, der Mehrwert (abgesehen von 'Wir haben eine Homepage!/Wir haben eine App!') scheint nicht existent, es ist nahezu unmöglich eine Positionierung mit dem Feature zu definieren.

Für Kunden ohne Geld und Ideen allerdings vermutlich wirklich eine sehr gute Lösung.

Das ist die einzig vernünftige Handhabe.
Es handelt sich immerhin um ein Smartphone und nicht um ein Serversystem.

Sprich: das Ding soll ressourcenschonend arbeiten. In einem bestimmten Zeitintervall im Hintergrund die Netzwerkverbindung abfragen und Daten hin und her schieben ist nicht ressourcenschonend.

Viel spannender ist die Frage: wozu das Ganze?
Es gibt doch nun wirklich überhaupt keinen sinnvollen Grund, permanent eine Datenbank aktualisieren zu wollen.
(Datensammelwut ist kein sinnvoller Grund.)

Meines Wissens schon. Ist das eine gute Idee?
Manche Nutzer mögen es nicht, wenn 'inaktive‘ Anwendungen hinter ihrem Rücken irgendwohin quatschen.

Am Elegantesten wäre es vermutlich, Du würdest dich informieren lassen sobald eine Internetverbindung besteht und die Daten dann automatisch im Hintergrund versenden.

Du könntest irgendwo unten rechts auf 'Als erledigt markieren' klicken oder darauf warten, dass hier 14 Tage nichts mehr passiert.

Ganz fein wäre es sicherlich auch, wenn Du im Titel noch ein [gelöst] oder so voranstellst.

Zitat von Laisu

Dort ist es doch eigentlich genau das gleiche, doch wie ist dort die Lizenz? Ist es dort egal?

Ja.
Natürlich kannst Du in Deinen Sourcecodes darauf hinweisen, dass Du die Assets mit dem Android Studio gebaut hast. Interessiert aber niemanden.

Die Jungs von Android Asset Studio wollen einfach nur ein bisschen Werbung für ihre Seite/ihr Produkt machen, das ist alles.
Wenn man es ganz genau nimmt ist das Skalieren und Packen von Graphiken absolut nichts von schöpferischer Höhe, das ein Copyright rechtfertigen würde.

Die ganze android-support-v4.jar ist nur 350kb groß, TestFlight knapp 500kb, alle anderen jars, die ich so nutze, kratzen an der 150kb Marke.

Welche jar soll das sein?

Zitat von Mr.Malte

ich nach meinem Verständnis also im ein-Sekunden-Takt neue Locations kriegen sollte

Dein Verständnis ist da nicht ganz richtig.

Zitat

The location update interval can be controlled using the minTime parameter. The elapsed time between location updates will never be less than minTime, although it can be more depending on the Location Provider implementation and the update interval requested by other applications.
…
Prior to Jellybean, the minTime parameter was only a hint, and some location provider implementations ignored it. From Jellybean and onwards it is mandatory for Android compatible devices to observe both the minTime and minDistance parameters.

Weiterhin musst Du die Locations im Manifest erlauben und auch eine gewisse Zeit warten, bis das GPS Signal zu Deinem Gerät in akzeptabler Qualität durchdringt.

Naja, und dass GPS angeschaltet und für die App freigegeben sein muss versteht sich ja von Selbst.
Und dass der Emulator so ohne Weiteres keine Locations empfängt sicherlich auch.

Ohne mich damit auszukennen würde ich vermuten, dass Du statt einem setRequestProperty zwei addRequestProperty nutzen solltest.

Du solltest es auf jeden Fall erst mal 'intern' testen, bevor Du Dir die 49€ geben lässt und dann nix funktioniert.

Sehr spannende Frage!
Hab ich leider keine Erfahrung mit.

Müsstest Du mal ausprobieren.