AndroidStudio mag mich wohl nicht

[jogimuc]

schön das Bild nur der Code wo es zuhängen scheite wäre besser sinnvoller.
Ich meine die onKlick Methode. welcher Variante von onKlick machst du den eigentlich?



Wenn du Code postet bitte in den Code Block.

 

[Selbstbauer]

hab es jetzt so gelöst (seit vorhin gehts ja plötzlich mit dieser methode)

bttn_speed_mode.setOnClickListener(OnClickListener{
if(MyClass.speedMode==1){
MyClass.speedMode=0;
bttn_speed_mode.setBackgroundResource(R.drawable.bttn_speed_play);
}else{
MyClass.speedMode=1;
bttn_speed_mode.setBackgroundResource(R.drawable.bttn_speed_stop);
}
})

und für die zeile mit dem bttn_speed_mode..........
gibts ne variante mit layout.setBackground............

da hatte AS mir erst dieses layout in rot angezeigt, DANK dem tipp mit der ALT+Eingabe kann man fehlende imports automatisch einfügen, obwohl unter automatisch versteh ich bißl was anderes naja aber seitdem das layout nichtmehr in rot angezeigt wurde, war es das setBackground. Bei den jetzt verwendeten zeilen hatte ich hinten den fehler gemacht dieses bttn_speed_play z.b. in diesen "" anzugeben, was AS aber allergisch reagieren ließ.

 

[jogimuc]

Ok dann ist ja alles gut. und wenn du gleich etwas von dienen Code ordentlich gezeigt hättest wäre alles einfacher gewesen.

Nur aus den wenigen Zeichen sich etwas zunehmen ist sehr schwer. Wie du selber sagst weist du schon nach wenigen Tagen nicht mehr was du alles geschrieben hast.

Und wir die deinen Code nicht sehen sollen es wissen durch ein paar wenige Zeichen.


layout.set..........



ich denke das du es nun verstanden hast.

 

[Selbstbauer]

hab jetzt aber ne andere variante entdeckt, meine buttons "zeichnen" zu lassen. "learning by doing" und keineswegs reiner raub von scripten ausm netz nur um ne app zu sammenzufummeln.

 

[jogimuc]

Hallo schön für dich aber du solltest langsam wieder runter kommen und mit deinen ständigen "learning by doing" Geschichten zu pralen aufhören.

Sonst wird es wirklich bald keine Hilfe mehr geben.
Was dein Haupt Fehler war, damit meine ich jetzt nicht beim der Programmierung, weist du nun. Schau meinen letzten post.

Ja auch wir lernen ständig dazu, selbst hier beim fragen beantworten. Denn auch ich schaue manchmal nach benutze codezeilen aus dem Netz um vielleicht helfen zu können, oder um meine eigenen Sachen zu machen das ist normal.
Logisch das man dabei auch neue Varianten entdeckt. Man liest und bildet sich ja auch dabei.

Nur eines noch , höre auf die beleidigte Leberwurst zuspielen du bist doch kein Kind mehr. Nimm es hin und freue dich über deine Erfolge. Ohne immer wider auf den alten Kamellen rumzukauen.



Schön das es geht und du eine zweite Variante hast .
sinnvoll wäre gewesen uns zu verraten wie die neue Variante aussieht..


So in dem Sinne noch große Erfolge.

 

[swa00]

Moin zusammen,

@swa00 soltest du @deek
eine Antwort geben und willst sie aber hier nicht mehr posten mich würde das auch Interessieren.

Nein, alles gut

Zum Thema als Einleitung
Overview of memory management | Android Developers

Deklarierte Variablen befinden sich also im Memory und werden beim Laden der Klasse auf deren Init-Werte gesetzt.

Soweit alles normal.

Wird allerdings die App in den Hintergrund geschickt , kann der Garbage Collector durchaus Teile der App aus dem Memory entfernen.
Kommt Diese wieder in der Vordergrund, entsteht eine neue Instanz dieser Klasse - der vorherige Wert der Variable erhält also seinen Init Wert.
Eine Deklaration von z.b. "public int counter;" wäre das also recht tödlich , deshalb immer zumindest "public int counter = 0";
Wann das passiert, entscheidet das System , nicht der Entwickler.

Und da viele try & catch gar nicht verwenden, wundert man sich über die "seltsame Begebenheiten der dritten Dimension" )

Verwendet man diese Variable global und klassen- übergreifend , (z.b. ein Zähler als Getter/Setter) hat man natürlich nicht mehr den
Zählerstand, den man erwartet. - Auch nicht wenn man die LifeCycle Routinen ordentlich verarbeitet.

Als Test kann man das recht schnell in einer Foregroundapp nachvollziehen, indem man einfach ein paar Views nimmt und mit dem PageViewer arbeitet.
Dort lädt das System erst dann die Klasse nach, wenn sie benötigt wird, (meist +/- 2)
Vorherige bereits initiierte View-Klassen werden schlichtweg rausgeschmissen. (Eine Art FIFO)
@jogimuc - Erinnere Dich an unseren fleißigen Roberto im anderen Forum und seinen Fragmenten

Das Gleiche gilt auch nicht nur für dämliche Variablen , auch für z.b. Bitmap Klassen Instanzen.
Diese enthalten nicht das Image , sondern schlichtweg nur einen Pointer auf das komprimierte Image(File) und werden erst beim Rendern verarbeitet.
Hierzu auch interessant : LRU Cache LruCache | Android Developers

Hierbei entscheidet das System , welche allociierten Memory es noch aufrecht erhält.
Da hat ein Entwickler nichts mehr zu sagen - Maximal nur noch einen Wunsch zu äussern.

Um zu verhindern , dass eine neue Instanz einer Klasse erstellt wird, nimmt man dann halt Singleton als eindeutige Instanz.
Wird die App allerdings vom System komplett gekillt, ist dann auch dieser letzte Mechanismus nicht mehr gültig.
Auch hier hat der Entwickler keinen Einfluss drauf. Da hilft dann nur noch das Shared-Handling oder ein Datenmodel.

Das hier erwähnte "Gedöns" ist also Elementar , dient allerdings eher als temporärer Mechanismus ( z.b. (broadcast) Intent)

Deshalb verwende ich persönlich nur noch Singletons mit einer eigenen und einmaligen Instanz z.b. als SetupKlasse.
Bei im Business-Bereich verwendete Apps unerlässlich.
Es gibt auch keine Beschränkung von SingleTons innerhalb einer App - Man kann also völlig creativ damit umgehen


Und warum das Ganze ? : Es ist ein gewollter Ablaufprozess von Android um die Belastung des Systems möglichst gering zu halten.

Randbemerkung :
Einer meiner Auftraggeber verwendet z.B. AndroidDevices als Controller in seine medizinischen OP Geräten.
Eigentlich ein Unding mit Hintergrund wie Android arbeitet und ein Kraftakt. Aber Kunde ist nun mal König.
Alleine der Umstand , dass der Arzt nicht ständig auf dem Gerät rumdaddelt, um es am "leben" zu halten , machen es unabdingbar,
dieses Basiswissen eigentlich schon von Anfang an inne zu haben.

 

[jogimuc]

@swa00 danke für die Antwort. Ist sehr Aufschluss reich. Etwas von denen habe ich ja auch schon gesagt und festgestellt.

Klar singelton macht mehr Sinn denn da wird eine Instanz gebildet. Die der Gc auch mit verwaltet..
Das ist und war mira auch so in etwa bekannt.

Nun würde mich interessieren wie das bei kotlin ist?
Mit der object Klasse. Oder mit Variablen im top lavel Bereich. Bereich oberhalb außerhalb einer Klasse.
Denn die sind in kotlin wirklich fast global. Im gleichen packet.
Ähnlich zu c. Das waren ja auch die ersten und einigen fast globalen Variablen in Kotlin.
Bevor das companion object geschaffen wurde.


Genau aus den von dir genannten Gründen wurde static in kotlin nicht aufgenommen.
Und erst später kam das companion Objekt was ja eigentlich eine spezielle Klasse ist, dazu..
Nun wäre es interessant wie der Compiler das in Java bytecode umsetzt als static oder anders.
Wenn es statig wäre hätten wir das gleiche Problem mit dem GC.

 

[swa00]

Von Kotlin habe ich null Plan , da bist du mittlerweile weiter als ich .....
Ich komme einfach nicht dazu

Aber was soll das groß verändern ?, Kotlin ist nun auch mal ein Wrapper zur Basis
und verändert nicht das System und sein Memoryverhalten


Gibt es in der API nichts Schlaues zum Lesen ??
(Wobei wir wieder beim Lesen wären

 

[jogimuc]

Klar der Wirt ist der gleiche.
[doublepost=1563514396,1563514063][/doublepost]Ich wede wohl mal zwei Beispiele machen müssen Java und Kotlin und schauen wie sie in Bytecode aussehen.
dazu muss ich mich erest mal in den Bytecode noch einlesen.
(Wobei wir wieder beim Lesen wären
[doublepost=1563514935][/doublepost]das System ist das gleiche nur wenn man es andere Übersetz damit meine ich den Kotlin Compiler kann was anderes rauskommen und die negativen Seiten des Systems etwas kompensieren. Zumindest wenn zb Kotlin im Hintergrund eine Instanz bildet reagiert der GC anders als wenn ich nur eine statische Kassen variabel ohne Instanz habe.

 

[swa00]

Somit hast du Dir selbst die verantwortungsvolle Aufgabe gesetzt, dies für uns in Erfahrung zu bringen

Kotlin ist mir eigentlich noch zu neu, was mich derzeit noch davon abhält, für
kommerzielle Anwendungen zu verwenden .

Ich lass das Ganze sich erst mal ein wenig etablieren

 

[jogimuc]

Ok lassen wir das du hast es super erklärt. Noch mal danke das wird auch @deek freuen.

 

[deek]

...obwohl unter automatisch versteh ich bißl was anderes ...

File->Settings->Editor->General->Auto Import
Haken bei "Add unambiguous imports on the fly"
Dann macht er den Import automatisch wenn es nur eine Möglichkeit gibt. Gibt es mehrere Klassen mit dem gleichen Namen musst du nach wie vor von Hand wählen.

Moin zusammen,
Nein, alles gut

Zum Thema als Einleitung
Overview of memory management | Android Developers

Deklarierte Variablen befinden sich also im Memory und werden beim Laden der Klasse auf deren Init-Werte gesetzt.

Danke für die ausführliche Beschreibung. War mir denke ich so aber alles bewusst. Meine Frage zielte explizit auf die Aussage ab, dass sich statische Variablen durch den GC ändern können. (unabhängig von einem kompletten App-Restart, dann sind sie natürlich weg)
Mir wäre nicht bewusst, dass geladene Klassen "entladen" werden und damit die statische Initialisierung neu durchlaufen wird.

 

[swa00]

Mir wäre nicht bewusst, dass geladene Klassen "entladen" werden und damit die statische Initialisierung neu durchlaufen wird.

Moin deek,

war mir auch anfangs nicht bewusst , bis ich dann den obigen link genau studiert hatte und ich auch deshalb das
Bespiel mit dem PageViewer angebracht hatte .

Ich hatte sogar vor Kurzem noch den Fall, dass eine brutal ständig in den Vordergrund geschobene App deshalb ihren Dienst verweigerte.
Also eine App , die eher eine kontinuierliche Anzeige darstellt, auf der nicht rumgetippt wurde.

Dabei wurde eine non Singelton-Klasse, die zwei/drei Threads verwaltet , einfach abgeschossen.
Anfangs dachte ich , das reicht - dem war dann leider nicht so.
(Übrigens nur bei Pie , Oreo lies sie mir tapfer stehen)

 

[deek]

Hmm, das ist mir mit dem ViewPager klar, der arbeitet ja auf Instanzen.

aber nehmen wir mal wirklich das Beispiel aus dem Thread:

public class InformationSharing {
    public static int counter;
}

...
woanders:
onClick() {
    InformationSharing.counter++;
}

Ich kann aus meiner Erfahrung und auch dem Text oben nicht rauslesen, dass hier counter im laufenden Betrieb wieder auf 0 initialisiert wird.
Der GC ist ja für instanziierte Objekte zuständig, nicht für vom Classloader geladene Klassen. Und letzteres reicht für statische Variablen aus.

Sorry, wenn ich darauf rumhacke, aber bisher hat es mich hier noch nicht überzeugt und vielleicht reden wir auch nur aneinander vorbei.
Es hätte nämlich auch für Singletons ebenfallss weitreichende Konsequenzen, da deren Instanz ja ebenfalls in einer statischen Variable gespeichert wird.

 

[swa00]

Sorry, wenn ich darauf rumhacke,

Quatsch , das ist ein guter und konstruktiver Austausch, sowas müsste es öfters geben

Du hast damit völlig recht - der TE leitete das Thema allerdings damit ein , dass er es nicht versteht , dass er eine unter
Java public deklarierte Klassenvariable nicht Klassenübergreifend einfach verwenden kann.

Daraufhin haben wir ihn schlichtweg nur hingewiesen , dass das vom Erfinder nicht so gedacht ist, es aber Lösungsansätze dazu gibt .
Und das ist uns (Dir/jogi) ja hinreichend bekannt - auch GC/Lifecycle - Das ist also nichts Neues für uns.

Mein Fehler war es dann , ihn explizit auf die GC / LifeCycle hinzuweisen
Und damit nahm die Diskussion ihren Lauf ( hätte ich wohl besser die Klappe gehalten)

 

[jogimuc]

Nein wieso klappe halten.
[doublepost=1563520015,1563519800][/doublepost]War doch auch richtig und sinnvoll.

 

[swa00]

Um an dem Punkt weiter zu bohren - und ich komme auf Jogi und Kotlin zurück .

Was ich bis jetzt immer noch nicht verstanden habe - vielleicht weis das einer von euch :

Warum geht man denn nicht hin und deklariert interne Klassen nicht gleich als Standard Singleton und setzt neben Standards
al la "new" euch eine "clear/delete" Prozedur. (somit ein kontrolliertes Abschiessen)
"= null" haut den memory auch nicht gleich aus dem Stack - ausserdem brutal & tödlich.

Damit wäre man selbst für den memory verantwortlich.
Oder traut man einem Entwickler nicht zu , mitzudenken ?

Was macht Kotlin in dem Falle ?

 

[jogimuc]

Bei einem Singelton wird aber zu Laufzeit von der klasse ein Instanz erstellt und in der statischen klassenvariablen gespeichert.
bei der anderen Methode wird keine Instanz der Variablen umgeben Klasse erstellt. da gibt es kein new.

die wird wie deek sagt vom Classloader erstellt und das wird wohl der GC auch wissen.
[doublepost=1563521209,1563521052][/doublepost]Was macht Kotlin in dem Falle ?

genau das frage ich mich auch, und deshalb haben die Entwickler der Sprache das auch am anfang weg gelassen.

 

[swa00]

die wird wie deek sagt vom Classloader erstellt und das wird wohl der GC auch wissen.

Alles bewusst , nur warum geht man so vor und lässt den GC das wissen -
Was bringt es dem System, nur Teile aufzuräumen - ich rede nicht vom gesamten binary.

Somit auch für uns eine erschwerte Bugsuche

Wenn du einen C/C++ daemon grausam programmierst , macht das System das ja auch so mit,
bis es nicht mehr kann. (Stack Overflow)

 

[jogimuc]

Ja das ist eben Java. Und eine virtuelle maschine.
Damals wollte man es beben etwas einfacher machen mit der Speicherverwaltung als in C. Da java ja auf verschiedenen OS laufen sollte , und es also viele verschiedene Systeme und somit auch Jre gibt.
Es gibt halt verschiedene OS mit unterschiedlichen Speicherverwaltung das wollte man vereinfachen ob es gelungen ist. Darüber kann man streiten.