Abriß III

Weiter geht es mit den Abrißarbeiten: hintere Hauswand abgetragen und Bad entkernt, wiederum mit tatkräftiger Unterstützung von W.

M. nimmt sich die feineren Arbeiten vor, namentlich Entfernung der Deckenpaneele in Kinder- und Wohnzimmer sowie sämtlicher Steckdosen und Lichtschalter.

Anhänger

Um für sämtliche Be- und Entsorgungsfälle, die ja zwangsläufig bei einer derartigen Bauaktion anfallen, gerüstet zu sein, kauft Z. kurz entschlossen einen Anhänger. Dieser wird heute in Werneck abgeholt. Sehr lustige Fuhre, Z. und T. sowie die drei Zwerge, auf dem Rückweg noch ein kurzer Abstecher in den Baumarkt Mellrichstadt.

Kleiner Wermutstropfen: Es stellte sich, leider erst abends, heraus daß das Stützrad des Anhängers defekt war. Stand sogar drauf.

Abriß II

Zweite große Abrißaktion, welcher der Vorbau und der hintere Anbau zum Opfer fielen. Freitag innerhalb von drei Stunden letzteres erledigt.

Samstag früh im dichten Nebel spektakulärer Kraneinsatz um Betondachplatte des Vorbaus in den Container zu befördern.

Vorbildliche Teamarbeit zwischen Z. und W. um den Vorbau bis auf die Grundmauern abzuknabbern.

Besondere Vorkommnisse: Zusammenbruch des Schleppdachs mit Z. obendrauf. Zusammenbruch eines Steinabsatzes, ebenfalls mit Z. obendrauf. Stuntquote für das Wochenende mehr als erfüllt.

Abriß I

Das Häuschen ist schon ein bisschen speziell. Es gibt nicht nur ein außen liegendes, aber unbenutztes, Klo, sondern auch ein innen liegendes, welches über keinen Wasserzugang verfügt. Ein Geheimraum ohne Zugang, welcher einstmals einen Öltank beherbergte, fügt sich zwischen Bad und Außenwand ein.

Jedenfalls fängt Z. schon einmal an, den Innenklobunker zu entfernen.

An one finger rotation gesture recognizer

Last year we developed the Raumfeld iPhone App. The goal was to build something that could replace our native controller completely. The main design feature of the native controller is the massive volume knob. Of course we wanted to have something similar in our App, so the designer created the volume screen with a big knob, as shown in the right picture.

To create a volume control, we needed a way to detect if the user performs a rotation gesture on the knob image. There is no default UIGestureRecognizer that detects such a gesture, so we had to implement a custom gesture recognizer. It was surprisingly easy – to be honest, the hardest part was to do the math right.

To track the finger movement, we need to check for every touch event, whether it is within the defined area. The gesture is rotating, so there is a center point m, the radius a which defines the minimum distance from m and the radius b which defines the maximum distance from m. Finally we need to calculate the angle ? between the startpoint and the current finger position (relative to m).

For the first check, we calculate the distance d from the center and make sure, that a < d < b is true.

The rotation angle is the angle between the two lines a and b. The arc tangent function atan() is the key:

Ok, that was the hard part 🙂 To implement a custom gesture recognizer, let’s have a look at the UIGestureRecognizer API docs, especially the subclassing notes. We just need to overwrite five methods

The key is touchMoved:withEvent: This method checks the distance of the touch event from the center point. If the touch is within the valid area, the angle between the start point and the current touch position is calculated. The result is sent to the delegate object of our class.

target needs to implement some kind of protocol to allow the gesture recognizer notification of movements:

And that’s the whole magic. To use the gesture recognizer, create an image of a rotating control and add a gesture recognizer to your view:

As soon as a gesture is detected, the delegate method is called and you can rotate the image according to the angle:

I’ve created a sample project on github, feel free to play with. Also make sure to read Ole Begemanns article about the UX details on gesture recognition.

Namensschilder für Polizisten: potentiell tödliche Waffen!!!1!!

Nein, ernsthaft. Wenn jetzt alle Polizisten in Berlin ein Namensschild tragen, kann jeder dahergelaufene Gelegenheitsmörder dem Polizisten das Namensschild entreißen und damit ein Massaker anrichten. Bodo Pfalzgraf, Vorsitzender der deutschen Polizeigewerkschaft demonstriert die von den Namensschildern ausgehende Gefahr an einem Eisbein.

Die Plastikteile könnten den Polizisten entrissen und als lebensbedrohliche Waffe eingesetzt werden.

Große Sprüche auch von Rainer Wendt:

Die Zwangskennzeichnung ist ein gigantischer Misstrauensbeweis in unsere Polizei“, sagt Rainer Wendt, Bundesvorsitzender der Gewerkschaft. Das Vertrauensverhältnis der Bürger in die Polizei sei hervorragend, die individuelle Kennzeichnung daher überflüssig.

Richtig! Es ist ja noch NIE vorgekommen, dass die Polizei versehentlich Demonstranten mit verprügelt hat. Nie! NIE! Ehrenwort! Die Leidtragenden sind letztendlich die armen Polizisten:

Einige Kollegen hätten sich beim Anschnallen im Auto an den Kanten in den Arm geritzt.

Ich muss mir erstmal ein Taschentuch holen… schnüff..

Huch, schon August?

Oh, es ist ja Camp. Und gutes Wetter… Wir haben erstmal einen Graben gezogen, in der Hoffnung, dass das Zelt nicht absäuft.
Sehr cool: schon mit Kind 1 ein Throwie (LED + Batterie + Magnet) gebastelt und morgen für den Raketenworkshop angemeldet. Noch keinen Vortrag gesehen, aber dabei sein ist alles 🙂

Objective C: KVC und KVO

Ich empfinde das Eintauchen in die Welt von Objective C und Cocoa als sehr erfrischend, jeden Tag gibt es etwas neues zu entdecken. Wenn man sich mit anderen Entwicklern, die Objective C nicht kennen, unterhält, kommt aus der C++ Ecke garantiert die Frage: „Kann man dort Operatoren überladen?„.

Nein kann man nicht. Braucht man auch gar nicht. Operatoren zu überladen ist zweifelsohne cool, aber ich multipliziere nicht den ganzen Tag Matrizen, sondern baue Dinge für Endanwender. Das angenehme an Objective C ist, dass es bestimmte Real World Probleme sehr schön löst.

Key Value Observing ist so eine Lösung und es ist ein so verdammt einfaches Konzept, dass ich mich wundere, wie die Welt bisher ohne leben konnte… (Um es vorweg zu nehmen: GObject hat ein ähnliches Konzept und es gibt bestimmt noch mehr Implementierungen dieses Patterns).

Das Real World Problem kommt bestimmt jedem bekannt vor: man hat eine Klasse A gebaut und eine andere Klasse B muss benachrichtigt werden, wenn sich in A irgendetwas interessantes ändert. Bisher wäre das Herangehen, dass A eine Referenz auf B mitschleifen muss, damit Klasse A die Klasse B benachrichtigen kann. Das bringt natürlich das schöne Klassendesign durcheinander, eigentlich hat A mit B nichts zu tun und die Referenz auf B zu handhaben ist auch nervig.

In Objective C gibt es Properties, die Membervariablen und deren Getter und Setter erzeugen können:

Im obrigen Beispiel hat die Klasse „Foo“ ein Member „bar“ und @synthesize generiert die Getter und Setter, die dann so verwendet werden können:

Soweit, so trivial. Mit Key Value Coding kann man auf Properties programmatisch zugreifen. Das bedeutet, ich baue mir einen String zusammen, dessen Inhalt der Name einer Property ist und ich kann auf die Property zugreifen:

Das wird unheimlich praktisch, wenn man z.B. XML parsen muss und die geparsten Key/Value-Paare direkt via KVC in den Properties einer Klasse speichern kann.

Key Value Observing ist nun die Lösung o.g. Problems: man kann sich einfach von außen als Observer für bestimmte Properties einer Klasse registrieren und wird benachrichtigt, falls sich ein Wert ändert.

Das spart eine Menge Code und die beobachtete Klasse A braucht sich um Klasse B nicht kümmern und muss keine Referenz auf B mitschleifen.

Ich finde das ziemlich elegant. Das Klassendesign bleibt sauber und trotzdem ist es möglich, sich kreuz und quer durch alle Schichten der Anwendung über Zustandsänderungen benachrichtigen zu lassen.

Update: Es gibt einen sehr schönen Wrapper von Andy Matuschak: Block Callbacks for Cocoa Observers (via Ole Bergmanns hoch interessantem Twitterstream)

Der Einstieg in die iPhone / iPad Programmierung

Ich lese mich gerade in die Welt der iOS-Programmierung ein, „for fun and profit“ sozusagen. Die Hürde bei der Plattform ist etwas höher, weil man erstmal eine neue Programmiersprache (Objective C) lernen muss und zusätzlich die ganze Cocoa-API verstehen muss. Ich mache Dinge gerne gründlich, deswegen habe ich mir erstmal die Sprache an sich zu Brust genommen um dann in die iPhone-Programmierung einzusteigen.

Objective C macht auf mich erstmal einen sehr aufgeräumten Eindruck. Ich habe vorher C, Java und etwas C++ programmiert und von den Sprachen findet man einen guten Mix in Objective C wieder. Die umfangreiche Foundation- API ist vergleichbar mit dem, was man in Java vorfindet, trotzdem kann man bis auf C-Ebene hinunter. Die Objektorientierung ist angenehm gelöst, es heisst alles nur ein bisschen anders. So sind Protokolle z.B. das was man in Java Interfaces nennt.

Die Syntax ist etwas anstrengend, man merkt der Sprache deutlich an, dass die ersten Versionen vermutlich im C-Präprozessor implementiert wurden. Die vielen eckigen Klammern sind zwar erstmal ungewohnt, aber damit kommt man relativ schnell klar. Schlimmer ist, dass mit Objective C 2.0 ein Bruch erfolgte und Setter/Getter jetzt mit einem Punkt angesprochen werden können. Das spart zwei eckige Klammern ein, wirkt aber ziemlich inkonsistent.

Insgesamt ist die Sprache sehr mächtig, es gibt schöne dynamische Features. So kann man einer Klasse nachträglich Methoden hinzufügen (Categories), es gibt Dictionaries, wie man sie aus Python kennt und man kann auch mit dem for x in y Konstrukt durch solche assoziativen Speicher durchiterieren:

Als Buch kann ich Programming in Objective-C 2.0* von Stephen Kochan empfehlen. Das Buch hat den Anspruch auch für Menschen geeignet zu sein, die bisher noch nicht in C programmiert haben. Trotzdem vermittelt es alle wichtigen Aspekte in der zu erwartenden Tiefe.

Was die Literatur zur „richtigen“ Programmierung unter iOS angeht: der Markt ist erstmal sehr unübersichtlich. Es gibt viele Bücher, aber welches davon ist gut? Ziemlich hoch gelobt wurde in letzter Zeit IPhone Programming: The Big Nerd Ranch Guide*. Wer sich die 3500 Euro für ein 7-Tage Training auf der Big Nerd Ranch nicht leisten kann, ist mit dem Buch gut beraten.
Man merkt deutlich, dass es aus Schulungsunterlagen hervorgegangen ist, aber das ist kein Manko, im Gegenteil. Man hat sofort Erfolgserlebnisse und muss nicht erst 200 Seiten Urschleim wälzen, bevor man einen Button programmieren darf. Ich kann das Buch fast uneingeschränkt empfehlen. Einziger Kritikpunkt ist, dass es für meinen Geschmack etwas Tiefgang missen lässt. Ich habe das Buch zur Hälfte durch und bis jetzt wurde das Thema Speicherverwaltung, das allen iOS-Anfängern das Genick bricht, sträflich vernachlässigt.

Zur iOS-Umgebung selbst kann ich noch nicht so viel sagen. Es wirkt alles sehr durchdacht, allerdings muss man sich das lineare Denken abgewöhnen. Jeder Pups wird über einen Callback erledigt (er heisst nur Delegate), was einfache Probleme ein bisschen verkompliziert. Aber ich denke das ist nur Übungssache.

Die Dokumentation ist mindestens auf dem Niveau der MSDN, wenn nicht sogar besser. Man kann Beispiele mit einem Knopfdruck direkt in Xcode öffnen. Die IDE ist allerdings eine Zumutung, Xcode 3 ist ein Wirrwar von Fenstern, die man ständig zur Seite schieben muss. Ich frage mich welcher ADS-Patient für das Interface-Design verantwortlich ist.
Xcode 4 dürfte die nächsten Wochen das Licht der Welt erblicken, hier findet sich alles in einem iTunes-Artigen Fenster wieder, was sich wesentlich angenehmer anfühlt. Allerdings haben die Previews von Xcode 4 noch ein paar hässliche Bugs, so lange die Final noch nicht draußen ist, würde ich Anfängern raten, bei Xcode 3 zu bleiben.

Was braucht man, um erstmal loszulegen? Ein gutes Buch, einen intel-Mac / Hackintosh und früher oder später ein „richtiges“ iOS-Gerät. Es genügt ein alter iPod-Touch, aber ohne geht es kaum. Der Simulator kann bestimmte Dinge nicht (Gravitationssensor, Kamera) und verhält sich auch manchmal ein klein bisschen anders (ich hatte speziell bei der Maps-API Probleme). Danke an Semmi, der mir so selbstlos seinen iPod Touch zur Verfügung gestellt hat. Ich verspreche, Du bekommst ihn noch in diesem Leben zurück 😉

Als Entwickler kann man kann nur Anwendungen auf iOS Geräten installieren, wenn man ein Entwicklerzertifikat hat, das kostet pro Jahr 79 Euro. Das ist die einzige Kröte, die man schlucken muss. Ob das gerechtfertigt ist, vermag ich nicht zu sagen, aber man kann sich so ein Zertifikat auch teilen und dann bis zu 100 iOS-Geräte bestücken. Das klappt natürlich nur mit Leuten, denen man halbwegs vertrauen kann.

*=affiliate Link

OH HAI new job

Der letzte Chaos Communication Congress hat mir einen neuen Job beschert 🙂 Interessant ist auch, wie schnell so etwas gehen kann. Einen Monat nach dem ersten informellen Gespräch auf dem Kongress habe ich am Montag meinen letzten Arbeitstag in der alten Firma. Wie alles im Leben sind eben auch Kündigungsfristen verhandelbar.

Pages: <<< 1 2 3 4 5 6 7 8 ... 96 97 98 >>>