Beiträge von Marco Feltmann

    [matthias]
    Eclipse ist ein Arschloch. Ich mag es echt nicht, vor Allem auf dem Mac ist es eine Katastrophe.
    Teste mal, ob das mit der Community Edition von IntelliJ IDEA auch auftritt.


    Und beim Mac gilt wie bei jedem UNIX: RAM ist durch nix zu ersetzen, außer durch mehr RAM. ;)


    [schymura]
    Ich verstehe deine Darlegung nicht.
    Noch weniger verstehe ich, warum du im onDestroy() auf isFinishing() prüfst.
    Gemäß Activity Life Cycle ist die Activity gerade am Sterben, nicht am Beenden.
    Statische Variablen behalten auch immer ihren Kontext. Was würde passieren, wenn du einfach nicht auf isFinishing() testest?

    Nur beim Format würde ich noch mehr investieren, wenn du den Nutzern das Ändern per Hand etwas erleichtern möchtest.


    In dem Punkt wäre ich zwiegespalten. Mit Messengern wie WhatsApp oder auch via MMS kann man ja Dateien anfügen.
    Da wäre es meiner Meinung nach sinnvoller, wenn die Dateien möglichst klein sind, zumal der Editor ja dem Game beiliegt.


    Sollte das Spielfeld also maximal 16x16 Felder haben und maximal 16 Bilder beinhalten, ließe sich das Ganze schön binär abspeichern.

    C
    100 10F 110 11F 120 12F 130 13F 140 14F


    Wird das Ganze auf 256 ausgeweitet, sieht das natürlich etwas gröber aus:

    C
    010000 0100FF 010100 0101FF 010200 0102FF 010300 0103FF 010400 0104FF


    Dann noch ein paar Infoflags dazu und gut.

    C
    1 3 0A 100 10F 110 11F 120 12F 130 13F 140 14F


    C
    02 06 0A 010000 0100FF 010100 0101FF 010200 0102FF 010300 0103FF 010400 0104FF


    Das ganze noch zusammengekürzt (Darstellung in Bit-Blöcken von 8 Bit, also 0 bis 255 [entspricht dem Datentyp unsigned char]) und die Datei ist um Längen kleiner als JSON oder XML.

    C
    00000001 00001000 00001010 00000000  00000001 00000000 00000000 00000001 00000000 00001111 00000001 00000001 00000000 00000001 00000001 00001111 00000001 00000010 00000000 00000001 00000010 00001111 00000001 00000011 00000000 00000001 00000011 00001111 00000001 00000100 00000000 00000001 00000100 00001111


    Parsen muss man den Kram so oder so, also empfiehlt es sich doch, einen Binärparser zu erstellen.
    1. Byte: Version der Datei/des Programms (falls in Version 1 Bild 5 ein anderes ist als in Version 2 oder 3...)
    2. Byte: In der Ursprungsplanung als Bitlänge je Eintrag gedacht, um möglichst viel Platz zu sparen. Sprich: wenn maximal 15 Elemente vergeben werden, reichen 4 Bit pro Ziffer, bei 8 Elementen reichen 3 Bit pro Ziffer, bei 32 Elementen wären es 5 Bit pro Ziffer und so weiter. Hab ich in meinem Beispiel der Einfachheit halber mal nicht weiter berücksichtigt und auf 8 gesetzt.
    3. Byte: Anzahl der Elemente (hier: 10)


    Man kann also an Hand des ersten Bytes irgend ein Flag setzen, an Hand des zweiten Bytes sehen, wie viele Bits für ein Element verarbeitet werden müssen und an Hand des dritten Bytes wie viele Elemente es gibt.
    Nun schleift man also 3.Byte male 3*2.Byte Bits um daraus die Ziffern der drei Objekte Bild, xPosition und yPosition zu generieren.
    Vorher lässt sich natürlich ausrechnen, ob die Dateigröße gleich (3*3.Byte*2.Byte/8)+3Byte entspricht, um inhaltliche Fehler zu vermeiden.


    Oh, wie ich LowLevel liebe. ^^
    Natürlich kann es durchaus passieren, dass man mal mit unterschiedlichen ByteOrders arbeitet, dürfte allerdings mittlerweile echt sehr selten sein.
    Wichtig ist dabei nur, dass das verdammt gut dokumentiert ist. Sonst sieht da ja keine Sau mehr durch. ^^


    Zum Schluss zum Vergleich Binary vs. JSON vs. XML:

    C
    <nicht darstellbarer Steuerzeichensalat>


    (33 Byte für 10 Elemente zuzüglich Overhead)

    C
    [{I:1,X:0,Y:0}{I:1,X:0,Y:15}{I:1,X:1,Y:0}{I:1,X:1,Y:15}{I:1,X:2,Y:0}{I:1,X:2,Y:15}{I:1,X:3,Y:0}{I:1,X:3,Y:15}{I:1,X:4,Y:0}{I:1,X:4,Y:15}]


    (138 Byte für 10 Elemente zuzüglich Overhead)


    (598 Byte für 10 Elemente zuzüglich Overhead)


    Zitat

    iMac-LDV:~ ldv$ ls -lsah *tst
    8 -rwxr--r-- 1 ldv staff 33B 20 Mär 11:17 bintst
    8 -rw-r--r-- 1 ldv staff 138B 20 Mär 11:16 jsontst
    8 -rw-r--r-- 1 ldv staff 598B 20 Mär 11:18 xmltst

    Naja, du hättest die Ausgabe ruhig auf das Wesentliche zusammen kürzen können. ;)


    Ich vermute die Probleme hier:
    [quote03-19 14:34:18.641: W/UsbObserver(70): This kernel does not have USB configuration switch support
    03-19 14:34:18.652: E/UsbObserver(70): java.lang.NullPointerException
    03-19 14:34:18.652: E/UsbObserver(70): at com.android.server.UsbObserver.init(UsbObserver.java:131)
    03-19 14:34:18.652: E/UsbObserver(70): at com.android.server.UsbObserver.<init>(UsbObserver.java:65)
    03-19 14:34:18.652: E/UsbObserver(70): at com.android.server.ServerThread.run(SystemServer.java:402)[/quote]


    Davon ausgehend, dass UsbObserver deine Klasse ist.
    Die NullPointerException wird nach oben durchgereicht und ist dann schlussendlich der Grund dafür, warum deine Activity nicht starten mag.


    Testest du das auch einmal auf den Gerät?
    Denn offenbar klappt hier irgendwas nicht. Der Emulator hat eigentlich kaum eine Hardwareschnittstelle, die das Gerät bietet.

    Ja, eine Datei.
    Allerdings kann ja auch eine Textdatei mit deinem Inhalt eine Datei sein. ^^


    Die Idee, das Ganze als Text einzubinden, halte ich irgendwie für befremdlich.
    Deshalb wäre ich einfach für eine Datei. :)


    Ich hatte es ein paar Mal bei einigen Anwendungen, dass in dem Textfeld entweder das Kopieren oder das Einfügen deaktiviert war.
    Fand ich da ziemlich nervig, wird aber mit Sicherheit an den Anwendungen gelegen haben.

    Aha, du musst zu Schulungszwecken etwas programmieren und stehst dabei unter Zeitdruck? Da hat wohl wer das Prinzip von einer Schulung nicht verstanden.


    Wie dem auch sei, ohne komplette Logausgabe des Fehlers kann ich dir hier nicht helfen. ;)

    Ich persönlich mach das gar nicht, weil ich davon nix halte.
    Zumal du nie weißt, ob deine Nutzungsbedingungen nicht von den Bedingungen des Google Play Stores oder sonstiger Stores abweicht.


    Ansonsten würde ich eine eigene Activity mit den Nutzungsbedingungen machen und diese Activity beim ersten Start aufrufen, anschließend dann einfach nicht mehr zeigen. Das Flag stünde dann in den sharedPreferences.

    Open Source bedeutet, dass der Quelltext (Source) frei (open) zur Verfügung steht.
    Nachdem du also eine App erworben hast, bekommst du den komplette Quelltext und kannst beispielsweise daran Verbesserungen vornehmen oder davon lernen.
    In vielen Fällen sind die Open Source Anwendungen übrigens kostenlos.

    Die Frage ist natürlich, was du mit der Levelweitergabe bezweckst bzw. welche Informationen sie enthalten.
    Diese Art der Weitergabe ist natürlich simpelst manipulierbar. ;)
    Ich persönlich würde nichts davon halten, den Kram via Copy'n'Paste übergeben zu müssen, zumal man sich einfach nicht darauf verlassen kann, dass Copy'n'Paste wirklich immer und überall funktioniert.
    Da ich total auf Bitfelder und Ähnliches stehe würde ich eher für ein binäres Austauschformat plädieren. :)

    Moin,


    also ich denke, das 'erledigt'-Problem ist so ein Foren–Feature.
    Wenn 14 Tage keiner was geschrieben hat wird die Sache als ‚erledigt‘ markiert. ;)


    Die Frage ist, was sinnvoll ist. Ein Nutzer im Forum wird eher nach Schlagworten suchen, und wenn du alles in einen Thread klatscht kann es durchaus sein, dass dieselben Fragen später von Anderen wieder auftauchen.


    Zum Problem:
    Du hast zunächst einmal zwei Klassen mit identischem Namen, das geht so natürlich nicht.
    Woher soll Java denn wissen, ob du jetzt das Datepicker Main oder das Timepicker Main meinst?


    Diese Notation sagt eigentlich Folgendes aus:
    <Sichtbarkeit> class <Name> extends <Elternklasse> (implements <Interface>[,<Interface>,<Interface>...])
    Also deine öffentlich sichtbare Klasse Main erbt von Activity.


    Hier hast du nun schon mal zwei weitere Folgeprobleme.
    1) Du definierst zwei öffentlich sichtbare Klassen in einer Datei. Das ist unschön. Wenn jetzt jemand 'MainActivity' einbinden möchte, muss er wissen, dass diese in der Main.java liegt. Das wird er aber nicht wissen. Deshalb möchte das System, dass du es in eine eigene Datei packst.
    2) Jeder sichtbare Screen deiner App hat jeweils nur eine Activity. Um beide Elemente auf einem Screen zu zeigen, kannst du nicht einfach die Activity Klassen untereinander weg einfügen.
    Du musst vielmehr die anzeigerelevanten Elemente aus beiden Main heraussuchen und in die neue Activity passend einfügen.


    Hast du einmal die Android Trainings durchgearbeitet?

    Code
    03-15 08:58:57.624: E/AndroidRuntime(29460): Caused by: java.lang.NullPointerException
    03-15 08:58:57.624: E/AndroidRuntime(29460): 	at fb1907.de.SongList.QuitKlick(SongList.java:55)
    03-15 08:58:57.624: E/AndroidRuntime(29460): 	... 14 more


    Das dürfte ein Folgefehler des Memory-Problems sein: irgend etwas, dass in SongList.java Zeile 55 gebraucht wird, ist null.
    Vermutlich, weil kein Speicherplatz mehr zur Verfügung stand.


    Wie macht man sowas eigentlich mit der GC? Ich kann ja nix von Allein freigeben oder so.
    (Dinge, die ich nicht verstehe. ^^)


    Code
    public void QuitKlick(View v) {
    	if(mp.isPlaying() || mp != null) {
    		mp.stop();
    		mp.release();
    		mp = null;
    	}
    	this.finish();
    }


    Tausch' mal das Auftreten in der IF-Abfrage. Du fragst erst 'Spielt der MusicPlayer noch?' und dann 'Ist der MusicPlayer null?'.
    Was passiert, wenn der MusicPlayer null ist? Genau: NullPointerException.


    Die IF-Abfrage greift oftmals schon nach Überprüfung der ersten Option. Und das ist von links nach rechts. (Im Gegensatz zu Variablenzuweisungen, die ja von rechts nach links gehen.)
    Bei einer Und-Abfrage solltest du also zuerst auf != null prüfen und dann die Methode checken.


    Übrigens halte ich die Oder-Abfrage dort für falsch, es sollte eine Und-Abfrage sein.
    Denn wenn mp == null kann mp.isPlaying() ja niemals wahr sein. Ebenso wenig kannst du die Wiedergabe stoppen oder irgendwas releasen. Und null = null ist ebenfalls eine sinnlose Zuweisung.


    Mach daraus lieber ein

    Code
    public void QuitKlick(View v) 
    {
    	if(mp != null && mp.isPlaying())
    	{
    		mp.stop();
    		mp.release();
    		mp = null;
    	}
    	this.finish();
    }


    Wenn jetzt mp==null, kann diese Und-Abfrage niemals wahr sein und wird auch gar nicht weiter geprüft, es wird also sofort this.finisch() aufgerufen.

    Im Prinzip klingt so ein Service ja ganz toll.
    Mir fehlt da nur so ein bisschen die Transparenz des Ganzen.


    Also vor Allem die Kommunikation des Services mit meiner App erschließt sich mir noch nicht so ganz.
    Wenn ich mal ein wenig Zeit über habe versuche ich mal, ein bisschen Backgroundaktivität an einen eigenen Service zu übergeben.
    Mal sehen, wie das wird.


    Auf jeden Fall vielen Dank für das Stichwort! :)

    Moin,


    ich hätte da mal ne grundsätzliche Frage.
    Die von Apple haben in ihrer Entwicklergemeinde so lokale Gruppen mit regelmäßigen Treffen, das Ganze nennt sich ‚Cocoaheads‘.


    Mal ist es ein gemütliches Beisammensitzen bei nem Bierchen (also so stammtischmäßig), mal werden in Räumen Vorträge gehalten oder Gemeinschaftsprojektideen gesponnen.


    Gibt es eine ähnliche Gruppierung/ein ähnliches Angebot auch für Android?
    Vor Allem hier im Raum Hamburg wäre das perfekt. Man ist ja egoistisch. ^^


    Ich habe gesehen, dass killphil75 eine Art Stammtisch für den Bereich Sachsen geplant hat.


    Gibt es da echt nix halboffizielles Fertiges, oder bin ich nur zu doof zum Finden?