Suche
Mobile-Entwicklung mit und ohne Eclipse: eine Retrospektive

IDEs der Steinzeit

Tam Hanna

Tausende Android-Entwickler beginnen ihren Arbeitstag mit dem Anwerfen einer auf Eclipse basierenden Entwicklungsumgebung. Wer früher mit anderen Umgebungen gearbeitet hat, kann über die „Schwächen“ heutiger IDEs nur lachen.

Das zehnjährige Jubiläum des Eclipse Magazins nehmen wir als Anlass für eine kleine Zeitreise in die Mobile-Vergangenheit. Es gab – man mag es bei der Lektüre heutiger Medienberichte kaum glauben – nämlich auch vor iPhone und Android Horden von Handcomputerprogrammierern.

Die damaligen Arbeitsbedingungen sind mit den heutigen in keiner Weise vergleichbar. Damalige Handhelds mussten mit wenigen Kilobytes Arbeitsspeicher auskommen, die IDEs waren von der Perfektion heutiger Systeme meilenweit entfernt. Die Erstellung anspruchsvoller Programme setzte eine Vielzahl von Tricks voraus: Datenstrukturen wurden mitunter auf kariertem Papier entworfen, um einige Bytes Speicher einzusparen. Dazu kam das – gelinde gesagt – miserable Sozialprestige im deutschsprachigen Raum. Wer einen Handcomputer hatte, war ein internetsüchtiger und asozialer Wichtigtuer. Die diversen Vorteile immer verfügbarer Rechenleistung und maschineller Unterstützung im Alltag wurden in Westeuropa nicht verstanden und/oder verdrängt.

An dieser Stelle sei – allem Zeitgeist zuwiderlaufend – angemerkt, dass die Türkei in dieser Hinsicht immer eine Ausnahme war. Als der Autor vor vielen Jahren mit seiner Frau dienstlich in einem Businesshotel in Antalya aufschlug, waren wir normale Gäste. Ein Barkeeper stellte zufällig fest, dass die Tamoggemon an einer nie veröffentlichten Gruppe von Spielen für Treos arbeitete. Ab diesem Zeitpunkt fanden wir uns in der unangenehmen Situation des VIPs wieder. Der Hoteldirektor bat um eine Vorführung der Spiele für seine Mitarbeiter – er dürfte bis heute der einzige Besitzer einer legalen und voll bezahlten Lizenz von TypeGun sein.

Befreiungsschlag Eclipse

Palm-OS-Entwickler arbeiteten von Anfang an in einer als CodeWarrior bezeichneten IDE. Der Untergang des mittlerweile in Motorolas Halbleitersparte Freescale aufgegangenen Unternehmens wäre Thema für einen eigenen Artikel. Wir wollen uns hier darauf beschränken, dass diverse Ursachen die Weiterentwicklung des Produkts wesentlich verlangsamten und am Ende ganz zum Erliegen brachten.

PalmSource war sich dieser Problematik bewusst. Entwickler, die unter Linux arbeiten wollten, hatten in Eigenregie eine auf dem quelloffenen GCC-Compiler basierende Toolchain zusammengebastelt, die – mit etwas Handarbeit – durchaus brauchbare Kompilate lieferte. Dass die Effizienz im Vergleich zum im CodeWarrior verbauten Compiler reduziert war, war messbar, spielte aber aufgrund einer kleinen Besonderheit von Palm OS 5 keine Rolle. Motorola stoppte die Weiterentwicklung der 68-k-Prozessoren nach dem Erscheinen einer mit 66 MHz getakteten SuperVZ-CPU. Palm fand sich in der unangenehmen Lage, seinen Kunden keine richtig schnellen Prozessoren anbieten zu können: Im PocketPC-Bereich waren Taktraten von bis 400 MHz gang und gäbe. Wegen der Sparsamkeit von Palm OS führte dies außerhalb des Multimediabereichs nicht zu Performanceproblemen – aus marketingtechnischer Sicht war diese Situation natürlich ein Disaster.

Palm löste dieses Problem durch eine als PACE bezeichnete Emulationsumgebung. Sie übersetzte die auszuführenden Applikationen on the fly in ARM Assembly, die daraufhin von der ARM-CPU ausgeführt wurde. Aufgrund der enormen Arbeitsgeschwindigkeit der ersten Palm-OS5-Geräte – ihre CPUs waren nominell mindestens fünfmal schneller als die mit 33 MHz dahindümpelnden 68k-Geräte – fühlten sich die neuen Maschinen nicht langsamer an als ihre Vorgänger. Wer die Leistungsfähigkeit der ARM-CPUs voll ausnutzen wollte, musste auf so genannte ARMlets ausweichen. Da deren Behandlung den Rahmen dieses Artikels sprengen würde, erwähnen wir sie hier nur der Vollständigkeit halber.

GUI, perfekt

Der in PODS integrierte GUI-Editor verdient besondere Erwähnung: Er bot ein von der Genauigkeit her an Visual Basic erinnerndes Arbeitsfeeling. Palm-OS-Applikationen bestanden aus Datenbanken; Code und GUI-Elemente wurden in Form von Ressourcen angelegt. Wer mit PODS ein neues Formular erstellen wollte, generierte eine XML-Datei. Diese wurde vom Compiler während der Zusammenstellung des Programms in Binärcode umgewandelt, der vom GUI-Stack beim Laden des Formulars eingelesen wurde.

Palm beschränkte seinen Editor auf die Erstellung dieser Ressourcen. Zur Laufzeit wurden die Steuerelemente erstellt. Emittierte Ereignisse wanderten in Formular-Event-Handler, die von einer im Rahmen des Ladens eines Formulars festzulegenden Hilfsfunktion festgelegt wurden:

Listing 1
static Boolean AppHandleEvent(EventType* pEvent)
{
  UInt16     formId;
  FormType*   pForm;
  Boolean    handled = false;

  if (pEvent->eType == frmLoadEvent) {
    // Load the form resource.
    formId = pEvent->data.frmLoad.formID;
    
    pForm = FrmInitForm(formId);
    FrmSetActiveForm(pForm);

    // Set the event handler for the form.  The handler of the currently
    // active form is called by FrmHandleEvent each time is receives an
    // event.
    switch (formId) {
      case MainForm:
        FrmSetEventHandler(pForm, MainFormHandleEvent);
        break;
      case RegForm:
        FrmSetEventHandler(pForm, regFormHandleEvent);
        break;

In den Funktionen wurden die Events anhand von Typ und Emitter unterteilt. Wir wollen dies anhand eines Event Handlers betrachten, der für das Laden und das Schließen eines Formulars zuständig ist:

Listing 2
Boolean regFormHandleEvent(EventType* pEvent)
{

  Boolean   handled = false;
  FormType* pForm;
  switch (pEvent->eType)
  { 
    case frmCloseEvent:
    pForm = FrmGetActiveForm();
    MemPtrFree(FldGetTextPtr(getObjectPtr(pForm, FldTimeLeft)));
    break;
  case frmOpenEvent:
    pForm = FrmGetActiveForm();

handled diente als Flag, die für die Propagation der Ereignisse zuständig war. Palm-OS-Applikationen mussten anfallende Ereignisse nicht unbedingt selbst verarbeiten: Ein uninteressantes Event konnte durch das false-Setzen von handled an das Betriebssystem remittiert werden.

Leider zeigte sich der Zahn der Zeit. Die mit dem Tungsten T3 eingeführte Möglichkeit, den Bildschirm durch das „Herunterziehen“ der Schublade zu vergrößern, fand in XML nie wirklich Abbildung. PalmSource half seinen Entwicklern mit dem Anbieten einer Routine, die die am Bildschirm befindlichen Widgets nach einer Änderung der Bildschirmgröße automatisch reskalierte.

Da jedes Formular etwas anders aussah, wurden größere Programme oft mit mehreren Skalierungs-Handlern ausgeliefert. Als kleines Beispiel dafür sei eine Routine aus dem Unternehmen des Autors angeführt, die den Resultatdialog von FileFind an die gerade aktuelle Größe des Bildschirms anpasste:

Listing 3
Boolean VfsResultsFormHandleEvent(EventType* pEvent)
{
  Boolean   handled = false;
  FormType*   pForm=FrmGetActiveForm();
  static char tapno=0;
  static UInt32 tics;
  static UInt32 sel=0;
  switch (pEvent->eType) 
  {
    case winDisplayChangedEvent:
    {
      RectangleType newBounds;
      RectangleType objBounds;
      WinGetBounds(WinGetDisplayWindow(),&newBounds); 
      // Resize list
      FrmGetObjectBounds(pForm, FrmGetObjectIndex(pForm, LstFoundFiles), &objBounds); 
      objBounds.extent.x=newBounds.extent.x - 8; 
      objBounds.extent.y=newBounds.extent.y - 37; 
      FrmSetObjectBounds(pForm, FrmGetObjectIndex(pForm, LstFoundFiles), &objBounds);
      // Resize label
      FrmGetObjectBounds(pForm, FrmGetObjectIndex(pForm, 1000), &objBounds); 
      objBounds.topLeft.y=newBounds.extent.y-19;
      FrmSetObjectBounds(pForm, FrmGetObjectIndex(pForm, 1000), &objBounds);
      // Resize button
      FrmGetObjectBounds(pForm, FrmGetObjectIndex(pForm, CmdAgain), &objBounds); 
      objBounds.topLeft.y=newBounds.extent.y-19;
      FrmSetObjectBounds(pForm, FrmGetObjectIndex(pForm, CmdAgain), &objBounds);   
      newBounds.topLeft.x+=2;
      newBounds.topLeft.y+=2;
      newBounds.extent.x-=4;
      newBounds.extent.y-=4;
                 
      WinSetBounds(FrmGetWindowHandle(pForm), &newBounds); 
      FrmDrawForm(pForm); 
    }
      handled=true;
      break;

Das Formular bestand aus einem Label, einem Knopf und einer Liste mit Resultaten. Da Palm-OS-Handhelds sowohl im Portrait- als auch im Landscape-Modus betrieben werden konnten, musste das Formular auf mehrere Arten von Größenänderung vorbereitet sein. Zum Verständnis der hier abgedruckten Routine ist es hilfreich, einen Blick auf das in Abbildung 1 gezeigte Resultatformular zu werfen.

Beim Verändern der Größe dieses Formulars genügte es, die Knöpfe an den unteren Bildschirmrand zu verschieben. Die Liste konnte danach im „Rest“ ausgebreitet werden. Bei komplizierteren Programmen sah die Sache naturgemäß anders aus – bis zuletzt gab es viele Applikationen, die nur auf einem quadratischen Bildschirm lebensfähig waren.

hanna_alteseclipse_1
Abbildung 1

Hilfe per Webserver

Palm OS Developer Studio erzürnte seine Nutzer mit einer für damalige Verhältnisse geradezu frevelhaften Tat. Das in die IDE integrierte (und sehr vollständige) Hilfesystem wurde über einen Webserver realisiert, der einen kleinen Webbrowser mit Inhalten versorgte. Auf dem Höhepunkt des Browserkriegs zwischen Microsoft und Mozilla war dies insbesondere deshalb interessant, als Firefox zum damaligen Zeitpunkt das Konzept des Tabbed Browsings populär machte.

Nach einiger Zeit kamen findige Entwickler auf den Gedanken, dem HTML-Viewer der IDE durch Rechtsklick einen Link auf das Hilfesystem „abzuluchsen“. Dieser wanderte im nächsten Schritt in die Eingabezeile von Firefox, womit ein tabfähiger (und speichersparenderer) Hilfe-Viewer in Erscheinung trat. Dies funktioniert interessanterweise auch mit heutigen integrierten Entwicklungsumgebungen auf Eclipse-Basis. So ist es ohne Weiteres möglich, das in die Android Developer Tools integrierte Hilfesystem in Firefox zu rendern.

Debugger auf Tauchstation

Auf dem Papier bot Palm OS hochwertige und vollständige Debugger-Unterstützung. Leider war dies in der Praxis nicht der Fall: Wer mit einem nicht englischen Windows arbeitete, konnte Programme nicht einmal automatisch auf den (sehr schnell startenden) Palm-OS-Simulator deployen.

Entwickler ersonnen diverse Möglichkeiten zum Mitprotokollieren des Programmzustands. Neben der auch im JavaScript-Bereich weit verbreiteten Nutzung der Alert-Funktion griff man auf Logfiles zurück, die auf SD-Karten oder sonstige Wechselmedien wanderten. Wegen des primitiven inneren Aufbaus von Palm OS erwies sich diese Vorgehensweise als nervtötend. Ein im Unternehmen des Autors entwickelter IRC-Client für Palm OS konnte sich normalerweise binnen zehn Sekunden mit dem Server verbinden. Mit aktiviertem Logging dauerte derselbe Prozess fast fünf Minuten.

Zur Begründung: Wenn eine Palm-OS-Applikation „stirbt“, so wirft sie den bei Nutzer und Entwickler gleichermaßen gefürchteten Fatal Alert. Dieser stoppt das gesamte Betriebssystem, wodurch alle in einem Logfile liegenden Informationen nicht mehr zugänglich sind. Leider ist das Herausschreiben einzelner Datenwörter keine besondere Stärke von SD-Karten: beim byteweisen und ungecachten Ansprechen schafften damalige SD-Karten Schreibraten im Bereich von 30 Byte pro Sekunde.

Im selben Boot

Das hinter Symbian OS stehende Lizenzierungsunternehmen wurde von Metrowerks Untergang kalt erwischt: CodeWarrior for Symbian hörte gegen 2008 quasi auf zu existieren. Nokia reagierte auf diese Änderung mit dem Anbieten einer eigenen Entwicklungsumgebung, die natürlich ebenfalls auf Eclipse basierte – dass ein Gutteil davon aus zugekauftem IP von Metrowerks bestand, ist erst seit David Woods Buch „Smartphones and Beyond“ allgemein bekannt.

Neben dem als Carbide.C++ bezeichneten Produkt gab es mit Carbide.vs auch ein kurzlebiges Plug-in für Microsofts Visual Studio. Carbide wurde zwecks Einspielung der nicht unerheblichen Akquisekosten anfangs in drei Versionen vertrieben: Neben der kostenlosen Express Edition gab es Varianten, die nur gegen die Zahlung einer (durchaus heftigen) Lizenzgebühr ihren Eigentümer wechselten. Der von diesen Varianten gebotene Mehrwert bestand in einem GUI-Designer, der Entwicklern den vom unter PocketPC laufenden .NET Framework gebotenen Komfort offerieren sollte. Dazu gehörte – natürlich – auch die Möglichkeit, Event Handler direkt im Editor anzulegen und zu verdrahten. Nokia wollte seinen Entwicklern den unter Palm OS notwendigen Umweg der manuellen Zuweisung im Code Behind ersparen. Eine großartige Idee, deren Implementierung aufgrund der technischen Rahmenbedingungen zu wünschen übrig ließ.

Der GUI-Stack von Series 60 war darauf optimiert, dass Entwickler die Benutzerschnittstellen ihrer Programme in Code realisieren. Der Import von Ressourcen war anders als unter Palm OS oder Android nicht vorgesehen. Carbide fand sich somit in der unangenehmen Rolle eines Codegenerators wieder, der seine Arbeit „am offenen Herzen“ der Applikation durchführen musste. Nokia löste dieses Problem auf höchst kontroverse Weise.Der von Carbide generierte Code wurde – wie im Snippet gezeigt – mit Kommentaren versehen. Nach Änderungen der Ressourcendatei überschrieb Carbide den Inhalt dieses Blocks gnadenlos mit dem neu erstellten Kompilat (Listing 4).

Listing 4
CCoeControl* CLocaNoteListView::ComponentControl( TInt aIndex ) const
{
  // [[[ begin generated region: do not modify [Generated Contents]
  switch ( aIndex )
    {
  case ELstFiles:
    return iLstFiles;
    }
  // ]]] end generated region [Generated Contents]
  
  // handle any user controls here...
  
  return NULL;
}

Dieses auf den ersten Blick sinnvoll erscheinende Vorgehen erwies sich in der Praxis oft als Quelle von niemals enden wollenden Ärgernissen. Nokias GUI-Designer unterstützte nämlich nur einen kleinen Teil der vom Avkon-GUI-Stack angebotenen Optionen. Häufig genutzte Einstellungen wie die Platzierung der Toolbar am Bildschirm wurden im Rahmen der Codegenerierung mit einem Default-Wert versehen.

Auf diese Art und Weise entstanden Edit Wars zwischen dem Entwickler und seiner IDE. Die folgende Routine ist ein gutes Beispiel dafür (Listing 5).

Listing 5
// [[[ begin generated function: do not modify
void CLocaNoteAppUi::InitializeContainersL()
{
  iLocaNoteListViewView = CLocaNoteListViewView::NewL();
  AddViewL( iLocaNoteListViewView );
#ifdef BUILD_LOCANOTE_LITE
#define APPUI_UNTOUCHED
  SetDefaultViewL( *iLocaNoteListViewView );
#endif
  iLocaNoteNagLandscapeView = CLocaNoteNagLandscapeView::NewL();
  AddViewL( iLocaNoteNagLandscapeView );
  iLocaNoteNagPortraitView = CLocaNoteNagPortraitView::NewL();
  AddViewL( iLocaNoteNagPortraitView );
#ifdef BUILD_LOCANOTE_FREE
#define APPUI_UNTOUCHED
  SetDefaultViewL( *iLocaNoteNagPortraitView );
#endif
  }
// ]]] end generated function

  #ifndef APPUI_UNTOUCHED
  #error The AppUI was touched and force edited by the compiler. Restore it from the CVS!
  #endif
.   . .

InitializeContainersL ist für die Initialisierung aller Formulare zuständig und legt zudem das nach dem Start anzuzeigende Element fest. Die Demoversion sollte das normalerweise angezeigte Formular durch eine Kauferinnerung ersetzen. Aus Gründen der Bequemlichkeit sollte diese Änderung über eine Präprozessorkonstante aktivierbar sein. Leider überschreibt Carbide den Teil um SetDefaultViewL nach jedem Ändern einer Ressourcendatei mit dem Default-Wert. Um das dadurch entstehende Fehlerpotenzial zu minimieren, bekam die Routine mit APPUI_UNTOUCHED eine zusätzliche Absicherung. Der regelmäßig erforderliche Zugriff auf das CVS war insbesondere unterwegs ein Ärgernis erster Klasse.

Quasi als Epilog zu diesem Abschnitt sei angemerkt, dass Nokia den Verkauf von Carbide.c++ mit Version 2 einstellte: Die Finnen waren aufgrund eines Entwicklermangels dazu bereit, die Anschaffungskosten abzuschreiben. Ab diesem Zeitpunkt stand die IDE jedermann kostenlos und als Vollversion zur Verfügung. Die im Rahmen dieser Umstellung auftretenden Probleme mit dem DRM-System verdienen an dieser Stelle besondere Erwähnung. Nokia realisierte das „Alles-Kostenlos-Machen“ durch das Ausliefern einer zeitlich beschränkten Lizenzdatei, die alle Funktionen der IDE auf einen Schlag freischaltete. Ein später nachgeschobenes Update sollte das Lizenzmanagement entfernen.
Leider kam es, wie es kommen musste. Die meisten Entwickler erwiesen sich als update-faul. Als die Lizenzdatei eines Tages ablief, standen hunderte Programmierer vor einer „versperrten“ Installation von Carbide.c++.

Nutze die Macht der Kerne!

Die Kompilation von größeren Codemengen gehört zu den am Besten skalierbaren Aufgaben: Es ist kein Wunder, dass Systeme wie distcc zu Zeiten von Einzelkernmaschinen enormen Zulauf genossen. Leider ist es für die Entwickler eines Compilers oft alles andere als trivial, diese Parallelisierung durchzuführen.
Auf Eclipse basierende Entwicklungsumgebungen bekommen die Parallelisierung mehr oder weniger frei Haus. Carbide.c++ konnte die damals neu aufkommenden Zweikernmaschinen bis an die Belastungsgrenze auslasten, was bei der Kompilation der oft umfangreichen Symbian- und/oder Qt-Applikationen ein nicht unerheblicher Vorteil war.

Leider war diese „Hochzeit“ nur von kurzer Dauer. TrollTech hatte mit dem Qt Creator ein eigenes Entwicklungssystem am Start, das von Nokia im Sinne der „Vereinheitlichung der Plattform“ forciert wurde. Carbide wurde nach Qt 4.6.x nicht mehr mit Updates versorgt, was zum Ende der IDE führte.

Freiheit oder Sicherheit?

In seiner Rolle als erstes für Nichtfreaks zugängliches Betriebssystem war Symbian für Virenprogrammierer attraktiv. Geräte wie das Nokia 7650 boten mit Bluetooth, MMS und Datenfunk jede Menge Verbreitungspotenzial. Nokia reagierte auf diese Problematik mit der Einführung eines als „Platform Security Model“ bezeichneten Sicherheitssystems. Applikationen mit „empfindlichen“ Funktionen mussten diese beim Betriebssystem anmelden, die Nutzung mancher Features setzte eine Signatur voraus.

Für Entwickler entstand daraus ein nicht unerheblicher Extraaufwand. Die im Handel erhältlichen Telefone verweigerten die Ausführung von selbst erstellten und nicht signierten Kompilaten. Da Symbian Signed in der Anfangszeit ein teurer und langsamer Prozess war, musste man von Seiten Nokias eine Alternativlösung vorschlagen. Damit war das Konzept der Developer Certificates geboren, das Entwickler zusätzliche Arbeit bescherte. Wer eine Applikation mit besonderen Rechten testen wollte, musste sie vor der Auslieferung auf sein zum Testen verwendetes Telefon signieren. Dazu war ein als Developer Certificate bezeichnetes Zertifikat erforderlich, das der Entwicklerworkstation das Erstellen von mit Symbian Signed kompatiblen Signaturen für einen bestimmten und vorher festgelegten Personenkreis ermöglichte.

Der Erhalt eines solchen Developer Certificate setzte eine Publisher-ID voraus. An dieser Stelle zeigte ein bisher nur wenig beachteter Industriestandard namens OMA DRM seine Zähne: Er postulierte, dass nur Kapitalgesellschaften als Besitzer einer solchen ID auftreten durften. Bis heute ist nicht überliefert, wie viele Limiteds nur aus diesem Grund erschaffen wurden. Es wäre nicht falsch, die Zahl im Bereich der Tausenden anzusetzen.

Emulator, nein danke!

Zu guter Letzt wollen wir noch einen kleinen Sonderaspekt der Entwicklung unter Symbian beleuchten. Er entlockt Kennern von Android mit Sicherheit ein Lächeln. Wer ein Speicherleck in einer App bejagen wollte, konnte dies mit einem – aus technischer Sicht sauber implementierten – Werkzeug tun. Es loggte alle Aufrufe von malloc samt auslösender Codezeile mit und konnte so auf den Entstehungspunkt des Lecks hinweisen.

Leider gibt es im Leben nichts umsonst. Der Preis dieses Tools war die Nutzung eines unter Windows lauffähigen Emulators, der selbst den Startvorgang eines Mainframe-Rechnersystems rasch erscheinen ließ. Auf einer durchaus schnellen Zweikernmaschine der damaligen Zeit nahm ein voller Testdurchlauf schon mal 10 bis 15 Minuten in Anspruch – der Gutteil des Prozesses wurde vom Entwickler mit Warten zugebracht.

Es geht nicht ohne Eclipse

Microsoft ist das einzige Unternehmen, das sich im Handcomputerbereich eine eigene IDE leistet. Da Visual Studio auch am Desktop weit verbreitet ist, hält sich der Aufwand für die Wartung der Mobilversion in engen Grenzen.

Samsung versuchte in der Anfangszeit seines Smart-TV-Betriebssystems eine ähnliche Vorgehensweise. Wer Programme für Smart-TVs der ersten Generation schreiben wollte, musste dazu auf eine hauseigene Entwicklungsumgebung samt GUI-Editor zurückgreifen. Samsung bemerkte schnell, dass die Wartung dieses Produkts Unmengen von Ressourcen verschlang. Der einzige Mehrwert einer proprietären Lösung ist die Verfügbarkeit eines GUI-Editors, der sich ohne großen Aufwand als Plug-in in Eclipse realisieren lässt.Im Rahmen eines Updates der Plattform wurde die proprietäre IDE durch Eclipse ersetzt. Samsung ersparte sich daraufhin die zeitaufwändige und unergiebige Wartung eines Codeeditors samt dazugehörender Autocomplete Engine.

Wer sich bisher nicht mit der Realisierung eines an IntelliSense angelehnten Systems befasst hat, kann die Komplexität dieser Aufgabe nicht annähernd einschätzen. Die Generierung von sinnvollen Vorschlägen setzt ein enormes Verständnis der zugrunde liegenden Programmiersprache voraus: Was bei Assembler oder C mit etwas Aufwand hinzugekommen ist, artet bei Websprachen wie dem für Samsung Smart-TVs notwendigen JavaScript ins Unermessliche aus.

Aus diesem Blickwinkel ist es nicht verwunderlich, dass die Entwicklerschaft die mit der Umstellung einhergehenden Kinderkrankheiten im Großen und Ganzen gelassen nahm. Wer einmal ohne IntelliSense auskommen musste, lernt die Vorteile intelligenter Codekomplettierung rasch zu schätzen. Research in Motion erlebte mit seinem Java-basierten Betriebssystem Ähnliches: Auch hier wurde die hauseigene IDE im Laufe der Zeit durch eine auf Eclipse-basierende Arbeitsumgebung ersetzt.

Fazit

Es steht außer Frage, dass heutige Mobile-Entwicklungsumgebungen die eine oder andere Schwäche aufweisen. Sich darüber aufregende Entwickler müssen sich im Klaren sein, dass sie auf hohem Niveau meckern. Ein mit PODS arbeitender Programmierer hätte sich über den zuverlässigen Debugger gefreut; unter Carbide rackernde Codierer blicken neidisch auf IntelliSense und den „einfach funktionierenden“ GUI-Designer. Wer in diesem Pleistozän der Handcomputerbranche mit seiner Arbeit begann, profitiert von den damals gewonnenen Erfahrungen. Ressourcenarme Systeme sind als Lehrumgebung in vielerlei Hinsicht besser geeignet, da sie den Entwickler zum Nachdenken zwingen.
Amerikaner drücken dies in dem Spruch aus:

Algorithms are for people who don’t know how to buy RAM

In ihm steckt mehr als nur ein Körnchen Wahrheit.

Aufmacherbild: Hand with PC RAM and computer monitor © Shutterstock.com
Urheberrecht: Naypong

Verwandte Themen:

Geschrieben von
Tam Hanna

Tam Hanna befasst sich seit der Zeit des Palm IIIc mit der Programmierung und Anwendung von Handcomputern. Er entwickelt Programme für diverse Plattformen, betreibt Onlinenewsdienste zum Thema und steht unter tamhan@tamoggemon.com für Fragen, Trainings und Vorträge gern zur Verfügung.

Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "IDEs der Steinzeit"

avatar
400
  Subscribe  
Benachrichtige mich zu:
TestP
Gast

„Microsoft ist das einzige Unternehmen, das sich im Handcomputerbereich eine eigene IDE leistet.“

Das tut Apple mit Xcode doch auch oder nicht?

Grüße