Beiträge von Marco Feltmann

    'Aktueller' Bug und Mac OS X 10.6.8 passt irgendwie nicht.
    10.6 ist 5 Jahre alt. ;)


    Keinerlei Probleme auf 10.9.5, alles bestens.


    Ich vermute, Dein Mac kann nicht höher als 10.6.8 aktualisiert werden, 10.7 steht ihm bereits nicht mehr zur Verfügung.
    Dasselbe Problem habe ich mit meinem alten MacBook (Plastikbomber).


    Hier ist die Lösung eigentlich recht simpel: 10.7 benötigt zwingend eine 64 Bit CPU, da es ein 64 Bit System ist.
    Dein Rechner hat aber nur eine 32 Bit CPU verbaut.
    (Falls nicht: Update auf 10.7 oder höher)


    Es ist jedenfalls nahezu unmöglich, auf einem 32 Bit Betriebssystem einen 64 Bit Emulator laufen zu lassen.
    Durch Abwarten wird sich dieses Problem vermutlich auch nicht lösen lassen.


    Da hilft nur, das Betriebssystem und gegebenenfalls die Hardware zu aktualisieren.
    (Hab den Hinweis auch in das Issue geschrieben.)

    Ich würde mal sagen, Du hast die Layouts verhaspelt.
    Der Drawerinhalt muss das erste Element der Layout Hierarchie sein, also das letzte Element in Deiner XML.
    Das letzte Element in Deiner XML ist aber Dein ListView.


    Tausch das, dann sollte das passen.

    Die Antwort gibt Dir Google:

    Zitat

    Before downloading the NDK, you should understand that the NDK will not benefit most apps. As a developer, you need to balance its benefits against its drawbacks. Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++.


    https://developer.android.com/tools/sdk/ndk/index.html


    Angry Bird ist in C++ geschrieben, nutzt OpenGL und OpenAL und wird für verschiedene Systeme gepflegt.
    Das Ding ist ein Schlachtschiff an Software und die Anforderung, den Kram in Java umschreiben zu müssen, wäre nicht zu schaffen.


    Zitat

    Typical good candidates for the NDK are CPU-intensive workloads such as game engines, signal processing, physics simulation, and so on. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.


    https://developer.android.com/tools/sdk/ndk/index.html


    Die Komplexität Deiner Anwendung wird um ein Vielfaches ansteigen, wenn Du in C/C++ programmierst.
    UI Design in C wird mindestens schwierig. Deine Komponenten werden eher nicht so aussehen und funktionieren, wie man es gewöhnt ist.
    Die Nutzung der C/C++ Funktionen zur Speicherverwaltung grätschen in gewissen Maße der Garbage Collection rein, niemand kann Dir also den Hintern retten, wenn Dein Code irgendwo Speicherfehler hat. (Und die wird er haben, verlass Dich drauf. ^^)


    Zusätzlich kostet der Wechsel von der Java Ebene zur nativen Ebene immer ein paar Ressourcen. Fällt nicht so auf, wenn man nur mal eben in die App rein und aus der App wieder raus springt. Wenn Du aber im nativen Bereich über JNI auf Java-Komponenten zugreifen willst, wird Deine hardwarenahe "schnelle" Anwendung plötzlich sehr sehr langsam. Langsamer als würdest Du das in reinem Java lösen.


    Der größte Kritikpunkt am NDK meiner Meinung nach: es bezieht sich auf sehr erfahrene Entwickler. Wie die Jungs, die Angry Bird entwickelt haben.
    Dementsprechend hast Du absolut KEINE Hilfen bezüglich der Dinge, die Du machen kannst – außer natürlich den C/C++ Header Dateien. Ohne Buch, dass Dich da ein bisschen ran führt, wirst Du sicherlich mehr Frust als Freude daran haben.

    Ja, bleib beim PC Scanner. +hihihi+


    Woher soll Deine Kamera wissen, ob sich da vor ihrer Linse etwas bewegt oder nicht?
    Mutmaßlich wird in dem Zeitraum, in dem Du das erste Dokument weggeschoben hast und kurz bevor Du das zweite Dokument hinschiebst, mindestens ein Foto vom leeren Schreibtisch gemacht – ziemlich unnötig.
    Davon abgesehen sind Fotos von Dokumenten immer so eine Sache. Ohne ordentliche Nachberechnung ist es mitunter unmöglich, auf den Dokumenten irgendwas zu erkennen, da der Autofokus der Kamera gern mal seinen eigenen Kopf hat und sich nicht immer korrekt auf das zu Grunde liegende Bild einstellt.


    Ich wüsste auch nicht, inwieweit man da mit dem Nahfeldsensor arbeiten kann. Einen wirklichen Bewegungssensor wird die Kamera allerdings in den seltensten Fällen haben.


    Du könntest Dir allerdings mal http://www.kofax.de ansehen, die bieten Lösungen, die so etwas in der Art können.
    Eventuell haben die auch Tipps für das Problem mit der Bewegung.
    Ist allerdings alles Andere als Open Source. ;)

    Kurze Antwort: gar nicht.
    Du übersiehst den entscheidenden Punkt: Der Sinn einer Webschnittstelle ist es, von überall erreichbar zu sein. Wenn also jemand den Request im Browser abschickt sieht er die Antwort.
    Works as intended.


    Welche Daten sollten so schützenswert sein, dass kein Anderer sie sehen darf?
    Wieso hast Du Benutzerdaten, wenn Deine Benutzer keine Loginmöglichkeiten haben?


    Die Verbindung selbst solltest Du via SSL absichern.


    Wie viel Ahnung hast Du von der Webentwicklung? Sobald die Benutzeranmeldung erfolgt, sichert sich der Server eine Session. Diese Session wird mit dem Nutzer starr verknüpft. So kann jeder Nutzer nur seine Daten.


    Gegenfrage: wenn Du in Deiner App Server-IP, Datenbanknutzer und Datenbankkennwort integrierst und sich Apps ja gern 'reverse engineeren' lassen, wie kannst Du dann sicher stellen, dass nur Deine App die Anfragen an die Datenbank stellt?

    Ein bisschen wenig Info, die genaue Fehlermeldung wäre hilfreich.


    Eventuell findet die neu instanziierte Activity die Ressourcen nicht, welche Du in den Inflater steckst.


    PS: Der Emulator ist nicht repräsentativ wie ein richtiges Gerät.
    Wenn es im Emulator läuft, ist es noch kein Garant dafür, dass es auf einem richtigen Gerät ebenfalls läuft.
    Allerdings: wenn es im Emulator nicht läuft, ist es ein Garant dafür, dass es auf einem richtigen Gerät ebenfalls nicht läuft. ;)

    Ganz korrekt wäre es mit dem Target-Action-Paradigma.
    Ich klicke drauf, und dann wird auf dem Target 'Activity' die Action 'ButtonPressed' ausgeführt.
    So wie es der OnClick-Eintrag im XML UI macht.


    Die Abhängigkeit ein Objekt an die Methode zu übergeben ist meiner Meinung nach totaler Bullshit.


    Ich benötige da ja eine Funktion, die irgend etwas tut. Daten darstellen, Fragmente einblenden, Activities wechseln, Verbindungen herstellen, pipapo.
    Was macht also jede halbwegs intelligente Programmiersprache? Funktionszeiger. Closure. Block. Irgendsowas.
    Irgendwas, das die Implementierung aufrufen kann, wenn das gekoppelte Ereignis eintritt.


    Java möchte dafür ein eigenes Objekt. Ein Objekt, das nur die eine Aufgabe hat, den Klick zu verarbeiten. Und dafür dann mindestens eine weitere Abhängigkeit benötigt. Warum ist das Bullshit?


    Für die eine einzige Aufgabe 'Klick verarbeiten' werden mehrere unterschiedliche Objekte benutzt. Sie sind zwar im Detail unterschiedlich implementiert, aber Implementierungsdetail dürfte in dem Fall keine Rolle spielen. Ein 'HandleOnClick' Objekt sollte immer einen OnClick handeln. Warum gibt es dann mehrere 'HandleOnClick' Objekte? Die OnClicks müssen unterschiedlich gehandelt werden.


    Du argumentierst, dass es nahezu unmöglich ist, dass ein OnClick dasselbe machen soll wie ein anderes OnClick. Weiterhin argumentierst Du, dass das OnClick viele Abhängigkeiten zur implementierenden Klasse hat.
    Damit argumentierst Du ganz eindeutig gegen die Nutzung eines eigenen Objektes für die Implementierung des OnClickListeners.


    Im Prinzip argumentierst Du also für die Nutzung des onClick Parameters in der XML als Äquivalent zum Funktionszeiger.

    Bei diesem Projekt hilft Raten leider überhaupt nicht, da muss man sich ransetzen und rumprobieren.
    Beziehungsweise in erster Zeit vermutlich ewig viel lesen…


    Ich meine, dass sich eine kleine Walkie-Talkie-App zur Kommunikation mit mehreren Leuten auch via Voice Over IP / SIP realisieren ließe.
    Es muss halt lediglich eine Datenverbindung bestehen, was sie aber in den meisten Gegenden ja tut.

    Ein WebView stellt den empfangenen HTML Quelltext graphisch dar. Da wird nicht drin rumgeschrieben.


    Dein Beispiel kannst Du auf zwei Arten realisieren.
    (Bestimmt noch mehr, mir fallen aber nur die beiden Arten ein.)

    • Du baust die Suche einfach an den Query String ran und rufst die Seite noch einmal auf.
      Beispiele:
      https://www.google.de/#q=android+webview (Mit ausgelöster Suche)
      https://www.google.de/?q=android+webview (Nur die Eingabe ins Suchfeld eingegeben)
    • Wenn das nur ein Beispiel war und Du wirklich in den Tiefen der Website rumfummeln möchtest, musst Du Deinem WebView ein paar JavaScripts unterjubeln, die dann das machen, was Du mit dem Button realisieren möchtest.

    Das hängt immer vom gewählten Ansatz ab.
    Normalerweise werden die Fragmente zerstört, sobald sie den Bildschirm verlassen und werden dann dementsprechend neu erstellt, wenn sie wieder dargestellt werden. Das gehört zum Fragment Lifecycle, der auch auf den Seiten von http://developer.android.com gut dokumentiert ist.


    Allerdings gibt es Implementierungen, die mehrere Fragmente vorhalten. Der ViewPager beispielsweise hat immer das aktuelle Fragment im Speicher, ebenso das (sofern vorhanden) davor liegende und das (sofern vorhanden) dahinter befindliche Fragment. Zu Spitzenzeiten hält es also drei Fragmente aktiv.
    Wenn Du zwei Fragmente in einen ViewPager stopfst, dürften sie theoretisch nie zerstört werden.


    Allerdings kann ich mir nicht vorstellen, dass Du das wirklich willst. ;)
    Sinnvoller ist es aber, die Neuerstellung der Fragmente möglichst fix geschehen zu lassen.