Projektwerkstatt: iBrowser

Lesetipps

1. Projektwerkstatt: OOPwp
2. Projektwerkstatt: Facebook Extended
3. Projektwerkstatt: CommentAnswerWP

Obwohl ich ja letzte Woche bereits eine Projektwerkstatt hatte, haben wir heute wieder die Ehre eine Idee von mir zu lesen. Irgendwie war ich ein wenig kreativ am Wochenende und das will man ja auch dann zu Papier bringen, um zu hören, was andere denke. Also fangen wir an.

Wir kennen alle das iPhone und iPad. Dort ist der Standardbrowser der Safari. Gutes und stabiles Teil, dass zum normalen Surfen ausreicht. Das Problem ist, es gibt keine Plugin-Schnittstelle. Ich kann also das Tool nicht erweitern, was für mich echt ein K.O. Kriterium ist. Die anderen Browser, die man im App-Store können das auch nicht. Irgendwo habe ich mal gehört, dass man keine Software in den Store bekommt, die nachträglich Programmteile bzw. Erweiterungen nachlädt. Wenn ich meine Tools so sehe, scheint an dem Gerücht auch was dran zu sein.

Jetzt die Idee. Wir bauen einen Browser im Browser. Das sollte dank HTML5, JavaScript und Co. kein Problem darstellen. Dieser bekommt eine Plugin-Schnittstelle. Wenn der Nutzer dort ein Plugin installiert, wird das im Netz gespeichert und kann somit verwendet werden. Wir brauchen dazu also nur noch ein kleines Backend und fertig ist der Lack. Um Rendering und JavaScript muss man sich ja schließlich nicht kümmern, man ist ja sozusagen Schmarotzer bei Safari.

Bei iOs kann ich ohne Probleme diesen Browser auf meinem “Desktop” speichern und ihn auch im Vollbildmodus launchen. Dass das also eigentlich ein Safari ist, wird man nicht merken. Wahrscheinlich gibt es schon viele Browser in Browser Lösungen, aber mit dem Fokus iOs hab ich nichts gefunden.

9 Kommentare »

• 
  

  Dominik Pesch

  am 28. März 2011 um 10:44 Uhr

  Eine insgesamt interessante Idee. Sicherheitstechnisch sicher eine Herausforderung, allerdings zeigt ja z. B. Firebug lite, dass einiges möglich ist.

  Beim Starten im Fullscreen-Modus, muss allerdings bedacht werden, dass die neue Nitro-JS-Engine nicht verwendet wird. Diese wird zur Zeit nur ausschließlich im iOS-Safari selbst verwendet. Siehe auch http://daringfireball.net/2011/03/nitro_ios_43 mit der Analyse von John Gruber.

• 
  

  Christian K.

  am 28. März 2011 um 10:57 Uhr

  Wofür brauchst du auf einem iOS-Gerät einen Browser mit Plugins? Debugging? Da sollte es doch Firebug lite tun. Ich kann deinen Featurewunsch nicht ganz nachvollziehen. Als Proof of concept, um es einfach zu machen, ok. Aber welchen Zweck soll sowas haben? Außerdem bietet Cydia sämtliche bekannten Plugins für den Safari, die man so von den Desktops kennt, an. In der Regel sind diese auch kostenlos.

• 
  

  Jochen

  am 28. März 2011 um 11:18 Uhr

  @Dominik
  Bezüglich der JS-Performanceunterschiede zwischen Safari und dem Web-Container für Apps hat ein Kollege die Tage auch was in unseren Blog geschrieben: http://antwr.ps/-7qwcr

• 
  

  Nils Langner

  am 28. März 2011 um 12:43 Uhr

  @Christian: Naja ich habe zum Beispiel einen Werbeblocker, Deliciousbookmarker, Google/Alexa Rank, Google Mail … als Plugins. Warum muss ich die auf dem iPad missen?

• 
  

  Christian K.

  am 28. März 2011 um 16:18 Uhr

  Google Mail macht doch Push, IIRC. Wozu dann im Browser ein Plugin dafür haben. Das halte ich nun wirklich für absurd. AdBlock habe ich auf meinen iPhones auch installiert. Und das blockt nicht nur im Safari, sondern auch in allen Apps, die das WebKit verwenden. Die Rankings kann man per Bookmarklet abfragen, die man auch schön via MobileMe über sämtliche Geräte synchronisieren kann.

• 
  

  Nils Langner

  am 28. März 2011 um 16:46 Uhr

  @Christian: Das klingt ja so, als ob Browser mit Plugin-Schnittstelle absolut unnötig sind?!

• 
  

  Ralf

  am 28. März 2011 um 17:15 Uhr

  is doch ganz einfach, du programmierst einen browser fürs iPhone, du stellst eine API bereit damit Plugins entwickelt werden können. Diese Plugins werden auf dein system gestellt, von dem sich der iBrowser funktionalitäten nachziehen kann Sozusagen ein App-Store im App-Store

• 
  

  Christian K.

  am 28. März 2011 um 17:53 Uhr

  @Nils Ja, das hört sich in der Tat so an. Ist aber nur auf mobile Geräte bezogen. Wobei dies lediglich meine persönliche Meinung ist, und sonst nicht belegbar. Es gibt Dinge, die fehlen definitiv. Das sind so Sachen wie Adblocker, Firewall oder PGP.

  Die mobilen Geräte sind einfach noch zu schwachbrüstig, als dass man eine offizielle Plugin-API implementieren sollte. Schau dir Firefox an. Wofür wurden SSDs erfunden? Damit man Firefox mit allen “benötigten” Plugins, Addons, Extendions und Themes mit einer ertragbaren Geschwindigkeit benutzen kann.

  Das Problem ist einfach: iOS ist ein geschlossenes System. Wenn iOS oder einzelne Apps plötzlich träge und lahm werden, dass fällt auf Apple zurück. Und ich glaube nicht, dass die ein weiteres Bergwerk für Plugins für den iOS Safari eröffnen wollen, um ein gewisses Mindestmaß an Qualität zu sichern.

  Kurz: im Fall von iOS macht eine Plugin-API beim Safari keinen Sinn. Auch nicht für vermeintlich verantwortungsbewusste Entwickler/Nerds/Geeks, die Wissen, was sie tun. Denn die sind nicht im geringsten die Kernzielgruppe. Kernzielgruppe ist der unbedarfte Otto Normal, der sofort sturmläuft, wenn was nicht mehr funktioniert.

• 
  

  Kevin

  am 29. März 2011 um 10:06 Uhr

  Christians Argumentation folgend würde ich jetzt sagen: Selber schuld Nils, Du hättest besser Android als Plattform gewählt

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar