Beiträge von Marco Feltmann

    In dem Fall ist es naheliegend mit dem Debugger rein zu gehen und zu schauen, welche Werte die einzelnen Variablen haben.
    Da loadProject nie aufgerufen wird, kannst Du davon ausgehen, dass loadProject nicht das Problem ist.


    Das Problem ist entweder:
    dbManager == null und null.loadProject(String) == crash


    Oder:
    project == null und null.getName() == crash


    //Nachtrag_ In Deinem Code wird dbManager nie gesetzt, also kann das nix werden. Soviel zum Thema 'vermeintlich richtiger Code'

    Geh das Log am Besten von unten nach oben durch.
    Da findest Du dann irgendwann:

    Code
    E/AndroidRuntime(2220): Caused by: java.lang.NullPointerException
    E/AndroidRuntime(2220): 	at and07c.lektion2.components.GatherActivity.onCreate(GatherActivity.java:59)


    Genauer als 'GatherActivity.java, Zeile 59, Methode onCreate' geht es kaum. ;)

    Fragments wurden ab Andorid 3 eingeführt und ermöglichen, dass mehere Views auf Tablets nebeneinander angezeigt werden können.


    Nicht nur. Ich würde sogar so weit gehen zu sagen, dass man immer ständig und nur mit Fragments arbeiten sollte.
    So kannst Du nämlich ganz bequem ein und dasselbe Layout inklusive ihrer dazugehörigen Logik in so vielen Activities nutzen wie du brauchst und musst die Steuerung für das Layout nicht in jeder Activity neu implementieren.

    Welche IDE benutzt Du?
    Wann immer Du ein neues Android Projekt anfängst, bekommst Du ja die Option in den ADT angezeigt, dass Du auch eine Activity anlegen kannst.
    Wenn Du diese Option auswählst bekommst Du etwas später (Minimum SDK von 10/3.0 vorausgesetzt) als Activity die Vorschläge 'Blank Activity', 'Fullscreen Activity' und 'Master-Detail Activity'.
    Letztere führt Dich dann zu einem komplett fertigen Ergebnis mit Fragmenten, welches unter Anderem hier etwas genauer beleuchtet wird.
    Du wirst sicherlich verstehen, dass ich es unsinnig finde zusammenhanglosen Sourcecode zu posten, den Du Dir innerhalb von 8 Klicks lokal auf Deinem Rechner zaubern kannst. ;)


    Es liegt natürlich an Dir das Ganze mit richtigen Daten statt der Dummies zu füllen und an Stelle des Detailfragments einen ViewPager oder ähnliches zu implementieren, damit Du durch deine Tabs navigieren kannst.
    (Ich bin mir allerdings grad nicht sicher, wie zuverlässig verschachtelte Fragmente funktionieren. Sofern sie im XML definiert sind, ist das alles soweit ich weiß ein totales Chaos, Du müsstest sie also von Hand verwalten.)


    Generelles über die Fragments erfährst Du auch in diesem Tutorial, bei dem leider die Bilder fehlen. Aber die Bilder zum Fragment Life Cycle bekommst Du ja schon über den offiziellen Guide.
    Überhaupt sind Life Cycles total wichtig in der mobilen Entwicklung, nicht nur unter Android.


    Und natürlich sind die Videos zu diversen Google I/O sehr zu empfehlen.
    Beispielhaft seien hier genannt:
    https://www.youtube.com/watch?v=WGIU2JX1U5Y
    https://www.youtube.com/watch?v=amZM8oZBgfk
    https://www.youtube.com/watch?v=qlrKh-L4bqU


    Eine gute Anlaufstelle für Tutorials ist neben der offiziellen Seite[1] auch die Seite von Lars Vogel[2].


    1) https://developer.android.com/training/index.html
    2) http://www.vogella.com/tutorials/android.html

    Wenn man bei Eclipse ein neues Projekt mit einer Master-Detail-Activity anlegt, bekommt man schon alles frei Haus und muss es sich nur noch durchschauen. :)

    Und ich glaube
    letzteres ist das was ich suche.


    Wie kommst Du auf die Idee, dass Du die Stelle suchst, an der die Recents geschlossen werden sollen? Du kennst die Implementierung des Ganzen nicht. Wenn es zu früh geschieht und die RecentsActivity noch gar nicht vollständig angezeigt wird, wer garantiert Dir dann, dass alles stehen und liegen gelassen und die RecentsActivity geschlossen wird?


    Eventuell brauchst Du eher die com.android.systemui.recent.action.PRELOAD um einzugreifen, bevor der Kram angezeigt werden soll.
    Und wenn Du dort 'nur' ein com.android.systemui.recent.action.CANCEL_PRELOAD schickst.
    Doch wird auch das nur passieren, wenn das PRELOAD überhaupt ausgeführt wurde, weshalb Du versuchen müsstest, Deine App für dieses Intent zu registrieren.


    Allerdings ist es im Allgemeinen so, dass Android Dir eine Auswahl der Apps anbietet, die das gewählte Intent verarbeiten können. Und da kann der User dann wieder raus aus Deiner App.


    Würde dieses Buch mir weiterhelfen?


    Vermutlich nicht. Dort steht nur, wie Du Deine Apps mit Intents verschönern und anpassen kannst. Du willst in die Funktionen des Betriebssystems eingreifen.
    (Und ich habe Dir schon mehrfach erklärt, dass das einerseits eine blöde Idee und andererseits schwer umzusetzen ist.)


    Entweder weitest Du Deine Recherche aus in dem Du Unternehmen fragst, die das hinbekommen haben, oder Du baust Dir ein eigenes angepasstes ROM.
    Du kannst es auch mit einem Java Disassembler etwas Reverse-Engineering versuchen.


    Nur wenn dieses Problem so trivial zu lösen wäre, dass eine halbe Stunde Google Dir Erleuchtung brächte, wäre so eine Masterarbeit ja geschenkt. Und damit noch weniger wert als eine abgeschriebene Doktorarbeit.

    Schön, dass Eclipse meckert. Eigentlich solltest Du wissen, dass man ohne genauere Angaben absolut nicht helfen kann.
    Zumindest bei mir scheint java.lang.occultism.CrystalBall gesprungen zu sein und java.lang.spiritualism.Ouija ist irgendwie auch nicht sehr auskunftsfreudig. :P


    Ich weiß nur, dass man Intents blocken kann. Eventuell wird diese Activity ja über einen Intent aufgerufen, der eben diese Signatur der Activity hat. Dann könntest Du Deine Activity für diesen Intent registrieren und eventuell wird die RecentApps Activity dann nicht aufgerufen, sondern Deine App erneut.

    SureLock ist ein plattformübergreifendes Mobile Device Managementsystem für Android, iOS und Windows/Windows Mobile.
    Das Ding kostet nicht aus Spaß $50 pro Lizenz. Da stecken Hirnschmalz und jahrelange Arbeit hinter. Vermutlich haben Sie im Windows Mobile/Windows CE Bereich angefangen, da diese Systeme hauptsächlich im Bereich Lager und Logistik eingesetzt wird und der 'Kiosk Modus' dort aus Sicht der Chefetage eine Existenzberechtigung hat.
    (Mit auf den Workflow zugeschnittener Hard- und Software bräuchten die das nicht – aber es ist ja cooler Tausende von Euro für ein breit verbreitetes allgemeines Betriebssystem auszugeben und weitere Tausende von Euro für eine Software, die das System beschneidet, als ein paar Tausend Euro für ein angepasstes Betriebssystem zu bezahlen.)


    Wenn Du es also wissen willst, wie die das machen, dann könntest Du ja da einfach mal nachfragen.
    Wenn es einfach wäre, gäbe es Hinweise auf StackOverflow. Beispielsweise wie beim Home-Button. Welcher sich seit 4.0 aber auch nicht mehr so abfangen lässt…


    Nach wie vor behaupte ich: niemand braucht einen Kiosk Mode.


    Ein Kiosk Mode versteckt Betriebssystemfunktionalität vor den Anwendern. Ein Kiosk Mode funktioniert so lange gut, bis das Admin Kennwort herausgefunden wurde. Und meine Erfahrungen mit Kiosk Modes sind, dass es immer mindestens einen Weg gibt dran vorbei zu kommen und sie immer mindestens eine Betriebssystemfunktionalität ungewollt beeinträchtigen.


    Wenn ein Gerät (beispielsweise ein Tablet für die schriftliche Prüfung – was an und für sich schon ein absurder Gedanke ist!) also nur eine Sache können soll, dann soll es gefälligst auch ein nur auf diese eine Sache speziell ausgerichtetes Gerät sein.
    Statt also zu versuchen irgendwie die normalen Eingabemethoden zu verhindern
    und die Eingabemethoden über eine Bluetooth Tastatur
    und die Eingabemethoden über ein Bluetooth Headset
    und die Eingaben über die Sprachsteuerung
    ist ein Custom ROM mit auf das Einsatzgebiet des Tablets zugeschnittenen Programmen die richtige Lösung.


    Keine Recent Apps? Dann ruft das Custom ROM eben keine Activity auf. Keine Browserunterstützung, um Googlen während der Prüfung zu unterbinden? Dann hat das Custom ROM eben keinen Browser. Ein Store fällt ebenfalls aus, weil die Schüler und Studenten sicherlich keine Apps installieren dürfen.


    Oder, anders ausgedrückt:
    Lieber einen Porsche kaufen, höher legen lassen, größere Reifen drauf, Getriebe statt auf Geschwindigkeit mehr auf Drehmoment anpassen, Unterboden angemessen versiegeln und eine Anhängerkupplung dran anstatt gleich einen Trecker zu kaufen.

    Normalerweise gibt es für ein und dasselbe Vorgehen in jeder Programmiersprache ein Äquivalent.


    Mir ist unter iOS absolut kein Mechanismus bekannt, mit dem ich ein Objekt per Index und Key ansprechen kann.
    In C# auch nicht, aber da stecke ich auch nicht so tief drin.


    Eigentlich kenne ich diese 'Unart' nur von PHP.


    Wenn es das in C# gibt, dann wirst Du unter demselben Stichwort sicherlich auch in Java fündig. Ist ja alles ziemlich ähnlich.
    Wenn es das in iOS gibt, dann sag mir das Stichwort und ich finde gern das Äquivalent dazu heraus.


    Ich befürchte aber, es wird auf eine Eigenimplementierung herauslaufen.
    Wobei diese zu erstellen für iOS vermutlich leichter wäre, so aus Speicherplatzgründen. Denn entweder die List oder die Map müsste lediglich eine weak reference auf das Objekt verwalten und zurückgeben, und wie sich so etwas in Garbage Collected Sprachen umsetzen lässt weiß ich nicht so genau.
    (Vermutlich mit einer Instanz, die WeakReference implementiert…)


    Tatsächlich finde ich Deine erste Idee sehr gut. Via linkedHashMap.values() bekommst Du das (entsprechend sortierte) Array und mit einem get(index) das darin enthaltene Objekt.
    Vielleicht reicht eine Subklasse von LinkedHashMap, in der Du ein get(int index) implementierst, und genau das machst.

    Moin c++11
    (ungewöhnlicher Name für Java-Entwickler :P)


    Wenn meine Stalking-Skillz nicht total eingerostet sind, dann bist Du ja eigentlich überhaupt kein Freund von Smartphone Apps.
    Da frage ich doch glatt mal: warum möchtest Du für Android Programme entwickeln?
    Hat Dich die Geldgier gepackt? ^^

    Diese 'Recents' Taste ist auf einigen Geräten eine Hardwaretaste, das 'nicht mehr anzeigen' wird also bestenfalls schwierig. ;)


    Doch davon völlig unberührt: es gibt keinen Grund in die Funktionalität der Hardware eingreifen zu wollen.
    Noch weniger gibt es einen Grund dafür das Verlassen der App über die 'Recent Apps' Taste unterbinden zu wollen.


    Ein Kiosk-Modus ist und bleibt Sache des Betriebssystems. Da Android das offenbar nicht anbietet und es mit Bordmitteln offenbar nicht möglich ist, gibt es das auch nicht.


    Mir fällt als einzige Möglichkeit nur ein, dass Du Deine Manifest-Datei anpasst. Gemäß Surelock fangen sie 'einfach' das Intent com.android.systemui.recent.RecentsAcitivity
    ab.


    Eventuell kannst Du Deine Activity im Manifest so konfigurieren, dass diese beim Aufrufen von com.android.systemui.recent.RecentsAcitivity gestartet wird.


    Nur noch einmal zum Betonen meines Standpunktes: Finger weg von der Usability. Diese Funktionalität hat ihre Gründe und mir fällt absolut kein Punkt ein, die eine Deaktivierung rechtfertigen würde.

    Mal meine Gedanken zu Deinen Fragen:

    • Ich bin zwar nicht bei der Feuerwehr, aber ich lebe in Deutschland. Und ich weiß, dass wir hier Normen und Gesetze haben.
      Abweichungen sind kalkulierbar, da gesetzlich vorgegeben. Natürlich wirst Du mit dem einem Schaummittel 105 Liter, mit dem Anderen 101 Liter und mit dem Dritten 112 Liter herausbekommen, aber das dürfte unerheblich sein.
    • Sehr gute Frage. Eventuell für die (sehr theoretische) Einsatzplanung. Wenn eine (kleine) Lagerhalle von 1.200 Quadratmetern brennt, braucht man gar nicht erst mit 120 Litern Schaummenge losfahren – damit bekommst Du dann höchstens den Eingangsbereich gelöscht bis Dir der Löschschaum ausgeht. Also lieber ordentlich aufstocken, gleich nen größeren Löschzug nehmen oder zu dritt aufbrechen.


    Natürlich ist der Schaum leer wenn der Schaum leer ist. Es wäre nur denkbar ungünstig, wenn ein fünfstöckiges Mehrfamilienhaus in Brand steht und Dir schon nach den ersten fünf Metern im Treppenhaus der Schaum ausgeht.
    Nur wird sich die Einsatzleitung/der Fahrzeugführer lieber auf ihre Erfahrungen beim Befüllen des Schaummittels verlassen als zwei Minuten lang auf einer App rumzudrücken. Abgesehen davon: weiß man vorher genau, wie groß die zu löschenden Flächen sein werden und wie lange man mit Schaum löschen muss? Vermutlich eher nicht.

    tl;dr:

    • Nö.
    • Isso.


    Oder, etwas langatmiger:


    Der API Key basiert auf einer Signatur, die Eclipse bei jedem Entwickler erstellt.
    Diese Signatur (genannt debug-key) unterscheidet sich also von Eclipse Installation zu Eclipse Installation.


    Die APK wurde mit dem Eclipse des Entwicklers erstellt, der seinen API Key eingetragen hat. Das bedeutet, dass sein API Key zu seinem debug-key passt.
    Wenn Du jetzt die Sourcen baust, dann ändert sich der debug-key und dieser passt dann nicht mehr zu seinem API Key.


    Um mit Google Maps arbeiten zu können benötigst Du also einen eigenen API Key.
    Da kommst Du auch nicht drum rum. :)

    Mit dem Google Cloud Messaging hab ich noch nichts gemacht.


    Gibt es da keine ausführliche Dokumentation zu?
    Geht eventuell das Tablet irgendwann in den Ruhestand, so dass die Verbindung zum Server weg fällt? Hast Du gravierende Memory Issues, so dass Dein Registrierungsobjekt zu früh weggeräumt wird?