Code: Alles auswählen
public devplugin.Date getSelectedDay() {
MainFrame mainFrame = (MainFrame) getParentFrame();
if (null == mainFrame) return new devplugin.Date();
return mainFrame.getProgramTableModel().getDate();
}Verletzung der Plugin-Schnittstelle
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.
Gemeint ist sicher @pumpkin.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?Code: Alles auswählen
void setProgramCookie(Program prog, String key, String value); String getProgramCookie(Program prog, String key);
-
pumpkin
- Gold Member
- Beiträge: 236
- Registriert: 29 Dez 2004, 10:52
- Wohnort: Vichten/Luxemburg
- Kontaktdaten:
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.pck hat geschrieben:Gemeint ist sicher @pumpkin.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?
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.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?
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?
OK, verstehe. D.h. mit der Version 1.1 bräuchtest du dann keine eigene Deaktivierung mehr?pck hat geschrieben: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.til hat geschrieben:Warum muss das das Plugin machen?
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.pck hat geschrieben:Genau, nur hätte man ja erstmal die Funktion deprecated belassen können und meinetwegen eine leere Pluginliste liefern können.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.
Das mit der leeren Liste bau ich ein. Besser die Plugins bekommen eine leere Plugin-Liste, als eine NoSuchMethod-Exception...
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.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.
Aber das ist mir lieber, als eine Hintertür einzubauen.
Ihr seht: Ich bin schon völlig Banane...pck hat geschrieben:Gemeint ist sicher @pumpkin.
Ach so, jetzt verstehe ich. Da wäre so eine MetaData-Cookie-was-auch-immer-Sache natürlich 1000 mal sauberer...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.
ja, find ich ok so. Da müssen dann aber nicht alle Einstellungen angeboten werden, sondern nur jene, die ein Plugin evtl. brauchen kann.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...
Gut wäre auch ein Getter für das TV-Browser-Home-Verzeichnis
Lasst uns erstmal zwei Probleme auseinanderhalten:Til hat geschrieben: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.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.
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
}Aber es ist doch besser, dafür eine eigene Klasse zu spendieren, oder sollte das ganze in den devplugin.PluginManager?Martin hat geschrieben:ja, find ich ok so. Da müssen dann aber nicht alle Einstellungen angeboten werden, sondern nur jene, die ein Plugin evtl. brauchen kann.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...
Gut wäre auch ein Getter für das TV-Browser-Home-Verzeichnis
Im PluginManager gibt es doch "getSubscribedChannels()" und "getChannelDayProgram(Date, Channel)".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)
Wenn du jetzt noch den aktuellen Tag bekommst, dann hast du doch alles, was du brauchst, oder?
Das geht doch auch schon...pumpkin hat geschrieben:Die Klarnamen (PluginInfo.getName()) der installierten Plugins wären auch nicht schlecht.
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...