Beiträge von Marco Feltmann

Zitat von matthias

Hoi,
die Frage wieso du musst kann ich mir wohl nicht verkneifen ...

Na dann frag.

Zitat von matthias

wieso musst du ein riesiges Bild anzeigen, dass auf einem kleinen Display selbst wenn der Speicher es reisst trotzdem zu Problemen führt?

Weil der Chef es so verlangt. Frei nach dem Motto 'unter iOS funktioniert das ja auch'.
Natürlich hängt da noch ganz viel Kram hinter, der eben dieses schöne Bild produziert. Das Ding auf Tiles umzustellen würde nicht nur dort sondern auch bei der bereits laufenden iOS Variante erhebliche Umbauten nach sich ziehen. +seufz+

Zitat von matthias

Also wo liegt das Bild und darf es wirklich nicht kleiner werden?

Auf der SD-Karte im Files Directory. Beziehungsweise ohne SD-Karte im internen Files Directory. Und ja, darf es wirklich nicht.

Zitat von matthias

Feste Breite/Höhe, nix verändern?

Natürlich alles fix, sonst läuft der Rest nicht korrekt.

Zitat von matthias

Für welche Android-Versionen?

Ab API 10 aufwärts.

Zitat von matthias

Da bin ich fürchterlich aufs Maul gefallen, weil man unter 3.0 glaube ich wars jeden sch... recyclen muss und ein removeView() auch nicht langt sondern man da teilweise echt dynamisch die Child-Objekte raus kramen darf um die dann zu recyclen.

Das war soweit ich gelesen habe bis einschließlich API 10 der Fall, fällt also genau in das Wunsch-OS.

Zitat von matthias

Hast du schonmal solch ein Konstrukt getestet?

Nein. Das sieht ja recht geil aus.
Ich vermute nur, dass auch das ein bisschen Speicher frisst. Zumal das fertige Bild ja wie geschrieben als 3MB PNG vorliegt und nur im Memory, BitmapFactory sei Dank, auf über 30MB aufgeblasen wird.

Naja, das Projekt ist jetzt für teuer Geld an extern abgetreten worden. Ich bin dafür offenbar einfach zu unfähig.

Das übliche Leid: der mickrige VM Heap.

Ich muss (ja, ich muss!) ein großes Bild anzeigen, um die 2000x3000 Pixel.
Dieses Bild nimmt als PNG lächerliche 3MB ein, als Bitmap für Android hingegen nicht mehr ganz so lächerliche 30MB.

Alle gefundenen Lösungen zum Speicherproblem mit Bildern geht folgende Ansage voraus: Finger weg von großen Bildern.
In meinem Fall kann ich aber die Finger nicht von den großen Bildern lassen.

Welche Möglichkeiten habe ich, ein Bitmap aus einem PNG zu erstellen, dass zwar dieselben Dimensionen wie das PNG hat, doch hübsch komprimiert nur einen Zehntel des Speicherplatzes einnimmt?

Klingt erst mal so, als hätte er das in einen Nur-Lesen-Kalender gepackt, den er auf dem Rechner nicht synchronisiert.
Keine Idee was das sein könnte-

Eigene Subklasse von Button und schön selber malen.

Man muss mit Aussagen zum Syncen der User leider sehr vorsichtig sein.

Ich würde folgende Schritte durchgehen:
1) Schauen, ob der Eintrag im Google Kalender auf dem Gerät auftaucht.
2) Schauen, ob der Eintrag online im Google Kalender auftaucht.
3) Schauen, ob der Eintrag im Google Kalender am PC auftaucht.

Wenn einer der Schritte fehl schlug weiß man, welche Sync nicht geklappt hat.
Generell gilt: wenn das Ding im Kalender auf dem Gerät auftaucht, dann hast du deine Schuldigkeit getan.
(Natürlich spricht nichts dagegen, den User an die Hand zu nehmen und ihm bei den Einstellungen zu helfen.)

Ich muss zu meiner Schande gesehen, dass ich darüber in Android keine Ahnung habe. In die View-Geschichten arbeite ich mich erst ein...

Pauschal würde ich versuchen, ein Sechseck wirklich als Button zu implementieren, in der Hoffnung, dass der OnClickListener von transparenten Bereichen nicht getriggert wird.

Wenn du natürlich am Ende ein Raster von meinetwegen 512x512 von den Dingern hast, könnte das Ganze arg unperformant werden.
In dem Fall wäre Mathematik die beste Lösung. Also ein ImageView zeichnen und in der OnClick auswerten, wohin geklickt wurde.
Anschließend hast du dir irgendwo die Ausmaße deines Sechsecks gesichert und musst eigentlich nur 'längskacheln'.

Sprich:
(Breite einer Kachel (und zwar der oberen Geraden ohne Versatz!) + Versatz der linken Kachel) / x-Position des Klicks ergibt die Spalte,
(Höhe einer Kachel + halbe Höhe einer Kachel bei gerader Spalte) / y-Position des Klicks aufgerundet ergibt die 'Reihe'.

Probier erst mal diesen Ansatz.

Ich habe soeben festgestellt, dass es tatsächlich einen noch einfacheren Weg gibt: direkt auf die Bilder verweisen.
Im XML so:
android:src="@android:drawable/ic_dialog_map"

Im Code so:
android.R.drawable.ic_dialog_map

Sieht so aus als sei dbHelper null, sofern deine Bezifferung übereinstimmt.

Da das scheinbar eine private Variable deiner onCreate Methode ist, der OnClickListener aber in einem anderen Kontext ausgeführt wird und keinen Zugriff auf diese Variable hat, wird es daran scheitern.

Und zwar so ziemlich genau in Zeile 174.

Zitat von matthias

Hat sich Google jetzt selbst geowned?

Jau.

Möglichkeit 1 wäre in meinen Augen der Service.
Den müsste ich auch mal implementieren, habe mich aber noch nicht da ran getraut.

Als Möglichkeit 2 würde ich einen SplashScreen vorschlagen, der angezeigt wird. Und sobald das alles vernünftig durchgeeiert ist zeigst du die eigentliche Activity an.

Naja, je nach Hardwarehersteller haben die ihre eigenen Treiber für ihre eigene Hardware geschrieben und die namentlich so tollen Methoden, die auf diese Treiber zugreifen müssen, können nur Mist zurückgeben, weil sie nur Mist bekommen haben.

Ich würde immer das aktuelle Nexus zum Betriebssystem für derartige Tests nutzen und wenn es darauf läuft schauen, was andere Geräte so tun.
Da liegt die Versäumnis tatsächlich leider nicht bei Google.

Wenn ich einen String mit Scheiß übergebe und mir die Routine daraus eine Zahl bauen soll, dann ERWARTE ich, dass sie bei JEDEM String eine Zahl zurückgibt.
Sie muss mir nicht aus "zwölf" eine 12 machen und auch nicht aus "RüdigerDie80JährigeAltePottsauStinkt" eine 80.
Aber doch bitte aus "Hier steht keine Zahl drin, egal wie man sich dreht und wendet." eine 0.
Eine App hat niemals nicht abzustürzen, nur weil Müll übergeben wurde!

Vor Allem beim Beispiel "" ist 0 naheliegend. Denn "" kommt aus einem XML Element <maxtries/> und bedeutet: keine Höchstanzahl an Versuchen.

Auch FileNotFound Exceptions finde ich sinnlos. ICH habe meine Objekte zu prüfen und nicht irgend eine Routine. Öffne ich also eine Datei, die es nicht gibt, ist das Resultat NULL.
Niemals nicht soll die App dann einfach abstürzen, zumal 'Datei nicht vorhanden' ein Standardfall und kein schwerer Ausnahmefehler ist.
(Fun Fact: Fange ich den Fehler ab muss ich das Resultat auf irgendwas Vernünftiges setzen, da es ja weiterhin nicht initialisiert ist – das hätte ich auch ohne Exception tun können.)

Überhaupt habe ich das Gefühl, dass C#, Java oder C++ keine objektorientierten Sprachen sind, sondern klassenorientierte Sprachen.
Ein Interface kann keine optionalen Methoden haben. Warum nicht?

Konstrukte wie

if(!callback.getIsOkayToDoSo())
{
  callback.doSomethingElse();
}
else
{
  iDoItByMyself();
}

sind im Allgemeinen keine Seltenheit.
Dennoch muss meine abgeleitete Klasse selbst dann doSomethingElse() implementieren, wenn getIsOkayToDoSo() immer true zurückgibt.

Ein weiteres Beispiel: wie erfahre ich, ob ein Objekt...? Frag seine Klasse!

Wie erfahre ich, ob ein Objekt die Methode doSomething() implementiert? Frag seine Klasse nach den implementierten Methoden und schau nach, ob doSomething() dabei ist.
Wie erfahre ich, ob ein Objekt das Interface CanDoSomething() implementiert? Frag seine Klasse, ob sie eine Instanz des Interface ist.
Wie erfahre ich, ob eine Person Schreibmaschine schreiben kann? Frag ihn nach seinem Beruf und schaue nach, ob schreibmaschineSchreiben() dabei ist.

Der Programmierer fällt raus, ebenso der Maurer. Obwohl beide es gelernt haben, der Eine in der Ausbildung, der Andere nebenbei.
Der Schriftsteller übrigens fällt mit in die Auswahl, obwohl er seit Lebzeiten nur per Hand schreibt und nie eine Tastatur benutzt hat.

Der richtige Weg sieht anders aus.
Wenn du wissen willst, ob ein Objekt eine Methode implementiert, frag das Objekt, nicht seinen Bauplan.
Wenn du wissen willst, ob ein Objekt ein Interface implementiert, frag das Objekt, nicht seinen Bauplan.
Wenn du wissen willst, ob ein Mensch Schreibmaschine schreiben kann, frag den Menschen, nicht seinen Gesellenbrief.
Wenn du wissen willst, ob ein Kind Hunger hat, frag das Kind, nicht seine Mama.
Wenn du wissen willst, ob dein Flirt gut im Bett ist, frag deinen Flirt, nicht dessen Ex.
(Oder lass dich überraschen und probiere es aus. ;))

Im Gegensatz zum Menschen sagen die Objekte immer die Wahrheit. Das liegt allerdings darin begründet, dass bei Objekten Wahrheitstreue bei 100% und Fremdbeeinflussung bei 0% liegt.

Ich habe mit den Cams in den Geräten noch gar nichts gemacht, da ich dank der Fragmentierung ja bereits an den Displays scheitere.
Die Tatsache, dass es bei den eingebauten Kameras kein Stück besser aussieht motiviert mich auch nicht, dort in irgend eine Art und Weise zu investieren...

Zitat von matthias

Man möchte meinen die hätten das so wie das finally eines try-catch blocks verwirklicht. Man kann im try-catch einen Wert zurück geben via return und das finally wird trotzdem vorher noch ausgeführt ... etwas enttäuschend, dass das hier offenbar nicht auf diese Weise funktioniert.

Wieso erwartest du dieses Verhalten?
Ich persönlich mag ja Exceptions und das damit einhergehende Handling überhaupt nicht und empfinde try-catch Blöcke als hinderlichen Steinzeitmist.
Mein Lieblingsbeispiel: Integer.parseInt("");

Da erwarte ich: 0
Aber ich bekomme eine Exception – dafuq?

Wie dem auch sei, von einem Hintergrundtask erwarte ich, dass er im Hintergrund agiert. Ich erwarte, dass er mich über seine Zustände informiert.
Bei meinem Verständnis (ich komme wie bereits mehrfach angedeutet aus der Smalltalk/Objective-C Welt) teilen meine Objekte mir alles mit.

Das heißt, ich frage nicht ständig: "Ey, Hintergrundtask, BIST DU BALD MA FETTICH?" sondern er sagt mir: "Hier Hintergrundtask. Habe Fertig."

Ich frage nicht ständig: "Ey, Hintergrundtask, wie ist der Status?" und werte dann die Antworten aus um zu überlegen was ich nun tue.
Sondern er sagt mir 'Hier Hintergrundtask. Aufgabe 1 von 245 erledigt.', 'Hier Hintergrundtask. Aufgabe 2 von 254 erledigt.", 'Hier Hintergrundtask. Bearbeitung abgebrochen.'

Die Benutzung der Schnittstellen des AsyncTask erlaubt mir halt so etwas Ähnliches.
"Hier Hintergrundtask. Lege gleich los." = onPreExecute.
"Hier Hintergrundtask. Hab XYZ erledigt." = onProgressUpdate.
"Hier Hintergrundtask. Habe fertig." = onPostExecute.
"Hier Hintergrundtask. Habe abgebrochen." = onCancelled

Für mich ist das genau die Art und Weise, mit der die Objekte kommunizieren sollten.
Und wenn ich mitten drin sage "Ey Hintergrundtask, sach mir Bescheid wenn de fertig bist" (.get()), dann ist es doch ganz klar, dass der Hintergrundtask nicht noch ein zweites mal angeschissen kommt und sacht "Hier Hintergrundtask. Habe fertig."
Denn wie oft sollte er das auch sagen?

http://developer.android.com/r…oid/os/AsyncTask.html#get()

Zitat

Waits if necessary for the computation to complete, and then retrieves its result.

Der Task wird nicht beendet, sondern es wird auf sein Ende gewartet und dann bekommst du das Resultat.
Das bedeutet: wann immer du .get() auf deinen AsyncTask aufrufst ist dieser fertig. (Ansonsten hagelt es exceptions)

Ja, danach wird onPostExecute nicht mehr aufgerufen, da du dir ja selbst das Ergebnis geholt hast.
onPostExecute ist genau für derartige Fälle da: den User informieren wenn die Dinge fertig sind.
Denn all das geschieht über das UI. Wenn man die Infos nicht braucht, implementiert man halt eine leere onPostExecute.

Da aber gefühlt ALLE Aktionen in Android irgendwie auf diesen verfluchten UI Thread hinaus wollen gibt es nichts, was dagegen spricht.

Solange dein async Task irgendwas tut solltest du dich nicht um seinen Rückgabewert kümmern.
Sobald in onPostExecute gesprungen wird, ist dein async Task fertig. Vorher nicht.

Dein Rückgabewert landet als Parameter in der onPostExecute. Du selbst hast dich darum überhaupt nicht zu kümmern.

Wenn du also designbedingt irgendwo außerhalb deines Async Task auf den Wert der doInBackground zugreifen musst, dann musst du dein Design überdenken.

Moin,

mich würde einmal interessieren, wie viele der hier aktiven Mitmenschen an Gärten, Pflanzen und Ähnlichem interessiert sind.
Hat jemand von euch zufällig vor, die Internationale Gartenschau Hamburg zu besuchen?

Falls ja könnte man sich ja mal treffen und fachsimpelnderweise durch die Anlagen schlendern.

Genau. Ein ListView hat per Definition nämlich keinen Text.
Vermutlich hast du von 2.3.x auf 4.1 aktualisiert? In dem Fall würde ich vorschlagen, dass du die Textfarbe nirgendwo setzt und das System damit dann auf jedem Gerät die Standardtextfarbe zeigt, also ein sehr helles, fast weißes Grau auf 2.x und ein sehr dunkles, fast schwarzes Grau auf 4.x

Ansonsten bist du wohl gezwungen, die Hintergrundfarbe des ListViews und die Textfarbe der Textviews explizit zu setzen, damit es überall gleich aussieht.

Also da steht was übers Updaten.
Was davon trifft denn auf deinen Fall nicht zu?

Im Prinzip (auch wenn ich 0 als NotificationID ziemlich dämlich finde) kannst du doch mit diesem Code bei jeden neuen Musikstück createNotification(); aufrufen.
(Eventuell solltest du den Krams mit den Intents weglassen. Das Ding ist doch schon eine Activity.)