Beiträge von Fortuner

    du hast wahrscheinlich recht, dass beim Back-Button onStopp() und nicht onDestroy() ausgelöst wird:


    https://developer.android.com/…s/activity-lifecycle.html


    sicher ist nämlich, dass danach onCreate() ausgeführt wurde.


    Ich war von onDestroy() ausgegangen, weil für mich fest stand, dass die logging_flag - Variable zwei mal existiert hat. D.h., die alte wurde destroyed und eine neue erstellt aber das destroyen wurde nicht ganz abgeschlossen, weil der alte Service noch die Callbacks regelmäßig gerufen hat... oder so.


    Wovon hängt es eigentlich ab, ob nach onStop() onRestart() oder onCreate() ausgeführt wird? (siehe link). Kann es vielleicht sein, dass automatisch onCreate() ausgeführt wird, wenn man onResume() nicht überschrieben hat?

    Also der FileWriter schreibt in der Callbackfunktion in der MainActivity und das funktioniert ganz sehr gut. der Google-Service ruft die Callbackfunktion immer auf, solange die App nicht beendet wird und egal ob sie durch den Home-Button in den Hintergrund geschickt wird, die Activity durch den Back-Button destroyed wird oder der Screen schwarz wird.


    Muss ich da wirklich noch groß was ändern zu dem wie es so ist? Ich muss ja theoretisch nur dafür sorgen, dass nach dem destroy und Neustart der App die Buttons wieder den Zustand erhalten und verhindern, dass der Listener ein zweites mal registriert wird, damit keine doppelte Aufzeichnung auftritt.


    Aber was genau meinst du mit eigenem Service bauen eigentlich? Könntest du mir einen Link schicken wo das erklärt wird? Hört sich für mich richtig an und würde ich gerne lernen, um das bei der nächsten App von Anfang an richtig zu machen.

    Hi! Danke für deine Antwort.


    Ich benutze die Android Location Services, etwa so wie in diesem Post:


    https://stackoverflow.com/ques…statuschanged-not-working


    Ich registriere beim Listener die Callbackfunktion die vom System regelmäßig aufgerufen wird. Dort drinnen habe ich den FileWriter der die Datei schreibt. Damit läuft das ganze auch in einem eigenen Thread und meiner Meinung nach auch unabhängig von meiner Activity. Deswegen meine ich, dass ich quasi bereits in diesen Service alles ausgelagert habe und nichts eigenenes schreiben soll.
    Die Callbackfunktion schreibt nur, wenn logging_flag = true ist. Dieser ist in der MainActivity deklariert und wird dort auch über die UI geändert. Klappt alles wunderbar. Nur wenn dieser mysteriöse Activity-Neustart bzw. Neuaufbau der UI passiert, ist logging_flag false (da onCreate() ihn auf false setzt) und die App quasi im Neuzustand aber der Service läuft weiter, sprich die Callbackfunktionen werden immer noch aufgerufen und das Logging findet weiterhin statt, was nur sein kann, wenn logging_flag true ist. Deshalb vermute ich, dass die logging_flag nun irgendwie 2 mal existieren muss, weil vielleicht eine neue Instanz von MainActivity erzeugt wurde.


    Ich würde gerne verstehen, was hier vor sich geht.

    Hallo,


    Ich habe eine App geschrieben, die Daten aus der Location-Api periodisch in eine Textdatei schreibt. Sie registriert sich im System beim Listener (Location Manager), welcher eine Callback-Methode aufruft und die Daten übergibt. Diese werden dann in eine Textdatei geschrieben.
    Die App läuft soweit perfekt und zu 95% stabil. Es kommt jedoch manchmal vor, dass sich scheinbar die MainActivity neu erstellt (was ich an der Oberfläche sehen kann, da sich dann die UI wie nach einem Erststart der App neu aufbaut) allerdings die alte Activity im Hintergrund weiterläuft (was ich wiederum daran erkennen kann, dass die Datei weiter aufgezeichnet wird! D.h. es werden weiterhin neue Daten in die Datei geschrieben.)


    Problem 1: Die UI sieht aus, als ob nicht aufgezeichnet werden würde, weil sie gerade erst "neu gestartet" ist. In Wirklichkeit findet aber eine Aufzeichnung statt. Die App befindet sich in einem inkonsistenen Zustand.
    Problem 2: Wenn man in der neu aufgebauten UI (bzw. Activity) auf "Start" drückt, dann wird ein neuer Listener registriert und da die alte Activity mit dem alten Listener noch läuft, findet eine doppelte Aufzeichnung statt! D.h., es werden Daten doppelt in die Textdatei geschrieben und das auch noch ziemlich asynchron, da ziemlich oft geflusht wird -> Datei wird völlig unbrauchbar / zerschrieben.
    Screen-Rotation ist übrigens aus (immer Portrait).
    mir scheint es, als ob dieser Activity-Neuaufbau besonders häufig bei meinem Samsung S8 auftritt. Ich kann allerdings nicht sagen, wie und wann das passiert. Ich kann es leider nicht bewusst erzwingen. Mir scheint es, als ob dies manchmal passiert, wenn die App in den Hintergrund geht und dann längere Zeit dort bleibt bzw. das Gerät in Schlafmodus gegangen ist.


    Fragen:
    1.) Unter welchen Bedingungen tritt dies auf (also dass die MainAcitivity+UI neu aufgebaut wird und die alte MainActivity weiterläuft bzw. die darin enthaltene Callback-Funktion immer weiter aufgerufen wird).
    2.) Wie könnte ich elegant und einfach Problem 1 und 2 lösen? Ich meine Problem 1 evtl. mit static Variablen lösen zu können, sicher bin ich mir aber nicht.


    Danke

    Okay ich befürchte, dass das, was ich vor hatte, grundsätzlich nicht möglich war/ist.
    Ich wollte die btn_default bzw. die Buttons aus Widget.AppCompat.Light.ActionBar verwenden, und zwar mit abgerundeten Buttons, da sie ziemlich eckig sind und mir das nicht gefällt.
    Während man in Android Studio recht gut und einfach eigene Buttonstyles designed und anwenden kann, ist es wohl nicht vorgesehen, dass man bestehende Buttonstyles übernimmt und modifiziert. Zumindest ist es mir in 2 Tagen nicht gelungen.

    Hmm sicher dass ich in der styles.xml


    <item name="android:windowBackground">@drawable/RoundShapeBtn</item>


    und nicht Android:buttonStyle o.ä. schreiben muss?


    mit windowBackground ändert sich Garnichts, mit buttonStyle hingegen mehr. Allerdings sind die Buttons dann (wahrscheinlich) mangels Einstellungen in der RoundShapeBtn.xml nicht mehr sichtbar (nur noch der Text, oben links zentriert).
    [*]

    So wie ich es jetzt sehe willst du die Bottom programmatisch in Java erzeugen. Ob das da auch geht weiß ich nicht habe ich noch nicht gemacht. Erstelle mein Layout immer in XML.


    Mir wäre es auch lieber wenn ich alles in XML definieren könnte!


    Meine App hat jedoch zwei Buttons, die im Enabled-Zustand anders aussehen sollen, und zwar ein 9-Patch-Image (button.9.png im drawable-Ordner) als Hintergrund haben. Das habe ich so bewirkt:



    Button.setBackgroundResource(R.drawable.button);


    Wenn der Button dann disabled wurde, habe ich ihn dann wieder zum normalen Aussehen versetzt:


    Button.setBackgroundResource(android.R.drawable.btn_default);


    Wenn ich das in XML machen wollen würde, müsste ich einen neuen Button-Style definieren, indem diese Background-Resource in Abhängigkeit des Enabled-Zustands definiert ist, richtig? Kannst du mir sagen, wie ich hierzu vorgehen müsste?


    Übrigens, das 9-Patch-Button-Image hat runde ecken, btn_default jedoch nicht. und genau hier liegt das Problem.

    Etwas ich noch nicht ganz verstanden habe:


    meine Buttons sehen zu beginn immer anders aus, als dann, wenn ich


    Button.setBackgroundResource(android.R.drawable.btn_default);


    ausführe. Woran liegt das? Ich dachte ja immer, dass durch diesen Aufruf der Standardbackground, so wie er zu Beginn sein müsste, wieder eingestellt wird.


    hier meine styles.xml:


    Hey Ihr beiden,


    vielen vielen Dank!


    Das finde ich sehr gut. Die Sache jedoch ist, dass ich im Programm manche Buttons ständige ändere, und zwar hiermit:


    Button.setBackgroundResource(R.drawable.button);



    und


    Button.setBackgroundResource(android.R.drawable.btn_default);



    wie würden sich diese Interaktionen verhalten?



    Die Änderung des gesamten Themes wie es jogimuc verschlägt scheint die exakte Antwort auf meine Frage zu sein. So könnte ich die nicht-runden Buttons, welche sowieso nie zum Einsatz kommen sollen, von Anfang an gleich eliminieren und mir nie wieder Gedanken um sie machen. Ich würde nun wie folgt vorgehen:


    1. manifest.xml


    Code
    <application
    
    
       ...
    
    
            android:theme="@style/deinTheme" >


    2. styles.xml


    Code
    <style name="DeinTheme" parent="@android:style/Theme.Dialog">
    
    
        <item name="android:windowBackground">@drawable/RoundShapeBtn</item>
    
    
    </style>

    3. RoundShapeBtn.xml

    Wichtige Fragen:


    1. Wenn ich nun in meinem Programm diese Codes ausführe:


    Button.setBackgroundResource(R.drawable.button);
    Button.setBackgroundResource(android.R.drawable.btn_default);



    sind dann anschließend die runden Ecken weg oder noch da?



    2. Kann ich statt


    Theme.Dialog


    auch


    Theme.AppCompat.Light


    schreiben? Davon hätte ich nämlich gerne die Buttoneigenschaften (bis auf die Eckformen).

    Gebe die Radien mit an, welche die Buttons haben sollen.
    Teste mal das:

    Code
    <?xml version="1.0" encoding="utf-8"?>
    <shape xmlns:android="http://schemas.android.com/apk/res/android" 
    android:shape="rectangle">
        <solid android:color="#eeffffff" />
        <corners android:bottomRightRadius="8dp"
            android:bottomLeftRadius="8dp"  
            android:topRightRadius="8dp"
            android:topLeftRadius="8dp"/>
    </shape>


    Hey, danke!


    Aber wie kann ich dieses Shape einbinden, sodass dass dies Default wird? Also in der styles.xml (richtig?)

    Ich habe hier zwei Posts gefunden, wo Leute mehr oder weniger das gleiche versucht haben. Allerdings geht das drunter und drüber, wenn ich das bei mir einbringe (Fehlermeldungen, Buttons werden garnicht mehr angezeigt, etc.) aber vielleicht kann ja jemand hieraus die schnelle und einfache Lösung ableiten, nach der ich suche.


    https://stackoverflow.com/ques…of-an-android-application


    https://stackoverflow.com/ques…ns-in-android-application

    Hallo,


    ich bin hier ziemlich neu und muss offenbaren, dass ich mich in Sachen UI im Gegensatz zu Java und den Programmcodes selbst noch nicht wirklich auskenne.
    Ein großes Fragezeichen erstreckt sich dabei über die Themen Styles (insbesondere was die Vererbung angeht) - XML-Dateien - Themes. Wenn also jemand Seiten oder Tutorials kennt, die diese Thematik SEHR leicht und verständlich erklären, wäre ich sehr dankbar!


    Aktuell stehe ich vor dem folgenden, konkreten Problem:


    Ich möchte, dass alle Buttons in meiner App, egal in welchem Zustand, runde Ecken bekommen (das geht irgendwie unter Android Background ... shape ... Corners ... radius). Der Rest soll quasi Default bleiben.


    Ich habe herausgefunden, wie ich die Default-Werte für alle Buttons ändern kann, allerdings nicht, wie ich nur eine Eigenschaft (die mit den runden Ecken) ändere. D.h., ich muss gleich alle anderen Eigenschaften mitdefinieren, ansonsten wird der Button unsichtbar.


    Wenn ich im Javacode folgendes schreibe:


    stopButton.setBackgroundResource(android.R.drawable.btn_default);


    Dann sieht der Button sehr gut aus. Diese Darstellung würde ich gerne als Default haben. Ich denke die Darstellung rührt aus meiner styles.xml, kann das sein? dort steht:

    Code
    <resources xmlns:android="http://schemas.android.com/tools">    
     <style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar">
      <item name="colorPrimary">@color/colorPrimary</item>        
      <item name="colorPrimaryDark">@color/colorPrimaryDark</item>        
      <item name="colorAccent">@color/colorAccent</item>    
     </style>


    Nun, was muss ich ändern, damit diese Darstellung, die ich mit dem Java-Befehl umgesetzt habe, Default wird bzw. bleibt und die Buttons runde Ecken erhält? Für die Umsetzung wäre ich sehr dankbar, wenn ich möglichst wenige, neue .XML - Dateien erzeugen muss (für bessere Übersicht und Verständlichkeit).


    Vielen Dank !!

    Hi,


    ich bin aus tieferen Gründen zwingend angewiesen, für meine Appentwicklung Eclipse (Neon) zu verwenden und bin nun auf folgendes Problem gestoßen:


    Beim Einrichten der IDE und der Installation der neuesten Android SDKs musste ich feststellen, dass "Android Support Library" im SDK-Manager nicht mehr installiert werden kann (auch nicht unter "obsolet") da diese durch die "Android Support Repository" ersetzt wurde. Eclipse scheint aber noch mit der Android Support Library zu arbeiten und vermisst diese daher, was sich beim Builden durch Fehlermeldungen wie


    The import android.support cannot be resolved
    ActionBarActivity cannot be resolved to a type
    Error retrieving parent for item: No resource found that matches the given name "ThemeAppCompat. …"


    bemerkbar macht. Leider habe ich trotz intensiver Recherchen keine Lösung hierfür finden können. Allen anderen, die das gleiche Problem haben, wurde geraten auf Android Studio umzusteigen, was bei mir leider nicht möglich ist.


    Auf dieser Seite habe ich erfahren, dass man die Repository in ein gradle-Projekt einbinden kann:


    https://developer.android.com/…upport-library/setup.html


    also habe ich das versucht, indem ich das Projekt in Eclipse zu einem gradle umgewandelt habe und in der gradle.build den folgenden Code eingeführt habe:


    dependencies {

    compile 'com.android.support:appcompat-v7:24.0.0'
    }


    Leider brachte das keinen Unterschied und die Fehlermeldungen blieben bestehen. Habe ich was falsch gemacht?


    Gibt es vielleicht andere Lösungswege? Soll ich vielleicht die alte support library von einem Freund besorgen und manuell ins Verzeichnis einbringen? Müsste ich dann noch eine Einstellung in Eclipse ändern?


    Irgendwie ist das schon seltsam. Eigentlich müssten doch noch viel mehr dieses Problem haben, oder bin ich der einzige der mit Eclipse und der neuesten Android SDK arbeiten möchte?


    Vielen Dank schonmal!

    upps, da ist was schief gelaufen


    public String ReceiveASCIIBytes(int length){


    byte[] bytes = new byte[length];


    try { BufferedInputStream bis = new BufferedInputStream(socket.getInputStream());
    bis.read(bytes, 0, length);


    } catch (IOException e) { e.printStackTrace(); } finally { }


    return bytes.toString();


    }

    Angenommen, folgender Code:

    Was würde nun passieren, wenn ich diese Methode vom GUI-thread aus mehrmals ausführe, mit verschiedenen Parametern? Würde der zweite Thread erst nach dem Ende des ersten beginnen zu laufen, oder laufen beide gleichzeitig?


    Um das zu testen, habe ich eine App geschrieben, die bei Button-Klick diese Methode gleich zwei mal ausführt, allerdings mit zwei unterschiedlichen File-Pfad-Parametern. Die erste Datei ist eine Textdatei voller "AAAAAAA...", die zweite voller "BBBBBBBB...".


    Betätigt man diesen Button, kommen auf dem Server zuerst nur die AAAAA-Dateien an. Erst wenn das letzte A angekommen ist, kommen die ganzen Bs.


    Daraus KÖNNTE man schließen, dass die Threads sequentiell und nicht simultan ausgeführt werden.


    Allerdings bin ich dem nicht so ganz sicher. Es könnte ja auch sein, dass der Buffer vom BufferedOutputStreams (oder vom Socket-Output-Stream??!) dafür sorgt, dass nicht mehrere threads ihn gleichzeitig füllen können, d.h., Datei "B" kommt erst rein, wenn der Datei "A" fertig eingelesen wird.
    Falls ich damit recht haben sollte.... was passiert mit einem Thread (hier Thread2 mit B-Datei), wenn sein Einschreibungsvorgang in den Buffer (oder Socketstream oder was auch immer) aus den o.g. Gründen blockiert wird? Wird der ganze Thread blockiert, oder läuft er weiter? Beim letzteren könnte man sich die "Streamabteilung" ja wie ein eigener Thread vorstellen.


    Würde mich hier über etwas Aufklärung von einem Experten sehr freuen.


    Vielen Dank

    Hallo,


    der folgende Code funktioniert leider nicht wie er soll. Kompilierung klappt, nach dem Einbinden bekomme ich jedoch die Fehlermeldung "Invalid Array Length". Leider wird mir die Zeilennummer nicht mitgeteilt, sodass ich spekulieren muss wo es hapert. Ich finde jedoch nichts verdächtiges. Hat jemand von Euch vielleicht eine Idee?


    Danke schonmal...



    public String ReceiveASCIIBytes(int length){ byte[] bytes = new byte[length]; try { BufferedInputStream bis = new BufferedInputStream(socket.getInputStream()); bis.read(bytes, 0, length); } catch (IOException e) { e.printStackTrace(); } finally { } return bytes.toString();}

    Hallo,


    eine kleine Verständnisfrage zu BufferedInputStream und (z.B.) Sockets:


    BufferedInputStream bis = new BufferedInputStream(socket.getInputStream());



    wieviel wird in diesem Fall immer aus dem Socket gelesen? So viel wie vom buffered stream gelesen wird?


    Bsp:


    Angenommen, am Socket sind 10 Bytes angekommen. Nun wird aber nur ein Byte gelesen und der bis geclosed:


    bis.read();


    bis.close();


    Was passiert in diesen Fällen mit den restlichen 9 Bytes? Sind die schon in den BufferdInput gelesen worden und "verschwinden" mit bis.close() oder leigen die noch in dem Socket-"Eingangspuffer" ? Sprich, wenn nach bis.close() ein neuer bis sagen wir bis2 initialisiert werden würde und wie oben mit dem Socket verbunden werden würde, würde mann dann als erstes die 9 Bytes erhalten oder sind wären die weg? ;)


    Ich hoffe ich konnte meine Frage verständlich ausdrücken und danke euch schonmal für eventuelle Antworten.