Verletzung der Plugin-Schnittstelle

Hier haben Plugin-Entwickler die Möglichkeit, sich auszutauschen.
pck
Plugin-Developer
Beiträge: 108
Registriert: 26 Jan 2005, 08:59
Wohnort: Ilmenau
Kontaktdaten:

Beitrag von pck »

Gleich noch was ... eine Funktion die das gerade ausgewählte Datum liefert wäre enorm praktisch. Bis LocalImdb 0.15 hatte ich immer das heutige Datum als Default beim execute() verwendet. Selbst ich war ständig verwirrt, und das will was heissen. 8)

Code: Alles auswählen

public devplugin.Date getSelectedDay() {
    MainFrame mainFrame = (MainFrame) getParentFrame();
    if (null == mainFrame) return new devplugin.Date();
    return mainFrame.getProgramTableModel().getDate();
}
pck
Plugin-Developer
Beiträge: 108
Registriert: 26 Jan 2005, 08:59
Wohnort: Ilmenau
Kontaktdaten:

Beitrag von pck »

Til hat geschrieben:

Code: Alles auswählen

void setProgramCookie(Program prog, String key, String value);
String getProgramCookie(Program prog, String key);
@pck: Sag doch mal bitte ein konkretes Szenario, wie du das ganze einsetzen würdest. Was machst du beispielsweise mit den Bewertungen von Bodo?
Gemeint ist sicher @pumpkin.
pumpkin
Gold Member
Beiträge: 236
Registriert: 29 Dez 2004, 10:52
Wohnort: Vichten/Luxemburg
Kontaktdaten:

Beitrag von pumpkin »

pck hat geschrieben:
Til hat geschrieben:@pck: Sag doch mal bitte ein konkretes Szenario, wie du das ganze einsetzen würdest. Was machst du beispielsweise mit den Bewertungen von Bodo?
Gemeint ist sicher @pumpkin.
Wenns so war: ich exportiere die Bewertungen so dass sie auf den Handies angezeigt werden können. Das Midlet kann i.M. Bewertungen, Reminder und Favoriten "erraten". Allerdings nicht besonders zuverlässig. Ich benutze Program.getMarkedByPlugins() und hoffe auf eindeutige Klassennamen.
Benutzeravatar
Til
Site Admin
Beiträge: 1498
Registriert: 04 Dez 2003, 11:21
Wohnort: Karlsruhe
Kontaktdaten:

Beitrag von Til »

bodo hat geschrieben:Ich benutze die Settings-Klasse, aber ohne die kann man an den Stellen nich leben. Es macht also Sinn, die Settings-Klasse zu verschieben, so das die nich mehr im Core ist. Ein Plugin sollte alle Settings auslesen können, nicht nur Tages-Anfang/Ende, oder nich?
Ich finde nicht, dass man das sollte. Die Settings-Klasse erlaubt auch schreibenden Zugriff auf die Einstellungen, wodurch man ziemlich viel Mist machen kann. Außerdem wäre es ein riesen Aufwand, alle Settings rückwärtskompatibel zu halten.

Dann lieber eine extra Klasse für die Plugins über die ausgewählte Einstellungen lesend genutzt werden können. Dort könnte man dann Getter-Methoden anbieten und gegebenenfalls deprecated machen...

Was meint ihr?
Benutzeravatar
Til
Site Admin
Beiträge: 1498
Registriert: 04 Dez 2003, 11:21
Wohnort: Karlsruhe
Kontaktdaten:

Beitrag von Til »

pck hat geschrieben:
til hat geschrieben:Warum muss das das Plugin machen?
Das Plugin muss die Deaktivierung manchmal mit zusätzlichem Code unterstützen. Ihr habt ja daher auch in 1.1 die "onDeactivate()" Funktion hinzugefügt.
OK, verstehe. D.h. mit der Version 1.1 bräuchtest du dann keine eigene Deaktivierung mehr?
pck hat geschrieben:
til hat geschrieben:Das einzige, was nicht mehr rückwärtskompatibel ist, ist der Zugriff auf andere Plugins. Das konnten wir leider nicht retten, weil wir mit der Version 1.1 die Plugin hinter PluginProxies kapseln, so dass RuntimeExceptions abgefangen werden.
Genau, nur hätte man ja erstmal die Funktion deprecated belassen können und meinetwegen eine leere Pluginliste liefern können.
Ja, stimmt. Eine leere Pluginliste könnten wir zurückliefern. Ich habe bisher nur alle deprecated-Methoden so geschrieben, dass sie trotzdem noch funktionieren. Und in diesem Fall geht es einfach technisch nicht, weil niemand mehr direkten Zugriff auf die Plugins hat. Und ich wollte keine Hintertür einbauen, weil dann das ganze Konzept untergraben wäre.

Das mit der leeren Liste bau ich ein. Besser die Plugins bekommen eine leere Plugin-Liste, als eine NoSuchMethod-Exception...
pck hat geschrieben:Und ein Ersatzmechanismus, das Zugriff auf "ungebundene" Methoden anderer Plugins erlaubt ist noch nicht vorhanden. Und selbst wenn er vorhanden wäre könnte ich kein versionsunabhängiges Plugin schreiben, da Reflection hier nur eingeschränkt erlaubt ist.
Wie gesagt: Es hat niemand mehr direkten Zugriff auf Plugins. Das heißt, dass es technisch einfach nicht geht (außer mit einer Hintertür). Deshalb kann man leider kein versionsunabhängiges Plugin schreiben, das auf andere Plugins zugreift.

Aber das ist mir lieber, als eine Hintertür einzubauen.
Benutzeravatar
Til
Site Admin
Beiträge: 1498
Registriert: 04 Dez 2003, 11:21
Wohnort: Karlsruhe
Kontaktdaten:

Beitrag von Til »

pck hat geschrieben:Gleich noch was ... eine Funktion die das gerade ausgewählte Datum liefert wäre enorm praktisch.
Ich denke, das könnten wir zusammen mit der Settingsgeschichte machen. Ich warte erstmal, was bodo und Martin dazu sagen...
Benutzeravatar
Til
Site Admin
Beiträge: 1498
Registriert: 04 Dez 2003, 11:21
Wohnort: Karlsruhe
Kontaktdaten:

Beitrag von Til »

pck hat geschrieben:Gemeint ist sicher @pumpkin.
Ihr seht: Ich bin schon völlig Banane...
Bild
pumpkin hat geschrieben:Wenns so war: ich exportiere die Bewertungen so dass sie auf den Handies angezeigt werden können. Das Midlet kann i.M. Bewertungen, Reminder und Favoriten "erraten". Allerdings nicht besonders zuverlässig. Ich benutze Program.getMarkedByPlugins() und hoffe auf eindeutige Klassennamen.
Ach so, jetzt verstehe ich. Da wäre so eine MetaData-Cookie-was-auch-immer-Sache natürlich 1000 mal sauberer...
Martin
Site Admin
Beiträge: 2357
Registriert: 03 Dez 2003, 21:45
Kontaktdaten:

Beitrag von Martin »

Til hat geschrieben:Dann lieber eine extra Klasse für die Plugins über die ausgewählte Einstellungen lesend genutzt werden können. Dort könnte man dann Getter-Methoden anbieten und gegebenenfalls deprecated machen...
ja, find ich ok so. Da müssen dann aber nicht alle Einstellungen angeboten werden, sondern nur jene, die ein Plugin evtl. brauchen kann.

Gut wäre auch ein Getter für das TV-Browser-Home-Verzeichnis
pumpkin
Gold Member
Beiträge: 236
Registriert: 29 Dez 2004, 10:52
Wohnort: Vichten/Luxemburg
Kontaktdaten:

Beitrag von pumpkin »

Und eine Liste der im Moment sichtbaren Sendungen (damit man für Markierungen wie sie z.B. NewsFeed macht nicht alles durchsuchen sondern nur einen Tag durchgehen muss)

Die Klarnamen (PluginInfo.getName()) der installierten Plugins wären auch nicht schlecht.
pck
Plugin-Developer
Beiträge: 108
Registriert: 26 Jan 2005, 08:59
Wohnort: Ilmenau
Kontaktdaten:

Beitrag von pck »

Til hat geschrieben:
pck hat geschrieben:Und ein Ersatzmechanismus, das Zugriff auf "ungebundene" Methoden anderer Plugins erlaubt ist noch nicht vorhanden. Und selbst wenn er vorhanden wäre könnte ich kein versionsunabhängiges Plugin schreiben, da Reflection hier nur eingeschränkt erlaubt ist.
Wie gesagt: Es hat niemand mehr direkten Zugriff auf Plugins. Das heißt, dass es technisch einfach nicht geht (außer mit einer Hintertür). Deshalb kann man leider kein versionsunabhängiges Plugin schreiben, das auf andere Plugins zugreift.
Lasst uns erstmal zwei Probleme auseinanderhalten:

A) Versionsunabhängigkeit ist nicht gut machbar weil Plugins keine Aufrufe über die Reflection-API machen dürfen während die TVBrowser-APIs nicht abwärtskompatibel sind.

B) In TVBrowser 1.0.1 konnte man über Plugins an ungebundene "Aktionen" für Programme kommen. In TVBrowser 1.1cvs kann man über PluginAccess nur an gebundene "Aktionen" kommen. Es ist ok, dass ihr direkten Zugriff auf Plugins verhindert. Ich finde es aber schade, dass es beim PluginAccess keine ZUSÄTZLICHE Schnittstelle gibt, bei der ich "Aktionen" erhalte, die erst beim Aufruf an eine konkrete Sendung gebunden werden.

Code: Alles auswählen

interface devplugin.UnboundProgramAction {
  String getId();
  String getName();    // oder "Action getPlaceholderAction()"
  Action bindAction(devplugin.Program prog); // may return null
}
Das ist technisch kein Problem und der Anwender könnte auch weiterhin kontextabhängige Defaultaktionen auswählen.
Benutzeravatar
Til
Site Admin
Beiträge: 1498
Registriert: 04 Dez 2003, 11:21
Wohnort: Karlsruhe
Kontaktdaten:

Beitrag von Til »

Martin hat geschrieben:
Til hat geschrieben:Dann lieber eine extra Klasse für die Plugins über die ausgewählte Einstellungen lesend genutzt werden können. Dort könnte man dann Getter-Methoden anbieten und gegebenenfalls deprecated machen...
ja, find ich ok so. Da müssen dann aber nicht alle Einstellungen angeboten werden, sondern nur jene, die ein Plugin evtl. brauchen kann.

Gut wäre auch ein Getter für das TV-Browser-Home-Verzeichnis
Aber es ist doch besser, dafür eine eigene Klasse zu spendieren, oder sollte das ganze in den devplugin.PluginManager?
Benutzeravatar
bodo
Site Admin
Beiträge: 19635
Registriert: 03 Dez 2003, 19:37
Wohnort: Köln
Kontaktdaten:

Beitrag von bodo »

Eigene Klasse macht mehr Sinn. Und vergesst die Zeit-Knöpfe nicht, die brauch ich im ListView-Plugin ;)
Benutzeravatar
Til
Site Admin
Beiträge: 1498
Registriert: 04 Dez 2003, 11:21
Wohnort: Karlsruhe
Kontaktdaten:

Beitrag von Til »

pumpkin hat geschrieben:Und eine Liste der im Moment sichtbaren Sendungen (damit man für Markierungen wie sie z.B. NewsFeed macht nicht alles durchsuchen sondern nur einen Tag durchgehen muss)
Im PluginManager gibt es doch "getSubscribedChannels()" und "getChannelDayProgram(Date, Channel)".

Wenn du jetzt noch den aktuellen Tag bekommst, dann hast du doch alles, was du brauchst, oder?
pumpkin hat geschrieben:Die Klarnamen (PluginInfo.getName()) der installierten Plugins wären auch nicht schlecht.
Das geht doch auch schon...

Die Plugin-Schnittstelle ist jetzt schon recht umfangreich. Ich würde das ungerne mit "praktischen" Hilfsmethoden überfrachten. Es könnte sonst leicht passieren, dass neue Plugin-Entwickler von zu vielen Methoden überfordert werden...
Benutzeravatar
Til
Site Admin
Beiträge: 1498
Registriert: 04 Dez 2003, 11:21
Wohnort: Karlsruhe
Kontaktdaten:

Beitrag von Til »

@pck: Die Sache mit den "gebundenen" und "ungebundenen" Methoden kapier jetzt nicht so ganz. Erklär's doch bitte nochmal für Dumme... :wink:
Martin
Site Admin
Beiträge: 2357
Registriert: 03 Dez 2003, 21:45
Kontaktdaten:

Beitrag von Martin »

Til hat geschrieben:Aber es ist doch besser, dafür eine eigene Klasse zu spendieren, oder sollte das ganze in den devplugin.PluginManager?
ja, eine eigene Klasse mit den Settings. Aber im PluginManager eine Methode getSettings()...
Antworten