Beiträge von Marco Feltmann

Mit Gaming habe ich mich noch überhaupt nicht beschäftigt.
Allerdings sieht mir dieses Tutorial ganz gut gemacht aus. Vielleicht hilft es Dir ja.

Meist liefert LogCat aber noch mehr als nur NullPointerException. Im Allgemeinen liefert es noch einen StackTrace mit.

Hängt vom verwendeten Framework ab und dem Ziel, das Du erreichen möchtest.

Mit normaler UI würde ich auf die onTouchEvent des Pfeils entsprechend überschreiben, dass bei MotionEvent.ACTION_DOWN die Bewegung passiert, bei MotionEvent.ACTION_UP, MotionEvent.ACTION_CANCEL und MotionEvent.ACTION_OUTSIDE die Bewegung wieder stoppt.

Sollte das Ganze ein Spiel werden, würde ich allerdings davon Abstand nehmen es mit UI-Elementen zu machen und statt dessen OpenGL lernen.

Was genau sagt LogCat zu dem Thema?

NestedFragments mag Android meines Wissens nach nicht allzu gern. Da hatte ich schon Probleme mit, wenn ich im XML ein Fragment definiert hatte und dieses dann das Google Maps Fragment beinhaltete. Gab beim Wechsel gern lustige Probleme nach dem Motto 'Ein Fragment mit dieser ID oder diesem Parent existiert bereits."

In dem Zusammenhang war die StackOverflow der Auffassung, man solle auf jeden Fall die Fragmente über einen FragmentManager in den Fragmenten vernesteln statt alles über den applikationsweiten FragmentManager managen zu lassen.

Eventuell musst Du also dein ContentFragment so implementieren, dass es seinen eigenen FragmentManager hat (eventuell reicht seine eigene Instanz) und dort dann den Austausch des DetailFragments vornehmen.

Gern.

Windows und Ubuntu auf Kommandozeile benutzen und mal eben die Firmware umflashen wollen und nicht einmal die wichtigsten Befehle kennen?

cd C:\Users\Computer\AppData\Local\Android\android-sdk\platform-tools

Nicht anders, komplett.

Hab noch einmal genau nachgeschaut, Du befindest Dich unter C:\Users\Computer.
Da gibt es die Dateien natürlich gar nicht.

Du solltest also in das platform-tools Verzeichnis wechseln (via cd) oder die Dateien nach C:\Users\Computer verschieben.

Moin,

also zunächst mal scheinen die Fehlermeldungen doch eindeutig.

'cannot open bootloader-grouper-4.23.img' bedeutet offenbar, dass er die Datei bootloader-grouper-4.23.img nicht öffnen kann. Vermutlich fehlt sie?
'error: failed to load image-nakasi-kot49h.zip : no such file or directory' bedeutet ebenfalls, dass die Datei image-nakasi-kot49h.zip nicht geladen werden konnte. Offenbar wurde sie schlicht nicht gefunden.

Du befindest Dich mit Deiner Shell im Platform Tools Ordner des Android SDK.
Die Pfadangaben scheinen also überein zu stimmen.

Dennoch würde ich erst einmal ausprobieren den kompletten Pfad zur Datei anzugeben.

Ich würde immer zuerst bei Android selbst schauen.

Zunächst mal die konzeptionelle Theorie:
http://developer.android.com/guide/components/fragments.html

Dann das erste simple Tutorial zur UI-Erstellung mit Fragmenten:
http://developer.android.com/t…sics/fragments/index.html

Und schlussendlich das Nutzen gleicher Fragmente in unterschiedlichen Activities, hier am Beispiel Phone vs. Tablet:
http://developer.android.com/g…tablets-and-handsets.html

Viel zu lesen, viel zu verstehen, sehr detailliert und das Ganze zu verstehen, zu verinnerlichen und damit herumzuprobieren dauert sicherlich zwei bis drei Stunden.
Aber dann hast Du's wirklich drauf.

Wenn Du Dir mal ein paar Android 4+ Apps anschaust, wirst Du sehen, dass bei einem LongClick die Ansicht wechselt. Das ListView bekommt dann eben jenen MultiSelection Mode, eine Grafik, die den Selektionsstatus anzeigt und eine angepasste Toolbar beispielsweise mit einem Mülleimer.

Zur Implementierung des Ganzen gibt es einige Google I/O Videos.

Nein, die gesamte LogCat Ausgabe… (Mit Filter auf Error)

Wie gesagt fehlen die Angaben aus dem LogCat. Wie gesagt ist Dein JSON vermutlich leer. Wie gesagt liegt das am PHP Script.

Mir reicht die Qualität von ScreenRecord eigentlich.
Zumal ich die Dinger eh nur in 640x480 aufnehme. Wird ja ausschließlich online publiziert und von daher ist Full HD da auch ein bisschen übertrieben.

Gut wäre zu wissen, ob das im LoginUser oder im RegisterUser passiert.
Fakt ist, dass Du ein leeres JSON zurück bekommst.

Wenn es ohne Session klappte, wird wohl storeSession auf der PHP-Seite fehlschlagen.

Wenn es nur gegen den normalen Benutzer geht, versuch das Archiv einfach nicht .zip zu nennen sondern die Dateiendung wegzulassen.
Wenn es gegen etwas erfahrenere Benutzer geht, nimm ein anderes Archivierungsformat als zip und lass die Dateiendung weg.

1) Viel Spaß dabei. Packst Du die Videos in den Resources Ordner, liegen sie im .apk vor. Da es sich dabei nur um eine erweiterte .zip Datei handelt, hat jeder Hans und Franz sofortigen Zugriff auf die Videos, sofern er an das .apk ran kommt. Ich kann mir vorstellen, dass das nicht gewollt ist.
Ich kann mir aber nicht vorstellen, dass sich das umgehen lässt. Das ist übrigens bei dem .ipa von iOS auch nicht großartig anders.

2) Und selbst wenn wäre Streaming ziemlich blöd, da Streamen technisch nichts großartig Anderes ist als ein Download. Wenn also jemand die URL zu den Videos hat (welche sich auf einem gerooteten Gerät via Netzwerksniffer sehr sehr zügig herausfinden lässt) und über einen 'speziellen' Streamer laufen lässt (curl mit dem -o Flag zum Beispiel), landet das Video auf deren Platte und vielleicht wenig später auch auf Youtube.

Also ganz generell ist die Anforderung überhaupt nicht erfüllbar.
Sag mir, wie die iOS App heißt, und ich besorg Dir höchst wahrscheinlich die Videos daraus.

Mir fällt nur eine einzige wirklich sinnvolle Lösung, ein Video ausschließlich und nur für die App zur Verfügung zu stellen. Eigenes Videoformat ausdenken, programmieren und einen eigenen Player implementieren. Wird allerdings ein bisschen mehr Aufwand mit der Komprimierung der Daten und so weiter.

Wie gesagt, die von Dir aufgelisteten Anforderungen sind (nach meinem Kenntnisstand) nicht erfüllbar.
Mit einem Hinweis auf die iOS Variante schaue ich gerne nach, ob (und ggf. wie) der iOS Entwickler versucht hat das Ganze hinzubekommen.

Ich würde vermutlich ein von Android unterstütztes aber nicht allzu gängiges Komprimierungsverfahren nutzen (rar vielleicht) und die gepackte Datei einfach movies (ohne Dateiänderung) nennen. Der durchschnittliche Dieb wird den Braten der komprimierten Datei riechen und es in .zip umbenennen – und sicherlich scheitern.
Sobald natürlich jemand in den Header schaut, hat sich das auch erledigt.

Und mit Technologien wie einer Videokamera lässt sich auch das ganz einfach umgehen…

Fazit: Willkommen in der digitalen Welt. Wer will, kommt an alle Daten ran.

Entsprechenden OnItemClickListener implementieren.

That's Java…

Die Leute waren wohl der Meinung es sei total toll, wenn jede Activity selbst ihren DatePicker konfigurieren kann oder muss.

Ganz verstehe ich Dein Problem im speziellen Fall des DatePicker jedoch nicht.
Das Ding kommt doch vorkonfiguriert hoch. Entweder als DatePicker in Deinem eigenen Layout oder als DatePickerDialog über Dein aktuelles Layout.

Im Übrigen ist das auch der von Android vorgeschlagene Weg:
pack Dein eigenes Control in diesem Fall in einen eigenen Dialog und ruf nur diesen Dialog auf, wann immer Du Dein Control brauchst.

Der Inhalt des Fensters 'LogCat' wäre hilfreich.
Mutmaßlich hast Du irgendwo eine NullPointerException.

Indem Du etwas Grundlegendes liest.

Dann wird Dir auffallen, dass Du nicht einfach ein layout (touchanddrag.xml) übergeben kannst, sondern eine ID für eine View angeben musst.
Das betreffende View (meinetwegen auch das umschließende Layout) müsste ein 'android:id="@+id/irgendeineId"' haben.
Dementsprechend übergibst Du statt R.layout.touchanddrag ein R.id.irgendeineId.

Es ist schon recht auffällig, dass R.id.xxx auf IDs verzweigt während R.layout.xxx ein Layout meint. Spannenderweise zieht sich das wie ein roter Faden durch die Android Entwicklung.
R.string.xxx meint beispielsweise… <Trommelwirbel> einen String! Und R.drawable.xxx? Richtig.