Wir leben in der Zukunft!
Die drittbeste Erfindung bei “Zurück in die Zukunft”, nach dem Hoverboard und der Zeitmaschine, ist die Uhr, auf die Michael J. Fox schaut und mit den Worten “gleich kommt der “Fünf-Uhr-Zwölf-Regen”* kommentiert. Sekunden später regnet es.
Gut, wir haben noch keine Hoverboards, Zeitmaschinen gibts nur für Festplatten, und auch der Essens-Hydralisierer, der in Sekunden aus Minipizzen richtige Pizzen macht, steht noch aus. Aber wir haben iPhones.
Was dem Regenvorhersager as dem Film am allernächsten kommt, sind Regenradare. Wenn man die Radarbilder animiert, kann man sehr gut einschätzen, wann es wo regnen wird. Und WetterOnline hat ein besonders schönes, weil man die Regengebiete schön scharf erkennen kann.
Das Problem ist nur, dass deren Website für das iPhone ungeeignet ist: Apples Telefon animiert GIF-Bilder nur, wenn die besonders klein sind, hier kommt also leider nur das Radarbild auf der Startseite in Frage. Und auf der ist so viel drauf, dass der mobile Browser aus Speichergründen gerne mal aufhört zu animieren.
Ich habe daher dieses Bild von WetterOnlines Startseite einzeln und vergrößert auf eine eigene Seite gestellt, und dem ganzen ein eigenes Icon verpasst, dass verwendet wird, wenn man auf “Zum Home-Bildschirm” klickt. Das ganze findet man unter
So, jetzt muss ich aber weiter am Hoverboard rumschrauben. Viel Spaß!
*) Der genaue Wortlaut mag anders sein. Aber: “You get the idea”…
Finally! Readomatic goes Google Code
I announced it months ago and then it rested for far too long on my Todo-List: Today I uploaded the Source of Readomatic to Google Code. It’s shiny new address is:
I updated the stylesheet to Jon Hicks’ gReader 1.3 and cleaned out almost all the debug code. All development will from now on take place at the new Google Code site. New releases will continue to be announced on this blog, too. Have fun!
Fixing iChat for ICQ
iChat can do ICQ, but a bug that never got fixed made that feature unuseable.
I complained about it, hoping that it gets fixed. But waiting for a bugfix and telling every contact to switch messengers in the meantime is one thing, actually writing something that fixes the bug is another thing. So I did that 
I wrote a simple InputManager and got a lot of inspiration from Chax on how to do it. Some parts of my code are based on Keith Sutherlands work.
But Inputmanagers are potentially a bad thing. This one is so simple, it should do no harm. But Apple changed some rules concerning Inputmanagers so make sure the following conditions are met:
- The folder “IChatICQFix” is in /Library/InputManagers
- This InputManagers Directory and everything in it is owned by user root and group admin (recursively!)
- Nothing in the directory is writeable.
- There is no ~/Library/InputManagers Directory or any other InputManager leftovers from Tiger. They don’t work anyway.
Some notes on this:
- If you don’t know what I’m talking about, don’t do it.
- I don’t provide any support for this. Take it as it is.
- If you want to write an installer, go on and do so. Send it to me and I will publish it here.
- If you have improvements, do the same
- If you are from Apple: Fix that bug!
Here is the Source:
- iChatICQFixSource.zip
And here is a zip that includes everything nicely compiled:
- iChatICQFix.zip
Note: This only works with the Release Version of Leopard and iChat 4.0.
Leopard under the Hood
Here comes the first article pointing out why Leopard is a milestone besides the impressive list of 300 Features (of which some are lame and duplicates, but most are really nice to have).
It’s the developer’s frameworks that will make all the difference. Leopards frameworks are in most part really beautifully designed and easy to use once you get your head around the mountain of basic stuff. We will see a lot of developers switch to “Leopard only” immediately, not because Apple forces them to do so, or because being a 10.4 developer is a bad experience, but because the new release is a big leap forward. We will see a lot of articles about this when the info about the stuff in 10.5 is no longer under NDA on 10/26. If enough people are interested I will do a session about the stuff in Leopard that users don’t normally see on Barcamp Berlin 2 on the first weekend of November.
Possible ways of making the iPhone SDK secure
Steve finally announced that we can develop Cocoa applications on the iPhone from February. Apple needs this time to get the iPhone secure. Well, I suspect the real reason ist that they need to get their API stable – there have been several changes to UIKit from Version 1.0.x to 1.1.1. But aside from that: How can they make the iPhone more secure? By leveraging technologies from Leopard that they announced just yesterday and that one can read about in the security features of Leopard, of which the Phone runs some kind of variant:
- Signed Applications: The Developer signs his Apps. If there is a new App, with an unknown certificate, the phone asks the user for permission to run it. Apple signed Applications can run by default.
- Sandboxing: The App can only access what it needs to access. That prevents at least some viruses.
- Library Randomization: That’s making exploits a lot less likely, because you can’t assume the position of where to write your exploit.
- Tagging Applications also makes a lot of sense, especially with the signing described earlier.
So before an application is first run, it could present a screen like this:
“Do you want to run ‘’Super Atomic Bomberman’ signed by ‘John Doe’ which you trusted ealier with ‘Superfast Racing Game 3000’? It”s been downloaded from “supersoftware.com” on 08/03/08. It want’s to access the Wifi network as well as your contacts.”
iPhoneDevCamp Germany
Gute Ideen müssen kopiert werden 
Das zweite Kölner Barcamp hat noch gar nicht stattgefunden, da schlägt Franz schon das nächste Event vor: Ein iPhoneDevCamp. In San Francisco hat das sehr erfolgreich mit 400 Teilnehmern stattgefunden, drehte sich jedoch mangels SDK nur um die Anpassung von Webapplikationen, nicht um native iPhone-Apps.
Das kann beim deutschen Äquivalent anders werden: Entweder bringt Apple bis dahin ein richtiges SDK raus, oder wir behelfen uns eben damit. Sollte ich bis dahin ein iPhone haben und ein bisschen Zeit finden, um mit UIKit herumzuspielen, werde ich sicher einen Vortrag darüber beisteuern…
App development and Frameworks
Paul Kafasis of the independedent mac development company Rouge Amobea wrote an interesting piece called The Rise of the OS and another called Restarting Innovation that got quite a bit of attention in the mac development world.
Basically Paul says that the OS starts to make a lot of things that were formerly in the domain of third party applications. A modern operating system’s job isnt just to do Task scheduling, network and memory management and put a pretty UI on top of all this: Todays operating systems ship with mail clients, audio/photo/video management software, calendaring, contact management and a lot more. While this seems to be a good thing (You get more for less! Yeah!), it has some serious implications according to Paul: The developers of apps with similar functionality lose their markets and the Users don’t have many apps to chose from, since there is the OS vendor dominating the field.
This discussion began with some ranting about the missing functionality in Apple’s Mail and the fact that no developer wanting to improve that could possibly compete with the free Mail that comes with the OS. The solution proposed was to put Mail’s functionality into a Framework (named “MailKit”) and make it available for other applications. The Webkit framework is a good example for enabling successful applications by putting functionality into a reusable framwork, so why not do it for Mail, too?
I really like the Idea. Sure, Apple could concentrate more on existing frameworks instead of developing new ones, and while I agree with this point, I also think they are on the right track.
Operating systems need to provide the infrastructure that an application lives in. Formerly that was memory management and everything else that you learned in CS, but today’s MVC-driven applications need more things:
They want to share their Data model and make their data interoperable. This gets used more and more, the Address Book Framework is a good example of this, as is Leopard’s Calendar, Notes, and To-Do-List Framework (and some other Framworks that are still under NDA, but that are a huge deal.) A MailKit Framwork would fit right here: Providing a single Mail database to different Mail Applications and exposing functionality for sending and receiving mails. It would make it easy for the user to switch applications, since his actual Mail data is already there, all Mail Apps all access the same store. That’s a huge thing for developers: It doesn’t only cut down development cost for the Data model, it also makes the transition between apps very easy for the user.
In the Controller Layer, there can also be Frameworks, though most of this layser is really specific to the app. The speech Framework is an example, and we will also see some stuff in Leopard that will expose functionality to app developers that Apple used to have for themselves.
The View layer is a classic domain for Frameworks: Nothing here happens without them, as almost everything done here (Buttons, Windows, etc.) comes from AppKit. WebKit falls into this category, it’s a view framework.
This finally brings us to the point of this posting: I think the comparison between the fictional MailKit Framework and Webkit doesn’t fit. One is about shared Data, the other is about (isolated) use of the same view. I really like what Apple does with sharing data, however they can do a lot more. Frameworks are a very good solution of the problems that arise, when the OS is “taking over”. I hope to see ever more future Desktop Applications that work like “Mashups” of these Frameworks, and Leopard is bringing us a huge step into this direction. Also, a Framework that deals with the Data layer has to have the goal of sharing the data, and not only of sharing the model.