Mit unserem neuen Keychains and Provisioning Profiles Management Plugin für den Jenkins Continuous Integration Build Server können die zur Signierung einer iOS-App notwendingen Keychain- und Mobile Provisioning Profile Dateien einfach direkt über das Jenkins-Frontend verwaltet werden. Somit entfällt ein manuelles Hinzufügen von Keychains zur Schlüsselbundverwaltung und eine manuelle Installation der Provisioning Profiles auf jedem Mac, welcher als Build-Instanz (egal ob Master oder Slave) für iOS/OSX-Projekte dient.

Weiterlesen

Aufgrund des großen Interesses an unserem Artikel zur Corvette Fensterhebersteuerung per iPhone App nehmen wir das Thema Bluetooth 4.0 noch einmal auf. Wir bauen einen Universal-Fernbedienungs-Empfänger iPhone. Dazu gibt es hier die Do-it-yourself-Anleitung und im AppStore die passende App (Coming soon) dazu. Viel Spaß beim Nachbauen!  Weiterlesen

CoreData’s not SQL – dieser Slogan begegnet dem iOS-Entwickler, der in die CoreData-Welt einsteigt, an vielen Stellen – vor allem wenn es um die Selektion von Objekten/Entitäten geht. Zurück bleibt oft die Frage: Und was ist nun CoreData? Oder wie selektiere ich die Objekt, die mich interessieren?

Weiterlesen

Seit gut 3 Jahren verwenden wir Jenkins als Plattform für eine Continuous Integration Umgebung für iOS-Projekte.

Zu den Hauptaufgaben des Systems gehören die ständige Überprüfung der Baubarkeit von Projekten nachdem Quellcode in ein Source-Control-Management (SCM) System eingecheckt wurde und die Verteilung der Build-Produkte an eine interne Over-the-Air (OTA) Distribution Plattform sowie direkt an unsere Kunden.
Darüber hinaus unterstützen wir verschiedene Build-Job Konfigurationen zur automatischen Quellcode-Dokumentation und Code-Analyse:

  • Ausführung von OCUnit-Tests und Messen der Testabdeckung,
  • Statische Code-Analyse,
  • Erstellung von Code-Metriken,
  • Copy-Paste-Detection,
  • Appledoc und Headerdoc.

Weiterlesen

Bluetooth 4.0 Low Energy ist in aller Munde. Es erscheinen beinahe täglich neue Gadgets die per Bluetooth 4.0 mit dem Smartphone kommunizieren. Warum also nicht Funktionen des Autos per Smartphone fernsteuern?

Weiterlesen

Mit dem Erscheinen des iPhone 5 und dem neuen Anschluss ging ein Aufschrei durch die Apple Gemeinde, da die Kompatibilität zu bisherigem Zubehör mehr als ungewiss war.

An dieser Situation hat sich bis heute leider nicht viel geändert. Es herrscht immer noch große Unsicherheit, was die Kompatibilität von Zubehör mit dem Ligthning zu 30-Pin-Adapter betrifft.

Fakt ist der Folgende. Es gab bisher grundsätzlich drei Wege, wie Zubehör mit dem iPhone kommuniziert hat.

  1. iPod Interface (seriell), das sogenannte iPodOut. Das serielle Interface wurde benutzt, um den iPod zu steuern. Zusätzlich wurden analoge Line-Out-Ausgänge genutzt, um das Audiosignal abzugreifen.
  2. Einige Hersteller – wie z. B. BMW oder Pioneer mit dem AppRadio – benutzen zusätzlich den analogen Videoausgang, um den Bildschirminhalt des iPhone auf den eigenen Bildschirm zu spiegeln.
  3. USB Interface und Line-Out. Hier wird USB verwendet, um den iPod zu kontrollieren. Audio wird wieder über Line-Out abgegriffen.

Inzwischen hat sich herausgestellt, dass es beim iPhone 5 keinen analogen Videoausgang mehr gibt. Das bedeutet, dass Hersteller, die auf dieses Pferd gesetzt haben, im Moment ein großes Problem haben. Außerdem hat das neue iPhone keine analogen Ausgänge mehr für Audio-Signale. An dieser Stelle schafft aber der Lightning zu 30-Pin-Adapter Abhilfe und konvertiert die Signale (D/A Audio-Realtime-Konvertierung).

Zubehör, welches auf iPodOut setzt, um den iPod zu steuern, hat ganz schlechte Karten, da es schlichtweg im Moment dafür keine Lösung gibt. Betroffen ist hier unter anderem das AppRadio von Pioneer.
http://www.pioneerelectronics.com/PUSA/Apple+Compatibility

Das einzige Zubehör, welches sicher funktioniert, ist das, was rein über USB kommuniziert (also digital). Es wird spannend, wie die Hersteller dieses Problem in den Griff bekommen wollen.

Dank der iOS 6 Einführung ist es vermutlich endlich soweit, dass Apple den Kauf von Apps für die Mitarbeiter seiner Firmenkunden ermöglicht.

Lange haben Firmen darauf gewartet, jetzt wird es endlich Realität. Wovon andere Plattformen noch meilenweit entfernt sind, hat Apple damit in vielen Ländern umgesetzt.

Wozu genau soll das gut sein? Weiterlesen

Den Themenschwerpunkten
„einfach zu lesender Objective-C Code“ und „neue Features des llvm Clang Compilers „ reiht sich auch dieser Artikel ein und geht dabei kurz auf die Neuerungen der aktuellen Clang-Compiler Versionen 3.1 (Xcode 4.3) und 4.0 (Xcode 4.4) im Hinblick auf die Erweiterungen der Programmiersprache Objective-C ein. Auch das demnächst offiziell verfügbare Xcode 4.5 bringt einige nennenswerte Source-Code relevante Neuerungen mit sich.

In dem folgenden „zusammenhangslosen“ Code-Schnipsel habe ich versucht ausschließlich auf die Neuerungen einzugehen ohne eine sinnhafte Code-Sematik zu präsentieren. Weiterlesen

In meinem letzten Beitrag hatte ich bereits generelle Schwierigkeiten im Zusammenhang mit asynchronen Ladevorgängen in Listen dargestellt. Anhand eines einfachen Szenarios hatte ich die Komplexität dieses Use-Cases herausgearbeitet, ohne dabei zu sehr ins Detail zu gehen.

Diesen Artikel hingegen möchte ich in eine etwas technischere Richtung lenken – und damit meinem Versprechen nachkommen, einige Best-Practices und Kniffe Preiszugeben, die sich in unseren Projekten bewährt haben. Ich möchte aufzeigen, wie sich relativ einfach flüssig scrollende Listen implementieren lassen und einige hilfreiche Tools vorstellen, die einen dabei unterstützen können. Zwischen den Zeilen werde ich einige divergente Lösungsansätze ansprechen, die allgemein hin empfohlen werden, jedoch mit nicht ganz unerheblichen Problemen behaftet sind.

Weiterlesen

Es gibt bei der Entwicklung von Android Apps wohl kaum ein zweites Szenario, das so häufig Anwendung findet, so trivial zu sein scheint – zeitgleich jedoch so unglaublich herausfordernd zu implementieren ist, wie das effiziente und asynchrone Laden von Bildern in eine ListView. Unzählige Threads auf Stackoverflow, sowie ein unlängst von Google veröffentlichter Ratgeber über Best-Practices für den Umgang mit Bitmaps, unterstreichen diese Aussage. Gründe hierfür sind zum einen, dass das Android SDK zu diesem Zweck kaum vorgefertigte Hilfsklassen bereitstellt, die einem mit vertretbarem Entwicklungsaufwand eine brauchbare Lösung ermöglichen. Aber auch einige architekturelle Gegebenheiten, wie beispielsweise die grundlegende Funktionsweise eines Adapters, oder das Single-Thread-Modell (hier insbesondere die Tatsache, dass Views nur aus dem Main-Thread heraus manipuliert werden dürfen) sind einer einfachen Lösung wenig förderlich. Dabei könnte für den Entwickler doch alles so einfach sein, hätte er nur eine Methode setImageFromWeb(URI) – oder nicht? In diesem Artikel möchte ich darauf eingehen, wieso uns diese brillante Methode bislang vorenthalten wurde. Ich werde den Versuch unternehmen, die Komplexität des Problems etwas zu veranschaulichen und Gründe nennen, wieso das asynchrone Laden von Bildern in eine ListView alles andere als trivial ist. Weiterlesen