Device default Orientation

[ui_3k1]

Hallo,
wer schon mal etwas mit dem Beschleunigungssensor gemacht hat, wird vielleicht die Erfahrung gemacht haben, dass bei einem Tablet, oder einem anderen Gerät im "Standard-Querformat, die Achsen (X,Y,Z) getauscht sind.

Hier schnell eine Funktion, die für dieses Problem Abhilfe schafft:

Das Beispiel ist darauf ausgelegt, dass ein Smartphone im Landscape-Modus seitlich gekippt wird (also das Kippen so abläuft, als ob das Handy mittig an einem Lenkrad (BMW-Emblem / Mercedes Stern) festklebt wäre und das Lenkrad dreht wird = Y-Achse).

[COLOR=DarkOrange]/**Gibt, sofern es sich bei dem Geraet um ein Tablet handelt, die Z-Achse als Fixpunkt zurueck*/[/COLOR]
    public boolean getDeviceDefaultOrientation() {
        WindowManager windowManager = (WindowManager) getSystemService(WINDOW_SERVICE);[COLOR=SeaGreen] [COLOR=YellowGreen]// je nach dem wo die Implementierung erfolgt: [/COLOR][/COLOR][COLOR=YellowGreen]"Context.WINDOW_SERVICE);"[/COLOR]
        Configuration config = getResources().getConfiguration();
        int rotation = windowManager.getDefaultDisplay().getRotation();
        if (((rotation == Surface.ROTATION_0 || rotation == Surface.ROTATION_180) &&
                config.orientation == Configuration.ORIENTATION_LANDSCAPE)
                || ((rotation == Surface.ROTATION_90 || rotation == Surface.ROTATION_270) &&
                config.orientation == Configuration.ORIENTATION_PORTRAIT)) {
            return true;
        } else {
            return false;
        }
    }

Der Sensor kann dann als solcher in dieser Form angesprochen werden:

[COLOR=DarkOrange]/**Aktualisiert den Neigungswert, den das Geraet erfaehrt.*/[/COLOR]
    @Override
    public void onSensorChanged(SensorEvent sensorEvent) {
        synchronized (this) {
            if (sensorEvent.sensor.getType() == Sensor.TYPE_ACCELEROMETER) {
                if (tabletMode)
                   [COLOR=YellowGreen] // fuer Tablets sprechen wir die X-Achse an[/COLOR]
                    sensor_axisVar = -(int) (sensorEvent.values[0] );
                else
                  [COLOR=YellowGreen]  // fuer Smartphones die Y-Achse[/COLOR]
                    sensor_axisVar = (int) (sensorEvent.values[1] );
            }
        }
    }

Natürlich benötigen wir eine Variable, die den zurückgelieferten Wahrheitswert aus der ersten Funktion speichert. Dieser lässt sich zB in der onCreate-Methode setzen.

tabletMode = getDeviceDefaultOrientation();

 

[Zoopa]

Kleine Anmerkung:
Wenn eine Methode getDeviceDefaultOrientation() heisst, dann erwarte ich als Rückgabewert eine Orientation. Jetzt wird ein Boolean zurückgegeben, von dem man nicht weiss, was er bedeutet.

Entwickler: "was ist die Default Orientation vom Device?"
Android: false
Entwickler: ....

Entweder nennt man die Methode z.B. isTabletMode(), oder man gibt auch wirklich eine Orientation zurück, entweder Configuration.ORIENTATION_PORTRAIT oder Configuration.ORIENTATION_LANDSCAPE (oder evtl. Configuration.ORIENTATION_UNDEFINED)

 

[kleinerkathe]

*lach* Die Beschreibung ist auch gut, "gibt die Z-Achse zurück" und Rückgabewert ist ein boolean

 

[ui_3k1]

Ganz ehrlich: ich verstehe nicht so wirklich was ihr wollt.
1. Code funktioniert und laesst sich binnen Sekunden einbinden, habe neulich erst wieder gelesen, dass es darum geht schnell zum Ziel zu kommen, hehe. (wenn nicht bitte sagen, was genau wo falsch ist, damit ich das korrigieren kann).
2. von gibt die Z-Achse zurueck habe ich nie gesprochen - sondern "als Fixpunkt" -> gut, man haette es definitiv schoener / eindeutiger formulieren koennen, woertlich genommen kann man meine Formulierung bestimmt falsch verstehen, ok. Aber trotzdem ist das Jammern auf sehr hohem Niveau - meine Meinung. Schliesslich bitte ich an keiner Stelle um Geld, Spenden, Kaffee oder andere Guter bzw. Dienstleistungen (vom Beta-Tester abgesehen). Wem meine Kommentare nicht gefallen, der braucht sie nicht lesen und wer aus ihnen schlau wird, der braucht nichts spenden. Meiner Meinung nach ein guter Deal.
3. Die Logik hinter diesem Codeschnipsel ist ja eher rudimentaer, deswegen lag mein Hauptaugenmerk auch nicht auf der wasserdichten Kommentierung. Immerhin konntet ihr die Fehler in der Kommentierung schnell finden (und euch wie ein reudiges Pack Woelfe draufstuerzen - nicht boese gemeint ), dass dies ja praktisch schon den Beweis liefert, dass besagte Kommentierung sowieso eher untergewichtet werden kann. Natuerlich seid ihr wahrscheinlich auch deutlich professioneller unterwegs als der Durchschnitt hier im Forum (ernst gemeint) und ich kann nicht davon ausgehen, dass Hanni und Nanni es ebenfalls verstehen.
4. (so schaetze ich subjektiv jedenfalls "die Welt ein, in der ich lebe") Lapidar gesagt: Soll schon mal vorkommen, dass man vor Code sitzt und nicht sofort nachvollziehen kann was er macht. Dieses Phaenomen sollte gerade einem, der das hauptberuflich macht bekannt, sein. Wie gesagt, ist nur meine persoenliche Meinung und ich weiss dass ich damit auch falsch liegen kann und hoffe, dass ich damit keine erregten Gemueter zuruecklasse.
5. (der wichtigste Punkt - so langsam komme ich mir schon vor wie ein sich im Darm einer Katze windender Bandwurm) Trotzdem moechte ich das, was ihr sagt, beherzigen und werde mich in Zukunft mehr auf meine Formulierung und eine eindeutigere Ausdrucksweise bemuehen. Ihr habt schon Recht und ich sollte froh sein, dass mich jemand auf meinen schlechten Kommentierstil aufmerksam macht, nur so kann ich es verbessern.

In diesem Sinne einen schoenen Samstag.

 

[kleinerkathe]

1. Code funktioniert und laesst sich binnen Sekunden einbinden, habe neulich erst wieder gelesen, dass es darum geht schnell zum Ziel zu kommen, hehe.

Dann bitte weiterlesen bis zum Punkt "Wartbarkeit"

Deine Methode funktioniert, gut
Ist wenig Code, ist überschaubar, sieht ordentlich aus, gut

Das Problem, dass du selbst irgendwann haben wirst (und das hab ich genauso noch desöfteren), du sitzt in einem halben Jahr vor dem Code, siehst den Aufruf "getDeviceDefaultOrientation" und verstehst nicht warum da ein boolean zurückgegeben wird und was dieser nun aussagen soll Solche Fehler passieren mir auch noch häufig genug, da bin ich noch lange kein "Profi"

Du weißt garnicht, wie oft ich mich auch rechtfertigen muss bzw. erklären muss was ich da eigentlich gemacht habe Aber nur dadurch kommt man selbst darauf: "Oh, stimmt ... so ganz verständlich ist das nicht was ich da mache. Nenne ich die Methode so, die Variablen vll. so, dann ist das für den nächsten auch klar was ich da mache" oder "Okay, mehrere Kommentare könnten den Hack den ich da grade zusammenschuster leserlicher machen" ...

 

[Zoopa]

Das war ja nicht böse gemeint, wollte nur Tipps geben

Ja, ich entwickle beruflich, deshalb achte ich sehr auf solche Dinge. In einem Team ist es wichtig, dass der Code so aussagekräftig wie möglich ist. Zum einen brauchst du dann automatisch weniger Kommentare und zum anderen musst du dir nicht immer wieder den ganzen Code anderer Mitarbeiter durchlesen, wenn die Methodensignatur bereits klar sagt, was die Methode macht und zurückgibt.

Natürlich trifft man oft auf Code, den man nicht auf Anhieb versteht. Genau in diesen Situationen ist man aber umso froher, wenn der Code so sauber wie möglich geschrieben ist. Denn je sauberer geschrieben, desto einfacher zu verstehen.

Auch wenn du alleine entwickelst, solltest du versuchen, alles so deutlich wie möglich zu benennen, wie kleinerkathe bereits gesagt hat. Nicht nur, dass du deinen Code später besser verstehen wirst, es kann dir auch helfen, Code besser zu strukturieren. Wenn du keinen eindeutigen Namen für eine Methode finden kannst, liegt das nämlich oft daran, dass die Methode zu komplex ist und zu viele Dinge macht, die man in mehrere Methoden aufteilen sollte.

Falls dich das Thema näher interessiert, kann ich dir das Buch Clean Code empfehlen. Das ist eines der Standard-Bücher, dass meiner Meinung nach alle Entwickler lesen sollten Es ist auch eines der Bücher, das mir seit dem Studium wohl am meisten gebracht hat (Neben Büchern über Design Patterns und Testing).