Beiträge von matthias

  • Syntax Fehler

    Mir fällt grad auf du bist ja in keiner Methode sondern direkt auf Klassenebene. Du musst das Setzen des Listeners in eine Methode packen. Wirf das mal ans Ende der onCreate, also das

    Code
    Button myCall = (Button) findViewById( R.id.button3);
myCall.setOnClickListener(EventHandler3); <--- Fehler

  • Syntax Fehler

    Hoi,


    Java ist case sensitive, deine Variable heißt "eventHandler3", einhängen tust du aber "EventHandler3", großes/kleines "e".
    Grundsätzlich gilt Klassen groß, Variablen klein und dann in der Kamelhöcker-Schreibweise weiter (MyClass myClass = new MyClass() ...)


    Gruß,
    matze

  • Zeitverzögerung ohne einfaches Warten

    Hoi,


    vll überseh ich ja den genialen Hintergedanke, aber warum genau hast du quasi ein Runnable in einem Runnable? So wie ich das grad seh sollte UIUpdater ganz klassisch von Thread erben und gut ist. Dann macht er ein Thread.sleep, das die Zeit die du warten willst dauert, rufst die sendMessage auf und lässt das Ding einfach aus laufen.


    Gruß,
    matze

  • Galerie performance

    Hoi,


    kleiner Nachtrag, hab das ganze jetzt an sich so weit durch, dass es offenbar nur noch an einer Stelle scheitert, und das ist dieser Schnipsel

    Code
    return BitmapFactory.decodeByteArray(blob, 0, blob.length);


    Man liest immer wieder, dass die BitmapFactory eigene VM Arguments für seinen verfügbaren RAM hat und dieser recht gering ist. Finde aber leider auch keinen anderen Weg, aus einem byte[] ein Bitmap zu bekommen. Hat da jemand eine Idee?


    Bei meinen weiteren Recherchen bin ich nun auf folgenden Artikel gestoßen
    http://developer.android.com/t…laying-bitmaps/index.html


    Und mir wirft sich die Frage auf, ob ich meinen über die SQLite Datenbank gehandelter Cache durch den im Artikel erwähnten LruCache ersetzen soll oder vielleicht auch miteinander kombinieren indem ich im SplashScreen den LruCache aus dem DB-Cache heraus aufbaue ... was meint ihr?


    Des weiteren werde ich noch genauer untersuchen, inwieweit ich meine Bitmaps off the UI Thread auf die dort empfohlene Weise handle. Ich benutze an sich bereits AsynkTasks dafür, im nachhinein, wenn der Executor es zu lässt, mein Bitmap zu verwursten und in die ImageView zu werfen. Allerdings handle ich nichts dergleichen, was deren AsyncDrawable betrifft. Werd ich gleich mal ausprobieren.


    Ich meld mich wieder ;)


    Gruß,
    matze



    EDIT:


    Glaub bin grad auf des Rätsels Lösung gestoßen. Hab als Minimum SDK 10 eingestellt und der Emulator steht auch auf 10. Mein Galaxy Nexus hat 4.2.2 also 17 oder so (egal, auf jeden Fall mehr xD) und irgendwo bei Honeycomb hat sich bissl was geändert bzgl. Bitmap umd ImageView. Vorher soll man für das Bitmap explizit ein recycle aufrufen, später ist es nicht mehr so wichtig. Hab mich jetzt mal im destroyItem meines ViewPagers bis zum Bitmap durch gewühlt und ein recycle aufgerufen. Und siehe da, der Emulator schmiert nicht mehr weg!


    Haut mich bitte nicht für den Code, es Funktioniert der Rest ist mir jetzt erstmal egal :D



    Gruß,
    matze


    EDIT 2:


    Ach ja, hab auch in meinem ViewPager die Zeile

    Java
    this.setOffscreenPageLimit(1);


    eingefügt, damit er sich nicht so viele Views aufhebt.




    EDIT 2:


    Ich setz diesen Thread hier mal auf erledigt. Hab mir heute das HTC Wildfire S einer Bekannten unter den Nagel gerissen und damit getestet. Auch in diversen verschieden eingestellten Emulatoren ging es dann stabil. Dreh und Angelpunkt ist der VM Heap, der bei älteren Geräten um 2.3.3 bei 16 MB liegt, später dann 24, 32 ... mein Galaxy Nexus hat meine ich 64MB.


    Wenn jemand tieferes Interesse an meinem jetzigen Code hat oder auch noch Fragen / Anmerkungen / Verbesserungsvorschläge bin ich auf jeden Fall sehr aufgeschlossen.


    Gruß,
    matze

  • Galerie performance

    Hoi,


    das Problem ist wohl, wenn man weiß was man setzen muss damit es nicht kracht, läuft das ganze womöglich. Nur könnte man auch einfach auf null abfragen und brauchbare Exceptions werfen oder wenigstens was ins Javadoc schreiben ... aber gut, hilft nicht, kost ja auch nichts.



    Hab mir für meinen Plan ein paar Dinge abschauen können, so übergebe ich z.B. beim setzen des Images die ImageView auch einfach mit und setze dann das Bitmap im nachhinein, wenn der AsyncTask so weit ist. Das hat den coolen effekt, dass wenn man auf die Bilder-Galerie klickt die nach und nach auf ploppen, gefällt mir eigentlich gut.


    Meinen OutOfMemoryError konnte ich etwas eingrenzen, ich dussel hab hier mal einen Cursor nicht geschlossen, dort mal ein Bitmap nicht recycled ... jetzt kann ich die Galerie betreten und auch ein paar Bilder in einer größeren Ansicht betrachten und dank ViewPager innerhalb der Kategorie nach links und rechts durch wischen. Jedoch nach dem 5 - 10. wischen kapituliert er wieder mit OutOfMemory. Glaub mein

    Code
    @Override
    public void destroyItem(View collection, int position, Object view) {
    	((GalleryView) collection).removeView((LinearLayout) view);
    }


    gibt die Resourcen im LinearLayout nicht direkt frei ... werde mal sehen ob ich irgendwie bis zu meiner ImageView und dessen Bitmap durch komm, um dort nochmal ein .recycle() aufzurufen.



    Generell habe ich das ganze jetzt so verwirklicht:
    In meinem SplashScreen stoße ich in meinem ImageLoader eine Methode an, die alle Images cachen soll, die nicht schon gecached wurden. Konkret frage ich ab, ob in meiner SQLite Tabelle hierzu bereits ein Blob vorliegt. Tut er das geht es weiter, tut er das nicht erzeuge ich mithilfe der BitmapFactory je nachdem ein Thumbnail oder die große Vorschau davon und speichere den Blob in die Datenbank. Danach recycle ich das Bitmap, da ich es gerade nicht mehr brauche, von hand.
    Gehe ich dann in der App auf die Galerie frage ich mit demselben ImageLoader nach dem Bitmap, der greift dann direkt in die Datenbank, holt sich das Blob und erstellt daraus ein Bitmap, das er der ImageView einpflanzt.



    Bin an sich noch etwas gemischter Gefühle, selbst wenn ich das ganze jetzt so zum laufen bekomme, was passiert wenn 100 Bilder dazu kommen .... muss leider sagen in iOS ist das ganze etwas unproblematischer irgendwie. Da weiß man halt einfach mit was für ner Hardware der User daher steigt und muss es nicht auspendeln ...



    Gruß,
    matze

  • Galerie performance

    Hoi,


    habe es jetzt soweit auf meinem Galaxy Nexus lauffähig, im Emulator schmiert er ab ...


    Diese Stelle

    Code
    BitmapFactory.Options options = new BitmapFactory.Options();
options = new BitmapFactory.Options();
options.inSampleSize = sampleSize;
options.inDither = false; 
options.inPreferQualityOverSpeed = false; 
options.inPurgeable = true;


Bitmap bitmap = BitmapFactory.decodeStream(is, null, options);


    Erzeugt folgende Fehlermeldung:


    Die Frage ist, wie umgehe ich das ... hab die Bilder in ein paar Auflösungen vorliegen aber entscheide je nach device width eh schon, welche am besten ist, damit es nicht zu pixelig wird.



    Gruß,
    matze

  • system.exit(0)

    Hoi,


    muss irgendwie immer daran denken, wie Ingress das macht ...


    Ich mach mein GPS an, der Kreis erscheint und ist nicht ausgefüllt, er sucht auch keinen Satelliten. Dann mach ich Ingress an und er fängt an zu suchen. Mache ich Ingress wieder aus ist der Kreis wieder leer, also er trennt die Verbindung, GPS selbst ist aber noch an.


    Dieses Verhalten wäre doch genau das, was man erwartet. Inwiefern unterscheidet sich das von deinem jetzigen Stand?



    Gruß,
    matze

  • system.exit(0)

    Hoi,


    das Blinken heißt er sucht noch, wennsn icht mehr Blinkt hat er endlich ne Verbindung und ne genaue Position. Den Datenstrom erhält er aber aufrecht, wüsste ja sonst nicht ob du dich bewegst.


    System.exit(0) ist rein aus Java, nicht Android. An sich ist bei Android nicht vorgesehen, die App vollständig zu beenden. Wenn du via Home-Button die App verlässt bleibt sie so lange im Hintergrund, bis das System entschieden hat "ich brauch jetzt RAM, die App schieß ich jetzt weg".


    Hab mit GPS selbst noch nichts gemacht deshalb dort keine Erfahrung, aber eine kurze Recherche nach "android intent gps search stop" hat ergeben, dass wohl dein

    Code
    this.mylocationManager.removeUpdates(myLocationListener);


    bereits ausreichen hätte müssen.



    Gruß,
    matze

  • Daten exportieren und Text Displayauflösung

    Hoi ,


    ich würde JSON benutzen, da es einfach zu handhaben ist und die Klassen JSONArray und JSONObject echt schnuffig gelungen sind. Benutzen kannst du das ganze sowohl mit einer Datei als auch mit einem String.


    Ich persönlich würde folgende Funktionen anbieten:
    - Versenden der Datei via E-Mail
    - Falls es unbedingt WhatsApp und co sein muss:
    - Informieren, ob Cloud Storage wie Google Drive oder Dropbox anzapfbar sind, so dass man die Datei dort hoch lädt und in WhatsApp und co nur den Link versendet.


    JSON als Klartext via WhatsApp versenden würde mich als Benutzer schon etwas arg verwundern ...



    Gruß,
    matze

  • Zusammmenspiel von static und onDestroy()

    Es sind LinearLayout.LayoutParams weil ichs ja in ein LinearLayout häng, und mein Handy frisst es auch und zeigt es an.
    Und nö, da ist kein Reiter Design. Hatte diesen Reiter auf den Screenshots auch entdeckt, aber der fehlt irgendwie .... Bei ner Auflösung von 1920x1080 wird er sich wohl auch kaum irgendwo im nicht sichtbaren Bereich verkrochen haben. seltsam seltsam

  • Zusammmenspiel von static und onDestroy()

    Njoa grundsätzlich sollte jeder das verwenden, das ihm taugt. Ich für meinen Teil will so wenig wie irgend möglich mit der nativen Mac Oberfläche in Berührung kommen, da das ganze eine Philosophie verfolgt, die ich nicht haben will. Deshalb fühlen sich diese "grausigen" Crossplattform-Tools wie ein stück "heimat" für mich an ^^
    Aber genug damit, wir müllen hier einen Thread zu, der damit nichts zu tun hat xD


    Er behauptet mein LinearLayout hat keine addView, die eine ImageView und LayoutParams schluckt, was so ja nicht wirklich richtig ist, denn unter Eclipse rennts.


    Grundsätzlich ist meine erste Tat auch vom grafischen auf den Text-Editor zu wechseln, da der grafische Editor von Eclipse nichts kann und vor allem nicht das tut was ich will. Aber hätte mal gern gewusst wie der Editor von IntelliJ so funzt. Wenn ich allerdings auf das XML klicke, geht nur der Text-Editor auf.

  • Zusammmenspiel von static und onDestroy()

    Zitat von Lucas de Vil

    wird ja niemand zu einer Hardware gezwungen. :P


    Privat hätte ich mir im leben nie ein Macbook gekauft, das hier ist mein Firmen-Laptop. Also doch, es gibt Menschen die mich zwingen xD


    Thunderbird ist mit 500 Spitzenreiter, dann Eclipse mit 380, Chrome (20 Tabs) 360, Dock 100MB und dann wirds unter 50mb. Wobei da noch ein paar Google Chrome Renderer rum wuseln. Unterm strich mir egal, soll sich Chrome halt 1-2GB ram nehmen, sind 8 da jede Linux Kiste hätte 6gb komplett frei ...


    Ich sehs aber auch nicht ein die Mac-spezifischen Programme zu benutzen. Da bekomm ich ja nen fön wenn ich mir Mac, Windows und Linux spezifisch Programme merken dürfte, jedes funktioniert anders, sieht anders aus und speichert seine Daten anders. Ich nehm lieber die Plattformübergreifenden Varianten für mein zeug. Da exportier ich z.B. meine FileZilla Bookmarks unter Mac und importier sie unter Xubuntu ohne Probleme
    Aber ja, ein Apple Jünger denkt nicht so ... bin Linux Fanboy ;)


    Unterm Strich: Ich hasse Mac, Mac hasst mich xD


    Zu IntelliJ:
    Da wird mit nem UI Designer geworben, der quasi unauffindbar ist. Weißt du wo sich der versteckt? Und er zeigt mir diverse Fehler an, die sich nicht nachvollziehen lassen ... bin mir nicht sicher ob ich für dieses Projekt nicht in den sauren Apfel beissen sollte und das noch unter Eclipse durch würge.

  • Zusammmenspiel von static und onDestroy()

    Danke für den Tipp mit IntelliJ Lucas, sehe ich mir mal an.


    OffTopic:


    Den Satz mit UNIX versteh ich nicht ganz ... wieso die Einschränkung auf UNIX, gilt doch eigentlich generell. Aber joa, bei Mac ist das besonders deutlich.


    Offene Programme:
    - Eclipse
    - Chrome


    Speicher:
    - Frei: 300mb
    - Reserviert: 1,25GB
    - Aktiv: 3,58GB
    - Inaktiv: 2,85GB
    - Swap: 650mb


    Öffne ich jetzt z.B. VirtualBox und starte eine VM die 2GB Ram will, gehen die 2GB nicht bei Inaktiv weg wie man vermutet, sondern auf Swap rauf xD unbeschreiblich wie sehr ich Mac hasse .... da steckt nen i7 drin und mein AMD Neo 2 mit 1,8ghz macht einige Dinge flotter

  • Galerie performance

    Kurzer Zwischenstand:


    Auf den ersten Blick macht dieser Android Universal Image Loader wesentlich mehr Probleme als er löst. Von sauberem Exception-Handling kann wohl kaum die rede sein :( aber so leicht gebe ich noch nicht auf


    EDIT:
    Nach ausführlichem Fluchen und wilden Beschimpfungen meinerseits zeigt er nun tatsächlich etwas an. Das Teil zerlegt es bei jeder Gelegenheit komplett mit einer NullPointerException mit der man überhaupt nichts anfangen kann. Debuggt man etwas im Source herum sieht man jedoch, dass man z.B. der ImageView, die man übergibt, LayoutParams verpassen muss, weil die ausgelesen und nicht auf null abgefragt werden (ohman). Lauter solche scherze und kleinkram der enormst auf die nerven geht ...
    Das ganze funktioniert nun beim ersten Aufruf, jedoch beim zweiten haut er mir OutOfMemoryExceptions um die Ohren. Ich vermute mal ich konnte ihm noch nicht begreiflich machen, dass er die Bilder zu cachen hat.


    Ich meld mich wieder ;)


    Edit 2:
    Ich gebs auf, das hat keinen Sinn. Da gibts die Option CacheOnDisc und beim Laden des Bildes schaut er nur im Memory nach ob es dort ist. Da bin ich besser beraten, wenn ich mir meinen eigenen Cache baue, da weiß ich wenigstens an welcher Stelle das Ding seine Schwächen hat.


    Danke für den Tipp killphil aber ich hab zu wenig Nerven für das Teil.

  • Zusammmenspiel von static und onDestroy()

    Hmm, kann sein dass ich dich dann irgendwie falsch rum verstanden hab :D
    In meinem Fall ist jedenfalls ausnahmslos immer Eclipse schuld ... entweder Eclipse verträgt sich nicht mit meinem super tollen (Vorsicht ironie) Macbook, oder Eclipse wird von Version zu Version schlechter.

  • funktioniert nur über USB Debug alles

    Hoi,


    hört sich für mich nach einem Threading-Problem an. Du sagst ihm jetzt explizit wie er sich bei Veränderungen verhalten soll, vorher hat er die Activity neu gestartet, laut Doc.
    Vermutlich hat das von Eclipse heraus gestartet nichts aus gemacht, weil er mit Logging oder auch dem debuggen beschäftigt war und die Activity wieder schnell genug verfügbar war, bis irgend ein Thread drauf zugegriffen hat.



    Gruß,
    matze

  • Zusammmenspiel von static und onDestroy()

    Hi,


    hab dieses Phänomen sehr oft. Ich ändere etwas, füge Debug Ausgaben hinzu, baue ein try catch um etwas und will rein debuggen, aber er überspringt an Stellen wo er weiter muss mehrere Zeilen Code (innerhalb eines IFs z.B., überspringt dann auch das else, den catch-Block und den finaly-Block (!!!) also er hat definitiv nicht überrissen, dass er neu zu builden hat)


    Das liegt an Eclipse.


    Eclipse hat bei mir und offenbar auch bei einigen anderen Benutzern so dermaßen einen Hau, dass es nicht mehr feierlich ist. Erschwerend muss ich unter Mac arbeiten, was dank super Speicherverwaltung dieser Möhre dann zu einer Katastrophe führt und sporadisch mal das Speichern oder Copy&Paste mittels Tastenkombi nicht mehr geht. Auch nützliche Features von Eclipse wie das markieren der stellen, wo die Variable die man an geklickt hat, noch vor kommt geht nur bei Vollmond am dritten Montag des Monats ist.


    Bei mir hat bisher immer funktioniert:
    Rechtsklick aufs Projekt -> Close Project
    Projekt wieder öffnen
    Linke Maustaste aufs Projekt, im Menü Project > Clean (ja ist irgendwie doppelt, aber der braucht das offenbar ....)


    Hat das nicht geholfen hilft für gewöhnlich ein Neustart von Eclipse.



    Hab die aktuelle Version von Indigo getestet und auch die neue Kepler 4.3M6. Letztere hat im Großen und ganzen die gleichen "Fehler", läuft dabei aber gefühlt doppelt so schnell.



    Also im großen und Ganzen vermute ich mal du hast deinen Code einfach so oft geändert bis Eclipse irgendwann überrissen hat hey der hat ja was verändert, da muss ich ja neu builden.



    Gruß,
    matze

  • Galerie performance

    Hmjoa, momentan isses etwas subptimal. Ich start beim Drücken auf den Menüpunkt einen Thread, der ne for-schleife durch rödelt und pro Durchlauf eine Kategorie zusammen baut. Im Prinzip wird nur eine ArrayList mit Beans dem Adapter der GridView übergeben, der dann in der View-Methode (hab den Code grad nich da, verzeiht dass mir der genaue Name der Methode nicht einfällt) eine ImageView zusammen baut und sich mittels einer Methode, die einen AsyncTask startet, entweder ein Bitmap aus dem assets-Ordner oder ein Bitmap von einer URL aus spuckt. Das werf ich dann in die ImageView und gibs zurück.


    Also im Endeffekt 1 Bild 1 AsyncTask. Aber halt nie mehrere AsyncTasks nebeneinander. mir fällt gerade auf wieso starte ich nicht pro Kategorie einen AsyncTask, werfe den aber in einen Pool, der maximal anz_cpus gleichzeitig ausführt .... hmmm, muss ich morgen mal testen ;)


    Danke Uwe.


    Werd ich morgen genauer experimentieren, was da am flüssigsten läuft. Leider hab ich nur das eine Galaxy Nexus zum testen da, *grml* (zwegs cpu prozis)

  • Galerie performance

    Hey Phil,


    hab Dank für den Link.
    Werd ich mich morgen mal schlau machen, wie mächtig das Teil ist. Hatte gerade schon angefangen mir eine Art eigene Resource-Verwaltung zu schreiben, hab aber eigentlich keine Zeit das in schön zu machen ;)


    Ich werde berichten, wie es mir damit erging ^^



    Gruß,
    matze