MKBlog

iOS-Framework: Einführung in MKNetworkKit (German Translation of MKNetworkKit documentation)

2013-04-25T00:21:18-07:00

Translation by Jonas Pencke (@jonaspencke)

iOS-Framework: Einführung in MKNetworkKit

Wie genial wäre es, wenn sich ein Networking-Framework automatisch ums Cachen der Antworten kümmern würde?
Wie genial wäre es, wenn sich ein Networking-Framework automatisch alle noch auszuführenden Operationen merken würde, wenn der Client offline geht?
Im Offline-Zustand könnten somit Tweets favorisiert oder Feeds als gelesen markiert werden und das Networking-Framework würde sich um die Aufnahme aller Operationen kümmern, sobald das Gerät wieder online ist. Und dies alles ohne zusätzlichen Programmieraufwand? Herzlich Willkommen bei MKNetworkKit.

Was ist MKNetworkKit?

MKNetworkKit ist ein in Objective-C geschriebenes Networking-Framework, welches sich nahtlos integriert, Blocks verwendet, ARC ready ist und sich einfach verwenden lässt. Inspiriert wurde MKNetworkKit von zwei anderen bekannten Networking-Frameworks, namens ASIHTTPRequest und AFNetworking. Der Funktionsumfang beider wurde zusammengeführt und mit neuen zusätzlichen Funktionen erweitert. Im Vergleich mit anderen Frameworks schreibt man beim Verwenden von MKNetworkKit ein wenig mehr Code, was jedoch zu klarerem bzw. besser lesbarem Code führt. Mit MKNetworkKit ist es schwierig, unschönen Networking-Code zu schreiben.

Funktionen

Extremes Leichtgewicht
Das komplette Framework besteht im Wesentlichen aus 2 Hauptklassen und ein paar Kategorien. Aus diesem Grund sollte das Anpassen von MKNetworkKit ziemlich einfach von der Hand gehen.

Die gesamte Applikation benutzt eine einzige globale Queue
Apps die sehr stark von einer Internet-Verbindung abhängen, müssen sich um die Optimierung bei der Anzahl der gleichzeitig genutzten Netzwerk-Operationen kümmern. Bisher gibt es leider kein einziges Networking-Framework, was dies von Haus aus korrekt erledigt. Nachfolgend gebe ich euch ein Beispiel für Probleme, die auftreten können, wenn die Anzahl der gleichzeitig ablaufenden Netzwerk-Operationen in einer App nicht kontrolliert bzw. optimiert wird.
Angenommen wir möchten einige Fotos auf einen Server (z.B. Color oder Batch) laden. Die meisten mobilen Netzwerke (3G) sind dabei auf maximal 2 gleichzeitige HTTP-Verbindungen von der gleichen IP-Adresse beschränkt. Das bedeutet, dass von einem Gerät gleichzeitig nicht mehr als 2 HTTP-Verbindungen in einem 3G Netzwerk geöffnet werden können. Bei EDGE ist es oft sogar noch schlimmer bzw. sind weniger Verbindungen erlaubt. In den meisten Fällen verfügt man dort nur über eine einzige Verbindung. Das Limit von 6 in einem gewöhnlichen Breitbandnetz (Wifi) wirkt demgegenüber relativ hoch. Da die Verbindung von einem iDevice mit einem Wifi-Netzwerk jedoch nicht immer gesichert ist, sollte man auch auf eingeschränktere Netzwerk-Verbindung vorbereitet sein. Im Normalfall sollte das iDevice jedoch mit einem 3G-Netzwerk verbunden sein. Demzufolge ist es möglich 2 Fotos gleichzeitig hoch zu laden. Dabei ist die langsame Upload-Geschwindigkeit nicht das größte Problem. Das eigentliche Problem tritt auf, wenn z.B. ein View geöffnet wird, der mehrere Thumbnails (sagen wir auf einem anderen View) lädt, während im Hintergrund die anderen Upload-Operationen noch laufen. Wenn nun die Queue-Größe über die App hinweg nicht ordnungsgemäß gehandhabt wird, können die Download-Operationen der Thumbnails mit einem Timeout abbrechen, was nicht wirklich sinnvoll ist. Besser wäre es die Download-Operation der Thumbnails zu priorisieren oder solange zu warten, bis der Upload der Fotos fertig gestellt ist, um danach das Laden der Thumbnails zu beginnen. Damit das funktioniert, braucht man eine (einzige) globale Queue für die gesamte App. MKNetworkKit stellt genau dieses Prinzip automatisch sicher, indem es für jede Instanz eine globale Queue anlegt und verwendet. MKNetworkKit ist selbst kein Singleton, aber die globale Queue schon.

Netzwerk-Aktivitätsanzeige korrekt darstellen
Während viele Klassen und Bibliotheken von Drittanbietern ein einfaches In- bzw. Dekrementieren der Anzahl der Netzwerk-Anfragen verwenden, um den Aktivitätsindikator anzuzeigen, basiert die MKNetworkKit Aktivitätsanzeige auf dem Prinzip der global geteilten Queue. Durch das Observieren (KVO) der “operationCount” Property, wird die Aktivitätsanzeige immer dargestellt, solange noch eine Operation in der gemeinsamen Queue abgearbeitet wird. Für den Entwickler entfällt damit das manuelle Verwalten der Netzwerk-Aktivitätsanzeige.

Automatisches Testen der Queue-Größe
Vorhin wurde erwähnt, dass die meisten mobilen Netzwerke gleichzeitig nicht mehr als 2 Verbindungen erlauben. Aus diesem Grund sollte bei einer 3G Netzwerkverbindung die Queue-Größe auf 2 gesetzt werden. Dies wird automatisch von MKNetworkKit erledigt. Verschlechtert sich die Verbindung von Wifi zu 3G/EDGE/GPRS, dann passt MKNetworkKit für dich die Anzahl der erlaubten gleichzeitigen Verbindungen an – in diesem Fall auf 2. Selbstverständlich wird die Queue-Größe wieder zurück auf 6 gesetzt, sobald dem Gerät erneut ein Wifi Netzwerk zur Verfügung steht. Dieser Ansatzes bringt eine erhebliche Performance-Verbesserung beim Laden von Thumbnails (oder mehreren ähnlichen kleinen Anfragen) für eine Foto-Galerie von einem Remote-Server über 3G.

Automatisches Caching
MKNetworkKit kann automatisch alle “GET”-Anfragen cachen. Wird die gleiche Anfrage ein weiteres Mal ausgeführt, so ruft MKNetworkKit den “CompletionHandler” mit der gecachten Version der Antwort (wenn diese vorliegt) direkt auf. Wenn die Daten vom Server erfolgreich geladen wurden, wird der “CompletionHandler” ein weiteres Mal mit der neuen Antwort aufgerufen. Das bedeutet, dass das Cache-Handling nicht manuell gemacht werden muss. Alles was dafür notwendig ist, ist das Aufrufen der folgenden Methode.

In von MKNetworkEngine abgeleiteten Klassen können bei Bedarf Methoden überschrieben werden, um den Cache-Ordner und die “in-memory” Cache-Kosten einzustellen.

Freezen (einfrieren) von Operationen
MKNetworkKit bietet die Möglichkeit Netzwerk-Operationen einzufrieren. Wenn eine Operation eingefroren wird, z.B. beim Verlust der Netzwerkverbindung, werden die Operation automatisch serialisiert und wieder ausgeführt, sobald das Gerät wieder online kommt. Dies ist vergleichbar mit “Drafts” in einem Twitter- oder Email-Client.
Wenn ein Tweet gepostest wird, kann der Netzwerk-Aufruf als “freezable” markiert werden und MKNetworkKit übernimmt automatisch das Einfrieren und Wiederherstellen der Anfragen. Das heißt, dass fast kein extra Code geschrieben werden muss, um die Tweets später abzuschicken. Dies kann auch für andere Operationen, wie dem Favorisieren eines Tweets oder Sharen eines Posts von einem Google Reader Client, Hinzufügen eines Links zu Instapaper oder ähnlichen Operationen genutzt werden.

Führt exakt eine Operation für gleiche Anfragen aus
Beim Laden von Thumbnails (von einem Twitter Stream), wird oft für jedes einzelne Avatar Bild eine neue Anfrage erzeugt. In der Realität sollte jedoch die Anzahl der Anfragen gleich der einzigartigen URLs sein. MKNetworkKit führt jede GET Anfrage die in die Queue kommt nur exakt einmal aus. HTTP POST-Anfragen werden logischerweise nicht von MKNetworkKit gecacht.

Image Caching
MKNetworkKit kann einfach zum Cachen von Thumbnails genutzt werden. Durch das Überschreiben einiger weniger Methoden kann die Anzahl der Bilder, die im in-Memory-Cache gehalten werden sollen und der Speicherort im Cache-Directory eingestellt werden. Das Überschreiben dieser Methoden ist aber komplett optional.

Performance/Leistung
Nur ein einziges Wort: Geschwindigkeit. Das Cachen von MKNetworkKit ist nahtlos (seamless). Es arbeitet wie NSCache, jedoch mit der Ausnahme, dass beim Auftreten einer Speicherwarnung der in-Memory-Cache in den Cache Ordner geschrieben wird.

Volle Unterstützung von Objective-C ARC
Normalerweise wird für ein neues Projekt ein neues Netzwerk-Framework genommen. MKNetworkKit ist eigentlich nicht dafür gedacht existierende Frameworks zu ersetzen (obwohl es möglich ist, ist es meistens ein recht aufwendiger bzw. ermüdender Job). Neue Projekte sollten eigentlich immer ARC verwenden. Als dieser Artikel geschrieben wurde, war MKNetworkKit das einzige Networking-Framework, das komplett ARC fertig ist. ARC basierte Speicherverwaltung ist generell um eine Größenordnung schneller als die Speicherverwaltung ohne ARC.

Wie wird es benutzt
Ok genug des Eigenlobes. Lasst uns schauen, wie das Framework benutzt werden kann.

Hinzufügen des MKNetworkKits

1. Ziehe den MKNetworkKit Ordner in dein Projekt.
2. Füge das CFNetwork.Framework, SystemConfiguration.Framework und Security.Framework hinzu.
3. Inkludiere MKNetworkKit.h zu deiner PCH Datei
4. Lösche die NSAlert+MKNetworkKitAdditions.h Datei falls es ein iOS Projekt ist.
5. Lösche die UIAlerView+MKNetworkKitAdditions.h Datei falls es ein Mac Projekt ist.

Das war’s. Mit nur 5 Core Dateien verfügst du über ein mächtiges Networking-Kit.

Klassen in MKNetworkKit

1. MKNetworkOperation
2. MKNetworkEngine
3. Verschiedene Helferklassen (Apple’s Verfügbarkeits-Klasse (Reachability)) und Kategorien

Ich glaube an Einfachheit und Apple hat den schweren Job beim Schreiben des richtigen Networking-Codes bereits erledigt. Was ein Drittanbieter Netzwerk-Framework ermöglichen sollte, ist ein elegantes Queue basiertes Networking mit optionalem Caching. Ich glaube daran, dass jedes Drittanbieter-Framework weniger als 10 Klassen besitzen sollte (unabhängig davon ob es sich dabei um Networking handelt oder eine UIKit Ersetzung oder irgend etwas anderes). Mehr als das ist zu aufgebläht. Three20 sowie ShareKit sind Beispiele für eine aufgeblähte bzw. überfrachtete Bibliothek. Es kann sein, dass sie an sich gut sind, aber trotzdem bleiben sie riesig und total aufgebläht. ASIHttpRequest oder AFNetworking sind im Vergleich zu RESTKit schlank und somit wirkliche Leichtgewichte. Ebenfalls ist JSONKit ein Leichtgewicht, anders als TouchJSON (oder alle anderen TouchCode Bibliotheken). Es kann natürlich sein, dass nur ich Wert darauf lege, aber in meinem Source-Code soll nicht jede dritte Zeile von einer Drittanbieter-Bibliothek stammen.

Die Schwierigkeit bei einem großen und unüberschaubarem Framework ist, das Verständnis für die interne Funktionsweise und die Möglichkeit das Framework an die eigenen Bedürfnisse anzupassen (falls nötig). Meine Frameworks (wie MKStoreKit, das In-App-Verkäufe zu deiner App hinzufügt) konnten immer super einfach verwendet werden und ich glaube, dass dies auch für MKNetworkKit gilt. Um MKNetworkKit zu benutzen, musst du nur die öffentlichen Methoden der beiden Klassen MKNetworkOperation und MKNetworkEngine kennen. MKNetworkOperation ist der ASIHttpRequest Klasse recht ähnlich. Es ist eine Unterklasse von NSOperation und bilder einen Wrapper um deine Request- und Response-Klassen. In einer Applikation wird dann für jede benötigte Netzwerkoperation eine neue MKNetworkOperation erzeugt.

MKNetworkEngine ist eine Pseudo-Singleton Klasse, die die Netzwerk-Queue der Applikation verwaltet. Es ist in dem Sinne ein Pseudo-Singleton, da für einfache Anfragen die MKNetworkEngine Methoden direkt genutzt werden können. Für größere Anpassungen sollte jedoch eine von MKNetworkEngine ableitende Klasse erzeugt werden. Jede von MKNetworkEngine ableitende Klasse besitzt von Haus aus ihr eigenes Reachability Objekt, das sie über Server-Verfügbarkeitsänderungen notifiziert. Für jeden einzelnen REST-Server, den du verwendest, sollte eine eigene abgeleitete Klasse von MKNetworkEngine erzeugt werden. Es ist in diesem Sinne Pseudo-Singleton, da jede einzelne Anfrage, in egal welcher Subklasse, durch die eine globale Queue geht.

Instanzen deiner MKNetworkEngines können wie die CoreDataManagedObjectContext Klasse im “ApplicationDelegate” gespeichert werden. Beim Verwenden von MKNetworkKit werden Unterklassen von KNetworkEngine erzeugt, um die Netzwerk-Anfragen logisch zu gruppieren. Das bedeutet, dass alle Yahoo-relevanten Methoden in einer gemeinsamen Klasse und alle zu Facebook gehörenden Methoden in einer anderen Klasse liegen. Im Folgenden schauen wir uns drei Beispiele für die mögliche Verwendung des Frameworks an.

Beispiel 1

Lasst uns nun eine “YahooEngine” erzeugen, die aktuelle Wechselkurse von “Yahoo finance“ lädt.

Schritt 1:

Erzeuge einer “YahooEngine”-Klasse als abgeleitete Klasse von MKNetworkEngine. Die init-Methode der MKNetworkEngine bekommt als Parameter einen Host-Namen und bei Bedarf einen benutzerdefinierten Header. Die benutzerdefinierten Header sind optional und können “nil” sein. Wenn ein eigener REST Server geschrieben werden soll (anders als in diesem Fall), könnte dort die Client-App-Version und andere sonstige Daten, wie ein Client-Identifier hinzugefügt werden.

Dabei ist zu beachten, dass yahoo einen eigentlich nicht zwingt einen “x-client-identifier” im Header mitzuschicken. Zum Zeigen des Features wurde es aber im obigen Code-Beispiel hinzugefügt.

Da der komplette Code ARC verwendet, ist es die Aufgabe des Entwicklers eine Engine Instanz zu speichern (starke Referenz).

Wenn eine abgeleitete Klasse von MKNetworkEngine erzeugt wird, wird dazu automatisch die Reachability-Implementierung hinzugefügt. Das bedeutet, wenn der Server nicht mehr zu erreichen ist oder irgendwelche unvorhersehbaren Umstände eintreten, z.B. dass der Host nicht erreichbar ist, werden die Anfragen automatisch eingefroren. Für weitere Informationen bezüglich des Einfrieren von Operationen, schaut in der Sektion “Freezing Operations” etwas weiter unten nach.

Schritt 2:

Design der Engine Klasse (Trennung der Zuständigkeiten)
Nun kümmern wir uns um das Schreiben der “YahooEngine”-Methoden, welche die Wechselkurse abfragen. Die Engine-Methoden werden aus dem ViewController heraus aufgerufen. Eine gute Design-Angewohnheit ist, sicherzustellen, dass die Engine-Klasse die URL/HTTP-Headers nicht an die aufrufende Klasse weitergibt bzw. offenlegt. Der View braucht keine Informationen über die URL-Endpunkte oder andere Parameter. Das bedeutet, dass Parameter in Methoden der “YahooEngine” die Währungen und die Anzahl der Währungseinheiten sein sollten. Der Rückgabewert dieser Methode könnte ein double sein, der den Wechselrate-Faktor beschreibt und eventuell den Zeitstempel, wann es abgefragt wurde. Da die Operationen nicht synchron ausgeführt werden, sollten die Werte

mit Hilfe von Blocks zurückgegeben werden. Ein Beispiel hierfür wäre das folgende:

Die Basisklasse MKNetworkEngine definiert drei Typen von Block-Methoden, siehe unten:
In unserer “YahooEngine” nutzen wir eine neue Art von Block, “CurrencyResponseBlock”

der die Wechselrate zurück liefert. Die Definition sieht wie folgt aus:
In jeder normalen Applikation sollten eigene Block-Methoden – ähnlich wie der “CurrencyResponseBlock” – zum Zurücksenden von Daten zum View Controller definiert und genutzt werden.

Schritt 3:

Verarbeitung der Daten
Die Datenverarbeitung, die die vom Server geholten Daten – unabhängig ob es JSON, XML oder “Binary Plists” sind – umwandelt, sollte in der Engine durchgeführt werden. Noch einmal, die Controller sollten von dieser Aufgabe befreit werden. Die Engine sollte die Daten in passenden Model-Objekten oder Arrays von Model-Objekten (im Falle von Listen) zurück liefern. JSON/XML sollte deshalb in den Engines zu Modellen umgewandelt werden. Nochmals, um die richtige Aufteilung der Zuständigkeiten sicherzustellen, sollte der ViewController nicht über die Schlüssel (Keys) verfügen, um auf einzelne Elemente im JSON zugreifen zu können.

Dies fordert das Design der Engine bzw. lässt sich daraus schließen. Die meisten Networking Frameworks zwingen einen nicht, diesem Paradigma des “Separation of Concerns” zu folgen. Wir machen das, weil wir uns um euch kümmern

Schritt 4:

Methoden Implementierung
Wir werden nun die Implementierungsdetails der Methode diskutieren, die die Währungsumrechnungen durchführt.

Das Abgreifen der Währungsinformationen von Yahoo ist so einfach wie eine normale GET-Anfrage. Hierfür habe ich ein Makro geschrieben, welches die URL für ein zu

übergebendes Währungsformat formatiert.
Die Methoden, die in dieser Engine Klasse geschrieben werden, sollten die folgenden Sachen in ebendieser Reihenfolge tun.

1. Die URL aus den Parametern zusammenstellen.
2. Für die Anfrage ein MKNetworkOperation Objekt erzeugen.
3. Die Parameter der Methode setzen.
4. “Completion” und “ErrorHandler” zu der Operation hinzufügen (Der “CompletionHandler” ist dabei der richtige Platz, um die zurückgelieferten Antworten zu verarbeiten und in entsprechende Modelle zu konvertieren.)
5. Optional können “ProgressHandler” zur Operation hinzugefügt werden. (Oder aber im View Controller)
6. Falls die Operation ein Datei-Download ist, muss ein Download-Stream (im Normalfall eine Datei) gesetzt werden. Dies ist wiederum optional.
7. Wenn die Operation fertig ist, muss das Resultat weitergereicht und die Block-Methode aufgerufen werden, um die Daten zur aufrufenden Methode zurückzugeben.

Das ist im Folgenden dargestellt
Der obige Code formatiert die URL und legt eine MKNetworkOperation an. Nachdem die “Completion” und “ErrorHandler” definiert wurden, wird die Operation durch das Aufrufen der Superklassenmethode “enqueueOperation” in die Queue aufgenommen und liefert eine Referenz davon zurück. Der “ViewController” sollte diese Operation speichern und sie abbrechen, wenn der View aus der View-Hierarchie herausgeschmissen wird. Deshalb sollte, wenn die Engine Methode sagen wir in “viewDidAppear” aufgerufen wird, die Abbruch Operation in “viewWillDisappear” aufrufen. Das Abbrechen der Operation ermöglicht der Queue, andere Operationen des nächsten Views durchzuführen (Denkt dran, dass in einem mobilen Netzwerk nur zwei Operationen gleichzeitig verarbeitet werden können. Deshalb ist das Abbrechen von Operationen, wenn sie nicht mehr benötigt werden, eine Grundvoraussetzung, um Performance und Geschwindigkeit der App sicherzustellen).

Der View Controller kann zusätzlich (bei Bedarf) einen “ProgressHandler” hinzufügen und darüber das User Interface aktualisieren. Dies ist nachfolgend dargestellt.

Die MKNetworkEngine besitzt zudem Standardmethoden, um eine Operation nur aus einer URL zu erzeugen. Aus diesem Grund könnte die erste Zeile des Codes auch wie folgt

geschrieben werden
Beachten muss man, dass die bei der Initialisierung der Engine Klasse angegebenen Hostnamen automatisch vor die Request-URLs gesetzt werden.

Das Erzeugen einer POST, DELETE oder PUT Methode ist so einfach wie das Ändern eines Parameters einer http Methode. Die MKNetworkEngine besitzt noch mehr Standardmethoden wie diese. Mehr Informationen findet ihr in den header Dateien.

Beispiel 2

Hochladen eines Bildes zu einem Server (zum Beispiel zu TwitPic).
Lasst uns nun durch ein Beispiel schauen, in welchem ein Bild zu einem Server geschickt wird. Beim Hochladen eines Bildes muss die Operation offensichtlich als “multi-part form data” encodiert werden. Dabei folgt MKNetworkKit einem ähnlichen Pattern wie ASIHttpRequest. Durch den Aufruf der Methode “addFile:forKey:” in der MKNetworkOperation wird der Anfrage eine Datei als “multi-part form data” “hinzugefügt”. Es ist wirklich so einfach.
MKNetworkOperation hat zudem eine Standardmethode, um ein Bild von einem “NSData” Pointer hinzuzufügen. Das heißt, dass die Methode “addData:forKey:” direkt von einem “NSData” Pointer aufgerufen werden kann, um ein Bild zu einem Server zu schicken. (Interessant ist dies zum Beispiel beim direkten Hochladen eines gerade mit der Kamera geschossenen Bildes.)

Beispiel 3

Herunterladen von Dateien in einen lokalen Ordner (Caching).
MKNetworkKit ermöglicht das einfache Laden einer Datei von einem Remote-Server sowie das Speichern in einer Lokation auf dem iPhone des Benutzers.
Dafür muss nur der “outputStream” der MKNetworkOperation gesetzt werden und man ist

fertig.
Es können mehrere “Output Streams” zu einer einzelnen Operation hinzugefügt werden, um die gleiche Datei an mehreren Stellen zu speichern (zum Beispiel im Cache Ordner sowie im “Working” Ordner)

Beispiel 4

Thumbnail-Caching
Beim Herunterladen von Bildern muss eher eine absolute URL als ein Pfad angegeben werden. DIE MKNetworkEngine hat dafür eine Standard-Methode. Verwende einfach die Methode “operationWithURLString:params:httpMethod:” um eine Netzwerk-Operation mit einer absoluten URL zu erzeugen.
Die MKNetworkEngine ist intelligent, da sie mehrere GET-Anfragen zur gleichen URL zu einer einzigen zusammenführt und alle Blocks, wenn die eine Operation fertig ist, notifiziert. Dies verbessert drastisch die Geschwindigkeit beim Abgreifen von Bild-URLs für bekannte Thumbnails.

Leite die MKNetworkEngine ab und überschreibe den Bild Cache Ordner und die Cache-Kosten. Wenn diese beiden Einstellungen nicht individuell angepasst werden sollen, können auch direkt die MKNetworkEngine-Methoden zum Download von Bildern genutzt werden. Dies ist sogar empfehlenswert.

Caching Operationen
MKNetworkKit speichert standardmäßig alle Anfragen zwischen. Alles was dafür getan werden muss, ist das Cachen für die Engine anzuschalten. Wenn eine GET-Anfrage ausgeführt wird und die Antwort vorher bereits zwischengespeichert wurde, dann wird der “CompletionHandler” sofort mit der gecachten Antwort aufgerufen. Um zu wissen, ob die Antwort eine zwischengespeicherte ist oder nicht, kann die Methode “isCachedResponse”

genutzt werden. Dies ist im Folgenden illustriert:

Freezing-Operationen
Eines der wahrscheinlich interessantesten Features von MKNetworkKit ist die integrierte Möglichkeit, Operationen einfrieren zu können. Alles was dafür benötigt wird, ist die Operation als “freezable” zu markieren. Dies erfordert quasi keinen Aufwand.
Eingefrorene Operationen werden automatisch serialisiert, wenn die Netzwerk-Verbindung abbricht, und wieder aufgenommen, wenn eine neue Netzwerk-Verbindung besteht. Denkt über die sich bietenden Möglichkeiten nach, z.B. kann ein Tweet als Favorit markiert werden während man offline ist und die Operation wird später, wenn man wieder online ist, automatisch ausgeführt.
Eingefrorene Operationen werden ebenfalls auf der Festplatte persistiert, wenn die App in den Hintergrund tritt und auch automatisch fortgeführt, wenn die App wieder in den Vordergrund kommt.

Standardmethoden der MKNetworkOperation
Die Klasse MKNetworkOperation bietet folgende Standardmethoden, um das Daten-Format der Antwort zu bestimmen:

1. responseData
2. responseString
3. responseJSON (only on iOS 5)
4. responseImage
5. responseXML
6. error

Diese Methoden sind relativ praktisch beim Zugreifen auf die Antwort nach einer beendeten Netzwerk-Operation. Wenn das Format falsch ist, liefern die Methoden “nil” zurück. Wenn zum Beispiel versucht wird auf “responseImage” zuzugreifen, obwohl die aktuelle Antwort eine HTML Antwort ist, wird “nil” zurückgeliefert. Die einzige Methode, die garantiert das richtige und erwartete Resultat zurück liefert, ist “responseData”. Die anderen Methoden sollten benutzt werden, wenn der Typ der Antwort bekannt ist.

Sinnvolle Makros
Die Makros, “DLog” und “ALog” sind frecherweise von Stackoverflow geklaut und leider kann ich die Quelle nicht mehr finden. Falls du diese Makros geschrieben haben solltest, lass es mich wissen.

Eine Bemerkung zu GCD
Ich habe absichtlich GCD nicht verwendet, da Netzwerk Operationen bei Bedarf gestoppt und priorisiert werden müssen. GCD kann dies, obwohl es effektiver als NSOperationQueue ist, nicht. Ich empfehle GCD-basierte Queues nicht für Netzwerk-Operationen zu verwenden.

Dokumentation
Die Header-Files sind dokumentiert und ich probiere gerade das “headerdoc” von Apple aus. Währenddessen kannst du ein wenig mit dem Code herumspielen bzw. ihn verwenden (read: Fork).

Source Code
Der Source Code für das MKNetworkKit ist zusammen mit einer Demo-Applikation auf Github verfügbar.
MKNetworkKit bei Github

Anfragen für neue Funktionen
Bitte schickt mir keine Email für Funktionen, die ihr gerne in der Zukunft hättet. Der beste Weg ist ein Issue auf Github zu erzeugen.

Lizenz
MKNetworkKit ist unter der MIT Lizenz lizensiert.

Der gesamte Source Code kann unentgeltlich in deiner App genutzt werden, wenn ein Copyright Hinweis in der App angezeigt wird. Eine kleine Erwähnung in den tiefsten Winkeln deiner “About”-Seiten reicht aus.

Eine Attribution freie Lizenz kann auf Nachfrage stattgegeben werden. Kontaktiert mich unter mknetworkkit@mk.sg

Follow me on Twitter

MKBlockTimer

2013-04-04T07:11:53-07:00

Just published a NSObject category, MKBlockTimer.
Use this nifty utility to measure the time taken to execute a block of code, without macros.

Usage

The method is fairly straightforward to use.

  [self logTimeTakenToRunBlock:^{
 
    // your time consuming piece of code here
    for(int i = 0 ; i &lt; 1000000000; i ++);
 
  } withPrefix:@"For Loop"];

When you do this, you should see the following on the console.

Output

2013-04-04 22:07:08.966 MKBlockTimerDemo[69436:c07] For Loop: 1814 ms

The method logs the time taken to execute the block on the console with a specified prefix. You can pass any string for prefix and use it to identify the block. I’ve been using this for quite sometime and thought would open source it. I find this method much clearer than manually adding startTimer and endTimer methods and hope it would be useful for you too.

Source Code

The code is available under MIT license at the Github repository MKBlockTimer

–
Mugunth

Follow me on Twitter

Deploymate – An essential Xcode companion for iOS developers

2013-03-14T02:04:58-07:00

When you write an iOS app, you always use the “Latest iOS SDK” as your Base SDK and choose a older iOS version as your deployment target. As on date, you would probably use iOS 6.1.2 as your based SDK and iOS 5.1 as your target.

Because your Base SDK is 6.x, you are free to use APIs and frameworks that were introduced in iOS 6. However, its your responsibility as a developer to ensure that you either fallback gracefully on older versions of iOS either by providing alternatives or disabling the feature altogether.

For example, if the feature that you are implementing is “Sharing on Facebook”, you should be using the built in Facebook sharing (SLComposeViewController) on iOS 6 and fallback gracefully by sharing using the Facebook’s official SDK for iOS 5 devices.

Failing to do this will result in your app crashing on a older operating system.

Preventing crashes

When your deployment target is not the same as your Base SDK, you need to ensure three things to prevent your app from crashing.

1. Check if every framework you are linking against is available in all versions of iOS you are deploying to.

2. Check if every class you are using is available in all versions of iOS you are deploying to,

3. Check if every function you are using is available in all versions of iOS you are deploying to.

Framework Availability

See if all the frameworks you are linking against are available on all operating systems you are deploying to. If a specific framework is not available in For example, if you are linking against Social.Framework introduced in iOS 6, on an app that is deployed on iOS 5, your app will crash immediately at start up. The way to fix this crash is to weak-link the framework.

Fairly straight forward. You might be linking against a fairly limited number of frameworks and it’s easy to check them.

Class Availability

Sometimes an existing framework like UIKit or Foundation will have additional classes added. UICollectionView is a good example. If you use UICollectionView, you should ensure that, you either hide those UI on older devices, or using alternative UI on older devices by conditionally checking for availability of class.

You do that by

if([UICollectionView class]) {
 
 // iOS 6 specific code
} else {
 
 // iOS 5 specific code
}

Slightly tricky.

Method Availability

Sometimes an existing class will have new methods added. An example would be registerClass:forCellReuseIdentifier: in UITableView. This method is available only from iOS 6. You normally check for method availability using respondsToSelector and use it if the method is present.

Keeping track of method availability is arguably harder than the other two.

Meet Deploymate

Deploymate is a third party solution to free you from worrying about the last kind of crash, method availability check. All you need to do is to open your project in Deploymate and “Analyze” it. Deploymate will report if you are using any APIs that are not available in your deployment target operating system version.

By default Deploymate runs your code against the “Deployment Target” you set in your project. You can even change this setting without changing your project setting and “Analyze” again. So, even if your project’s deployment target is 5.1, you can try if it runs on iOS 5.0 using Deploymate and even change your project to deploy to iOS 5 devices.

Features missing

While the guys behind Deploymate has indeed done a great job, (in fact Deploymate is something that I would expect Apple to do) Deploymate, as on date doesn’t track wrong class usage or missed weak-linking on frameworks. I seriously wish those features are their highest priority. Nevertheless, the app is kind of complete now.

Download

You can read more about Deploymate on their website here. The app is on sale for $9.99. I just bought it and this is probably the best $10 you would have ever spent on an app. Get it now.

–

Mugunth

Follow me on Twitter

Why you shouldn’t hire a iOS developer based on his portfolio

2013-02-24T08:30:48-08:00

Well, this is not a tech post. Shoo… developers…

I’m not sure if this is a “Singaporean” thing or applies globally. Some people who are in charge of hiring has no clue how to get a good developer. So the first question they ask is for your “portfolio“. I really don’t understand how a iOS developer’s skill can be measured based on his application portfolio. A good looking app doesn’t correlate to a well written code. Back in the olden days of Web 2.0, asking for a portfolio means, you can have a look at the completed website AND the code (Javascript + CSS). Just because you hired people looking for their portfolios in the past doesn’t mean you should do that now.

Instead, ask the prospective hire for his open source contributions. Mine is here. If you aren’t too conversant looking at code, ask for client references. Turns out that, most developers can do this. (As developers you can ask your client before giving out their names as references. Believe me, almost all clients are more than willing to do so.)

App portfolios aren’t a great way to judge a iOS developer (or any closed source developer). Think again, have you ever hired a backend developer (PHP/Ruby/ASP.NET/Java) by looking at the website he built? Hiring a iOS developer is very similar to hiring a backend developer. App portfolios are good for design agencies and makes sense when you are hiring a designer (or outsourcing your complete app to an agency).

Stop asking for app portfolios. Look at the prospective developers’ Github contributions or ask for client references.

–
Mugunth

Follow me on Twitter

iOS programming architecture and design guidelines

2013-02-19T21:07:50-08:00

A good programmer gets the job done. A great programmer gets the job done, the right way. I’ve been a programmer for more than a decade now and been writing Objective-C code for almost half a decade. Some of the coding guidelines I follow have been immensely useful to me and I guess will be useful to you too.

Before that, a brief background. I started my career doing Win 32 SDK/MFC programming. Delved a bit into Windows Device Driver Kit (DDK) and into C#.NET and Java. Most of my life was into Object-oriented programming languages that are more strongly (and statically) typed than Javascript or PHP (and during those good old days, neither Javascript, nor PHP were Object oriented).

When a great programmer writes code in a given language, he follows the principles in that language instead of enforcing principles from his favourite language. In short, don’t write “Java” like code in Objective-C and Objective-C like code in Javascript. For most of us, Objective-C was not our first programming language and I believe, most of today’s Objective-C programmers are like me. A succinct explanation would help you understand the differences and make you a better Objective-C programmer.

Types in Objective-C

First is typing. Typing can be static or dynamic depending on when type safety is enforced by the language/compiler. Typing can be strong or weak depending on if the compiler would allow implicit type conversions. Some languages implicitly convert strings to integers and vice versa. so 1 + 2 is 3 and “1″ + “2″ is “12″ and 1 + “2a” is “12a”.

Objective-C is somewhere in between a strongly typed language like Java/C# and a weakly typed language like Javascript/PHP. Most of the type checking is implemented at runtime and Objective-C is a dynamically typed language.

For example,

var $i = 1;
$i = "Hello World"

is perfectly valid is PHP (or Javascript), It’s illegal in a strongly typed language like C#/Java.
Objective-C, as I said before, is somewhere in between. The compiler will warn you that you are trying to assign a incompatible pointer type.

It enforces type at compile time (at least warns) on most classes, but not collections. That means, in Objective-C, you will get a warning when you assign a NSString to a UIViewController object, but it’s perfectly fine to add a NSString and a UIViewController object into the same NSMutableArray.

However, you are free to override the warning by simply using a typecast.

  NSArray *a;
  a = (NSArray*) @"Hello";

Not that I’m advocating typecasts, get the point that, Objective-C is weakly typed, but not as weakly typed as Javascript or PHP. Java/C# on the other hand are strongly typed less dynamic than Objective-C. In Java, adding a non-compliant object to a collection class will be caught by the compiler if the compiler can reliably infer the type of the added object or the run time will throw a ClassCastException. No such thing in Objective-C.

When it comes to programming, there is no one best language. As a great programmer, you should NOT be a fan of a given type system. Embrace strong+static typing when you code in Java and appreciate the beauty of semi-strong + dynamic typing when you write Objective-C. Objective-C (and most C based languages) were invented for writing high performance software and the onus of type safety or checking the bounds of array indices is on you, the programmer and not the compiler.

So there comes our first rule. Never write Objective-C code that reads like code from a strongly typed language.

Naming conventions

Objective-C method names are verbose. Yes, you are reading it right. Objective-C is a verbose language. Method names are verbose and less imperative than C/C++ or even Java. For example,

-getCacheDirectory; should probably be named as -cacheDirectory.

-convertToJson should probably be named as -jsonValue

Tone down the level of imperativeness in your code. Embrace verbosity. While your favourite language, Ruby is succinct, Objective-C isn’t. Ruby is succinct, probably because most of the typing is done using a text editor that doesn’t do intelligent auto completes. Writing succinct method names or writing macros to introduce succinctness in your Objective-C code will only confuse other Objective-C programmers who are not familiar with your “other” programming language.

When in Rome, be a Roman. While writing Objective-C code, be an Objective-C programmer.

Subclassing

In almost any programming language, subclassing a framework provided class is perfectly allowed. But not in Objective-C. Most of the commonly used classes like NSArray, NSSet, NSDictionary are essentially clusters. Subclassing them is not advised unless you are planning to forward invocations or by implementing all of the primitive methods necessary.

In most traditional programming languages, you subclass a foundation class (like for instance, a NSArray) to either provide additional methods or to override existing methods or to customise appearance of a UI element. In Objective-C, you provided additional methods using a category extension. You override SDK provided implementation by swizzling the method and you use the appearance proxy protocol to customise appearance of a UI element.

Having said that, there are some classes that you commonly override. UIViewController, UITableViewController, UIControl are a few to name. Subclassing UIViewController is probably the best thing you can do to your app. Adding common functionalities becomes just so easy. In every app I do, I have a UIViewController subclass that has a bunch of common functionalities. All other view controllers that I use in the app inherit from this special view controller.

So, instead of

@interface MyAppFeaturedYouTubeVideosViewController : UIViewController

it would be

@interface MyAppFeaturedYouTubeVideosFeaturedViewController : MyAppViewController
@interface MyAppViewController : UIViewController

This common base class can be used to add common functionalities in future. I usually have the following methods in this super class.

-(UIView*) errorView;
-(UIView*) loadingView;
-(void) showLoadingAnimated:(BOOL) animated;
-(void) hideLoadingViewAnimated:(BOOL) animated;
-(void) showErrorViewAnimated:(BOOL) animated;
-(void) hideErrorViewAnimated:(BOOL) animated;

Implementation details below.

-(UIView*) errorView {
 
  return nil;
}
 
-(UIView*) loadingView {
 
  return nil;
}
 
-(void) showLoadingAnimated:(BOOL) animated {
 
  UIView *loadingView = [self loadingView];
  loadingView.alpha = 0.0f;
  [self.view addSubview:loadingView];
  [self.view bringSubviewToFront:loadingView];
 
  double duration = animated ? 0.4f:0.0f;
  [UIView animateWithDuration:duration animations:^{
    loadingView.alpha = 1.0f;
  }];
}
 
-(void) hideLoadingViewAnimated:(BOOL) animated {
 
  UIView *loadingView = [self loadingView];
 
  double duration = animated ? 0.4f:0.0f;
  [UIView animateWithDuration:duration animations:^{
    loadingView.alpha = 0.0f;
  } completion:^(BOOL finished) {
    [loadingView removeFromSuperview];
  }];
}
 
-(void) showErrorViewAnimated:(BOOL) animated {
 
  UIView *errorView = [self errorView];
  errorView.alpha = 0.0f;
  [self.view addSubview:errorView];
  [self.view bringSubviewToFront:errorView];
 
  double duration = animated ? 0.4f:0.0f;
  [UIView animateWithDuration:duration animations:^{
    errorView.alpha = 1.0f;
  }];
}
 
-(void) hideErrorViewAnimated:(BOOL) animated {
 
  UIView *errorView = [self errorView];
 
  double duration = animated ? 0.4f:0.0f;
  [UIView animateWithDuration:duration animations:^{
    errorView.alpha = 0.0f;
  } completion:^(BOOL finished) {
    [errorView removeFromSuperview];
  }];
}

Now, in my application’s View Controller subclass, I can easily change the view to a “loading” state or “error” state just by calling one of the following methods. Additionally, view controllers can override, -errorView and -loadingView methods to provide their own custom error and loading views.

You can even override viewDidLoad in the super class to change the look and feel of the all the views in your app. For example, adding a background pattern to your views or changing the background colour of all your views.

- (void)viewDidLoad
{
  [super viewDidLoad];
  self.view.backgroundColor = [UIColor appOffWhiteColor]; // changes all my views to "off-white"
}

UI Customisation

UI Customisation can be classified broadly into two. Writing custom controls. Skinning/theming the app. The former is what makes the app stand out from the crowd. The latter is what most apps require. I recommend writing a category extension on UIFont and UIColor to provide custom fonts and colours for your app.

For example, add methods like

+(UIFont*) appFontOfSize:(CGFloat) pointSize {
 
  return [UIFont fontWithName:@"MyriadPro-Regular" size:pointSize];
}
 
+(UIFont*) boldAppFontOfSize:(CGFloat) pointSize {
 
  return [UIFont fontWithName:@"MyriadPro-Black" size:pointSize];
}

to a UIFont category and use [UIFont appFontOfSize:13] to create a MyriadPro-Regular font. This way, you can easily switch to a different font later when your designer decides so.

The same design pattern can be applied for providing custom colours. Add a category on UIColor and write methods like the following

#define GREY(color) [UIColor colorWithRed:color/255.0 green:color/255.0 blue:color/255.0 alpha:1]
 
+(UIColor*) appBackgroundColor {
 
  return [UIColor colorWithPatternImage:[UIImage imageNamed:@"BGPattern"]];
}
 
+(UIColor*) appBlack1Color {
 
  return GREY(38);
}
 
+(UIColor*) appOffWhiteColor {
 
  return GREY(234);
}

For heavens’ sake, don’t use Interface Builder for choosing a colour.

Subclassing UILabels

There is one other school of thought where developers subclass UILabel, UITextField, UITextView and set the font and colour in the initWithFrame and initWithCoder methods. The following explains this technique.

@implementation AppPrefixLabel
 
-(void) setup {
 
  self.font = [UIFont fontWithName:@"SourceSansPro-Semibold" size:self.font.pointSize];
  self.textColor = [UIColor redColor];
}
 
-(id) initWithFrame:(CGRect)frame {
 
  if((self = [super initWithFrame:frame])) {
 
    [self setup];
  }
 
  return self;
}
-(id) initWithCoder:(NSCoder *)aDecoder {
 
  if((self = [super initWithCoder:aDecoder])) {
 
    [self setup];
  }
 
  return self;
}
 
@end

This technique allows developers to customise appearance of labels and other UIKit elements from Interface Builder. Drag a UILabel to your view and change the class of the label to your custom class, and boom! your fonts and colours are instantly applied without you having to write additional code.

While this technique works for most part, it becomes troublesome when your application supports custom themes and users can change themes from, say, a settings screen.

initWithFrame: and initWithCoder: are creation methods that are called once when the UI element is created and changing the font after it is created requires a bunch of boiler plate code. So, if your app supports themes, create a theme manager singleton that “provides” themes and colours for the entire project.

If you use the first method that I explained, your UIFont category extension methods will now be implemented as

+(UIFont*) appFontOfSize:(CGFloat) pointSize {
 
  NSString *currentFontName = [[ThemeProvider sharedInstance] currentFontName];
  return [UIFont fontWithName:currentFontName size:pointSize];
}

Same applies to UIColor category extension methods as well. There is no right or wrong ways to do this. Both methods are perfectly fine and I’ll leave it to you to figure out which works best for your app.

Following basic design patterns I explained here can make your iOS project look clean like a well written JS/CSS. Try it in your next app and let me know!

–
Mugunth

Follow me on Twitter

Windows Store App Development for iOS Developers

2012-12-04T19:32:53-08:00

Microsoft has partnered with Big Nerd Ranch to bring iOS developers a free two day training designed to jumpstart Windows Store development. The training is a two day event covering the basics, introduction to the platform, design differences between iOS and Windows 8 to Maps, Skydrive and Microsoft account integration.

The training happens in San Francisco. But, unlike most others that are free only for developers in San Francisco, what interests me about the event is that, it will be live streamed and anyone from any part of the world can watch the complete event. If you are in San Francisco, you can just walk down to their office to attend the training in person.

Timings

The training starts next week, December 13th 9 AM to December 14th 5 PM Pacific time. Around the world, the timings would be

06:00AM – Hawaii

08:00AM – Alaska

09:00AM – Pacific

10:00AM – Mountain

11:00PM – Central

12:00PM – Eastern

01:00PM – São Paulo

05:00PM – London

06:00PM – Paris

08:00PM – Moscow

01:00AM – Singapore (the next day)

02:00AM – Tokyo (the next day)

03:00AM – Sydney (the next day)

Trainers

The trainers for the course will be Aaron Hillegass and Jaime Rodriguez.

Registration

I registered, but I might be skipping the first few as it would early morning 1AM for me. Overall, I’m excited about Big Nerd Ranch’s collaboration and see how the Windows Phone platform would evolve.

Your should register too.

–
Mugunth

Follow me on Twitter

Performance improvements to MKNetworkKit

2012-11-20T03:01:22-08:00

Over the past couple of weeks, I was profiling MKNetworkKit and looking for bottlenecks.

I found around five major bottlenecks.

Performance Fix 1:

Decoding images in Background

UIImage will not decompress the PNG/JPG image until it’s actually displayed. This is fine for artwork or pattern images that you normally bundle with your iOS app. But for displaying avatar images on a Twitter timeline or a photo library application, the performance could be improved drastically by decompressing the image in the background. Thanks to Krzysztof Zabłocki (@merowing_) for the code snippet.

You can now use the method, imageAtUrl:size:completionHandler:errorHandler: to get a decompressed image from a MKNetworkEngine.

Performance Fix 2:

Decoding JSONs in a background thread

I added a method responseJSONWithCompletionHandler: to MKNetworkOperation to decode JSON in the background.
From here on, responseJSONWithCompletionHandler: is the recommended way to decode JSON instead of the older method, responseJSON.

Performance Fix 3:

Caching in a background thread

Caching is now thread safe and runs in a serial GCD queue completely in background without blocking the UI. you wouldn’t even know that the requests are being cached!

Performance Fix 4:

Replaced NSDateFormatter with strptime_l

MKNetworkOperation used NSDateFormatter to parse the dates in the Expires and Cache-Control header. While I did use a dispatch_once to mitigate the issue, dispatch_once did not eliminate the problem completely. The right way to do date formatting when the date format is fixed and unlocalized, is to use strptime_l I was dabbling around with strptime_l today and got this pull request from Bo98. He did an awesome job with strptime_l, and improved the overall performance.

Performance Fix 5:

There is one more performance tune up that could speed up the enqueueOperation. I’m looking at it now. You should see another post in a couple of days.

Overall, the latest on Github should offer a lot more performance. I hope you liked it. Keep the pull requests coming!

Thanks!
–
Mugunth

Follow me on Twitter

Mobile apps and number of concurrent connections

2012-11-08T03:15:46-08:00

HTTP RFC Spec 2616 Section 8.1.4 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html) says

A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users.

While this spec was written quite a long time ago, it’s still a spec and you as a client developer should respect. Most browsers till IE8 did not allow more than two concurrent connections to the same server. IE 8 changed the trend. Steve Sounders has an excellent write up on this here. Even with IE 8, Microsoft did limit the number of connections (to 6). The cap still exists and it’s not “unlimited” and in 2012, most browsers don’t allow more than 6 or 8 concurrent connections to the same server. (We are dealing with HTTP protocol and not torrents or others)

In my opinion, an iOS client that acts a native client for your website should behave like a browser (minus the layout engine), adhering to every possible HTTP standard (Caching headers, Authorization headers, Keep-Alive and others). This is exactly what my iOS networking framework MKNetworkKit, tries to achieve.

Effect of Multiple Connections

Making multiple HTTP requests concurrently hurts the performance. To understand why, we should first understand briefly about how web servers are architected. Firstly, servers (whether it’s a physical box in your office or a VPS or cloud instance) can handle only a given number of requests per second (depending on the hardware). In fact, most servers vie to handle 10,000 concurrent connections. (For the eager beaver, read about the c10k problem that offers solutions on how to implement 10k requests concurrently on your server). When a server cannot handle the load, it’s free to drop connections (again this is perfectly fine and an expected behaviour as per RFC). When a connection is dropped, a client retries the connection using a binary exponential back off algorithm (as per RFC 2616). So, achieving 10,000 concurrent connections per hardware is hard. So how do web server handle millions of users? With proper load balancing and making sure that a low Keep-Alive is sent to the client, a web server, tries to limit the number of concurrent connections.

Keep-Alive

Most HTTP servers including Apache/nginx allows sysadmins to set a value called “Keep-Alive”. I believe you might have edited this value too. Keep-Alive dictates how long a connection will be kept open before the server forcefully closes it. A lower value means, the server can serve more users and a high value means less latency for already connected user. Apache 2′s default value seems to be around 2 seconds. (This was originally 15 seconds before Apache 2). What that means is, if you make a request to your server (running apache) to get a list of items, and then when the user taps on the item to get the details, your second request would probably not use the same TCP connection (assuming your second request is started after 2 seconds). Initiating a new TCP connection is a slow process compared to fetching data over HTTP on an existing TCP connection. But unfortunately, servers are designed to cater to as many users as possible and not just your client and you just have to live with it.

This limitation has a side effect. It increases the number of concurrent connections opened by a client to a server. To workaround this, the RFC spec encourages clients not to maintain more than 2 connections per server. And let’s all face it. IE breaks standards. (But Microsoft could have broken the standard because the standard was too old and was written before the era of XmlHttpRequest). IE 8 changed this limit to 6 and other browsers followed.

When you open a higher number of concurrent connections (more than 6), say for a photo library app on an iPad that downloads 100 images for displaying it on the first screen, if your app is being used by 100 others at the same time (quite common, 100 users is not a huge number) you hit the 10,000 concurrent limit easily and your server will start closing connections. Without proper load balancing, your server will not even be able to handle a 100 concurrent users, a very poor engineering. (throwing more hardware at the problem is again poor engineering)

So, what can you do as a iOS developer? Limit the number of parallel connections in your app to somewhere around 6 or 8. Now, won’t throttling my download operations affect client side performance? No, apparently, limiting the number of operations will do more good than bad. Yes, it actually improves your performance. Let me explain.

Example

Let’s assume that you are making a photo library iPad app (something similar to cool iris) that downloads 100 images to be displayed on the first screen. Let’s assume that every image (thumbnail) you download is around 50 KB. Downloading 100 images is going to be around 5 MB. If your 3G bandwidth is around 1 Mbps (a fair assumption), it would probably take 40 seconds to download). If you have 100 parallel connections sharing the 1Mbps bandwidth, all 100 images will appear after 40 seconds. If you have 50 parallel connections, 50 images will appears after 20 seconds and the next 50 after 40 seconds. If you have 10 parallel connections, 10 images will appear progressively every 4 seconds, a much better user experience. So where do you exactly stop? RFC says, stop at 2 parallel connections. Most browsers however stop at 6 or 8 parallel connections. Mobile Safari, on my testing using this website uses 2-6 based on the current network speed. While our own app cannot determine the speed of a network before hand (It’s too painful to download a fat file and calculate the time it takes and get the speed and is not just worth it), it’s better to use 6 connections on WiFi and 2 on mobile data network. Of course, this limit might change in future when LTE adoption becomes widespread, but restricting number of connections goes a long way in building a robust product (both client and the server) than opening up unlimited number of connections.

It doesn’t stop there. On the server side, if a client opens 100 connections at once, assuming a single machine can handle 10,000 concurrent connections, you limit the number of concurrent users to 100, which is bad. You have to throw more hardware for every 100 user. Not a great scalable service. By limiting the concurrent connections on client side to 5, you allow 2000 concurrent users (per machine/node) and this limit will actually do more good than bad as we saw in our previous example.

Additionally, if you someone else, like ISP or a intermediate proxy server, limits the number of connections to say 6, your first 6 connections will go through. But 7th, 8th and nth operation will start and enter the “isExecuting” state within the NSOperationQueue. The NSURLConnection will start the connection and wait, but the connection:didReceiveResponse: will never be called on the delegate till one of the 6 operations, that you previously started completes. After 240 seconds, this operation will just timeout. You can avoid this scenario easily by preventing the 7th+ NSURLConnection to be started. While 240 seconds is a large number, you will easily hit this wait time with 6 concurrent connections trying to download a 50 kb thumbnail over a 10 Kbps edge/gprs network.

Moreover, even in an ideal world where there are no proxies or ISPs to throttle (gasp!), if you don’t limit the number of connections, the server can close them when load is high and again, you will get timeouts for some operations.

A timeout in a image heavy app like this means, only few images will go through and your photo library app will display empty images/placeholders for the rest. Again, not a great user experience. User experience is not just slapping a beautiful UI onto your iOS app. The underlying engineering should be good as well.

What does other “industry leading” companies recommend?

Lastly, minimising concurrent HTTP requests on the client side is not something new. Both Yahoo and Google’s best practices recommends that you to minimise concurrent HTTP requests. A web developer ensures that a browser doesn’t make multiple HTTP requests by coalescing Javascript files and/or CSS file into one big file. An iOS developer does not have a choice apart from limiting the number of concurrent connections.

Lastly, limiting the number of connections is not throttling. It’s optimization. It’s an optimization recommended by RFC and implemented by most browsers. You should implement them too. Throttling is limiting the bandwidth.

MKNetworkKit

MKNetworkKit has some nifty features to help you manage scenarios like this. MKNetworkKit uses a single shared queue and optimizes the number of concurrent connections based on the available network. As on date, it is 6 on WiFi and 2 on mobile networks. While browsers implement 6 concurrent connections per server, I do it per application. This is because, an iOS app mostly would normally won’t have 6 concurrent connections talking to different servers. In most cases, your implementation will contain one API fetch and multiple CDN fetch. Limiting it per application will just average out.

MKNetworkKit also coalesces multiple requests. Assume that you are a twitter client and you download the last 200 tweets in a user’s timeline. While a stream might contain 200 tweets, there would be far less than 10 or 20 friends (statistically). As the user scrolls through the timeline, you shouldn’t create operations to download 200 profile pictures. You should in fact a unique download operation per profile picture. Surprisingly, a twitter timeline containing the most recent 200 tweets will contain around 20 friends and 20 requests is all that you need to make. Fret not. With MKNetworkKit take care of this operation coalescing automatically. Even if you enqueue an image download operation twice, the actual URL fetch is performed exactly once.

Any networking app can and should implement such performance related fine tuning measures and profile the performance. In fact, one of the hardest aspect of iOS programming is getting the performance right and in the upcoming edition of our book, iOS 6 Programming: Pushing the Limits we added a whole new chapter that explains memory and CPU optimisation using Instruments. You might want to check that out.

Comments are welcome.

–
Mugunth

Follow me on Twitter

iPhone 5 Wallpaper – New York City

2012-09-27T05:00:17-07:00

I’m a fan of city skylines. Here is my own shot of New York City from Empire State Building for your shiny new iPhone 5.

New York City – Tap this link to view the actual size

It looks like this on my iPhone. Resized just the right way so that the city skyline stands out and the sky goes behind the date/time.

Ok, this photo doesn’t do justice. Download it from here and try it yourself.

–
Mugunth

Follow me on Twitter

iOS Tip: Applying a background pattern globally to all your views

2012-09-27T04:00:40-07:00

Applying a pattern is something that you already know. But supporting the older 3.5 inch iPhones and the iPhone 5′s taller resolution means, shipping two sets of background images and choosing the right one depending on the device.
However, there are at least two drawbacks of the above mentioned method. Firstly, shipping multiple images means you are increasing the download size of your app. Default.png and Background.png are usually the biggest files in most applications and adding another background for iPhone 5 is a felony. Secondly, code switch based on device is something I would not recommend writing explicitly, especially, if there is a way around, use it.

I instead recommend colorWithPatternImage: and I’m going to show you how I do this.

Step 1: Subclass UIViewController and create your own. I recommend this to avoid code duplication. In the viewDidLoad method, create a pattern layer and add it as a sublayer of your view. You should strongly own the pattern layer.

- (void)viewDidLoad
{
[super viewDidLoad];
 
self.patternLayer = [CALayer layer];
self.patternLayer.frame = self.view.bounds;
self.patternLayer.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"BackgroundPattern"]].CGColor;
self.patternLayer.opacity = 1.0f;
[self.view.layer insertSublayer:self.patternLayer atIndex:0];
}

Step 2: In your viewWillLayoutSubviews method, adjust the pattern layer’s frame. This is for iPhone 5 compatibility.

- (void)viewWillLayoutSubviews {
 
self.patternLayer.frame = self.view.bounds;
[super viewWillLayoutSubviews];
}

That’s all. Any view that is inheriting from this subclass of UIViewController will automatically get the background pattern. You can go on and apply corner radius, drop shadows and play around here to apply themes globally.

–
Mugunth

Follow me on Twitter