Beiträge von Marco Feltmann

So wie ich die Dinger verstehe (und ich klaue hier aus meinem Verständnis für iOS, weil das ScrollView für Android mal bescheiden dokumentiert ist...) ist das ScrollView genau so groß wie du sagst: 713 in diesem Fall.

Denn das ScrollView besteht im Allgemeinen aus einem Scroller und einem Content. Und innerhalb dieses Contents befinden sich die Views, die dann schlussendlich 'scrollen'.

Du willst also nicht wissen, wie groß dein ScrollView ist, sondern wie groß die Subviews im Content sind.

Leider hab ich keinen Plan, wie man da am Simpelsten ran kommt.

Ansätze wären:
• durch die Subviews iterieren (wie auch immer...) und mit measureChild(View child, int parentWidthMeasureSpec, int parentHeightMeasureSpec) arbeiten
• durch die Subviews iterieren (selbes Problem wie oben) und deren Höhenwerte aufaddieren
• via getMaxScrollAmount() herausfinden, wie groß der maximal erreichbare Scrollwert ist und mit dem aktuellen Wert vergleichen

Für dein Vorhaben scheint der letzte Punkt der passendste zu sein. Wenn der aktuelle Scrollwert (größer)gleich dem maximalen Scrollwert ist, wird wohl das Ende erreicht worden sein.

Eigene Erfahrungswerte.
Vergleiche aber auch free App Vorstellung Pönis Filmclub
(Gut, bei meinen eigenen Erfahrungswerten ist der Unterschied eher 6:1 statt 25:1, aber meine eigenen Erfahrungswerte basieren auf etwas spezielleren Apps die nicht [rein theoretisch] jeder gebrauchen kann..)

Was die Download-Zahlen der iOS und Android Projekte im direkten Vergleich angeht, ist es durchaus schlau, erst einmal für iOS zu entwickeln.

Also auf die Schnelle finde ich die Ursache nicht heraus.
Das passiert halt, wenn man alle Exceptions abfängt und weniger hilfreiche Infos statt Ihrer auswirft.

Es sieht alles danach aus, als läge das Problem beim Auslesen der gespeicherten Daten.

Zwei Mann, zwei Rechner, zwei Codes und am Ende zwei Programme.
Alles Andere (PhoneGap o.Ä.) halte ich für ausgesprochen unbefriedigend.

Und das Beste: Helpertools dann auch noch für Windows.
(Also Java, Objective-C und C#. One-Man-Coding-Army.)

Eigentlich benötigst du drei Dinge, um das Ganze umzusetzen.

Zum Einen Erfahrungen mit Datenbanken.
Da gibt es ein schönes fertiges Tutorial von den Android-Machern selbst:
http://developer.android.com/t…ta-storage/databases.html

Weit vorher solltest du wissen, wie man unterschiedliche Activities startet.
Auch da gibt es was Fertiges:
http://developer.android.com/t…asics/firstapp/index.html

Mit dem Wissen über diese Dinge kannst du dann anfangen, dich mit dem List View zu beschäftigen.
Da gibt es dann kein fertiges Tutorial mehr, sondern nur eine Kurzübersicht:
http://developer.android.com/g…s/ui/layout/listview.html

Wenn du das alles ein bisschen miteinander kombinierst, dann sollte das kein Problem werden.
Für den Anfang könnten die Bilder im Ressources-Ordner liegen, dann brauchst du nicht einmal mit der Factory hantieren, sondern kannst folgendes kurzes Beispiel nehmen:
http://developer.android.com/g…able-resource.html#Bitmap
(Also im Groben via imageView.setDrawable() und dann die Drawable aus den Ressources laden)

Vielleicht war ich auch einfach nur langsam.

Zitat von Kogoro

Du hast dazu nicht zufällig ein Stück Code?

Nö.
Nur ein postDelayed() auf die GPS-Koordinate setzende Methode mit einem Null-Parameter, ein paar Broadcasts und ein paar Dialoge.

Eine Datenbank: klar, nimm SQLite
Eine Tabelle: Keinesfalls. Niemals. Lies dich erst mal in Datenbanken ein.

Hallo nach Löhne!

Die Idee klingt (sofern ich sie richtig verstanden habe) recht spaßig und auch machbar. Nur hört sich das für mich nach einer unnötigen Verkomplizierung des Steuerungsprozesses an.

Das Abfangen von fehlenden oder bescheidenen Signalen mit Dialog an den Endnutzer hat mich jetzt mal locker 12 Stunden gekostet.
Alter Schwede, Spaß ist anders.

Na hoffentlich läuft das jetzt einigermaßen.

In der Mitte wovon?

Zitat von Kogoro

Also die App ist auf Version 7 geupdatet worden, aber die API ist immernoch auf Version 2...

Das darf auch gern noch ein wenig so bleiben.
Die App Version 7 läuft ja nur auf 4.0 aufwärts, man würde also 40% der User ausschließen, würde die API nur mit der aktuellen Maps Version interagieren.

Ich fänds ja super, den alten Rotz nicht mehr unterstützen zu müssen – aber erklär das einer den Usern.
"Wie, schon wieder 175€ für ein neues Smartphone ausgeben? Och nöööö!"

Ausgezeichnet, gratuliere.

Man merkt allerdings an den Preisen schon, dass das nicht für den Massenmarkt gefertigt ist...
Mein Bankkonto besteht ja leider aus geschichtetem Zwiebelleder.

Sagen wir so: mit einer Ungenauigkeit von 30 Metern ist das Signal schon unbrauchbar. Völlig egal ob Funk, WLAN oder GPS.
Warum mir 'BestProvider' in dem Zusammenhang dann 'passive' und 'network' anbietet finde ich schon mal daneben.
Ich werde also bei GPS als Provider bleiben. Wenn es den nicht gibt, dann gibt es den eben nicht.

Nur verstehe ich vielleicht die Umgebung falsch.
Ich habe jetzt ein GPS Signal. Dann ist mein GPS Signal plötzlich weg und kommt eine Ewigkeit nicht wieder. Irgendwann habe ich wieder ein Signal und es springt abrupt irgendwo hin. Das ist blöd, weil ich in der Zeit der Signallosigkeit ja keine Änderung erfahre.

Würde ich auf bestProvider schalten oder die Updates an das Criteria.FINE hängen, bekäme ich ja plötzlich bescheidene Ergebnisse. Daran erkenne ich dann ja, dass das GPS Signal unbrauchbar ist.

Und ich Depp hab gedacht, ich bekomme nach 2,5 Sekunden auf jeden Fall eine Location, schlimmstenfalls eine leere. Dass ich gar nichts bekomme war nicht Teil des Plans.

Zitat von Kogoro

Kannst du nicht vll ein bisschen die Koordinaten berechnen?

Da ich die relativ genauen Koordinaten für weiterführende Berechnungen brauche: eher nicht.

Zitat von matthias

Wie genau liest du denn den verwendeten Provider aus? Ich hab das mal mit getBestProvider und Criteria.ACCURACY_FINE getestet, hat super funktioniert.

Gar nicht.
Ich nutze den LocationManager und lasse mich von dem einfach nur informieren.
Und zwar über Änderungen des GPS_PROVIDER.

Mal mit dem getBestProvider herumhampeln, vielleicht löst das ja ein bis drei Probleme.
Danke für den Tipp!

Zitat von Kogoro

Meine Idee: Hersteller und Modell auslesen (http://developer.android.com/reference/android/os/Build.html) und dann entsprechend verarbeiten

Sehr gute Idee.
Allerdings bin ich ein Freund von 'Frag, was es kann' statt 'Frag, was es ist'.

Nehmen wir doch nur die Möglichkeit einen externen GPS Empfänger anzuschließen, der mal auf 1m genau arbeitet.
Dann lasse ich die Samsungs außen vor obwohl sie die megageilen GPS Hardware dran haben.

Andererseits verlasse ich mich ja auf den LocationManager, und ob externe Hardware in den eingreifen kann...
(FakeGPS kann es meines Wissens jedenfalls nicht.)

Wie dem auch sei, bei Samsung und GPS gehen die Meinungen wohl auseinander:
http://www.pocketpc.ch/samsung…ers-samsung-galaxy-s.html
http://www.androidpit.de/de/an…ans-Galaxy-S-anschliessen

Aber es wird wohl auf Auslesen und Verarbeiten hinauslaufen...
Ich hasse sowas!

Moinsen.

Ich hätte da mal gern ein Problem.

Meine App läuft auf vielen Geräten recht zuverlässig, nur die Samsungs machen offenbar Probleme.
(Beim Namen: Galaxy SII, Galaxy SIII mini, Galaxy ACE)

Obwohl ich die Updates alle 10 Meter oder 2,5 Sekunden anfordere, bekomme ich dort auch gern mal 50m und 30 Sekunden lang nichts rein.
Naja, und plötzlich macht es dann verständlicherweise einen riesigen Sprung von ungefähr 50 Metern...

Weder das LG Nexus 4 noch das HTC One V und auch nicht die Huawei Ascend und Sonic machen so einen Blödsinn.
Das scheint von Samsung gepachtet zu sein – und macht einen geringen Teil meiner App damit für Samsung-Nutzer schlicht unbrauchbar.
(Klar, gibt auch Tablet-Nutzer mit ohne GPS, für die ist der Teil der App ebenfalls unbrauchbar. Das wissen die aber auch.)

Muss ich jetzt irgendwie auf Samsung prüfen und den Leuten mitteilen 'Euer GPS ist Mist, du kriegst hier keine Führungen angeboten!' oder gibt es irgendwelche undokumentierten Tricks, wie man diesen Mistdingern ein ordentliches GPS Update aus dem Kreuz leiern kann?

Der 'Code in Question' wäre übrigens:

super.onStart();
if(locationManager == null)
{
    // Manche Geräte kennen keinen GPS_PROVIDER, so dass der Aufruf zu einer IllegalArgumentException führt.
    try
    {
        locationManager = (LocationManager)getSystemService(LOCATION_SERVICE);
        // Update alle 2,5 Sekunden oder 10 Meter.
        locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 2500, 10f, apl = new ApplicationLocationListener(this));
    }
    catch (Exception e)
    {
        locationManager = null;
    }
}
Location latestLocation = null;
if(locationManager != null)
{
    try
    {
        // Manche Geräte kennen keinen GPS_PROVIDER, so dass der Aufruf zu einer IllegalArgumentException führt.
        latestLocation = locationManager.getLastKnownLocation(LocationManager.GPS_PROVIDER);
    }
    catch (Exception e)
    {
        latestLocation = null;
    }
}

Der Shift-Steuerungskram funktioniert bei mir auch nicht und ein wenig umgebaut haben sie das beim letzten SDK Update offenbar auch.
Ich kann irgendwie nur durchgehende Linien ziehen. Wenn ich mich da verrannt habe, werde ich sie wieder los, indem ich den gesamten Bereich noch einmal markiere und dann die Maus außerhalb des Feldes ziehe. Also den kürzesten Weg, ohne neue Linien zu malen.

Ist ein bisschen gewöhnungsbedürftig, aber so malt man wenigstens keinen Blödsinn und ärgert sich dann später über unerklärliche Fehlermeldungen.