Auch wenn eine iPhoneApp in Javascript gebaut ist, muss der Coder wissen, was er tut. Das ist bei einer Webseite etwas ganz anderes – schon weil das kein „Programmieren“ ist. HTML-Bastler sehen das anders ;-)

Abseits dieses Streits gesehen hat das Bauen der Webseite auf dem Server nur eine sehr kurze Lebensdauer. Da kann man achtlos Speicher verbrauchen. Nach weniger als einer Sekunde ist der Prozess gestorben.

Eine iPhoneApp sollte quasi endlos laufen. Da schaut jemand drauf, lässt es wieder in der Hosentasche verschwinden und nach Tagen zeigt sie immer noch, das was sie tun soll. Die FahrradApp soll immer die Radschrauber anzeigen, die sich in der Nähe des iPhones befinden – und zwar nach ihrem Abstand sortiert. Dazu muss also laufend die Position bestimmt , die Abstände zu den Schraubern ausgerechnet und dann die Liste neue sortiert werden. Obwohl das alles wohlfein programmiert wurde, erbrachte die Anzeige des verfügbaren Speichers auf dem Handschmeichler ein Speicherleck. Das passier übrigens auch schon, wenn nur die Karte läuft und der Nutzer in der Welt umherwischt. Die linke, orange Zahl wird schrittweise immer kleiner. Offenbar gibt das iPhone die schon mal gesehenen Kacheln nicht frei, wenn sie nicht mehr gebraucht werden. Allerdings: schickt man die App in den Hintergrund und aktiviert man sie wiederum, dann ist eine ganze Menge Speicher plötzlich wieder da.

Nun ist das ein recht komplexes Problem und so war der Gedanke geboren, auch die Gemeinde an dem Problem teilhaben zu lassen. Tatsächlich hat sich sogar Trevor (ein Entwickler bei Titanium) eingemischt und eingeräumt, dass es zuweilen ein Issue mit diesem Neusortieren von Listen gibt.

Im Zusammenhang mit der ganzen Forumsarbeit trat ein neuer Begriff ins Bewusstsein: ¬Corona – hm, sollte ich da was verpasst haben? Eine kurze Recherche hat die kurze Aufregung wieder gedämpft. So wie Titanium vermeidet Corona native Sprachen wie ObjectivC und Java und soll damit eine Crossplattformkompatibilität sichern und Codern die Angst nehmen. Corona setzt auf Lua. Kennt das jemand? Ein kurzer Blicjk in die ¬API zeigt den Schwerpunkt. Standard-GUI-Elemente werden nur sehr spartanisch unterstützt. Schwerpunkt ist eindeutig die graphiklastige Spieleentwicklung. Dazu gehört natürlich auch eine ¬PhysicsLibrary. Für Nichteingeweihte: das sind Algorithmen, die das Verhalten von Masse-Körpern im Schwerefeld simulieren. Das System weiß dan eben, wie ein Ball springt. Überhaupt scheint das Corona-System sehr viel Anleihen von Flash geholt zu haben. Es tut kein Wunder. Immerhin waren Carlos Icaza und Walter Luh vorher bei Adobe und haben dort die mobile Entwicklung betreut.

Eine Vision: an allen Laternen Hamburgs prangt ein kleiner Aufkleber, der neugierig macht. Viele werden ihr iPhone herausholen und darauf halten, schon weil sie neugierig sind. Und schon – schwuppdiwupp – tauchen sie in die wunderbare Welt der Harfenmusik (oder sogar Harfenhafenmusik) von Siglinde ein. Hoffentlich buchen sie dann auch für Hochzeiten, Ehrungen, Abschiednahmen, Beschneidungen, Taufen oder einfach nur so. Aber das Spiel geht weiter: da die Handys wissen, wo sie stehen, könnte man auf einer Hamburger Stadtplan in Echtzeit anzeigen, wo gerade diese himmlische Musik gehört wird. Jetzt kommt wieder der Spruch: Mehr geht nicht!.

Auch heute gibt es wieder eine Neuerung für die FahrradApp: die bei Hamburgern beliebten Fahrradtouren sind nun neben den Werkstätten und den FahrRAD-Stationen auch auf der Übersichtskarte.

Bei der Lösung des Position-Problems ist ein schönes, neues Thema aufgekommen. In dem verwendeten Kalenderfeed sind die Treffpunkte für die Touren nur sehr unscharf angegeben. da gibt es Treffpunkte wie Finkenwerder Fähranleger oder U/S-Barmbek (Globetrotter). Das sind nun Adressangaben, bei der selbst Google in aller Plietschheit nicht auflösen kann. Also muss man händisch bei Google nachfragen. Das funktioniert so: man wirft eine Adresse hin (beispielsweise 'Haltestelle Kiekhut' und bekommt dann eine ¬JSON-Ergebnisstruktur zurück, in der dann auch die geographische Position enthalten ist. Das fühlt sich nach einer Suche in einem riesigen (Solr-?)Index an. Da müsste doch mehr gehen. Offiziell kann man nur die Adresse und die Region (Land) angeben. In den Antworten tauchen so Begriffe auf wie: train_station, transit_station, subway_station, point_of_interest, place_of_worship, establishment, sublocality, administrative_area_level_2 und postal_code auf. Denkbar und sinnstiftend wären Anfragen wie die Anfrage nach allen subway_stations in der sublocality Winterhude. Ist leider so nicht dokumentiert. Oder ¬doch? Stichwort: Places.

Die FahrradApp nähert sich ihrer Vollendung. Guter Tipp gestern von Ralf: die Radstationen der roten Stadträder sollten unbedingt mit drauf. Hm. War natürlich eine kleine Fleißaufgabe, die 77 Stationen mit der Maus in GoogleEarth zu markieren … War das jetzt ein (xajax-)Jux?

Jetzt fehlt nur noch eine vernünftige Verwaltung der eingescannten GPX-Routen und schon kann es ab in den AppStore gehen.

Eine wirkliche Herausforderung scheint die iPad-Variante dieses Twitter zu sein. Das ist eine App für iPad, die den Namen wirklich verdient. Was man hier auf dem Screenshot nicht siehtt: die rechte Spalte lässt sich horiziontal bewegen. Das ist selbst mit der Titanium-API schwierig. Es funzt vermutlich mit einer ScrollView. Ok, das ist gelöst, aber wie kommt die Glyphishbar in die linke obere Ecke? Und wie geht die Verkopplung der beiden Jalousiebewegungen. Schiebt man nämlich das obere Fenster über ein gewisses Maß, dann wird das darunterliegende Ding mitgezogen.

Überhaupt beruht der Überraschungseffekt bei diesen iDings darin, dass eigentlich suggeriert wird, da wird etwas bewegt. Das iPhone müsste eigentlich Tutso heißen. Es tut so als sei es eine Kamera, ein Navi oder ein Barcodescanner. Und es tut so, als ob der Nutzer mit dem Finger etwas mechanisch bewegt. Es wird aj auch noch mit Geräuschen unterstützt. Es geht schon mit dem schmatzenden Einschalter los.