ImageViews in OnCreate-Methode positionieren

  • Guten Tag!


    Also ich bin neu hier und ebenfalls neu beim Andtroid-basteln.
    Meine Programmierkenntnisse beschränken sich fast ausschließlich auf Delphi - ich bin also kein Programmieranfänger aber ein absoluter Javafrischling! Der Umstieg auf Java und Android ist da schon etwas gewöhnungsbedürtig - ist aber spannend und interessant. Ich habe bereits ein Anfänger Android-Buch und ein Anfänger-Java-Tutorium durchgrackert, programmieren lernt man aber nur beim Tun - und darum bin ich hier.


    Und hier meine ersten 2 Fragen:


    1) Ist es korrekt, dass sämtliche Instanzen, insbesondere auch jene, welche ich mit "new" erzeugt habe, beim Beenden des Programmes vom Programmierer nicht mehr freigegen werden müssen? Also ich muss mich nie zu keinem Zeitpunkt über eine Freigabe des Speichers kümmern?


    2) Mein erste App soll beim Start mehrere Bilder pixelgenau auf dem Bildschirm an verschiedenen Stellen positionieren ( Die Kontrolle über die Bildschirmabmessungen erhalte ich über die display.getWidth() u.s.w.-Methoden - das passt soweit). Diese Bilder sollen mit dem onTouch-Event dann nachträglich verschoben werden können.


    Hierzu lade ich dynamisch in der onCreate-Methode die z.B. 5 Bilder in 5 ImageViews. Diese ImageViews liegen in einem FrameLayout. Nun kann ich aber nicht die Position der ImageViews in der onCreate-Methode festlegen, da die Methode imageView1.layout(l,t,r,b) im onCreate noch nicht funktioniert. Wie setze ich die Views an meine gewollten Koordinaten?


    Ich hoff, ich hab mich halbwegs klar artikuliert?!




    Vielen Dank für gute Anrworten ;)
    Martin

  • Da ich zu faul war etwas selber zu schreiben, zitiere ich mal - der Mechanismus unter Java nennt sich Garbage Collector


    Zitat


    Java verwaltet den dynamischen Arbeitsspeicher vollkommen selbständig. Der Programmierer muss nicht Sorge für die Allokation und korrekte Freigabe des Speichers tragen. Realisiert wird dies über einen speziellen Prozess, der ständig im Hintergrund der JVM mitläuft. Er prüft, ob ein Objekt noch länger verwendet wird und gibt dessen allokierten Speicherbereich gegebenenfalls frei.


    An dieser Stelle gilt es zu unterscheiden. Java behandelt lokale Variablen und Klassenobjekte differenziert. Der Garbage Collector gibt den Speicher allerdings nur in gewissen Intervallen frei, also wenn er als niedrig laufender Prozess entscheidet. Daher kann es zu Verzögerungen kommen, wenn Objekte bereits nicht mehr verwendet werden. Es besteht aber auch die Möglichkeit, diesen Prozess über das System direkt aufzurufen.


    Hmm zu den folgenden Fragen, was soll es den werden mit den Images ???


    Eventl ist es einfacher dir ein eigenes Control (so hiess das damals unter Delphi :) ) zu bauen. Also in Android/Java kannst du Dir zb einen View ableiten und dort das onDraw überschreiben. Ich habe das mal für ein Puzzle gemacht (da werden die Images auch verschoben) und da sieht das in etwas so aus


    Zitat


    public class PuzzleView extends View implements View.OnTouchListener{


    Wie gesagt, ich würde jetzt davon abhängig machen was du vor hast. Hier noch etwas Lesestoff zum Thema "eigene Views"


    http://mindtherobot.com/blog/2…ng-a-vintage-thermometer/

  • 1) Ja, das ist leider richtig. Java hat diese Unart, genannt 'Garbage Collection'. Das Ding ist auch 'Garbage', collected sich aber leider nicht selbst. ;)
    --
    Zur Erläuterung, damit das nicht als Meckern und Trollen aufgefasst wird:
    Gemäß diversen Prüfungen von Matthew Hertz und Emery D. Berger aus dem Jahre 2005 ist Garbage Collection im Vergleich zu manueller Speicherverwaltung ein Ressourcenfresser, dessen Aufwand in keinem Verhältnis zum Nutzen steht.
    (OOPSLA’05, October 16–20, 2005, San Diego, California, USA. Copyright 2005 ACM 1-59593-031-0/05/0010)


    Ich bin mir ziemlich sicher, dass die Jungs das völlig objektiv bewerten und einschätzen können.
    Falls jemanden diese Ausarbeitung interessiert:
    http://ebookbrowse.com/gcmalloc-oopsla-2005-pdf-d359475443


    Und zusammengekürzt für die tl;dr Fraktion der meiner Meinung nach wichtige Punkt aus dem Fazit:

    Zitat

    Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower.


    2) Also ich finde deine Artikulation passend. :)
    Das Problem ist nur, dass dein Vorhaben so vermutlich nicht laufen wird.
    Ich sehe leider nicht, was genau dein FrameLayout jetzt genau ist, befürchte aber, dass der seine eigene Vorstellung davon hat wie Views platziert werden.
    Die Doku sagt dazu:

    Zitat

    FrameLayout is designed to block out an area on the screen to display a single item. Generally, FrameLayout should be used to hold a single child view, because it can be difficult to organize child views in a way that's scalable to different screen sizes without the children overlapping each other. You can, however, add multiple children to a FrameLayout and control their position within the FrameLayout by assigning gravity to each child, using the android:layout_gravity attribute.
    http://developer.android.com/r…d/widget/FrameLayout.html


    Eventuell macht ja ein GridLayout eher was du möchtest,

    Zitat

    A layout that places its children in a rectangular grid.


    was ich mir bei 5 Bildern aber nur schwerlich vorstellen kann (es sei denn, es soll ein Jigsaw-Puzzle werden: in dem Fall halte dich an kilphil75s oder ChampS' Tipps.)

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Vielen Dank für die ausführlichen Antworten. Mir ist vieles klarer geworden
    .. aber noch nicht alles :P


    zu 1)
    das mit den "ich kümmere mich in Zukunft nullundnix um eine gescheite
    Speicherfreigabe" find ich gar nicht übel; auch wenn es stark auf die
    Performance drückt, werden hier doch automatisch viele Fehlerquellen des
    Programmierers verhindert.


    zu 2)
    Die Idee mit dem FrameLayout war wohl nicht die Glücklichste. Mit einem
    eigenen Controll schaut's schon viel besser aus. Übrigens möcht ich zum Start eine Art Schiebepuzzle machen; ich glaub, hier streife ich gleich einige sehr interessante Themen... Was mir nicht so einleuchtet, warum implementierst Du, killphil75, das View.OnTouchListener in die View-Klasse

    Zitat


    public class PuzzleView extends View implements View.OnTouchListener{

    wo doch diese ein OnTouchEvent-Methode zum überschreiben anbietet. Vermutlich geht beides? Ich habs mit beiden Varianten versucht und bin nicht zufrieden. Hier reagiert nur der code vom ACTION_DOWN! Warum das??




    soweit trivial, nun wird's aber für mich noch nicht ganz rein:



    Bei der Variante mit dem Implementieren geht bei gleichem Code gar nix!?!



    Irgentwas kleines fehlt noch!

  • Hmm warum in den onTouch Listener nehme, wenn ich ehrlich bin muss ich sagen, ich weiss es nicht mehr, bilde mir aber ein, das es irgnedwas mit Multitouch und Gesten zu tun hatte.


    im onCreate steht noch das bei mir

    Java
    this.setOnTouchListener(this);


    und der Listener sieht so aus


  • Hallo killphil75, danke für Infos, habe es mit Deinem System immer noch nicht hingekrigt, aber so funktioniert es nun doch:
    Ich habe in der Activiy-Klasse eine Listener-Klasse geschrieben und die zugehörigem Listener-Objekte beim View-Element registriert. In der MyView-Klasse habe ich alle onTouch-Methoden rausgeschmissen. Wen's interessiert, hier der Code



    Auch wenn es nun klappt, ich würde aber trotzdem gerne wissen was bei meinen vorigen Versuchen falsch war. Ich glaub, der Fehler lag daran, dass ich die OnTouch-Objekte (aus der MyView-Klasse) in der onCreate bei dem myView hätte registrieren müssen, hab aber nicht rausgefunden wie das ginge, z.B. myView.onTouchListener(this) war es gar nicht erlaubt. Und warum funtionierte trotzdem immer der ACTION_DOWN-Teil?


  • zu 2)
    Die Idee mit dem FrameLayout war wohl nicht die Glücklichste. Mit einem
    eigenen Controll schaut's schon viel besser aus. Übrigens möcht ich zum Start eine Art Schiebepuzzle machen; ich glaub, hier streife ich gleich einige sehr interessante Themen... Was mir nicht so einleuchtet, warum implementierst Du, killphil75, das View.OnTouchListener in die View-Klasse


    Naja so speicherlastig ist das nicht, der Garbage Collector räumt halt nach einer gewissen Zeit den nichtbenutzen Speicher frei.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!