Notizen rund um Apple & iOS
Jeder Mac-Anwender ist immer auf der Suche nach kleinen Tools, die das Leben ein klein wenig einfacher machen. Deshalb mag ich die Listen anderer Benutzer, da man immer wieder etwas Neues entdeckt.
Aktuell findet man gerade eine kleine Übersicht über 10 kleine Helferlein bei apfelquak, die neben bekannten Utilities auch – zumindest mir bislang unbekannte – Perlen wie z.B. Cloud.app enthält. Lesebefehl!
Wer sich einen nahezu vollständigen Überblick über iOS 4 verschaffen möchte, nutzt dazu am Besten das Walkthrough bei TiPb.
Und wenn man schon auf der Seite ist, lohnt sich auch ein Blick auf den ebenfalls sehr ausführlichen Artikel über die neue Hardware des iPhone 4.
iPhone Applikationen wie z.B. AppSales Mobile, die mangels einer API die iTunes Connect Daten scrapen mussten, um sie dem Entwickler zur Verfügung stellen zu können, wurden bislang nicht in den offiziellen App Store gelassen. Da AppSales Mobile vom Entwickler als Open Source veröffentlicht wurde, gab es trotzdem eine praktikable Lösung.
Apple hat es nun aber nach vielen Jahren geschafft, ein wenig Entwicklungsressourcen freizuschaufeln, um eine eigene Lösung anzubieten. iTunes Connect Mobile ist seit wenigen Tagen kostenlos verfügbar und bietet grundlegende Funktionen, um auf die iTunes Connect Daten zuzugreifen:
Es ist ein Anfang, aber derzeit überzeugt AppSales Mobile durch einen deutlich größeren Funktionsempfang.
Viele von Euch werden sich sicherlich noch an die Diskussionen aus dem letzten Jahr erinnern, ob und wenn ja, welche Daten ein mobiles Endgerät über seinen Benutzer verbreiten darf. Im Detail könnt ihr die gesamte Geschichte beim fscklog nachlesen. Kurz gesagt ging es um die Frage, ob eine mehr oder weniger klare Formulierung in den Nutzungsbedingungen des iTunes Stores eine ausreichende Grundlage darstellt, um Benutzerinformationen wie z.B. eine Geräte-ID, den Standort, die Nutzungsdauer und bei Verwendung von Facebook auch Geschlecht und Alter an den Softwarehersteller übermitteln zu können.
Apple ließ die Diskussion solange kalt, bis sie selber betroffen waren: Flurry spekulierte im Januar 2010 auf seiner Webseite über eine neue Apple Hardware auf der Basis von Informationen, die ohne Wissen der Benutzer durch äußerst mitteilsame Bibliotheken der auf dem Apple Campus eingesetzten Geräte gewonnen wurde. Steve Jobs äußerte sich kürzlich auf der D8-Konferenz noch Monate später not amused über den Vorfall und begründete damit die im April durchgesetzte Änderung der Geschäftsbedingungen:
The use of third party software in Your Application to collect and send Device Data to a third party for processing or analysis is expressly prohibited.
Eine klare Linie: Es dürfen keine Bibliotheken mehr zum Einsatz kommen, um Geräteinformationen zu sammeln und an Dritte zu verschicken.
Damit hatte Apple ein paar Wochen Spaß und konnte dem einen oder anderen Anbieter sicher einen gehörigen Schrecken einjagen.
Letzte Woche wurde nun iOS 4.0 und in diesem Zuge auch iAd (erneut) vorgestellt. Grundlage jeglicher Werbung sind aber qualifizierte Informationen über die potentiellen Kunden und ihre Geräte. Also hat Apple die Geschäftsbedingungen wieder geändert und eingeführt, dass die Bibliotheken unter der Voraussetzung eingesetzt werden können, dass
Damit wird zukünftigen Diskussionen – zumindest benutzerseitig – der Wind aus den Segeln genommen: Der Benutzer ist Herr seiner Daten, ohne seine Einwilligung darf eine Übertragung von Geräteinformationen nicht erfolgen. Jeder sollte sich im Internet immer bewusst entscheiden können, wem er welche Daten zur Verfügung stellt.
Dass Apple mit dieser Änderung nicht nur die Interessen der Benutzer vor Augen hatte, zeigt sich durch die zweite Voraussetzung, denn die Erlaubnis wird nur “unabhängigen” Werbeanbietern erteilt. “Unabhängig” heisst in diesem Kontext:
…an advertising service provider owned by or affiliated with a developer or distributor of mobile devices, mobile operating systems or development environments other than Apple would not qualify as independent.
Google == Android == Mobile devices
AdMob == Google == abhängig
Tja, ein weiterer Fall für die FTC…?
Dieser Tipp ist extrem einfach aber für manche Apps extrem nützlich. Folgende Codezeile aktiviert die Anzeige einer Nummer (“Icon Bade”) als rot/weißes Kästchen direkt auf dem Application-Icon.
[UIApplication sharedApplication].applicationIconBadgeNumber = 10;Wo im Quellcode die Eigenschaft gesetzt wird ist egal. Um die Anzeige wieder zu löschen, genügt es die Property wieder auf 0 zu setzen. Möglich sind alle Werte die NSInteger hergibt, allerdings wird die Anzeige bei größeren Werten verkürzt dargestellt (siehe Screenshot).
IconBadge
Das iPhone-Erlebnis wäre wahrscheinlich deutlich weniger reizvoll, wenn die Oberflächenelemente dem Benutzer sich weniger animiert zeigen würden. Oft fällt es gar nicht mehr auf, wenn UI-Elemente mit einer Animation ausgestattet sind. Umso interessanter sind die vielfältigen Möglichkeiten, die Benutzeroberfläche mit CoreAnimation aufzupeppen. In unserer DevTipp-Reihe wird es daher immer mal wieder einen Tipp zu animierten Oberflächen geben. In diesem ersten Tipp fängt es einfach an. Mit folgendem Code lassen sich Instanzen von UIViews animiert auf der Oberfläche einblenden. Der Alpha-Wert muss zuvor natürlich auf 0 gesetzt werden, damit die View zunächst nicht angezeigt wird:
-(void)fadeIn:(UIView*)viewToFadeIn withDuration:(NSTimeInterval)duration
andWait:(NSTimeInterval)wait
{
[UIView beginAnimations: @"Fade In" context:nil];
[UIView setAnimationDelegate:self];
[UIView setAnimationDidStopSelector:@selector(animationStop:finished:context:)];
[UIView setAnimationDelay:wait];
[UIView setAnimationDuration:duration];
viewToFadeIn.alpha = 1;
[UIView commitAnimations];
}Ein StopSelector kann, muss aber nicht übergeben werden. Der übergebene Selektor wird unmittelbar nach Beendigung der Animation aufgerufen und muss folgender Signatur folgen:
- (void)animationStop:(NSString *)animationID finished:(BOOL)finished
context:(void *)context
{
if ([animationID isEqualToString:@"Fade In"]){
}
}Über die AnimationID kann ermittelt werden, welche Animation beendet wurde. Die Aufrufe erfolgen stets asynchron. Mit dieser Funktion und einem Alpha-Wert von 0 könne Views auch wieder ausgeblendet werden.
Vor einigen Tagen hat Apple einen neuen Support-Artikel veröffentlicht, in dem ausdrücklich empfohlen wird, bei der Konfiguration eines WLAN-Netzes den Standard WPA2 (Personal) zu verwenden.
Als Hauptgrund wird die Beschränkung der Geschwindigkeit auf 54 Mbps bei WEP/WPA (entsprechend der Spezifikation des IEEE 802.11n Standards) angeführt. Im Artikel findet sich zwar die zarte Empfehlung, ein Passwort zu verwenden, aber meines Erachtens kommt der Sicherheitsgedanke hier deutlich zu kurz.
WPA2 ist die Implementierung des aktuellen Sicherheitsstandards IEEE 802.11i und wie es mit der Sicherheit so nun mal ist, handelt es sich um ein Katz und Maus Spiel. Wie sagt der CCC so schön:
Sicherheit ist ein Prozess und kein Zustand.
Deshalb sollte man immer den aktuellen Standard verwenden. Bei WPA2 vor allem in Verbindung mit der maximalen Schlüssellänge von 63 Zeichen.
Dann kann sich die Katze erst einmal um die Mäuse in der Nachbarschaft kümmern.
Soeben hat Steve Jobs die Keynote auf der WWDC beendet und – wenig überraschend für alle, die die letzten Woche nicht in einer Höhle verbracht haben – das neue iPhone vorgestellt. Die Optik entspricht dem des “verlorenen” Prototypen, es hört auf den Namen iPhone HD iPhone 4 und Raider heißt jetzt…ähh..nee…iPhone OS heißt jetzt iOS und geändert hat sich Einiges.
iOS soll heute noch als GM für Entwickler zur Verfügung stehen, offiziell wird es dann ab dem 21.6. zum Download verfügbar sein. Das iPhone 4 steht in Deutschland zum 24.6. zum Kauf bereit. Details der Telekom folgen später, aber wollen wir das wirklich wissen?
Alle Details und ein Design-Video finden sich wie gewohnt hübsch aufbereitet bei Apple. Einen recht ausführlichen Bericht und viele weitere Infos gibt es auch beim fscklog.
Pro-Tip: Nicht anschauen, wenn Ihr Euer iPhone 3GS noch weiterhin lieb haben wollt.
Update: Das Video der Keynote ist bei Apple als Stream verfügbar.
Eine View zu einer Subview hinzufügen ist einfach, aber wie entfernt man wieder eine Subview aus einer View? Aus der Sicht des Parent-View gibt es dafür keine geeignete Methode. Lediglich aus der Sicht des Child-Views gibt es die Methode removeFromSuperview. Wie löscht man nun elegant sämtliche Child-Views? Dafür gibt es zwei Alternativen:
Löschen in einer Schleife aus der Sicht des Parent-Views:
for (UIView *view in self.subviews){
[view removeFromSuperview];
}oder etwas eleganter – dafür aber mit weniger Kontrolle – über den Aufruf eines Selektors auf allen Elementen des Subview-Array im Parent-Views:
[self.subviews makeObjectsPerformSelector:@selector(removeFromSuperview)];Apple hat im letzten Jahr mit der Firmware 3.0 viele Funktionalitäten eingeführt, die das Gerät auch für Unternehmen interessant(er) machen. Einen schönen Überblick findet man hier.
Dort findet man auch einige PDFs, die sich mit den Themen näher auseinandersetzen. Eines davon gibt einen Überblick über die relevanten Sicherheitsfunktionalitäten des iPhone OS. Und für alle, die des Englischen nicht ausreichend mächtig sind, sind die PDFs sogar auf deutsch. Bravo!
Moment mal. Verkauft Apple in Deutschland ein anderes iPhone oder ist die Beschreibung etwa von Googles Android geklaut? Der Absatz “Laufzeitschutz” lautet jedenfalls:
Die Programme auf dem Gerät sind „offen“ angelegt, sodass sie auf Daten, die von anderen Programmen gespeichert wurden, zugreifen können. Darüber hinaus sind die Systemdateien, Ressourcen und der Kernel vom Programmbereich des Benutzers abgegrenzt. Wenn ein Programm auf Daten eines anderen Programms zugreifen muss, kann dies nur über die APIs und Dienste des iPhone OS geschehen. Außerdem wird die Codeerstellung verhindert.
Also die Programme sind offen, dürfen aber nur über APIs auf andere Daten zugreifen? Widerspricht sich das nicht? War das nicht anders? Wie steht es denn im Original?
Applications on the device are “sandboxed” so they cannot access data stored by other applications. In addition, system files, resources, and the kernel are shielded from the user’s application space. If an application needs to access data from another application, it can only do so using the APIs and services provided by iPhone OS. Code generation is also prevented.
Okay, also “sandboxed” bedeutet “offen”. Klingt logisch, Sandkästen sind ja nun mal offen.
Gut, dass da mal einer mitgedacht hat.
