Beiträge von Marco Feltmann

Dann zeig doch mal Deinen bisherigen Code für das PDF-Anzeigefragment.
(Das hast Du hoffentlich in eine eigene .java Datei gepackt.)

Oh, und bitte setz es in die [code=java] Code Tags, dann kann man es auch lesen.

Nein. Das gibt es in der IDE. Müsste je nach IDE 'Log', 'LogCat', 'Android' oder so heißen.
Müsste je nach IDE automatisch auftauchen.
Müsste bei einem 'leider beendet' ne Menge roten Text beinhalten.

Dafür hast Du schon den vollkommen falschen Ansatz gewählt.
Activities sind so alt und von Nachteilen behaftet, dass man sie einfach wo es geht wegfallen lassen sollte.

Genau das macht Android Studio. Anstatt mit Activities herumzufrickeln nutzt es Fragments.
Fragments sind so etwas Ähnliches wie Activities, nur dass sie nicht allein existieren können. Dafür kannst Du aber ein und dasselbe Fragment an unterschiedlichen Stellen in der App problemlos weiter benutzen. Und deine Navigation kannst Du auch an einer Stelle vorhalten und brauchst sie nicht Activity-übergreifend gestalten. (Das macht echt keinen Spaß.)

Bei dem Beispielprojekt kannst Du ja schon sehen, wie das mit den Fragments geht.
Es wird ein DummyFragment erstellt, sobald Du auf einen Eintrag in der Liste tippst.
Die Position des Eintrags wird vor der Erstellung an das DummyFragment übergeben und das DummyFragment richtet dementsprechend dann sein Textfeld ein.

Du siehst also nicht einfach nur 'eine Zahl', sondern immer die Position des gewählten Eintrags deiner Navigationsliste.
Wenn Du jetzt also in Deinem Fragment ein PDF anzeigen willst, kannst Du an Hand der internen Datenstruktur beispielsweise herausfinden, wie der Dateiname zum PDF an der berührten Position der Liste ist und kannst diese dann an das Fragment übergeben.

Das Fragment braucht dann nur noch das PDF hinter dem übergebenen Dateinamen öffnen und anzeigen.

Insofern mein Tipp: lies Dich in Fragments ein.

Welche Meldungen stehen im Log, nachdem sich die App 'leider beendet' hat?

Moin,

da hast Du aber mal ein schönes Sample gepostet. Vom aktuellen Android Studio, nehme ich an.

Zitat von DreiPunktVier

Was muss ich ändern?

Och, so ziemlich alles ab

@Override
public boolean onNavigationItemSelected(int position, long id) {

Welche Dokumentationen/Bücher/Videos nutzt Du zum Lernen?
Was hast Du bisher versucht um Dein Ziel zu erreichen?

Direkt nach dem automatisch generierten Samplecode um Hilfe zu fragen ist ähnlich produktiv wie direkt nach dem Auspacken des IKEA Schrankes die Hotline anzurufen.

Dann verstehe ich nicht ganz, warum Du das nicht mit diesem ISO versuchst.
Ich glaube aber auch mich zu erinnern, dass iOS7 erst mit Mountain Lion (also 10.8) unterstützt wurde.

Und Du hast vermutlich schon getestet, ob dieses ISO bootbar ist...

Ach ja, die Geschichte mit dem nicht mehr bootbaren Medium. Ich vergaß, das ist ja auch noch ne andere Baustelle bei mir. +seufz+

Definiere 'legale Version von Lion'. Meines Wissens wurde seit 10.7 nur noch über den App Store das aktuelle Betriebssystem vertrieben und Installationsmedien gab es gar keine mehr.

Vielleicht kannst Du die Infos aus folgendem HowTo ja gewinnbringend anwenden:
http://www.macbreaker.com/2012…tain-lion-virtualbox.html

1) Das hängt von der Zielplatform ab. Du müsstest schon wissen, wie PhoneGap genau arbeitet.
Du erstellst deinen HTML+CSS+JavaScript Krams mit Deiner bevorzugten IDE für HTML+CSS+JavaScript Krams.
In meiner WebDevelopment Zeit habe ich gern Komodo IDE dafür verwendet. IntelliJs WebStorm dürfte auch gehen.
Du erstellst ein Grundprojekt über das Command Line Tool 'cordova' von PhoneGap und machst ein minimales Setup, damit Du die Programme im Anschluss auch ausführen kannst.

Im Prinzip baut Dir das Ganze dann einen kleinen HTML-Server zusammen und Du zimmerst die anzuzeigende Website.

Problem: für jede Platform benötigst Du das entsprechende SDK. Also meinetwegen das Android SDK für Android (Cross Platform), das Blackberry WebSDK für Blackberry < 10 (Windows/Mac OS X), das Blackberry Native SDK für Blackberry 10 (Cross Platform), das Windows Phone SDK für Windows Phone (Windows) und dementsprechend das iOS SDK für iOS (Mac OS X)

Dein Plan wird also schon an der Hardware scheitern.

2) Nö. Erstens wird da nix auf Klick sondern alles per Command Line Interface in die Wege geleitet. Zweitens kannst Du wegen des fehlenden SDKs und Simulators weder für iOS bauen noch auf dem Simulator testen. Zumal man iOS Geschichten immer auf dem Gerät testen sollte – der Simulator emuliert nämlich nicht, wie er es bei Android tut: er simuliert.

3) Ich wüsste nicht, dass es irgend einen Cross Platform Frameworkkrams gibt, der ohne das Mac OS X auskommt. Du brauchst das SDK beziehungsweise die Frameworks zum Entwickeln, Du brauchst den angepassten LLVM zum Compilieren.

Ich würde die Finger davon lassen.
Hab zwei Apps getestet, die via PhoneGap erstellt wurden. Sie sind sowohl auf dem nicht so ganz aktuellen Android Gerät als auch auf dem iPod Touch 4G arschlahm. Und einige Teile funktionieren nicht einmal. Das Look&Feel passt ebenfalls nicht. Dabei tun die Apps nichts weiter als irgendwo Daten anzuzeigen.

Generell tust Du eigentlich besser daran, vor Allem simple Projekte für beide Systeme nativ zu entwickeln.
Buttons, Listen und Webviews sind jetzt kein Hexenwerk.

So oder so, um ein laufendes Mac OS X kommst Du nicht umhin, wenn Du für iOS entwickeln willst.
(Und in dem Fall kannst Du es auch gleich richtig machen.)

Oh, spannend. Spannend, spannend, spannend.
Aber auch: Ui, kompliziert.

Den ungefähren Ablauf habe ich so verstanden:
Du bekommst Briefe. Du startest Deine Smartphone App. Du fotografierst alle Briefe ab. Dann lädst Du diese Fotos auf einen Server. Danach sollen die Fotos vom Smartphone verschwunden sein.

Allein damit wirst Du schon gut zu tun haben.

1) Ich nehme an Du fragst nach einer Lösung für den lokalen Speicher auf dem Gerät. Da würde ich komplett von Persistenz absehen. Also keine Datenbank.
Für mich sehe ich da zwei Möglichkeiten: du legst irgendwo (auf der SD Karte?) einen Übertragungsordner an. Hierhin verschiebst Du alle gemachten Bilder. Dann lädst Du alle Bilder in dem Ordner hoch. Jedes hoch geladene Bild löscht Du.
Möglichkeit zwei: Du belässt die Photos im Bilderordner. Deine App merkt die Dateinamen und überträgt dann diese Dateien. Anschließend löscht Deine App die gemerkten Bilder.

Nirgendwo auf Deinem Gerät wird irgendwo festgehalten, welche Dateien Du wann wo hin kopiert hast. Um eine doppelte Datenhaltung solltest Du Dir auf der Endgerätseite also keine Gedanken machen.

Auf der Serverseite bin ich mir nicht sicher, ob Du da eine Datenbank brauchst. Generell würde ich aber nur Dateipfade und keine Dateien in die Datenbank packen. Nicht wegen der Performance der Internetverbindung. Wenn die nix taugt ist es egal ob die Daten aus einer Datenbank oder einer Festplatte kommen.

Nur müllt Dir die Datenbank irgendwann zu. Weiter gegen eine Datenbank spricht das synchron halten. Wann immer Du eine Datei entfernst (beispielsweise willst Du Rechnungen nach 5 Jahren loswerden), musst Du diese Änderung in die Datenbank mit einbringen. Das halte ich für schwierig.

2) Ob das Verschlüsselungsverfahren so zu realisieren ist bezweifle ich stark. Du wärst meines Wissens am Besten mit einer durch eine Mischung aus Zertifikaten und Public Key/Private Key geschützten Verbindung bedient. Das Zertifikat Deines Servers kannst Du ja einmalig erstellen, die Schlüsselzuordnungen sollten allerdings pro Gerät erstellt werden. Weiterhin musst Du einen Weg finden, wie Du die Schlüssel synchron halten kannst, da Du sonst im schlimmsten Fall nur die Hälfte der Daten mit dem Smartphone und die andere Hälfte mit dem PC lesen kannst.

3) Sobald jemand in Deinem Datenstream steckt, ist es egal, was Deine Datenbank sagt wie die Datei heißt. Sobald jemand in Deiner Datenbank den Dateinamen lesen kann, hast Du ein gewaltiges Problem. Nicht weil er den Dateinamen lesen kann. Sondern weil er in Deiner Datenbank ist.
Sobald jemand auf deinen WebDAV Speicher gelangt, sind die Daten erst einmal potenziell gefährdet.
Ohne SSL-verschlüsselten Zugriff solltest Du keinesfalls mit dem WebDAV kommunizieren. Ob Du die Datei dann via HTTPS, angepassten MIME-Type und ein bisschen unentdecktem Voodoo an das Smartphone auslieferst oder direkt über SFTP oder WebDAV/SSL dürfte erst einmal egal sein – sie dürfte eh keinen erkennbaren Namen haben. Das 'wie' ist also zweitrangig.

Viel interessanter ist da die Frage, wie Du die Daten organisieren möchtest.
Das Problem mit der Papierkramschlamperei wird nämlich leider nur auf eine andere Metaebene getragen.
Wie erkennst Du deine Rechnungen? Wonach sortierst/kategorisierst Du sie? Wie legst Du deine Bezügemitteilungen ab? Was passiert mit privater Korrespondenz? Wie findest Du effizient und schnell die Mobilfunkrechnungen der letzten 12 Monate für die Steuerabrechung? Wo genau hattest Du noch mal deine Steueridentifikationsnummer gespeichert?

Natürlich kann ich Deine Sorge mit NSA und Co teilen. (Als ob BND [04/1956] und MAD [01/1956] jetzt sooo eine Neurung wären…)
Andererseits würde ich vermuten, dass ein ordentlich via SSL gesicherter Server mit Public/Private Key Zertifikaten (anstelle von Username:Passwort) durchaus ausreichend ist. (Und falls nicht liegt das Hauptproblem genau da.)

An deiner Stelle würde ich erst einmal eines der offenen Dokument Management Systeme testen und schauen, ob Deine Papierkramschlamperei damit weniger wird. Denn vermutlich wirst Du auf Grund der Erstellung des Ganzen mindestens ein halbes Jahr nicht dazu kommen, Deinen Papierkram gewuppt zu bekommen.

Moin!

Schon an Hand Deines ersten Satzes stelle ich fest: unser Humor scheint kompatibel.

Ich persönlich bin ja erst beim 386er eingestiegen (der C64 davor zählt nicht...) und hätte nicht gedacht, dass ich einmal die Turbo-Taste vermissen würde.
Was die unzähligen Betriebssysteme angeht: ja, das kommt mir bekannt vor. Irgendwann erkennt man: every OS sucks.
Allerdings lernt man sich mit den Macken 'seines' Betriebssystems zu arrangieren.

Wie jedem ernsthaften Einsteiger empfehle ich auch dir das Buch Java von Kopf bis Fuß aus dem O'Reilly Verlag.
Anders als andere Fachbücher nutzt die 'Kopf bis Fuß' Reihe etliche Möglichkeiten die graue Masse anzuregen. Da stumpfes Lesen und Behalten so ab dem gefühlten 25. Lebensjahr versagt finde ich die modernen Ansätze durchaus hilfreich.

Wenn das Geld ausreicht und Du noch vorher einsteigen möchtest sei Dir weiterhin Programmierung von Kopf bis Fuß ans Herz gelegt.
Die Beispiele sind nicht in Java sondern Python geschrieben, doch das dürfte kein Problem sein. Sie illustrieren ja nur Dinge.

Wenn weitere Infos über den Stil der Bücher und ein Vergleich zu herkömmlicher Literatur gewünscht ist: Struktureller Vergleich zweier Lehrbücher zum Programmieren in Java in didaktischer Perspektive, Timotheus Haeck, 06/2012

Wann immer Du Fragen haben solltest: ich helfe gern.

Implementierungsdetail.
Du musst Dir doch irgendwo/irgendwie/irgendwann vorhalten, welche Nachrichten bereits gelesen wurden.
Also vorhalten im Sinne von 'über den App-Neustart hinaus'.
Vor Allem, wenn die Nachrichten via Push Notification kommen, musst Du sie ja irgendwo persistieren – ansonsten sind sie ja mit Beenden der App verschwunden.

Es liest sich so, als würde mit Eintreten in die Übersicht dieser Wert aus dem XML gelesen und dort nicht verändert – egal was Du in der Detailansicht machst.

Ich sehe da auf Anhieb zwei Möglichkeiten.
1) Du sicherst Dir die IDs aller gelesenen Einträge, beispielsweise in eine Datenbank. Dann errechnest Du die Anzahl ungelesener Nachrichten, indem Du sämtliche Nachrichten-IDs mit denen in der Datenbank vergleichst. Taucht nicht auf = ungelesen.
2) Du sicherst Dir die kompletten Einträge, beispielsweise in eine Datenbank. Beim Import setzt Du einen Flag 'Gelesen' auf 'false' und sobald der Eintrag gelesen wurde, setzt Du ihn auf 'true'. Dann kannst Du die Anzahl der ungelesenen Datensätze mit einer Query 'select count() where gelesen = false' abfragen.
Vermutlich gibt es noch mehr.

Tja, dazu müsste man wissen, wie Du 'neue Einträge' darstellst.
Gibt es dafür einen Flag in deinem Datensatz/Objektbaum?

Für mich klingt das so, als hättest Du eine wichtige Komponente vergessen: das Android SDK.

Ob deine ADB geht oder nicht bekommst Du ja ganz einfach im Terminal raus:

cd /Path/To/Android/SDK
platform-tools/adb version

Wenn irgendwas kommt wie

Zitat

Android Debug Bridge version 1.0.31

ist alles okay und Eclipse ist doof.
Eventuell passt dann einfach der Pfad zum SDK nicht.

Wenn irgendwas kommt wie

Zitat

-bash: platform-tools/adb: command not found

fehlt da was.

Und wenn Du bereits Probleme hast /Path/To/Android/SDK zu finden, dürfte der Fall klar sein.

Beim Klick auf den Marker möchtest Du vermutlich auf das Objekt zugreifen, welches vom Marker repräsentiert wird.

Wie machst Du das?
Wenn Deine DaoKlasse das serializable Interface bedient und Du es als serializable Extra an deine Activity übergibst, dann klappt das nicht.

Wie bereits anderweitig angesprochen:
"Ich brauchte die Referenzobjekte da ja noch nicht sondern hab einfach den FK an die neue Activity übergeben.
(Ist meiner Meinung nach simpler als das ganze Herumgeparcele…)"

Das Problem liegt dann meiner Erfahrung nach nicht am loadAll()/loadDeep(), sondern an der androideigenen Eigenheit geboren aus der Zeigerunfreundlichkeit Javas, keine Zeiger übergeben zu wollen: das Objekt wird gepackt, das Pack wird übergeben, ein neues Objekt wird aus dem Pack erstellt und dieses neue Objekt hängt dann nicht mehr persistent in der Datenbank, hat also dementsprechend keine eigene Session mehr.

Ungefähr dasselbe erreichst Du, wenn Du von Hand ein Objekt anlegst und dessen Referenzen setzen möchtest bevor Du es der Datenbank zugefügt hast.

Deshalb mein Workaround mit dem Foreign Key: Key an die Activity übergeben, passenden Datensatz an Hand des Keys laden und Infos anzeigen.

Welches Problem denn?
Fehlermeldungen? Abstürze? Aufhängen?

+narf+
Ich erinnere mich an die Fehlermeldung.
Aber wie habe ich das damals gelöst? +grübel+

Ach, richtig. Ich brauchte die Referenzobjekte da ja noch nicht sondern hab einfach den FK an die neue Activity übergeben.
(Ist meiner Meinung nach simpler als das ganze Herumgeparcele…)

Ansonsten hilft statt loadAll() ein loadDeep()…
Dann wird (gemäß Dokumentation) auch die passende Session weitergereicht.

Weitere Infos:
Google Gruppe

1) Nein. Die Auswahl passiert ja über die RingtonePreference. Das bedeutet, dass sich das System schon um alles kümmert. In eben jenem Auswahldialog stehen auch die korrekten Bezeichnungen.

2) Ich bekomme ein gültiges Objekt vom Typ Ringtone zurück und kann den erfolgreich abspielen. Klingt für mich nach einem korrekten Parsing.

3) Nein. Wie würde ich das tun?

4) Ich hantiere nicht in der Gerätekonfiguration herum. Insofern dürften diese Permissions unnötig sein. Sie einzubauen ändert auch nichts.

Erkenntnis: In einem anderen Fragment als dem PreferenceFragment läuft es.
Dann sehe ich mal von getActivity() ab und leg mir eine Referenz auf die angehängte Activity an.
Vielleicht ändert das was.

//Nachtrag
Ejup, das war's. Da referenzierte jemand die falsche Activity. Mit dem jetzigen Setup geht es. Erst mal.

Es wäre halt wichtig zu wissen wie die Exception lautet und wie die Relations erstellt sind.

Aktuell habe ich kein Projekt mehr mit GreenDao, deshalb kann ich da auch nicht mal eben schnell nachschauen.