Beiträge von Marco Feltmann

Moin,

ist es irgendwie möglich, das App Icon einfach auszutauschen?
Ich plane ein Projekt, bei dem so etwas wie ein Fortschritt getrackt wird. Diesen Fortschritt würde ich gern sinnbildlich im App Icon wiedergeben.
Also beispielsweise ein Füllbalken, der je nach erreichtem Fortschritt höher gefüllt wird. Oder eine Art LED, die je nach aktuellem Fortschritt rot, orange, gelb oder grün anzeigt.

Gibts da was von Ratiopharm?
(Spontan würde ich vermuten das nicht, da ich im APK selbst rumbauen müsste und das weder kann noch darf. Aber eventuell weiß ja jemand was.)

SQLite 3 kann RANDOM().

create table test(_id INTEGER PRIMARY KEY ASC, value INTEGER);
INSERT INTO test VALUES(1,0);
INSERT INTO test VALUES(2,0);
INSERT INTO test VALUES(3,0);
INSERT INTO test VALUES(4,0);
INSERT INTO test VALUES(5,1);
INSERT INTO test VALUES(6,1);
INSERT INTO test VALUES(7,1);
INSERT INTO test VALUES(8,0);
INSERT INTO test VALUES(9,1);
INSERT INTO test VALUES(10,0);
INSERT INTO test VALUES(11,1);
INSERT INTO test VALUES(12,0);
INSERT INTO test VALUES(13,0);
INSERT INTO test VALUES(14,0);


sqlite> select * from test where value=0 ORDER BY RANDOM() LIMIT 1;
_id|value
12|0


sqlite> select * from test where value=0 ORDER BY RANDOM() LIMIT 1;
_id|value
10|0


sqlite> select * from test where value=0 ORDER BY RANDOM() LIMIT 1;
_id|value
4|0


sqlite> select * from test where value=0 ORDER BY RANDOM() LIMIT 1;
_id|value
13|0


sqlite> select * from test where value=0 ORDER BY RANDOM() LIMIT 1;
_id|value
12|0


sqlite> select * from test where value=0 ORDER BY RANDOM() LIMIT 1;
_id|value
13|0

Es wäre also hilfreich zu sehen, welche Fehlermeldung Du genau bekommst.
An der Query selbst liegt es nicht. Vielleicht produziert die Verknüpfung aus Query und Category ja irgend einen Müll.
Lass Dir am Besten die gesamte, fertige Query anzeigen.

Niemand 'verunstaltet' Deine Klasse.

Die Kategorie folgt dem Open Closed Principle: Offen für Erweiterungen, geschlossen für Änderungen.

Es kann Dir doch völlig egal sein, ob jemand deinem Additionsobjekt eine Methode zur Addition von echten Brüchen beifügt und nur für sich benutzt oder in seinem Code verteilt.
Es kann Dir hingegen nicht völlig egal sein, ob jemand in deinem Additionsobjekt den Konstruktor auf echte Brüche umbiegt.

Der Decorator tut in Etwa das, was ich haben möchte, wenngleich auf etwas anderem Weg. Inwieweit das jetzt deiner Library schaden kann verstehe ich nicht.

InputFilter in Verbindung mit Patterns.IP_ADDRESS und Patterns.DOMAIN_NAME tut genau das, was ich will.
Vorausgesetzt, ich stelle ihn so ein wie ich will.

Geilo. =)

+narf+
TextWatcher tut nur die Hälfte dessen, was es tun soll.

Nämlich die Eingaben weiterleiten um damit Dinge tun zu können.
Es liegt aber nicht in meiner Macht dem Textfeld zu sagen 'Hey, den letzten getippen Buchstaben nimmst Du gefälligst nicht an!".
Genau das bräuchte ich aber für den 'händisch parsen' Ansatz.

Muss ich jetzt echt eine Referenz auf das EditText mitschleppen und die Eingaben manuell zurücksetzen?
+seufz+

Und nun kommen wir zum Oberhammer: Dekorierte Dekorierer.

Wir erinnern uns, folgender Code gab folgende Ausgabe:

public class TestActivity extends Activity {
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);


        Location testLocation = new Location("manual");
        testLocation.setLatitude(53.550000);
        testLocation.setLongitude(09.983333);


        LocationDecorator decorator = new LocationDecorator(testLocation);
        Log.e("INFO", decorator.locationString());
        HamburgDecorator inHamburg = new HamburgDecorator(testLocation);
        Log.e("INFO", inHamburg.locationString());


        testLocation.setLatitude(110);
        testLocation.setLongitude(-911);


        LocationDecorator newDecorator = new LocationDecorator(testLocation);
        Log.e("INFO", newDecorator.locationString());
        HamburgDecorator outOfHamburg = new HamburgDecorator(testLocation);
        Log.e("INFO", outOfHamburg.locationString());
    }
}

Zitat

11-29 13:19:32.928 1254-1254/de.tagnewmedia.locationconverter.locationconverter E/INFO﹕ N53° 32' 59"; W9° 58' 59"
11-29 13:19:32.928 1254-1254/de.tagnewmedia.locationconverter.locationconverter E/INFO﹕ Looks like you are located in Hamburg.
11-29 13:19:32.928 1254-1254/de.tagnewmedia.locationconverter.locationconverter E/INFO﹕ Degree 110.0 is invalid!; Degree -911.0 is invalid!
11-29 13:19:32.928 1254-1254/de.tagnewmedia.locationconverter.locationconverter E/INFO﹕ Seems you are outside Hamburg.

Nun ändern wir aber einmal den Code:

public class TestActivity extends Activity {
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);


        Location testLocation = new Location("manual");
        testLocation.setLatitude(53.550000);
        testLocation.setLongitude(09.983333);


        LocationDecorator decorator = new LocationDecorator(testLocation);
        HamburgDecorator inHamburg = new HamburgDecorator(decorator);
        Log.e("INFO", inHamburg.locationString());


        testLocation.setLatitude(110);
        testLocation.setLongitude(-911);


        LocationDecorator newDecorator = new LocationDecorator(testLocation);
        HamburgDecorator outOfHamburg = new HamburgDecorator(newDecorator);
        Log.e("INFO", outOfHamburg.locationString());
    }
}

Wir übergeben jetzt keine Location mehr, sondern einen Decorator.
Und die Ausgabe?

Zitat

11-29 13:25:17.588 E/INFO﹕ N53° 32' 59"; W9° 58' 59"
Looks like you are located in Hamburg.
11-29 13:25:17.588 1E/INFO﹕ Degree 110.0 is invalid!; Degree -911.0 is invalid!
Seems you are outside Hamburg.

Was bringt uns das jetzt?
Nun, man könnte einen weiteren Decorator erstellen:

// HamburgDecorator.java 
import android.location.Location;
import java.security.InvalidParameterException;


public class HamburgDecorator implements LocationStringDecorator {
    private Location decoratedLocation;
    private LocationStringDecorator decoratedDecorator;


    public HamburgDecorator(Location locationToDecorate) throws InvalidParameterException {
        if(locationToDecorate == null) {
            throw new InvalidParameterException("The given location must not be null in order to get a working decorator!");
        }
        decoratedLocation = locationToDecorate;
    }


    public HamburgDecorator(LocationStringDecorator decoratorToDecorate) {
        decoratedDecorator = decoratorToDecorate;
    }


    @Override
    public double getLatitude() {
        if(decoratedDecorator != null) {
            return decoratedDecorator.getLatitude();
        }
        return decoratedLocation.getLatitude();
    }


    public double getLongitude() {
        if(decoratedDecorator != null) {
            return decoratedDecorator.getLongitude();
        }
        return decoratedLocation.getLongitude();
    }


    @Override
    public String locationString() {
        String result = "";
        if(decoratedDecorator != null) {
            result += decoratedDecorator.locationString()+"\n";
        }
        if(getLatitude() <= 53.6 && getLatitude() >= 53.5 && getLongitude() <= 10.0 && getLatitude() >= 09.8) {
            result += "Looks like you are located in Hamburg.";
        }
        else {
            result += "Seems you are outside Hamburg.";
        }
        return result;
    }
}

Wenn wir das jetzt noch benutzen, dann kommt das Folgende bei rum:

Zitat

11-29 13:10:56.718 E/INFO﹕ N53° 32' 59"; W9° 58' 59"
11-29 13:10:56.718 E/INFO﹕ Looks like you are located in Hamburg.
11-29 13:10:56.718 E/INFO﹕ Degree 110.0 is invalid!; Degree -911.0 is invalid!
11-29 13:10:56.718 E/INFO﹕ Seems you are outside Hamburg.

Moin,

wie in einem anderen Thread (Konzept gesucht: Elternklasse erweitern) angedeutet habe ich ein bisschen mit dem Decorator Pattern gespielt.

Der Ansatz war es, ein bestimmtes Objekt zu erweitern ohne es subclassen zu müssen.
Im Endeffekt stelle ich fest, dass es vermutlich sinnvoller gewesen wäre, den Decorator gegen eine abstrakte Klasse oder ein Interface zu erstellen. Schließlich werde ich nur eine android.location.Location bekommen. Nichts desto trotz hoffe ich, dass der Ansatz klar wird.

Er besteht aus zwei Komponenten: dem Interface des Decorators und einer konkreten Implementierung.

// LocationStringDecorator.java
public interface LocationStringDecorator {
    public String locationString();


    public double getLatitude();
    public double getLongitude();
}

// LocationDecorator.java
import android.location.Location;
import java.security.InvalidParameterException;


public class LocationDecorator implements LocationStringDecorator {


    private Location decoratedLocation;


    public LocationDecorator(Location locationToDecorate) throws InvalidParameterException {
        if(locationToDecorate == null) {
            throw new InvalidParameterException("The given location must not be null in order to get a working decorator!");
        }
        decoratedLocation = locationToDecorate;
    }


    @Override
    public double getLatitude() {
        return decoratedLocation.getLatitude();
    }


    @Override
    public double getLongitude() {
        return decoratedLocation.getLongitude();
    }


    @Override
    public String locationString() {
        String resultString = stringForDegreeAsLatitude(getLatitude(), true);
        resultString += "; ";
        resultString += stringForDegreeAsLatitude(getLongitude(), false);


        return resultString;
    }


    private String stringForDegreeAsLatitude(double locationDegree, boolean isLatitude) {
        if(!isDegreeValidAsLatitude(locationDegree, isLatitude)) {
            return "Degree "+locationDegree+" is invalid!";
        }
        String resultString = orientationStringForDegreeAsLatitude(locationDegree, isLatitude);


        // We need to calculate with positive numbers so we'll need the absolute value first.
        locationDegree = Math.abs(locationDegree);


        double degree = Math.floor(locationDegree);
        resultString += (int)degree+"° ";


        double x = (locationDegree - degree) * 60.0;
        double minute = Math.floor(x);
        resultString += (int)minute+"' ";


        double second = Math.floor((x - minute) * 60.0);
        resultString += (int)second+'"';


        return resultString;
    }


    private boolean isDegreeValidAsLatitude(double degree, boolean isLatitude) {
        if(isLatitude) {
            return isLatitudeValid(degree);
        }
        else {
            return isLongitudeValid(degree);
        }
    }


    private boolean isLatitudeValid(double degree) {
        return (degree >= -90 && degree <= 90);
    }


    private boolean isLongitudeValid(double degree) {
        return (degree >= -180 && degree <= 180);
    }


    private String orientationStringForDegreeAsLatitude(double degree, boolean isLatitude) {
        if(isLatitude) {
            return orientationStringForLatitude(degree);
        }
        else {
            return orientationStringForLongitude(degree);
        }
    }


    private String orientationStringForLatitude(double latitude) {
        if(latitude >= 0) {
            return "N";
        }
        else {
            return "S";
        }
    }


    private String orientationStringForLongitude(double longitude) {
        if(longitude >= 0) {
            return "W";
        }
        else {
            return "E";
        }
    }
}

Das Einsatzgebiet sieht wie folgt aus: (Unit Tests scheinen unter Android Studio 0.3.6 defekt, deshalb via Activity)

import android.app.Activity;
import android.os.Bundle;
import android.location.Location;
import android.util.Log;


import LocationDecorator;


public class TestActivity extends Activity {
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);


        Location testLocation = new Location("manual");
        testLocation.setLatitude(52.12525);
        testLocation.setLongitude(-13.76584);


        LocationDecorator decorator = new LocationDecorator(testLocation);
        Log.e("INFO", decorator.locationString());


        testLocation.setLatitude(110);
        testLocation.setLongitude(-911);


        LocationDecorator newDecorator = new LocationDecorator(testLocation);
        Log.e("INFO", newDecorator.locationString());
    }
}

Zitat

Output
11-29 12:48:24.768 E/INFO﹕ N52° 7' 30"; E13° 45' 57"
11-29 12:48:24.768 E/INFO﹕ Degree 110.0 is invalid!; Degree -911.0 is invalid!

Ich werde auf die Regenechsen verzichten und brav die Eingabe händisch parsen. Alles Andere ist doch Bullshit.

Zitat von ChampS

Bin ich der einzige der es komisch findet das er R.menu als ContentView setzt? :o

Zumindest scheinst Du der erste zu sein der es erwähnt.

Mit einem entsprechenden Eintrag aus LogCat wäre es uns sicherlich auch aufgefallen.

Na, was hast Du dann?

Mal für Interessierte zum Lesen, was genau so eine Kategorie eigentlich tut:
http://www.dpunkt.de/leseprobe…ategorien%20(Kap%207).pdf

Zitat von matthias

Hoi,
hab ich dich jetzt richtig verstanden, du willst eine Klasse - die dir nicht gehört - erweitern. Direkt?

Exakt.

Zitat von matthias

Die Vererbung wurde nicht umsonst erfunden ... ich denke nicht, dass du dein Vorhaben ohne Vererbung realisieren kannst.

Die Vererbung ist kein Allheilmittel. Die Vererbung ist oftmals sogar ein Code Smell.
Nicht umsonst gibt es Ansätze wie das Decorator Pattern: wenn ich eine bestimmte Funktionalität nachreichen möchte, dann möchte ich nicht zwingend 700 Unterklassen erstellen müssen.

Nehmen wir als Beispiel 'Balzac Coffee' (Ich mag 'Starbucks' einfach nicht...):
Ich kann mir ja für jede Kaffeesorte eine Subklasse von 'Kaffee' erstellen, die dann auch die Eigenarten des Kaffees hat.
Muss aber der Kaffee an sich wissen in welche Bechergröße er kommt? Muss der Kaffee an sich wissen, ob er ein Sahnetopping bekommt? Muss der Kaffee an sich wissen, ob ein Aromasirup in ihn gekippt wird?
Nein.

Also statt jeder Kaffeesorte diverse Größen mitgeben zu wollen (und dann bei der Einführung des XXXS Bechers für Neugeborene 700 Sourcedateien anfassen zu müssen), erstellt man sich einen Dekorateur, der den Kaffee um die jeweilige Größe erweitert. Oder um das Topping. Oder um das Aroma.

Zitat von matthias

Java ist und bleibt nun mal streng typsicher, was auch seine Vorteile hat.

Das hat ja damit nichts zu tun.

Nur offenbar ist Java so starr, dass es nicht 'mal eben zur Laufzeit' Methoden an ein Objekt anheften kann.
(Objective-C kann. Objective-C kann noch ganz andere Dinge. Objekten zur Laufzeit die Klasse wegreißen, Objekten eine andere Klasse unterjubeln, Objekte einer Klasse durch Objekte einer anderen Klasse ersetzen…)

Ich werde dann mal ein bisschen was mit dem Dekorierer versuchen und meine Ergebnisse hier posten.

Der TextWatcher klingt schon ziemlich genau nach dem, was ich gesucht habe. Danke!

Hui, danke für die Rückmeldung.
Schön, dass Du Fortschritte machst.

Was hast Du denn versucht, um das View in deiner Activity einzubinden?

Eventuell nutzt Du ja auch ein Template von Android Studio mit den Fragments.
Dann musst Du das in die onCreateView() deiner Fragment Subclass packen.

Du kannst die Zeichenroutine in eine eigene View stecken und diese View dann in die Activity packen.
Beispielsweise via setContentView().

Im Zusammenhang mit dem Gelaber im vorangegangenen Thread suche ich noch ein weiteres Konzept, mit dessen Hilfe ich mir ein bisschen Arbeit abnehmen kann.

Ich möchte android.location.Location um insgesamt vier Funktionen erweitern.
- Berechnung eines Locationstrings aus einer Location
- Berechnung einer Location aus einem Locationstring
- Berechnung eines Koordinatenstrings aus einer Koordinate
- Berechnung einer Koordinate aus einem Koordinatenstring
(Vielleicht auch noch eine Fünfte: Rückgabe des Locationstrings der aktuellen Location.)

Unter iOS hätte ich da die Möglichkeit der Kategorie. Die habe ich unter Java natürlich nicht.

Spontan fiele mir das Decorator Pattern ein, mit dessen Hilfe ich Location um ein paar Methoden erweitern kann.
Problematisch ist dann nur, dass ich mit einer eigenen Implementierung von Location arbeiten muss – da kann ich ja fast schon subclassen.

Ich möchte aber, dass jede android.location.Location meine Methoden beherrscht.
Wie gehe ich das an?

Wir alle kennen das ja: man kann ein Textfeld definieren und diesem dann einen Eingabetyp zuweisen.

Ich halte das für den richtigen Ansatz, um da einhaken zu können. (Falls ich falsch liege bin ich für jede Klarstellung dankbar.)

Ich möchte gern ein TextView haben, in dem ich ganz bestimmte Dinge eingeben kann: [0123456789nNeEwWsS.+-°"' ]
Allerdings nicht in beliebiger Reihenfolge... Habe ich nNeEwWsS, darf kein +- vorkommen. Der Punkt darf immer nur in der letzten Ziffer sein.
Die erste Ziffer darf nicht größer als 180 und nicht kleiner als -180 sein, es sei denn, es sind nNsS definiert, dann darf sie nicht größer als 90 und nicht kleiner als -90 sein. Die nächste Zahl darf keinesfalls größer als 59 und auch nicht kleiner als 0 sein. Und sollte es noch eine Zahl geben, so darf auch diese nicht größer als 59 und nicht kleiner als 0 sein.

Unter iOS wüerde ich mir einen Formatter bauen und an das TextField hängen.

Was mache ich unter Android mit dem TextView?

(Die ganz ausgefuchsten werden es erkannt haben. Für alle Anderen: das TextView [richtiger: der EditText] soll Geo-Koordinaten in allen gängigen Formaten annehmen können: 13.4557; 13.4557°; N13.4557; n13.4557°, -13° 45.57'; 13° 45.57'S, E13° 45' 57"; 13°45'57.8"W; Und so weiter.)

Klingt so als hättest Du nachträglich da rein geschaut.
Das bringt nix.

Du musst schon dann rein schauen, wenn deine App (auf dem Emulator oder dem verbundenen Gerät) abschmiert.