Hallo iOS!

Es war kein leichter Weg, aber nun ist es endlich so weit: Xojo iOS ist da. Als beim Alpha- und Betatest Beteiligter weiß ich, dass die Freude gerade für alte Hasen nicht ganz ungetrübt sein wird, denn es gilt auch, alte Wege zu verlassen und ein paar Dinge neu zu lernen.
Deshalb vorweg ein paar beruhigende Worte: Keine Angst! Bei allen Beteiligten hat sich die Aufregung schnell gelegt, und nach kurzer Zeit ist die Gewöhnung so groß, dass man sich fragt, warum es früher so kompliziert war. Um aber möglichst wenig Verwirrung aufkommen zu lassen, hier ein paar Plaudereien aus dem iOS-Nähkästchen:

Neue Frameworks

Xojo 2014r3 führt nicht nur ein iOS-Framework ein, sondern auch ein neues Xojo.Core-Framework, das zum Großteil auch den anderen Plattformen zur Verfügung steht und nach und nach erweitert wird. Das heißt also: Wenn Sie gar nicht für iOS programmieren wollen, sind Sie zu keinen Änderungen gezwungen – bestenfalls ein paar Anpassungen, denn der Compiler prüft jetzt genauer, z.B. auf doppelt angelegte globale Variablen. Sollten Sie die MacOSLib für OS X-Desktopprojekte benutzen, müssen Sie die neue Version installieren, die für Xojo 2014r3 vorbereitet ist. Nur falls Ihre OS X-Projekte noch das alte Carbon-Framework verwenden, sind Sie gezwungen, die Ärmel hochzukrempeln: Carbon, das ja schon ewig von Apple abgekündigt ist, wurde jetzt aus Xojo gestrichen. Aber in den meisten Fällen können Sie weitermachen wie bisher.

Ob Sie das auf lange Sicht wirklich so tun sollten, ist andererseits eine durchaus überlegenswerte Frage. Das Core-Framework, das wie beschrieben aktuell nur für iOS-Projekte Pflicht ist, wird nach und nach das alte RB-Framework, zumindest große Teile davon, ersetzen. (Auch hier: Keine Angst! Die Transformation wurde sehr langfristig geplant!) Es bietet allerdings auch geräumige Vorteile, unter anderem:

 

Text ersetzt String

Das ist zugegeben für viele erst mal ein Hammer – String hat man seit Jahrzehnten liebgewonnen, und er hat doch so gut funktioniert – aber hat er? Der String-Datentyp ist ein Relikt aus den frühen Computertagen, als ein kompletter Zeichensatz locker mit einem Byte pro Zeichen dargestellt werden konnte. Aber heute? Wir leben im Zeitalter der lokalisierten globalen Anwendungen, ein kompletter Unicode-Zeichensatz kann Tausende unterschiedlicher Glyphen mit sich führen. Und nicht nur das: Wenn Sie eine Textdatei öffnen und ihren Inhalt als String einlesen: Wie wahrscheinlich ist es, dass Sie Rauten, Kreuze und alle möglichen putzigen Zeichenkombinationen dort finden, wo Sie eigentlich Buchstaben erwarten würden? Näher betrachtet taugt ein String heute eher dazu, die Vermutung zu geben, dass es sich bei seinem Inhalt um Text handeln könnte. Wie dieser beschaffen ist, muss aber erst einmal herausgefunden werden.

Beim Datentyp Text ist das kein Ratespiel mehr. Eine Textvariable trägt stets die Kenntnisse über ihre Zeichencodierung mit sich. Das führt dazu, dass Sie bei vielen Text-Methoden eine optionale Variable locale mit angeben können, um genau auf die sprachlichen Eigenschaften einzugehen. Und ansonsten verhält sich Text größtenteils genau wie String, nur ohne Ärger bei der Suche nach vergessenen DefineEncodings. Sogar mit ein paar schnellen Convenience-Funktionen wie

Text.Empty

Und wenn Sie wirklich einmal die puren Bytes benötigen, hilft die TextEncoding-Klasse Ihnen. Für Declares arbeitet die CFStringRef-Konvertierung genauso gerne mit Text wie bislang mit String.

 

Lokalisierungs-Hilfen
Wie die Angabe locale bei der Textklasse die lokalen Systemparameter bereithält, ziehen sich Hilfen für international funktionierende Progamme durch das ganze Core-Framework. Die Xojo.Core.Date-Klasse (um sie von der bisherigen und wie gesagt weiter verfügbaren Date-Klasse abzugrenzen mal ausgeschrieben) z.B. kennt die TimeZone und bietet damit Konvertierungs- und Ausgabemöglichkeiten über alle Zeitzonen und Landesgepflogenheiten hinweg. Und elendige Datumsberechnungen werden einfach durch die Klasse DateInterval, die Sie für Additionen und Subtraktionen im Datumsbereich verwenden können.

 

Tipp-Hilfen
Nehmen wir mal an, Sie haben Gefallen am neuen Core-Framework gefunden und stellen ein paar Ihrer Methoden – oder ein ganzes Projekt – darauf um. Aber jedesmal Xojo.Core. tippen, um die Klassen zu verwenden? Brauchen Sie nicht! Beginnen Sie de Methode (oder Schleife bzw. sonstigen Scope-Bereich) einfach mit

Using Xojo.Core,

und statt der alten Dictionary-Klasse wird nun z.B. Xojo.Core.Dictionary verwendet.

Wühlen Sie sich mal durch die (neue) iOS-Sprachreferenz, in der auch das Core-Framework beschrieben ist. Sie werden sehen, nach dem ersten Fremdeln stellt sich
bald mehr als Gewöhnung ein.

 

iOS
Und die eigentliche iOS-Programmierung? Im Prinzip wie gewohnt: Sie ziehen Steuerelemente aus der Library auf den Layout-Editor. Nur finden Sie darin kein Fenster, sondern ein View – im Prinzip ein Rechteck mit Event- und Verwaltungsmöglichkeit für den Inhalt. Sie ändern ganz wie gehabt die Properties im Inspector.

WebViewer Autolayout RightNur beim Layout hat sich etwas geändert: Statt der Verankerungssymbole existiert nun eine Auto-Layout-Abteilung mit einer ziemlich frei erweiterbaren Liste für Layoutangaben. Denn ein iOS-Layout ist in vielen Fällen flexibel: So ein iPhone oder -Pad kann mal horizontal, mal vertikal gehalten werden. Um nicht für jede Ausrichtung und jedes Bildschirmformat ein eigenes Layout erstellen zu müssen, versteht sich iOS auf automatische Anordnung der Bildschirmelemente. Die Befehle dazu versucht Xojo schon anhand der Ausrichtung der Steuerelemente zu erahnen, aber mitunter muss man hier manuell eingreifen und z.B. ein Referenzobjekt, an dem sich eine Kante orientieren soll, neu zuweisen oder den Abstand (hier im Bild: Offset) zur Referenzkante verändern. Denn darum geht es: Statt fester oder flexibler Kantenabstände zum Elternobjekt kann nun frei ein Referenzobjekt (bzw. eine Kante davon) angegeben werden und definiert, wie sich die Kante des in Arbeit befindlichen Steuerelements dazu verhalten soll. Dabei kann manchmal weniger mehr sein – für diesen Fall lassen sich Auto-Layout-Anweisungen auch löschen.

Das bedeutet allerdings – zumindest momentan noch – ein wenig Mehrarbeit beim Layout. Xojo versucht zwar, Referenzobjekte herauszufinden, an denen sich ein neues Steuerelement orientiert, aber die Einschätzung der IDE deckt sich nicht immer mit dem Wunsch des Programmierers. Es wird Ihnen anfänglich mehr als einmal passieren, dass bei einer Layoutänderung eines einzigen Objekts plötzlich alles durcheinandergerät. Sobald man sich aber angewöhnt hat, die Auto-Layout-Einstellungen gleich bei der Anlage korrekt einzustellen, verschwinden diese Ärgernisse.

Was sich nicht von der Hand weisen lässt: Viele Steuerelemente fehlen noch oder machen nicht alle Properties ihrer Klasse frei zugänglich. Das wird Stück für Stück nachgeliefert, soll aber kein Grund sein, Sie zu stoppen. Nur müssen für diesen Fall noch Declares hinhalten. Während der Alpha- und Betaphase wurden davon schon einige erstellt. Ich werde in Kürze anfangen, hier ein paar meiner Kreationen zum Download anzubieten.

 

Eine Kleinigkeit vorweg schon: Die neue iOSImage-Klasse ist im Prinzip ein UIImage, und diese sind immutable, zu gut deutsch unveränderbar. Was, wenn Sie doch einmal die Größe eines Bilds verändern (und dabei die hochklassigen Skalierungsmöglichkeiten von iOS nutzen) wollen? Dafür finden Sie hier ein Modul, das Ihnen diese Möglichkeit mit dem Befehl

SkaliertesImage = OriginalImage.ScaledImage (Faktor as Double)

zur Verfügung stellt. Ein Faktor von 1.0 entspricht dabei der Originalgröße, 2.0 einer Reduktion um die Hälfte etc.
ImageScale

De deutsche iOS-Schnellstartanleitung ist womöglich etwas versteckt. Man findet sie hier.

Und eine zweite Erweiterung gleich noch hinterher: Mit dieser Subklasse von iOSTextField können ein paar weitere Features der zugrundliegenden  UITextView-Klasse angesprochen werden. Sie können viele davon auch für andere Controls verwenden – Backgroundcolor, Alpha und TintColor beispielsweise sind Eigenschaften der UIView-Klasse, und diese ist Basis für sehr vieles von dem, was sich auf dem iOS-Bildschirm so tummelt. Der Download:  UITextField

UItextfield 2

4 Gedanken zu “Hallo iOS!

  1. Das mit dem Text verstehe ich nicht. Eine String variable hat doch auch ein Encoding, da gibt’s kein Gerate, mal von einigen Bugs von Textfinktionen abgesehen, welche die Encoding-Information löschen…
    Also was soll der Vorteil von „Text“ sein, abgesehen davon das ich jetzt in AppleScript und RB die gleiche Bezeichnung habe. ;-D

    Gefällt mir

    1. Hallo Christian,

      vielen Dank für den (ersten echten) Kommentar hier! Das Problem liegt in der Struktur von Strings: Grundsätzlich repräsentiert ein String eine Folge von Bytes. Es stimmt, darauf kann eine Codierung gesetzt werden, aber gerade beim Zugriff auf Textdateien oder Sockets vergisst man dies gerne mal, und das Ergebnis ist dann eben das bekannte … Auch die Entgegennahme aus Funktionen, die einen Memoryblock liefern, kann zu Codierungsfehlern führen. Im Grunde ist die Stringcodierung ein Versuch, eine moderne Zeichencodierung wie UTF-8 auf einen Container anzuwenden, der dafür nicht wirklich vorbereitet ist.

      Text hingegen verlässt die Bytezuordnung und versteht sich als Reihe von Zeichen – also Glyphen. Wie viele Bytes diese jeweils intern benötigen, ist dabei völlig egal, darum kümmert sich der Datentyp. Und durch direkte Konvertierbarkeit in String bzw. CFStringRef werden alte Funktionen oder Declares – also alles, was eben doch eine reine ASCII-Zeichenkette verlangt – nicht außer Kraft gesetzt. Aber wie geschrieben: Wenn dir Text missfällt, musst du auf die nächsten Jahre nicht umstellen. Dem klassischen Framework bleibt String noch auf Jahre erhalten. Nur in iOS ist Text jetzt schon Pflicht.

      Ich selbst allerdings merke, immer häufiger die neuen Core-Klassen zu verwenden statt der alten. Ein WasAuchimmer.ToText merkt sich weitaus besser als ein str(WasAuchImmer). Aber das ist wie gesagt reine Kosmetik. Spannender wird es z.B. bei den Sockets, die bei iOS jetzt erstmalig höhere API-Aufrufe verwenden und deshalb wohl auf Timerpolling verzichten können. Dafür nehme ich die Umbaumaßnahmen gerne in Kauf, wenn sie auch in die anderen Plattformen Einzug halten sollten.

      Gefällt mir

  2. Hallo Ulrich, ganz vergessen, erstmal: toll das es Deinen Xojo Blog gibt, und das auch noch in German. 🙂 Gerne bin ich der erste Senfgeber. 😉

    Ok, ‚Text‘ funktioniert aber nur innerhalb von Xojo. Sobald man mit der Außenwelt (Datei, Socket, etc) spricht ist es quasi das Gleiche wie vorher.
    Unicode sollte ja auch die große Befreiung bringen (hat es zum Großteil auch). Wenn nun Xojo konsequent wäre, und wirklich überall Unicode ausspucken würde wo es das soll, dann bräuchten wir wohl keinen neuen ‚Text‘-Typ.
    Wahrscheinlich scheuen sich die Entwickler mal wieder alte Bugs zu fixen weil sie bei uns nix kaputt machen wollen. 😀 Die Haltung werde ich nie verstehen. Stattdessen kommt ein neuer Datentyp der das dann alles bereinigen soll. Na mal schauen ob das diesmal klappt… 😉
    Nörgel, nörgel… 😉

    Also mir missfällt Text nicht, sehe jetzt nur nicht den großen Vorteil gegenüber fehlerfrei arbeitenden UTF8 String-Funktionen. Vielleicht habe ich’s aber auch noch nicht ganz geblickt, das will ich mal lieber nicht ausschließen. 😉

    Das neue Framework insgesamt finde ich schon spannend (mit ‚Using‘ wird der Übergang ja auch erleichtert). Ich hoffe nur das alte Fehler nicht wiederholt werden. Ich bin noch auf Xojo 2013r32 (wegen 10.6 Unterstützung für meine User), obwohl meine Lizenz bis 2021 geht. 😀 Also ich habe ich noch nix selbst gesehen… Z.B. hoffe ich das Properties der Dot-Notation Logik folgen, ohne Dots halt.
    Z.B. Window Properties, jetzt:
    Bottom
    Left
    Right
    Top

    Verstreut in langen Property-Listen, schlecht. Bei so bekannten geht’s ja noch, aber in Objekten mit kilometerlangen Properties dauert es ewig bis man sich durchgelesen hat um was zu finden…
    Besser wäre:

    PositionBottom
    PositionLeft
    PositionRight
    PositionTop

    Auch beim Auto-Vervollständigen hätte man so leichteres Spiel…

    Oder Methoden, der Namespace könnte so aussehen:
    String.Convert.Base64encode()
    String.Convert.Base64decode()

    Wichtig ist auf jeden Fall, dass das „Ding“, um das es eigentlich geht, im Methoden-/Propertynamen vorn zu haben und hinten die Aktion/Eigenschaft. Dann gibt’s nicht so’n endloses Kuddelmuddel und Gesuche, weil alles in Blöcken gruppiert ist, die man viel schneller mit den Augen scannen kann.
    Ich weiß dass das nicht immer 100% clean umsetzbar ist, besonders wenn man später Klassen erweitert kann je nach Situation ein etwas anderes Schema mal besser sein. Aber grundsätzlich wäre das mal sehr hilfreich für die Übersicht und schnelleres Arbeiten.

    Boah, lang geworden, sorry.

    Gefällt mir

  3. Vielen Dank erneut, Christian!

    Was deine Überlegungen zu Text und Außenweltfunktionen angeht: Ja, ich geb dir da völlig recht. Bei meinen ersten Spielereien mit iOS fand ich es allerdings sehr komfortabel, dass viele Datentypen bzw. Grundklassen jetzt auch voll nativ vorliegen: Ein iOSImage ist grundsätzlich ein UIImage, wenn bei ersterem auch noch nicht alle Properties implementiert wurden. Lässt sich via Declare aber ganz problemlos machen, ohne jede Typkonvertierung, da das Handle verfügbar ist. Ob sich so ein Vorteil auch im Textbereich finden wird, kann ich allerdings noch nicht sagen.

    Ich finde, beim Vergleich iOS : OS X fällt durchaus auf, dass iOS ein paar Jahre später gestartet ist. Vieles ist übersichtlicher und komfortabler angelegt. Und davon schwappt ja nach und nach einiges zu Mac OS X zurück. Ob sich das irgendwann bei Text-API-Funktionen bemerkbar machen wird: Warten wir’s ab. Insofern ist Text also eher eine Investition in die Zukunft, allerdings mit den nicht zu verachtenden Locale-Features, die sehr hilfreich bei lokalisierten Programmen sind. Wenn man die entsprechenden Properties anzapft, muss man sich um korrekte Anführungszeichen, Zahlenformatierung etc. keine Gedanken machen.

    Was die Übersicht angeht: Ebenso Zustimmung. Ich hoffe, dass die Autocomplete-Liste irgendwann mal sortierbar oder filterbar ist. Beim Xojo-iOS-Framework, scheint mit, gibt man sich Mühe, Hierarchien einzuführen, was m.E. ebenso gut, wenn nicht besser ist, um Übersicht zu erhalten. Den Frame eines Steuerelements findet man in seinen Bounds definiert – als Xojo.Core.Rect, das seinerseits einen (Origin).Core.Point und ein Core.Size beinhaltet. Mag erst mal nach viel Tipperei aussehen, aber ich begrüße die größere Übersicht durch weniger volle Autocomplete-Listen. Wobei grundsätzlich: Ja, es wäre sehr wünschenswert, wenn sich die Übersicht da noch steigern ließe. Unterordner für bestimmte Methoden- oder Eigenschaftengruppen o.ä. wären auch ein Weg. Aber ich denke, sowas wird erst nach 64bit realisierbar werden, das ja Priorität besitzt.

    Edit: Noch ein Nachtrag wegen der Bugfixes. Im Prinzip teile ich deine Sicht, aber es ist nun einmal in der Tat so, dass das RealBasic-Framework schon eine lange Geschichte hinter sich hat, und es sind viele große Projekte damit im Laufe der Zeit entstanden. Rigoros alle Fehler auszumerzen würde wahrscheinlich viele Projekte ruinieren und eine Menge Pflegeaufwand für die Entwickler bedeuten. Stattdessen eine sanfte Transformation einzuführen und dazu anzuregen, nach und nach auf das moderne Framework umzusteigen, ist da in meinen Augen ein durchaus verständlicher Weg. Am Ende sollte man am gleichen Punkt ankommen, nur ohne allzu viele zornige Reaktionen aufgrund von Hunderten plötzlich zu korrigierender Programmzeilen. Joe Ranieri hat hier ein paar ganz interessante Gesichtspunkte geschildert.

    Und kein Problem mit langen Kommentaren! Ganz im Gegenteil!

    Gefällt mir

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s