Code: Alles auswählen
public devplugin.Date getSelectedDay() {
MainFrame mainFrame = (MainFrame) getParentFrame();
if (null == mainFrame) return new devplugin.Date();
return mainFrame.getProgramTableModel().getDate();
}
Code: Alles auswählen
public devplugin.Date getSelectedDay() {
MainFrame mainFrame = (MainFrame) getParentFrame();
if (null == mainFrame) return new devplugin.Date();
return mainFrame.getProgramTableModel().getDate();
}
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);
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?
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.
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.
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...
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.
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)
Das geht doch auch schon...pumpkin hat geschrieben:Die Klarnamen (PluginInfo.getName()) der installierten Plugins wären auch nicht schlecht.