Beiträge von Marco Feltmann


    Den Weg mit dem Button finde ich umständlich. Ein Button soll darstellen, dass man ihn anklicken kann. Er braucht einen Rahmen (nein, keine Ramen!) und eine Fläche, auf die er reagiert. Wenn du nun die Fläche auf transparent setzt, dann hast du rein optisch nur ein Textfeld — doof. Wenn es wie ein Textfeld aussieht, kann man auch einfach ein Textfeld nehmen.


    Ein Button ist auch nur ein View. Und auch ein View kann einen OnClickListener haben, den View.OnClickListener.
    Es spricht also überhaupt nichts dagegen, wie in deinem Beispiel dargestellt, einen OnClickListener an das View (statt des Buttons) zu pappen. Der android.text.method.CharacterPickerDialog zum Beispiel implementiert das Ganze einmal für den Abbrechen-Button und einmal als Erweiterung für die anderen Views.
    Man muss dem User nur irgendwie anzeigen, dass er das Textfeld antippen kann. ;)

    Mahlzeit zusammen,


    ich gebe erstmal auf.... :-X


    Wenn das daran liegt, dass du ne ganze Menge anderer Dinge um die Ohren hast, dann ist das eine sehr gute Idee.
    Wenn das daran liegt, dass du dir das einfach nur nicht zutraust (und genau so lese ich das da heraus), dann halte ich das für eine äußerst blöde Idee.


    Wir alle mussten erst einmal die Grundlagen für Laufen lernen um festzustellen, dass das ganz toll ist – und machen das noch immer.
    Sehr viele von uns haben erst einmal die Grundlagen für Radfahren lernen müssen um festzustellen, dass das ganz toll ist - und einige machen das noch immer.


    Nun haben viele von uns auch die Grundlagen für Schlittschuhlaufen oder Inline-Skaten gelernt. Entweder machen wir das immer noch oder haben es für doof befunden und sein lassen.
    Das ganze lässt sich auf die Themen Auto/Motorrad fahren, Rauchen, Saufen, Kopulation, Musikinstrumente, Spiele, Kochen, Lesen, Filme... ausweiten:
    Grundlagen lernen. Verschiedenes ausprobieren. Weiter machen wenn es gefällt. Aufhören wenn es blöd ist.


    Noch vor Beendigung von Schritt 1 aufzugeben halte ich für dumm. Dann weiß man ja nie, ob es einem gefallen hätte oder nicht.


    Die SQLite Datenbank mit ContentProvider wird wahrscheinlich auch nochmal richtig rein haun bei dir. Das ist in Access natürlich auch viel einfacher.


    Ihr immer mit eurem Datenbankfetisch...
    Ich verstehe nicht, warum in objektorientierten Sprachen immer noch ein gefrickelter Datenbankzugriff von Nöten sein muss.
    Jeder, der mit objektorientierter Programmierung anfängt, will irgendwann einmal mit Datenbanken herumhampeln — wozu?
    Es heißt 'Objektorientiert'. Nicht 'Klassenorientiert' oder gar 'Datenbankorientiert'.


    Warum lernt man nicht erst einmal das Arbeiten komplett mit Objekten und schwenkt dann auf Datenbank um, wenn es wirklich notwendig wird?
    (Aus der Kategorie: Dinge, die ich bei den meisten objektorientierten Programmiersprachen nie begreifen werde.)

    Wäre echt schon mal die wirklich betroffenen Codezeilen zu sehen...

    Zitat

    03-05 16:46:04.575: E/AndroidRuntime(28734): Caused by: java.lang.NullPointerException
    03-05 16:46:04.575: E/AndroidRuntime(28734): at com.example.myrandommusicplayer.MainActivity.PlaylistBlack(MainActivity.java:65)


    Irgendwas ist da null. Entweder dein getApplicationContext() oder der mp oder was auch immer in Zeile 65 deiner MainActivity.java steht.

    Na, der Drumliner hat ja die meisten Fragen schon gut beantwortet. :)


    In einem Punkt muss ich dem Guten jedoch widersprechen.

    Zitat

    Dann wirst du Java lieben lernen :)
    Die Hürde ist bei Java eig. sehr niedrig.


    Das hängt ganz gewaltig von der Vorbildung ab.
    Wer C/C++/Objective-C gewöhnt ist, der bekommt bei Java zusätzlich zu diversen Krisen auch noch das kalte Kotzen. ;)
    (ich für meinen Teil habe nie etwas Anderes gemacht, außer mal ein paar Dinge in PHP.)
    Wer allerdings viel mit Delphi oder C# gearbeitet hat, dem fällt das Umdenken auf Java leicht.


    Mit Visual Basic Kenntnissen aus MS Access hingegen ist jede objektorientierte Programmiersprache erst einmal eine mittelschwere Katastrophe, was die Einstiegshürde angeht. Vor Allem Dinge wie die Variablensichtbarkeit bringen einen jedes Mal zur totalen Verzweiflung.
    (Bei Java habe ich bis heute nicht verstanden, was dieser 'final'-Quatsch soll - was daran liegt, dass ich das Übergeben von nackten Zeigern gewöhnt bin.)


    Hinzu kommt, dass meiner Meinung nach die Integration von UI und Code für Android im Speziellen und Java im Allgemeinen total beschissen gelöst ist.
    Bei Cocoa hast du einen Interface-Designer. Dort werden vollständige Objekte in dein Interface gepackt und du kannst problemlos darauf zugreifen, in dem du dein Interface-Objekt lädst.
    Bei .NET hast du einen Interface Designer. Dort werden vollständige Objekte in dein Interface gepackt und du kannst problemlos darauf zugreifen, in dem du deine Interface-Klasse instanziierst.
    Bei Android hast du eine XML-Datei und musst bei jeder Klasse, die dieses Interface darstellen soll, erst einmal selbst Variablen setzen, zuweisen und umhercasten, bevor du endlich auf dein Interface zugreifen kannst.
    Das führt dann zu Dingen wie dem ViewHolder Pattern, welches es weder bei iOS/Mac OS X noch bei Windows/Windows Phone gibt.


    Vor allem bei deiner Vorbildung würde auch ich dir empfehlen: Zeit lassen, durchbeißen, nach jedem Teilerfolg erst mal fünf Minuten an die frische Luft gehen, dann darüber nachdenken und Notizen machen.


    Die gesamten Programmierfachbücher scheinen meiner Meinung nach davon auszugehen, dass man die zu Grunde liegende Programmiersprache bereits supergut kennt. Damit sie sich dennoch 'Einsteiger' schimpfen können, werden noch einmal die komplett langweiligen, unendlich oft durchexerzierten, in wirklich jeder verdammten Miniprogrammiersprache vorhandenen Dinge wie Schleifen und Abfragen durchgekaspert.


    Nur um die wichtigen Dinge kümmert sich da keiner.
    Was ist der Unterschied zwischen einer normalen und einer statischen Variable? Was sind innere Klassen? Welche Architekturmuster gibt es und wie werden sie umgesetzt?


    Für all diese wichtigen Fragen gibt es nach wie vor eigentlich nur eine einzige Standardreferenz, die glücklicherweise nicht teuer sein muss:
    [openbook] Java ist auch eine Insel

    Ich habs soeben nochmal überprüft, es scheint als hätte ich mich vorher versehen? Ich rätsle gerade wirklich, wohl möglich war mein code zuvor etwas anders...


    Da hilft ein SCM wie CVS, SVN oder GIT. ;)


    Jedenfalls hab ichs gerade überprüft, catlog spuckt bei catch (IOException e) {} ein "nicht geladen" aus (was dann auch heißt, dass zuvor keinerlei Daten geladen wurden :| ). Das heißt dann wohl, dass ich tatsächlich keine Rechte auf die Datei habe.


    Also zunächst mal: e ist kein dummer Jungenstreich, sondern ein Objekt vom Typ 'Exception'. Gegebenenfalls auch eines von Exception geerbten Objektes.
    Wie dem auch sei, e kann unter Anderem .toString().
    Dies zu wissen ist unglaublich wichtig. Denn damit bekommt man total hilfreiche Informationen.
    Beispielsweise 'no permission', 'file does not exist' oder Ähnliches.
    Wenn du also ganz genau wissen willst, warum Laden (und ggf. auch speichern) fehl geschlagen ist, dann gib e.toString() mit aus.


    Soweit ich die Ideologie von Android verstanden habe, möchten die nicht, dass du deine Daten irgendwo hin packst.
    Einfach, weil dann 500 Anwendungen 500 Ordner auf dem Root der SD Karte anlegen und kein Mensch mehr durchsieht. Im Allgemeinen möchte das der durchschnittliche User nicht, obgleich dir als Entwickler das sehr entgegen käme. Du kannst also nicht einfach die Schreibrechte für irgendwelche Ordner der SD-Karte übernehmen. (Vielleicht mit Jailbreak, aber das will ja keiner.)
    Es gibt wohl einige Apps, die das so machen. (Xing beispielsweise für ihre Visitenkarten, openfeint, 7digital, dsatab...)
    Mich persönlich nervt das. ;)
    Es kann aber durchaus sein, dass dein /sdcard/ das Problem ist.
    Du könntest mal versuchen, getExternalFilesDir(Environment.DIRECTORY_PICTURES)+"../ABCD" zu benutzen.
    Das sollte dann einen Pfad /mnt/sdcard/Pictures/../ABCD erzeugen, also ein /mnt/sdcard/ABCD.


    Dafür gibt es jedenfalls getExternalFilesDir(). Du kannst der Methode noch einen String-Parameter mitgeben, damit Bilder im Bilderordner, Musik im Musikordner, Klingeltöne im Klingeltonorder etc.pp. landen.
    (siehe Beispiel oben)
    Für eigene Dateien ist meines Wissens /mnt/sdcard/Android/data/com.example.myapp/files vorgesehen.


    Wenn jetzt jemand einen Ordner hat, in dem er die ganzen selbst erstellten Dateien hinlegt, dann kommst du da aus deiner App natürlich eher nicht ran.
    Wenn er die Daten statt auf /mnt/sdcard/ABCD lieber in /mnt/sdcard/Levels packen möchte, kommst du da ebenfalls nicht ran.


    Du hast also genau drei Möglichkeiten:
    a) statt dem User mitzuteilen 'Pack deine Daten nach /sdcard/ABCD' sagst du ihm 'Pack deine Daten nach /sdcard/Android/data/com.example.myapp/files/ABCD'
    b) gib ihm eine Option 'Import level data' oder 'Import level data from directory', lasse ihn manuell die Datei oder den Ordner wählen, und kopiere es dann in deiner App an den gewünschten Ort. (eventuell noch mit Option 'delete files after import')
    c) mach eine Einstellung, in der du den Ordner für die Levels angeben lässt und stelle den halt standardmäßig auf getExternalFilesDir(null)


    Es spricht natürlich gar nichts dagegen, a+b+c gleichermaßen durchzuführen. :)

    Verlass dich niemals auf hardgecodete Pfadangaben wie /sdcard/bla.


    Im schlimmsten Fall hast du keinerlei Schreibrechte auf /sdcard/ABCD.
    (Das sollte dir LogCat dann auch entsprechend mitteilen.)


    Nutze statt dessen lieber getExternalFilesDir(null);
    Manchmal liefert das null zurück, was dann immer zu Problemen führt - allerdings ist das bei mir bis jetzt nur auf seltsamen AVD passiert, nie auf dem Gerät.


    Jedenfalls sollte der dich dann in ein Verzeichnis werfen, dass du beschreiben kannst.
    Meist etwas wie /mnt/sdcard/Android/data/tld.company.app/files


    Dann sollte das Kopieren auch klappen. :)

    Na wenn du eh nichts anderes als die Telefon/SMS Funktion nutzt reicht auch nen alter Nokia knochen der 1-2Wochen durchhält :)


    Naja, fast.
    Relativ unkaputtbar, 3 Jahre Gewährleistung, A-GPS und mit Java SDK. ;)
    Akku hält beim für mich durchschnittlichen Betrieb ungefähr 4 Wochen.



    Ich nutze hingegen relativ selten die Telefonfunktion des Geräts :D Meine Top Apps belaufen sich dabei auf Nachrichten (Whats App, Email etc), Surfen. Natürlich kommen meine eigenen Apps dazu ;)


    Für solche Dinge werde ich sicherlich auch in 10 Jahren noch Notebooks oder höchstens Tablets benutzen.
    Ich bin von 1984, ich mag Tastaturen. :P
    Mit denen bin ich einfach mal um ein Zehnfaches schneller als mit dem On-Screen-Gealbere auf den elektronischen Geräten.


    Tja, und für alles Andere (Termine, Notizen, Kontakte, To-Do-Listen, MindMaps etc.pp.) nutze ich nach wie vor tote Bäume und je nach Anwendungsfall Graphit oder eine Methylenblau-Wasser-Mixtur.


    Der Pro-Kopf-Jahrespapierverbrauch ist von 2000 bis 2008 um knapp 8% auf 251kg gestiegen, 1990 waren es nur 194kg.
    Die Papierindustrie produzierte 1990 insgesamt 15,5 Millionen Tonnen Pappe/Papier/etc, 20 Jahre später sind wir bei fast 20 Millionen Tonnen. [1]
    Das hat sicherlich Gründe. ;)
    (zugegeben, die Produktion an 'graphischen Papieren' ist zurückgegangen, dafür gibt es umso mehr Verpackungs- und Hygienepapier.)


    Bzgl. Android hätte ich dir vor einiger Zeit vermutlich zugestimmt. Bei mir hat sich die Ansicht aber echt gewandelt. Das reine System gefällt mir sogar sehr gut.


    Ich benutze ein HTC One V beruflich. Das System finde ich ebenfalls super. Nur hat mir das Endgerät einfach zu viele Tasten, jede Anwendung sieht irgendwie anders aus, kaum eine macht Dinge so wie ich sie erwarte und ich musste nicht einmal mein Windows XP so oft neu starten wie die Android Geräte (hab noch ein Samsung SII für Tests), nur weil sich wieder irgend eine Komponente unerklärlicherweise weggehängt hat.
    (Meist WLAN oder Mobiles Netzwerk, selten auch mal eine Kernkomponente.)


    Kurz: die Qualität überzeugt mich nicht. ;)


    Allerdings muss ich schon sagen, dass was Samsung mit TouchWiz bzw. HTC mit Sense macht finde ich nun auch nicht so toll gelöst. Das neue 5.0 Sense lässt sich wenigstens relativ gut nutzen und gefällt mir auch soweit (Bis auf einige Dinge). Finde es dennoch nicht besonders, dass die Hersteller uns vorschreiben wollen, welche Oberfläche man von vorn herein nutzen soll (ohne zusatzprogramme). Dies führt dann im umkehrschluss auch oft wieder zu Update verspätunge (Was wohl das Schlimmste in der Android Welt überhaupt ist).


    Tja, das kommt noch erschwerend hinzu.


    1) http://www.vdp-online.de/de/papierindustrie/statistik.html sowie
    http://www.gramufon.de/gramufon/papierkrieg/

    Einerseits bin ich von Smartphones schlicht nicht überzeugt.
    Nix von dem, was sie können, erachte ich für mich als sinnvoll.
    Außer vielleicht Telefonieren oder SMS schreiben, aber für das bisschen Funktionalität sind die Dinger neben überteuert auch noch beschissen von der Akkulaufzeit und Empfindlichkeit her.


    Ach ja, und von allen Möglichkeiten des Betriebssystems ist für mich Android auch die am Wenigsten sympathische.
    Gut geplant, wunderbar auf die Hardware optimiert, und leider nicht vernünftig zu Ende gedacht und geführt.
    Kurz: ich mag das Feeling überhaupt nicht. ;)

    Lucas du hast den Bedankenbutton vergessen :)


    Nachgereicht. ^^

    Hab schon auf die Antwort gewartet ^^


    +puh+ Da bin ich beruhigt. Hab schon gedacht, dass ich mich als Typ mit mal gerade 1 Jahr so richtig auf Android hier als Klugscheißer gleich unbeliebt mache. +g+


    durch einen check mit instanceof fiel mir auf das trotz des types list das objekt trotzdem eine instanz von arraylist ist


    Ansonsten wird das mit dem Casten auch ziemlich schwierig. :)

    Bald nutze ich nur noch Collection. Diese Möglichkeiten der Unterteilung sind ja echt bekloppt. 8|


    Wie dem auch sei, es ist eine ArrayList.
    Ich kann sie ja prima als solche casten und der Name verrät mir schon, dass ich keine ClassCastException dabei bekommen werde. :P
    (Dinge, die man beim NDK und Objective-C lernt: Ein Objekt ist immer das Objekt, das man erstellt hat. Egal wie man es zu Anfang deklariert und egal wohin man es zu casten versucht.)

    Java
    Object id = new Date();


    Was ist id denn jetzt, ein Object oder ein Date?
    Die Runtime lässt mich nur die Object-Methoden auf id ausführen, ich muss also erst einmal casten.
    Doch ich kann id auf Date casten, weil es ein Date ist.
    Will ich id auf String casten, bekomme ich eine ClassCastException. id ist ja schließlich kein String.


    Im NDK ist das übrigens komplett anders.
    Da kann ich lustig jLongArray in jString in jDate in jDouble casten. Alle Objekte im ndk sind als 'void *' definiert, wie auch alle Objekte in Objective-C.
    Folgendes funktioniert da tatsächlich und wirft keine Exceptions, Fehler oder Warnungen:

    C
    jdouble einspunktdrei = env->newDate();
    (jLongArray)einspunktdrei;
    (jString)einspunktdrei;
    jdate today = env->newString("Heute");
    (jArrayList)today;


    Dennoch ist einspunktdrei ein Datum und today ein String.

    Also auf meinem Smartphone mit 4.0.3 wird es angezeigt...
    Ich habe in meiner Action Bar oben rechts drei untereinander angeordnete Quadrate, die nach einem Tab darauf das Menü zeigen.
    Halte ich die 'Kürzliche Apps'-Taste gedrückt, dann fährt dieses Menü an der oberen rechten Ecke ein und aus.
    Mache ich dasselbe im Simulator mit 4.0.3, habe ich keine Eintragungen in meiner ActionBar und beim Halten der 'Kürzliche Apps' Taste fährt das Menu von unten Mitte ein.


    Unter AndroVM mit 4.1.1 verhält es sich so wie mit dem Simulator.


    (ich habe nur die onCreateOptionsMenu drin gehabt, nicht die onOptionsItemSelected)