Beiträge von Marco Feltmann

Vielleicht muss man auf dem Note noch den Buffer irgendwie flushen, damit er nicht nur aktualisiert sondern komplett neu zeichnet.

Ah. In meiner Welt ist 'jemand' == 'ich'. Also nicht 'jemand' == 'Marco' sondern 'jemand' == 'derjenige, der die Aussage tätigt'.
Daher hab ich das wohl ein wenig überinterpretiert.

Zitat von Kogoro-Christopher

Warum was neues, wenn es das schon gibt?

Spieltrieb.

Natürlich geht so etwas.
Du könntest Dir auf parse.com ein Backend zusammenschrauben, bräuchtest ein Verwaltungstool, welches parse.com mit den aktuellen Spieldaten füttert, schickst die Notification raus und lässt Deine Jungs antworten.
Dann kannst Du Dein Verwaltungstool noch darüber informieren lassen wenn eine Antwort kam und kannst diese dann in Dein Excel Dokument übernehmen.
Oder aber Dein Backend berechnet nach Erreichen der Deadline für die Tipps und nach Eintragen der Ergebnisse durch Dich dann die einzelnen Punkte und führt eine aktuelle Tabelle.

Da geht einiges.
Ist allerdings alles mit Arbeit verbunden und vermutlich nicht in zwei Wochen gebaut.

Gibt doch ein GridLayout.

Damit legst Du eine Instanzvariable an. Ob die jetzt aus Deinem eingeschobenen Code kommt oder aus einer eigenen Datei ist ja egal.

In einem anderen ListView wirst Du da allerdings nicht mehr ran kommen.

Zitat von ChampS

Also ich finde das die einzelnen Listener Objekte genauso gut wiederverwendbar sind wie eine einzelne Klasse.

Dann erklär mir bitte mal, wie Du ein und denselben dynamisch generierten Listener drei unterschiedlichen Buttons zuweist.

Schicken Broadcasts keine Intents?

Den beschriebenen Beitrag finde ich gar nicht.

Insofern versuche ich das hier zu erklären:
Wenn Du <Klasse> implements ActionListener machst, dann leitest Du eine neue Klasse ab, Du nutzt also die Vererbung.
Sagen wir, Du hast 9 unterschiedliche Buttons die das Gleiche tun. Dann kannst Du mit .setActionListener(this) jedem dieser Buttons Deine Klasse zuordnen und hast die Aktion an zentraler Stelle.

Sagen wir, Du Du hast 9 unterschiedliche Buttons die unterschiedliche Dinge tun. Dann kannst Du mit .setActionListener(this) jedem dieser Buttons Deine Klasse zuordnen und hast die Aktion an zentraler Stelle. In diesem Fall musst Du die einzelnen Button irgendwie unterscheiden können.
Oh, und ellenlange if Abfragen und switch Statements sind einerseits schwer zu lesen und andererseits schwer zu debuggen.

Du kannst natürlich jedem der Buttons eigene Implementierungen eines ActionListener geben. .setActionListener(new ersteButtonActionListener())
Damit legst Du für jede Aktion eine neue Klasse an.
Die Variante .setActionListener(new ActionListener () { onAction() {} } ) zentralisiert das Ganze in eine einzige Klasse, so dass Du eben keine 9 einzelnen Dateien herumfliegen hast.
Hier nutzt Du also nicht die Vererbung, sondern erstellst dynamisch konkrete Instanzen eines abstrakten Interface, die völlig unabhängig und losgelöst voneinander existieren.

Tutorials sind ja kein Produktivcode. Da wird Dir nur gezeigt wie etwas grob funktioniert. Die Konzepte richtig anzuwenden musst Du schon selbst lernen.

Die Frage, welche Variante man nimmt, hängt also immer davon ab, was genau man zu erreichen versucht.
Dazu könnte es hilfreich sein, die Vor- und Nachteile zu kennen.

Eigene Einzelklasse:
Pro:

• Kapselung
• Zentraler Zugriff
• Wiederverwendbar

Contra:

• Verleitet zur unübersichtlichen Verschachtelung bei Trennung der aufrufenden Objekte

Eigene mehrere Klassen:
Pro:

• Wiederverwendbar

Contra:

• Bei starker funktionaler Ähnlichkeit mehrere Dateien zu pflegen

Dynamisch erzeugte Objekte:
Pro:

• Schnell implementiert
• Leicht zu testen

Contra:

• Schlecht wiederverwendbar
• Verleitet bei ähnlicher Funktionalität zu doppeltem Code
• Schwer zu lesen

Man sieht also: Das beste Pro:Contra Verhältnis (3:1) hat die einzelne eigene Klasse.

Bei den meisten UI Implementierungen tun die 9 Buttons auch alle das Gleiche – nur halt mit unterschiedlichen Werten.
Alle spielen einen Sound ab – aber jeder einen Anderen. (SoundBoard)
Alle öffnen einen neuen Screen – aber jeder einen Anderen (Button-Navigation)
Alle tragen eine Ziffer in das Display ein – aber jeder eine Andere (Wähltasten, Taschenrechner, OnScreen Tastatur…)
Alle navigieren zu einer Seite – aber jeder zu einer Anderen. (Browsertasten: Zurück/Reload/Nächste)

Klar gibt es bei einigen UI unterschiedliche Aktivitäten pro Button, beispielsweise im Dateimanager Kopiere/Verschieben/Löschen.
Da sollten das dann eine Klasse pro Listener werden.

HTH

~ Doppelpost ~

Na, da nimmst Du Dir aber viel heraus.
Wenn die folgenden Zeilen bei Dir das Gefühl auslösen, ich würde zu einem pubertierenden 14jährigen schreiben: Das liegt daran, dass Du Dich wie ein pubertierender 14jähriger aufführst.

Ich verteidige keinesfalls, dass die Programmierung so kompliziert ist. Es wäre unglaublich genial, wenn man sich hinsetzen könnte, eine Zeichnung des User Interface erstellen würde, in ein paar einfachen Sätzen genau beschreiben würde, was die App wann macht und nach Drücken auf einen Knopf wird daraus dann die gewünschte App erstellt.
DAS wäre großartig. Jeder könnte das Programm für das Gerät haben, das er braucht.
Die Automatisierung würde vorangetrieben, das digitale Bewusstsein der Menschen würde sich erweitern und niemand wäre mehr auf Softwarehersteller angewiesen.
(Bitte erst erfinden, wenn es das bedingungslose Grundgehalt gibt – dann bin ich nämlich zunächst einmal arbeitslos.)

Es gibt bereits diverse Ansätze, mit denen sich durch das Geschiebe grafischer Elemente logische Zusammenhänge darstellen und kleine Programme 'zeichnen' lassen.
Lego Mindstorms™ fällt mir da spontan als bekannteste Variante ein.

Im Übrigen ist javac+java auch nur so lange einfach, solange Du da keine Abhängigkeiten hast. Sobald Du mehr als eine .java Datei einbindest (und man kann HalloWelt prima auf zwei Dateien auslagern), benötigst Du eine Manifest Datei, die definiert, welche der generierten Klassen jetzt Dein Einstiegspunkt ist.
Und schon klappt das mit nur einem Codesnippet hinten und vorne nicht mehr.
Das liegt nicht an uns und nicht an der Programmierung, das liegt an der Funktionsweise von Java.
Unter C/C++ hast Du das Problem eher nicht, allerdings darfst Du da noch mit einem Linker herumhanitieren, wenn Du zusätzliche Komponenten nimmst.

Nun zu Deinem Problem:
Du fragst uns ob das einfacher geht, wir sagen 'Nö. Ist so gestrickt, geht nicht einfacher.'
Dann meckerst Du rum, wir würden den alten festgefahrenen Scheiß verteidigen. Das ist Blödsinn. Wir teilen Dir lediglich mit, dass Dein Vorhaben nicht umzusetzen ist, weil Java komplett anders funktioniert.
Wenn Du gefragt hättest, was wir davon halten würden, wenn es eine Möglichkeit gäbe ganz einfach ein Programm zu erstellen – einfach ein paar Zeilen Code tippen und fertig – dann wäre ich total auf Deiner Seite gewesen.
Gut, ich hatte nicht viel Compilerbau und muss sagen, so ganz trivial wird das sicherlich nicht sein. Aber egal.
Es geht hier aber nicht um eine esoterische zukünftige Welt, sondern um die aktuell reale Umgebung. Und da hast Du einfach zu viele Einstellungsmöglichkeiten und –pflichten, als dass Du auf Knopfdruck aus einem Codeschnippsel eine App produzieren könntest*

Aktuell wird Softwareentwicklung noch als Handwerk bezeichnet, weil es so kompliziert ist. Und das meint nicht nur die Programmierung an sich sondern vor allem die Softwarearchitektur.
Den Kram zu vereinfachen würde ein ähnliches Ergebnis haben wie alles in der IT: Es wird für alle einfacher zu benutzen, aber immer schwerer zu verstehen. Und schlussendlich ist man doch wieder auf Andere angewiesen.
(Wann hast Du das letzte Mal bei Deinem Laptop die BIOS Batterie rausgenommen, weil Dein SmartCard Reader defekt war und Du die Sicherheitseinstellungen des Gerätes zurücksetzen musstest? Ist bei mir ungefähr 10 Jahre her. Hat mich damals 120€ gespart. Heute komme ich nicht umhin mit den Dingern zum Fachmann zu gehen…)

*) Es wäre natürlich theoretisch denkbar und möglich, dass man aus einem Snippet eine Standard-Main-Activity generiert die sich dann idealerweise auch noch um die Imports kümmert und auch noch die notwendigen Berechtigungen in die Manifest einträgt. Da kannste dann Deine gefundenen Snippets zügig testen. Also, relativ zügig. Das ganze Zusammengeschustere wird länger dauern als ein Projekt anlegen und es da hineinzukopieren.
Hinzu kommt, dass diese automatisierten Verfahren im Allgemeinen nicht allzu viel taugen. Es gibt etliche Ansätze, die das Lernen neuer Programmiersprachen erleichtern wollen, in dem sie die Möglichkeit bieten, Code in der gewohnten Programmiersprache zu übersetzen. Das klappt aber nur bei Standardfällen, und auch da nur zu ca. 80%.
Programmieren hat aber nichts mit Standardfällen zu tun. Wir lösen jeden Tag Probleme, die wir vorher noch nie hatten (und sollen im Vorfeld auch noch wissen wie lange wir dafür brauchen.)
Dabei hilft es, sich mit unbekannten Problemen auseinanderzusetzen statt auf eine simple Lösung zu warten. Also fang am Besten gleich mal damit an.
Beispielsweise, indem Du Dir Deinen gewünschten vereinfachenden Service selbst baust.

Das Problem an SQLite Datenbanken ist ja, dass sie dateibasiert sind.
Solange Du also irgendwo lesend irgend ein Bild aus Deiner Datenbank lädst, hast Du keinen Zugriff auf weitere Daten aus Deiner Datenbank.
Mag bei modernen Geräten mittlerweile egal geworden sein, ich bin da ein wenig altmodisch.

Eine weitere Sache, die meiner Meinung nach gegen BLOBs spricht, ist die Zugriffsfähigkeit.
Die ist stumpf nicht vorhanden.

Wenn die Dinger in eine Datenbank eingetragen werden (können), dann hat der User ja irgendwie dafür gesorgt, dass die Daten da drin liegen.
Sagen wir, er hat ein Foto geschossen oder eine Sprachaufzeichnung gemacht.

Wenn er dieses Foto oder diese Sprachaufzeichnung jetzt beispielsweise auch noch per WhatsApp an seine Schwester schicken möchte, dann muss er sich darauf verlassen, dass Deine App eine 'Sharing' Funktion für WhatsApp, eine Exportfunktion oder ähnlichen umständlichen Kram anbietet.
Schlimmer noch: das Foto wird einerseits auf dem Dateisystem abgelegt und in der Datenbank Deiner App. Jetzt löscht er das Foto, weil er beim Versuch sein gebrochenes Bein zu fotografieren sein Geschlechtsteil mit im Bild eingefangen hat, was ihm unangenehm ist.
Der nächste, der dann Deine App aufmacht, findet das Foto, exportiert es und stellt es öffentlich auf Facebook – dumm, da der User eigentlich davon ausgehen konnte, dass das Bild weg ist.

Ich bin ja der Auffassung, in Datenbanken gehören all diejenigen veränderbaren Dinge, die der App gehören: Texte.
Alle anderen veränderbaren Dinge gehören der App nicht, ergo haben sie auch nichts in einer Datenbank verloren.

Wenn sie alle was Anderes machen ist es sinnvoller, jedem seinen eigenen OnClickListener zu geben.
Wenn sie alle dasselbe machen, ist es sinnvoller, ein und denselben OnClickListener zu benutzen.

Wenn sie alle dasselbe mit anderen Werten machen (Beispielsweise diese dusseligen Soundboards), ist es sinnvoll, ein und denselben OnClickListener zu benutzen und den Buttons die Werte, die anders sind, mitzugeben.
(Beispielsweise einen Standardbutton um einen String 'mediafile' erweitern und in der onClick eben diesen String auszulesen und an Hand dessen dann das Soundfile zu laden)

Im Normalfall immer dann, wenn die gewünschte Sprache nicht gefunden wurde.
Nimm beispielsweise mal Finnisch.

(Ist natürlich nur dann sinnvoll, wenn die normale strings.xml andere Werte enthält als de/strings.xml)

Wenn das Dein Anwendungsfall ist, sollte der überflüssig sein.
Das sollte das System doch schon berücksichtigen.

Ansonsten:

static public String getString(String resourceText) {
  int a = Variables.mainActivity.getResources().getIdentifier(resourceText, "string", Variables.mainActivity.getPackageName());
  return Variables.mainActivity.getString(a);
}

Aber auch das müsste eigentlich heftig schief gehen, weil in den Standardfiles herumgesucht wird.

Was genau willst Du Dir damit eigentlich vereinfachen?

Na, dann bleibt ja nur noch zu erwähnen, dass BLOBs in Datenbanken immer eine unglaublich schlechte Idee sind und Du lieber Pfadangaben hinterlegen solltest.

Zitat von ChampS

Du brauchst immer einen Context

Das kann ich so nicht stehen lassen.
Du brauchst den Context eben nicht immer, sondern nur, wenn Du auf Methoden des Contexts zugreifen willst.
getSharedPreferences() ist so eine Methode.

ChampS

Er bezieht sich auf folgendes Snippet:

public class MainActivity extends Activity {
    // …
    String ring="x123.y456";
    TextView textview1;
    TextView textview2;
    // …
    protected void aufteilen() {
        String[] parts = ring.split(".");
        textview1.setText(parts[0]);
        textview2.setText(parts[1]);
    }
    // …
}

Die Methode aufteilen() gibt es, sie ist nur keine Instanzmethode von string.
Ich denke, beim Verständnis von Instanzmethoden bzw. wem sie gehören gibt es ein paar Verständnisprobleme seitens
gammel.

In dem Fall solltest Du vielleicht einen ViewPager nutzen:

https://developer.android.com/…imation/screen-slide.html
https://developer.android.com/…rt/v4/view/ViewPager.html

Spannend bleibt natürlich die Frage nach der Implementierung, denn eigentlich will man ja gar keine x Tabs sondern immer nur ein Fragment/View überschreiben.

Ich glaube, ich spiel mal kurz.

Was genau ist denn ring? Wenn das ein String ist, dann kennt der aufteilen() natürlich nicht.
Genau genommen dürfte es aufteilen() überhaupt nicht kennen, sofern es keine MainActivity ist…

Dein Vorhaben funktioniert so nicht*

Im Prinzip hast Du zwei Möglichkeiten.
In der onCreate() am Ende einfach aufteilen() aufrufen oder das Ganze ein bisschen umbauen und eine Art teileUndSetze(String) erstellen.

public void splitAndPopulate(String value) {
  ArrayList<String> substrings = value.split(".");


  if( substrings.length > 0 ) { 
    textview1.setText(substrings.objectAtIndex(0));
  }


  if( substrings.length > 1 ) {
    textview1.setText(substrings.objectAtIndex(1));
  }


}

*) unter Android. Unter iOS würdest Du einfach eine Kategorie auf NSString bauen, die das kann. Wäre allerdings sinnlos, da es schon einige Funktion zum Aufteilen gibt.