Beiträge von Marco Feltmann

Zitat von dee_

Hatte bisher i.wie immer nur eine Loop was natürlich auch nicht Sinn und Zweck der Sache ist.

Warum ist das nicht Sinn und Zweck der Sache?

Natürlich könntest Du die Aktion in einen Service auslagern.
Dann nimmst Du einen onTouch Listener und feuerst entsprechend Deinen Service.

// this goes somewhere in your class:
  button.setOnTouchListener(new OnTouchListener() {
     @Override
     public boolean onTouch(View v, MotionEvent event) {
        if(event.getAction() == MotionEvent.ACTION_DOWN) {
           calculationService.start();
        } else if (event.getAction() == MotionEvent.ACTION_UP) {
           calculationService.stop();
        }
        // Eventuell noch Dinge wie CANCEL oder UP_OUTSIDE berücksichtigen, sollte es diese Actions geben.
     }
  };

Ach ja, sollte Dir das mit dem Service zu kompliziert werden, kannst Du mit diesem Konstrukt auch einen flag setzen, der steuert ob Deine Aktionen in einer WHILE-Schleife durchgeführt werden.

Ich benutze immer den Quellcodeeditor statt des Texteditors, damit geht das mit dem Code eigentlich.

Zitat von Krehk

Java

Runnable runnable = new Runnable() {
        public void run() {
            int PORT = 11000;
            byte[] buf = new byte[1000];
            DatagramPacket dgp = new DatagramPacket(buf, buf.length);
            DatagramSocket sk;
            try {
                sk = new DatagramSocket(PORT);
                Log.d("Nachricht","  Läuft!");
                while (true) {
                    Log.d("Nachricht","  Läuft!");
                    try {
                        sk.receive(dgp);
                        String rcvd = new String(dgp.getData(), 0, dgp.getLength());
                        if(rcvd != null){
                            Log.d("Nachricht"," Empfangen!");
                        }
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
	    	}
            } catch (SocketException e) {
                e.printStackTrace();
            }
        }
    };

Alles anzeigen

Wenn ich die Sache richtig deute, dann wird Deine while-Schleife überhaupt nicht ausgeführt.
Theoretisch sollte es Dich zumindest mit "Nachricht" "Läuft!" zuballern.

An Deiner Stelle würde ich erst einmal diese ganzen Try-Catch-Blöcke rauswerfen. Du machst ja eh nix Sinnvolles mit den Exceptions, dann kannst Du es auch gleich ganz bleiben lassen…

Dann setzt Du Dir einen Breakpoint auf Deine Portzuweisung und steppst Dich Schritt für Schritt durch Deinen Code.
So dürftest Du ziemlich schnell sehen, wo das Ganze aussteigt.

Ohne ein CrashLog gleicht das Ganze der Suche der Nadel im Heuhaufen.
Eigentlich kannst Du nur versuchen sämtliche Fehlerfälle beim Speichern im Vorfeld zu verhindern.
(Oder Du wrappst das Ganze in einen Try-Catch-Block. Nicht schön, verhindert aber Abstürze)

Ich frage mich nur, wie du alle x Sekunden speicherst.
Wenn Du das in einer Schleife machst, solltest Du das Design überdenken. Denn dann bekommst Du sicherlich den Absturz, weil der Arbeitsspeicher irgendwann vollgelaufen ist.

Das ging ja zügig, danke.

Ein Bekannter von mir hat mal auf Mac OS X einen kompletten PDF Viewer selbst gebastelt.
Der Junge wusste was er tat und hat dafür ungefähr einen Monat (bei 10h/Tag, am Wochenende auch mal 12h) gebraucht.

Das Ganze ging wunderbar mit dem CoreText Framework, welches ziemlich nativ ziemlich viele Eingriffe erlaubte.
Haarsträubend und Kopfzerbrechend waren lediglich die PDF-Spezifikationen beziehungsweise deren Umsetzung.

Andere Bekannte haben (ebenfalls mit CoreText) einen Textprozessor für Mac OS X und iOS geschrieben und auf der Macoun 2012 ein paar schöne Stolpersteine präsentiert.

Für Android sehe ich keine Möglichkeiten ein von den Standardcontrols abweichendes Textsystem zu erstellen. Vielleicht suche ich aber auch nur falsch.

Wenn Du komplett freie Hand hast, nimm den Acrobat Reader.
Wenn Du Dinge selbst machen willst und ab KitKat entwickeln kannst, probier mal das PdfDocument und seine Subklassen aus. Eventuell macht das ja Spaß.

Wie dem auch sei: wenn Du ein innovatives neues PDF Textsystem entwickeln (und idealerweise auch als Open Source Library zur Verfügung stellen) willst, bin ich Dir sehr dankbar – oh, und rechne mit mindestens einem halben Jahr Arbeitsaufwand.

Ich glaube, Du solltest an Deinen Debugging-Skills arbeiten.

1) Setze einen Breakpoint auf die Zeile 'switch (item.getItemId())'
2) Starte den Debugger (entweder über den großen grünen Käfer -> Rebuild&Debug oder über das schwarze Gerät mit dem kleinen grünen Käfer -> Attach Debugger)
3) Wähle Deinen Menüeintrag
4) In der Debugging-Ansichst siehst Du beispielsweise, welchen Wert Du gerade abgreifst. Du kannst via Step Into und Step Over Zeile für Zeile das Programm weiter laufen lassen. Dann siehst Du auch, wo das Programm hin springt.
4) Du könntest item.getItemId() ein wenig optimieren indem Du es in eine Variable packst. Dann siehst Du auch den genauen Wert.

Meine Vermutung: Deine Methode wird nicht aufgerufen. In dem Fall dürfte Deine App nie stoppen und der Debugger nie an dem Breakpoint anhalten.

So liest sich das wie in 10 Stunden zusammengeklickt.

Doch was ist mit den Sonderfällen? Display zu klein -> Zoom im PDF muss möglich werden -> Scroll- und Swipehandling wie handhaben?
Hyperlinks -> wie verlassen?
Sollen immer nur ein PDF zur Zeit gezeigt werden oder soll aus einer Liste von PDFs gewählt werden können?

Du kannst da also auch locker 500 Stunden draus machen.
Die Frage ist halt wie komplex das Ganze am Ende wirklich sein soll und wie fix Du bist.

Moin,

es dauert gefühlt ewig, bis die Forenansicht oder Startseite geladen sind.

Wenn man den Entwicklertools des Browsers Glauben schenken kann, läuft ein Ad-Service nicht so ganz rund.

'http://ads.huetter-it.de/www/delivery/spcjs.php?id=1 : Zeitüberschreitung der Anforderung'

Wäre mal nett, wenn das behoben werden könnte.

Ich würde ungefähr da eingreifen:

// successfully captured the image

1) erst verkleinern, dann speichern. Dauert beim Schießen des Fotos ein wenig länger, reduziert aber die Zeiten beim Laden. Und da jedes Bild nur einmal geschossen aber mindestens zwei mal geladen wird dürfte klar sein, wo optimiert werden muss.
(Eventuell das Skalieren in einen Hintergrundprozess legen...)

2) Du hast irgend ein Google Nexus, oder? Meines Wissens die einzigen Geräte, die eine derartige Einschränkung besitzen.

3) Vielleicht hilft Dir dieses offizielle Training ein bisschen weiter.

Zitat von killphil75

Marco mag mich jetzt hauen, aber die Ableitung zu einer Activity geht nicht wirklich so...

Nein nein, Marco ist da vollkommen auf Deiner Seite.

Was sagt LogCat zu dem Absturz?

Ich glaube ja, er enthält uns nicht nur Teile des LogCat vor sondern auch Teile der .java – nämlich die Overrides der interessanten Methoden.

Zitat von Neven

View eTextUsername = inflater.inflate(R.id.editTextUsername, parent, true); // <---- HIER FEHLER

Das glaube ich gern und das dürfte auch in einer Activity nicht funktioniert haben.
Du übergibst dem Inflater die ID eines Views, dabei will der doch die ID eines Layouts.

Welche einführende Literatur nutzt Du?

Zitat von killphil75

Du brauchst einen Context, am besten beim Erschaffen deiner Klasse übergeben und speichern

Das Ding erbt von Activity und dürfte damit sein eigener Context sein.

Noch was: getSensorManager() kann null zurückliefern, wenn der entsprechende Sensor nicht gefunden wurde.
Leider ist Dein LogCat nicht informativ genug, man sieht nicht, was genau ihm nicht passt.

Hast Du im Manifest die <uses-feature> Werte entsprechend Deiner Sensoren eingetragen?
Link zur Dokumentation

Du wirst die Activities in Fragments umschreiben müssen.

Ich vermute, Du benutzt Windows.
In dem Fall musst Du den Treiber für Dein Nexus deinstallieren und aus dem SDK neu installieren.
Vergleiche Google für genauere Anleitungen.

Wie viele Ressourcen der Emulator benötigt hängt in erster Linie davon ab wie Du die AVD konfiguriert hast.

Klingt fein.

Meines Wissens dank fehlender Zeiger und Distributed Objects: nö, nur Broadcasts.