In den letzten Monaten, gab es dazu viele Vermutungen und Spekulationen, wann die ersten kompatiblen Geräte auf den Markt kämen. Nun sind erste Namen von Produkten sind aufgetaucht, die kompatibel mit der Apple Technik sind. Apple selbst hat dazu eine Liste mit bereits lizenzierten HomeKit Produkten von Drittanbietern veröffentlicht. Ob es auch eigenes HomeKit Zubehör made by Apple geben wird ist fraglich, denn bisher sind keine eigenen Produkte angekündigt worden.

HomeKit Zubehör aus Deutschland

Ganz oben in der Supportliste befinden sich Produkte von der deutschen Firma Elgato, die ihren Hauptsitz in München hat. Unter der Produktfamilie Eve vertreibt die Firma verschiedene Geräte, die z.B. Temperatur, Luftfeuchtigkeit oder den Energieverbrauch in den eigenen vier Wänden erfassen. Die gesammelten Daten werden übersichtlich in der eigenen Eve App dargestellt. Mit dem „Eve door & window“ Produkt hat man beispielsweise seine geöffneten oder geschlossenen Fenster im Blick und kann sein Lüftungsverhalten optimieren.

Es gibt unzählige Möglichkeiten, wie wir unsere alltäglichen Haushaltsgeräte durch intelligentere ersetzen können. Denkbar ist z.B. das Bedienen des Kaffeekochers mit dem Smartphone, während man noch im Bett liegt und die ersten Sonnenstrahlen einfängt.

Neuerungen

Außerdem hat Apple ein Dokument veröffentlicht, in der die Grundlagen von HomeKit beschrieben werden. Das HomeKit Zubehör wird mittels eines Setup-Codes, der sich auf dem Gerät befindet, ausgeliefert. Diesen gibt man in der jeweiligen App an und danach können die Geräte miteinander kommunizieren. Momentan gibt es leider noch keine zentrale HomeKit-Steuerung von Apple.

Die Steuerung der Geräte über Sprachkommandos, wie z.B. “Lösche alle Lichter im Wohnzimmer” ist mit Siri möglich. Die Fernsteuerung seiner HomeKit-Geräte außerhalb der eigenen vier Wände soll per iCloud-Dienst möglich sein. Dieser soll mit iOS 9 eingeführt werden. Hervorzuheben ist, das jegliche Verbindung mit den HomeKit-Geräten End-zu-End verschlüsselt wird. Außerdem kann man mehrere HomeKit Geräte auch in Zonen zusammenfassen, die raumunabhängig angelegt werden können.

Zu den Neuerungen zählen auch die sogenannten “Event Trigger”. Mit diesen können die HomeKit-Geräte so vorkonfiguriert werden, dass diese Aktionen bei bestimmten Ereignissen ausführen. Denkbar ist hier z.B. das anschalten der Wohnzimmerbeleuchtung nach dem Sonnenuntergang. Zustätzlich wird es auch einen programmierbaren Schalter geben, durch diesen man dann z.B. mit einem Knopfdruck alle Türen im Haus verschließen kann oder um bestimmte Lampen auszuschalten. Viele weitere Szenarien sind denkbar und es ergeben sich dadurch auch neue Möglichkeiten für App Entwickler.

Kompatibilität zu Altgeräten negativ

Es ist davon auszugehen, dass bereits vorhandene Heimautomatisierungslösungen, die nicht HomeKit lizenziert sind, sich nicht in die neue Apple Infrastruktur einbinden lassen und nicht ohne Weiteres kompatibel sind. Das hängt mit der Philosophie von Apple zusammen.

Ausblick

Wir von der creative workline GmbH sind gespannt, wie es in den kommenden Monaten weitergeht – die bereits veröffentlichten Neuerungen machen Lust auf mehr. Weitere Firmen werden auf den Zug aufspringen und innovative Produkte und die dazugehörigen Apps entwickeln. Der noch junge Markt hat viel Potential und inwieweit Apple vorne mitspielen wird, lässt sich zum jetzigen Zeitpunkt noch nicht sagen. Apple will natürlich seine Standards durchsetzen, was dann wiederum Konfliktpotential mit anderen Herstellern wie Google und Samsung bietet, die auch in diesen Markt investieren.

Noch ist die Apple Watch nicht auf dem Markt. Kein Grund sich allerdings noch nicht mit ihr oder bereits verfügbaren Wearables auseinander zu setzen. Schenkt man den bisherigen Informationen von Apple Glauben, dann wird die Uhr im April veröffentlicht. Doch was haben die anderen Hersteller in petto? Dieser Artikel soll über die Apple Watch und bereits verfügbare Smartwatches anderer Hersteller informieren.

Apple Watch

Apple hat die hauseigene Smartwatch erstmalig im September 2014 der Öffentlichkeit präsentiert. Neben einigen technischen Funktionen und natürlich der Präsentation des Designs sind allerdings einige Fragen bisher immer noch ungeklärt. Hierzu zählen vor allem die Akku Laufzeit und die Frage ob die Apple Watch wasserdicht ist. Wahrscheinlich werden wir am 09. März 2015 mehr erfahren, denn Apple hat für diesem Tag Einladungen für eine Konferenz unter dem Motto „Spring Forward“ verschickt.

Design der Apple Watch

Die Apple Watch wird in zwei verschiedenen Größen verfügbar sein. Wir von creative workline haben schon beide Größen anprobieren können. Es handelte sich zwar nicht um die echte Smartwatch von Apple, allerdings um detailgetreue Nachbildungen aus dem 3D Drucker. Erstaunt waren wir vom Größenverhältnis beider Uhren. Die größere Variante haben wir uns deutlich größer vorgestellt, sie ist jedoch auch für Menschen mit relativ kleinem Handgelenk gut tragbar. Letztendlich muss dies natürlich jeder für sich selbst entscheiden.

Die Apple Watch wird neben den zwei unterschiedlichen Größen in drei verschiedenen Varianten erscheinen: Apple Watch, Apple Watch Sport und Apple Watch Edition. Die letztere Version unterscheidet sich von den Anderen vor allem in der Legierung. Ihr Rahmen besteht aus 18 Karat Gelbgold oder Roségold. Die Apple Watch wird ein Gehäuse aus Edelstahl und ein Display aus Saphirglas erhalten. Das Einsteigermodell die Apple Watch Sport besitzt ein eloxiertes Gehäuse aus Aluminium und gehärtetes Ion-X Glas für das Display.

Alle drei Varianten sollen im Kern aus den selben Hardware-Komponenten bestehen.

Bedienung der Apple Watch

Für die Watch hat Apple sich ein neues System zum Benutzen der Uhr einfallen lassen. Apple selbst nennt es die „Digitale Krone“. Sie befindet sich am rechten Rand der Uhr und stellt ein drehbares Rädchen dar wie es auch bei normalen Uhren in ähnlicher Form verbaut wird. Mit deren Hilfe lassen sich Vorgänge wie Zoomen oder Auswählen von Listenelementen vornehmen. Neben einem weiteren Knopf dient natürlich auch das Display als Eingabequelle. Dieses kann im Gegensatz zur aktuellen Generation des iPhones zwischen einem Tippen und einem Drücken unterscheiden. Natürlich wird auch Siri mit an Bord sein mit dessen Hilfe sich Spracheingaben tätigen lassen. Schließlich würde das Benutzen einer Tastatur auf einem solch kleinen Display keine benutzerfreundliche Bedienung darstellen.

Sensoren und Konnektivität

Um auch auf gesundheitlicher Ebene zu punkten sind in der Apple Watch ein Herzfrequenzmesser und ein Beschleunigungsensor verbaut. Mit deren Hilfe lassen sich vor alle Apps im Fitness und Medizin Bereich umsetzen. Gekoppelt sein wird die Apple Watch mit dem iPhone über Bluetooth und W-LAN. Über diese Verbindung nutzt die intelligente Uhr auch GPS Daten des iPhones.

Wearables anderer Hersteller

Unter Benutzung des Android Betriebssystems Android Wear gibt es mittlerweile eine Hand voll Smartwatches. Zu den bisher bekanntesten zählen beispielsweise die Moto 360 von Motorola und die LG G Watch R.

Beide besitzen ein rundes Display und bauen auf Android Wear auf. Neben vom Android Smartphone weitergeleiteten Benachrichtigungen gibt es ähnlich wie bei der Apple Watch Fitness Funktionen. Außerdem lassen sich zum Beispiel die Musikwiedergabe steuern, Erinnerungen erstellen, Sprachmemos aufzeichnen oder die Sprachsuche via Google nutzen.

Samsung geht sein geraumer Zeit seinen eigenen Weg was die hauseigene Smartwatch Reihe Galaxy Gear angeht. Wo vorher Android Wear zum Einsatz kam wird nun das hauseigene Betriebssystem Tizen genutzt. Samsung verspricht mit dem Betriebssystem längere Akku Laufzeiten, eine flüssigere Bedienung und viele neue Features. Die Uhr soll sie sich außerdem besser an die eigenen Bedürfnisse anpassen lassen.

Smartwatches – Revolution oder Technologie die niemand braucht?

Diese Frage wird sich erst beantworten lassen, wenn der Markt ins Rollen gekommen ist, oder eben auch nicht. Wir glauben dass dies auch abhängig vom Erfolg der Apple Watch ist. Wenn sie erfolgreich sein sollte, werden auch andere Hersteller davon profitieren. Zu Beginn werden Apps auf der Apple Watch nur in Verbindung mit einer App auf dem iPhone funktionieren. Dies bedeutet letztendlich das eine App auf der Apple Watch nur eine Erweiterung einer Smartphone App darstellt. Inwiefern sich dies ändern wird muss sich erst noch zeigen. Sicher allerdings ist, dass auch auf dem ersten iPhone keine nativen Apps entwickelt werden konnten. Zur damaligen Zeit wurden hauptsächlich Webseiten benutzt um zum Beispiel etwas bei eBay oder Amazon zu kaufen. Mit der Zeit haben Apps eine wichtige Rolle eingenommen und in bestimmten Bereichen werden sie heutzutage sogar öfter benutzt als die Webseite. Vielleicht lässt sich das in 5-10 Jahren auch von Smartwatches behaupten.

Sollten Sie eine Idee oder ein bereits ausgearbeitetes Konzept für eine Smartwatch App haben, sind wir von der creative workline GmbH genau der richtige Ansprechpartner für Sie. Mit unserer langjährigen Erfahrung im Bereich der mobilen App Entwicklung stehen wir Ihnen gerne zur Verfügung.

Nehmen Sie jetzt unverbindlich Kontakt zu uns auf. Unser Ziel ist Ihre Zufriedenheit: We love to make you Appy!

Bildquellen:
Apple, Motorola, LG, Samsung, Highsnobiety

Core Location Manager in iOS 8

The Core Location Framework in iOS worked over the years in almost the same way, in some version updates Apple may have changed the delegate methods, but all in all the process always stayed the same. Although the process in iOS 8 is not that different, Apple added two steps that might at first cause some trouble to developers who didn’t have a look into the new iOS 8 SDK.

Old Code behavior in iOS 8

- (void)viewDidLoad
{
    [super viewDidLoad];
    // Do any additional setup after loading the view, typically from a nib.

    // initialize the location manager
    self.locationManager = [[CLLocationManager alloc] init];
    self.locationManager.delegate = self;
    // Start getting location updates
    [self.locationManager startUpdatingLocation];

}

// Location updates
- (void)locationManager:(CLLocationManager *)manager didUpdateLocations:(NSArray *)locations
{
	// Do what ever you want with the location
}

Until iOS 8, this is how a simple location retrieving process would look like.
This code fails in iOS 8, furthermore this code fails without any sort of warnings, exceptions or errors, the app won’t ask for permission to get location updates, the process won’t start at all and we, the app developers won’t be told why.

Passing the code to iOS 8

As stated above, in iOS 8 they are new steps that we need to pay attention to in order make make the location fetching work. The first step is to add either one or two keys into the project’s .plist depending on the main functionality of the app. The two keys are NSLocationWhenInUseUsageDescription and NSLocationAlwaysUsageDescription, you will then need to add a String that explains to the user why does the app needs to access his location, something among the lines of „This app uses location in the background/foreground because of A, B and C“. Each of these Strings has a corresponding authorization method that needs to be called, WhenInUse or Alway (i.e. Background).

*Note: adding the keys without explicitly asking for authorization fails as well

Here are the corresponding methods:

[self.locationManager requestWhenInUseAuthorization]
[self.locationManager requestAlwaysAuthorization]

And here is a full implementation example in case of using the Always key String (i.e NSLocationAlwaysUsageDescription):

- (void)viewDidLoad
{
    [super viewDidLoad];
    self.locationManager = [[CLLocationManager alloc] init];
    self.locationManager.delegate = self;
    if ([self.locationManager respondsToSelector:@selector(requestAlwaysAuthorization)])
    {
        [self.locationManager requestAlwaysAuthorization];
    }
    [self.locationManager startUpdatingLocation];
}

*Note: Don’t forget to add the key in the app’s .plist and to give it a string, otherwise the authorization UIAlertView won’t show and the process won’t start.

Choosing the right authorization

Now that we have to explicitly ask for the user’s permission, we also need to decide what kind of permission do we actually need so that we don’t ask for unnecessary permissions. As you probably already noticed, the keys and method names, give a pretty clear idea on should be the one or the other used. The WhenInUse key allows the app to receive location updates only when the app is in the foreground. The Always key allow the app to receive location updates at any given time in the background. For example if you would like at some point to wake the app based on the user’s location, you need the Always key, as working in the background is it’s main functionality. Of course, asking for the Always authorization gives the WhenInUse authorization, but not the other way around. If your app’s main functionality is getting location updates in the foreground but has a small functionality that should work in the background, you can use both keys and start by asking for the WhenInUse. You can always ask for the Always authorization at a later point, if needed (Keep in mind that once the user has accepted the one authorization, he won’t be asked again, and you need to ask him to go to the settings and change the authorization manually). All the location services are available with both authorizations, except that the WhenInUse authorization can access these services only when the app is in the foreground. If you wish to wake the app based on these services, you need to use the Always authorization.

Fetching location in the background

The following part of this article is based on the following example, provided by Ricky, here is the source code for those of you who are interested. After implementing everything needed to start receiving location updates, those who need the app to keep working and fetching the user’s location in the background, still need to face the challenge of keeping the app from terminating. Due to the iOS’s multitasking, the system will at some point move the app from running in background to suspended as it sees fit, at that point any process that the app was running will be stopped. In order to be able to consistently fetch location updates from the device, a solution must be implemented, that will consistently refresh the app in the background giving it enough time to perform a short time period process that will be executed with each refresh. In our case it’s to receive a location update and do whatever we want with it. Refreshing the app in the background is a matter of explicitly starting and ending background tasks through our [UIApplication sharedApplication] object and it’s two methods beginBackgroundTaskWithExpirationHandler: and endBackgroundTask:. Failing in one of these processes will cause the system to kill your app. In other words, in order for the process to keep on going, the starting and ending of the background tasks need to be synchronized with the start, stop and restart of the location fetching process.
But first things first, before starting any of the steps above, we must first check if the app has background authorization, as it might be that the user has disabled the background services:

UIAlertView * alert;

    //We have to make sure that the Background app Refresh is enabled for the Location updates to work in the background.
    if([[UIApplication sharedApplication] backgroundRefreshStatus] == UIBackgroundRefreshStatusDenied)
     {

            // The user explicitly disabled the background services for this app or for the whole system.

        alert = [[UIAlertView alloc]initWithTitle:@""
                                          message:@"The app doesn't work without the Background app Refresh enabled. To turn it on, go to Settings > General > Background app Refresh"
                                         delegate:nil
                                cancelButtonTitle:@"Ok"
                                otherButtonTitles:nil, nil];
        [alert show];

    } else if([[UIApplication sharedApplication] backgroundRefreshStatus] == UIBackgroundRefreshStatusRestricted)
    {

            // Background services are disabled and the user cannot turn them on.
            // May occur when the device is restricted under parental control.
        alert = [[UIAlertView alloc]initWithTitle:@""
                                          message:@"The functions of this app are limited because the Background app Refresh is disable."
                                         delegate:nil
                                cancelButtonTitle:@"Ok"
                                otherButtonTitles:nil, nil];
        [alert show];

    } else
    {

        // Background service is enabled, you can start the background supported location updates process
    }

After checking if the background services are available, we then need implement the following behaviors:

The Core Location Manager and it’s delegate, to receive location updates.
The explicitly starting and ending of the background tasks inc. stopping and refreshing the processes of the app.
Link the starting and ending of the background tasks to the Location Manager updates.
Object to save the returned values in order to use them later.

In our example we have three objects other than the Appdelegate and the ViewController:

BackgroundTaskManager: is a singleton and implements the starting and ending behavior of the background taks, hence the name BackgroundTaskManager.
LocationTracker: is a singleton as well, implements the Core Location Manager delegate, takes on itself to get notified when the app enters the background and links between the background tasks and the location updates.
LocationShareModel: is a singleton and has four global variables: two timers, backgroundTaskManager object and array of the locations; the first timer is a 60 seconds timer and is practically responsible of refreshing the app every 60 seconds and restarting the process so the app won’t terminate, the second timer is a 10 seconds timer, which is there for battery life reasons. consistently updating the devices location incl. when the app goes in the background can be a process that consumes a lot of battery over time. These two timers in play allow the app to receive location updates every 60 seconds, for 10 seconds in order to keep the battery consume as low as possible. The BackgroundTaskManager object is then used by the LocationTracker and the location-Array, to save the returned locations.

BackgroundTaskManager

The BackgroundTaskManager object has two global variables (masterTaskId and bgTaskIdList) that keep track of the background tasks, and four methods that start and end the background tasks.

The beginNewBackgroundTask method

-(UIBackgroundTaskIdentifier)beginNewBackgroundTask
{

// Once called, the beginNewBackgroundTask will start a new background task, if the app is indeed in the
// background, and will then explicitly end all the other tasks to prevent the app from being killed by the system

  UIApplication* application = [UIApplication sharedApplication];

    UIBackgroundTaskIdentifier bgTaskId = UIBackgroundTaskInvalid;
    if([application respondsToSelector:@selector(beginBackgroundTaskWithExpirationHandler:)])
        {

                bgTaskId = [application beginBackgroundTaskWithExpirationHandler:^{

                        NSLog(@"background task %lu expired", (unsigned long)bgTaskId);

                }];

                if ( self.masterTaskId == UIBackgroundTaskInvalid )
                {
                        self.masterTaskId = bgTaskId;
                        NSLog(@"started master task %lu", (unsigned long)self.masterTaskId);
                }
                else
                {
                       //add this id to our list
                        NSLog(@"started background task %lu", (unsigned long)bgTaskId);
                        [self.bgTaskIdList addObject:@(bgTaskId)];
                        // the endBackgroundTasks is simply a convenience method that ends all of the
                        // background tasks excl. the masterTask.
                        [self endBackgroundTasks];
                }
        }

    return bgTaskId;
}

The drainBGTaskList Method

// has a BOOL parameter, indicating if all background tasks should be stopped
// This method is called only through the two convenience methods
// endBackgroundTasks that passes NO as a parameter
// and endAllBackgroundTasks that passes YES as a parameter
-(void)drainBGTaskList:(BOOL)all
{
    //mark end of each of our background task
    UIApplication* application = [UIApplication sharedApplication];

    if([application respondsToSelector:@selector(endBackgroundTask:)])
    {
        NSUInteger count=self.bgTaskIdList.count;

        // when the "all" parameter is false, the integer value starts with one
        // the for then goes on ending all the previous tasks keeping only the one
        // that was just added
        for ( NSUInteger i=(all?0:1); i<count; i++ )             {     UIBackgroundTaskIdentifier bgTaskId = [[self.bgTaskIdList objectAtIndex:0] integerValue];     NSLog(@"ending background task with id -%lu", (unsigned long)bgTaskId);     [application endBackgroundTask:bgTaskId];     [self.bgTaskIdList removeObjectAtIndex:0];             }                      if ( self.bgTaskIdList.count > 0 )
            {
        NSLog(@"kept background task id %@", [self.bgTaskIdList objectAtIndex:0]);
            }

            if ( all )
            {
    // case "all" was true, all the tasks must be terminated, including the masterTask
    NSLog(@"no more background tasks running");
    [application endBackgroundTask:self.masterTaskId];
    self.masterTaskId = UIBackgroundTaskInvalid;
            } else
            {
     NSLog(@"kept master background task id %lu", (unsigned long)self.masterTaskId);
            }
    }
}

LocationTracker

After implementing the BackgroundTaskManager, comes the interesting part, here we will now have to implement the order of events that will keep refreshing the app and receiving location updates. Naturally we have the SharedModel as a global variable in order to have access to our BackgroundTaskManager object and the location array. Other than that we have the Core Location Manager delegate methods and five other important methods to start, stop, restart and terminate the process as well as a method that will be triggered through a local NSNotification when the app goes into the background.

- (void)startLocationTracking
{
        // Check for the location services authorizations and act accordingly

        // inc. the new iOS 8 way
        if(IS_OS_8_OR_LATER)
        {
          [locationManager requestAlwaysAuthorization];
        }
        [locationManager startUpdatingLocation];
}

// Stop the locationManager and the process completely
- (void)stopLocationTracking
{

    // Invalidate the timer and set it to nil
    //  so the process won’t repeat itself

        if (self.shareModel.timer)
        {
            [self.shareModel.timer invalidate];
            self.shareModel.timer = nil;
        }

        CLLocationManager *locationManager = [LocationTracker sharedLocationManager];
        [locationManager stopUpdatingLocation];
}

//Restart the locationManager
- (void) restartLocationUpdates
{
    // Invalidate the timer and set it to nil
    // because we are restarting the process
    if (self.shareModel.timer)
    {
        [self.shareModel.timer invalidate];
        self.shareModel.timer = nil;
    }

    CLLocationManager *locationManager = [LocationTracker sharedLocationManager];
    locationManager.delegate = self;
    // any further initialization that you see fit

    // check for iOS 8
    if(IS_OS_8_OR_LATER)
    {
        [locationManager requestAlwaysAuthorization];
    }
    [locationManager startUpdatingLocation];
}

//Stop the locationManager
-(void)stopLocationDelayBy10Seconds
{
    // This method is called by the 10 seconds timer -  "delay10Seconds"
    // in order to conserve battery life
    // The location updates will then be stopped
    // and restarted after 60 seconds by the 60 seconds timer - "timer"
    CLLocationManager *locationManager = [LocationTracker sharedLocationManager];
    [locationManager stopUpdatingLocation];
}

// This Method will be called as soon as the app goes into the background
// (Which is done through the "[NSNotificationCenter defaultCenter] addObserver" method with the key
// "UIApplicationDidEnterBackgroundNotification
//" in the "name" parameter, should be implemented in the init method).
-(void)applicationEnterBackground
{
        CLLocationManager *locationManager = [LocationTracker sharedLocationManager];
        locationManager.delegate = self;
        // Any other initializations you see fit

        // check for iOS 8
        if(IS_OS_8_OR_LATER)
        {
            [locationManager requestAlwaysAuthorization];
        }
        [locationManager startUpdatingLocation];

        //Use the BackgroundTaskManager to manage all the background Task
        self.shareModel.bgTask = [BackgroundTaskManager sharedBackgroundTaskManager];
        // Begin a new background task.
        [self.shareModel.bgTask beginNewBackgroundTask];
}

After going over these five methods, we still need one last piece in our puzzle. The Core Location Manager delegate method, didUpdateLocations:

-(void)locationManager:(CLLocationManager *)manager didUpdateLocations:(NSArray *)locations
{

    // filter the given locations as you see fit
    // and add them to the location array list
    for (int i = 0 ; i    {
        //…… filtering logic
        [self.shareModel.myLocationArray addObject:];
    }

    //If the timer still valid, it means the 60 seconds are not yet over, and any other
    // process shouldn’t be started, so return the method here (Will not run the code below)
    if (self.shareModel.timer)
    {
        return;
    }

    // start a new background task case app is in background
    self.shareModel.bgTask = [BackgroundTaskManager sharedBackgroundTaskManager];
    [self.shareModel.bgTask beginNewBackgroundTask];

    //Restart the locationMaanger after 1 minute
    self.shareModel.timer = [NSTimer scheduledTimerWithTimeInterval:60 target:self
                                                           selector:@selector(restartLocationUpdates)
                                                           userInfo:nil
                                                            repeats:NO];

    //Will only stop the locationManager after 10 seconds, so that we can get some accurate locations
    //The location manager will only operate for 10 seconds to save battery
    if (self.shareModel.delay10Seconds)
    {
        [self.shareModel.delay10Seconds invalidate];
        self.shareModel.delay10Seconds = nil;
    }

    self.shareModel.delay10Seconds = [NSTimer scheduledTimerWithTimeInterval:10 target:self
                                                                    selector:@selector(stopLocationDelayBy10Seconds)
                                                                    userInfo:nil
                                                                     repeats:NO];

}

And that is everything you need to know to make you receive location updates in the background without being terminated or killed by the iOS system. Again, you can find the source code link at the beginning of this part of the article.

Will this solution be approved by the Apple code review?

The answer to this question is probably yes, the provider of this example claims he has two live apps in the App Store using the given solution, he says so in one of the comments in his article where he shares this solution, here is the link. In the comment he also added a link to his portfolio.

For which use cases does it make sense to use this solution?

The backgroundTaskManager is there to keep the app alive and to allow it to constantly receive location updates in the background, the timers are there to keep the app from consuming huge amounts of battery life making, the interplay between the timers and the backgroundTaskManager makes it optimal to receive very accurate location updates on a long term basis. This solution is useful in apps that rely heavily on location, like GPS tracking apps or location-based dating apps. In other words, if you need a to constantly receive locations with a high accuracy, this solution is good for you.

What about Apple’s significant-change location service?

Apple’s significant-change location service, which includes calling the method: startMonitoringSignificantLocationChanges, has a low accuracy. The startMonitoringSignificantLocationChanges method initiates the delivery of location events asynchronously, returning them to the locationManager:didUpdateLocations: delegate method. After receiving a location fix, this method will update events only when a significant change in the user’s location is detected and will not answer to the distanceFilter property. So although this service relaunches your app, it will unfortunately do so in cases where for example the device becomes associated with a different cell tower. More information about the matter is here and here to be found. This will consume less power than the solution from this article, but it will also be much less accurate and you can’t really rely on a certain time or distance interval for location updates. So think about your use case before you decide for a certain solution.

Conclusions

Basically the main change in iOS is that Apple now gives the location authorization process to the developer and lets him decide the kind of access that he needs (foreground or background), in other word, if in the past the only thing we needed to get location updates was to call the method startUpdatingLocation and hope that the user gives the permission, now we need to take care of the authorization process. Which on the up side gives us more room to optimize the app for our exact needs, but on the down side makes it more complicated to work on the edge cases. Making the app working in the background is definitely the more complicated part of this article, but after going through the code two or three times everything becomes easier, hopefully for you as well! With this code being provable by Apple, the only thing left for you to do is to integrate it your app and to pass it to your exact needs, which shouldn’t be a problem after fully understanding the order of events, that is of course if that is the solution you were looking for. For other use cases, that do not need such a high accuracy background fetching solution, you can always still use Apple’s significant-change location service.

Where to now?

For a more detailed explanation about the location fetching changes in iOS 8, you should definitely check out the following article. And of course a link to the WWDC, what’s new in Core location. Are you interested in having your own location-based app for iOS (or Android) developed? Then just contact us.

Till next time,
Happy coding

Technology inside the car is not a new trend. During the last years, several car manufacturers had tried to add new features in order to improve the driver’s experience. Google and Apple have realized that maybe they could bring their most known operating systems to the car. They are called “Apple CarPlay” and “Android Auto”. And here it is a new world of opportunities to app developers.

A new era of technologies

While Android and iOS are trying to lead the mobile industry, other new devices are coming, known as “wearables”. These new devices are focused on improving the quality of life through technology and as cars are in our life, they are also included. So this article is not about „smartwatches“, but cars’ new operating systems.

Most of people are familiar with Android and iOS experience so, why do not try to bring these experiences to the car?

Cars and technology

Cars mean technology. Every automobile company invests great amounts of money in technology. They are investing in safety, performance and user experience, among others. The user experience can be also interpreted as safety, so a great operating system can significantly improve the experience of driving a car.

Nowadays, car users tend to connect their smartphones to their cars in order to use some useful apps that they use everyday. But it is still a smartphone connected to a car. What if we could use a native car app which was specifically developed for cars? Of course it would be great, as it was conceived only for this purpose.

Android Auto

Android Auto, the right information for the road ahead.

Google’s Android Auto is conceived to be another part of the Android enterprise. It takes the same interface and connects to other Android devices. That means that can connect with the 84.7%[1] of the smartphones in the world. The principles of Android Auto are “Extending Android to Cars”, “Build for one platform” and “Minimize distraction”.

Right now, they offer maps, music, voice and many other apps. They have announced in their website the new SDK (Software Development Kit) for Android Auto. Any user with a compatible vehicle and a smartphone with Android 5.0 or higher is ready to use the adapted apps for this system. There is no limitation when you imagine what an app can do inside a car. Google wants to make it easy for developers and they make the integration easier as ever.

As for the car manufacturers, the list is increasing every day and now they are 28. VW, Audi, Fiat or Ford are some of the names.

Apple CarPlay

The best iPhone experience on four wheels.

Apple wants to make their product as an extension of their most popular device, the iPhone. CarPlay will display maps, play music and interact with Siri. They just want to make the driving easier and safer. This means that currently there is a SDK but it is not open for all the developers, so if someone has an app idea, the only way to start the development is to send the proposal to Apple and be accepted. Only few apps are available and the certification control will be tougher than in the normal app store for iOS. Many sources point that there will be a special certification for CarPlay apps.

The number of car brands with Apple CarPlay is also increasing and right now the list grows to 29.

Safety limitation

Both Google and Apple are aware of the possible distractions when driving. In order to prevent accidents, they have decide to establish a set of restrictions to apps. In case of Apple, the restrictions are even tougher as only accepted ideas will be able to carry out.

New opportunities for developers

And here is where the developers come into play. We can adapt to the car the apps which are already at the app stores or create new ones and make driving easier and more comfortable. Now is possible to make real any idea comes to mind when driving. The future of the automobile is coming and there is no doubt that the apps will be there.

Can I bring my own app to the car?

Google plans to make it really easy. They said „easily extend your existing apps to work in the car“ and they promise to release a new SDK for this purpose in the next months. Of course, it won’t be possible to bring the same app with the same whole features, but we will be able to adapt these apps to get a better experience when driving.

On the other hand, Apple also has a SDK but it is not going to be as easy as Android Auto. Apple will apply a double validation process for the CarPlay apps. Right now, only approved ideas are able to begin with the development, so we will have to wait until Apple decides to make it open to the public. No doubt we will be there.

Current apps on the market

Both platforms have iHeartRadio, Spotify and AtBat apps. Android is also working with tuneIn and Songza. Carplay has Beats Music and Podcasts, among others.

Real alternatives to Apple and Google?

Of course, not only Apple and Google are interested in cars. There is a company called „Mirrorlink“ which tries to bring to the car’s screen the same screen from the smartphone. Microsoft is also on the battle and they have presented „Windows in the car“. This is an early concept from Microsoft, but they have promised to have their own marketplace for apps created by developers.

Why should I have or not an App for these new technology

Right now there are 1,200 millions of cars in the world and by 2035 is estimated to be 2,000 millions. This is a huge number of car users, and potential car app users. Most of the famous apps for smartphone are in the app stores from the early beginning, so, why don’t to try and bring your app to the car? In addition, if the user enjoys the car app, then he probably will take a look at the smartphone app.

Conclusion

Car apps are coming, Google and Apple know it and they are ready to provide app developers the tools to make it possible. Google Auto and CarPlay will be probably the main operating systems, if we see the number of car brands that will support them. And we as developers are also ready to bring these apps to the car. Are you interested in bringing your own app to the car? Contact us.

[1] data from IDC http://www.idc.com/getdoc.jsp?containerId=prUS25037214

Es gibt viele verschiedene Arten von Tests. Einige wichtige Arten sollen nun kurz vorgestellt werden.

Testarten

Usability Tests

Diese Art von Tests sollen die Benutzerfreundlichkeit der App testen. Hierzu gehören die Wechsel zwischen den verschiedenen Screens, die Verwendung unterschiedlicher Sprachen oder die Fehlermeldungen einer App. Sollte einmal ein Fehler auftreten weil zum Beispiel die Internetverbindung ausbleibt ist dies kein Weltuntergang, jedoch sollte der Benutzer in solchen Fällen mit einer eindeutigen Nachricht auf die Missstände hingewiesen werden. Grundsätzlich gilt: Je mehr Arbeit man dem Benutzer abnimmt, desto besser.

Stress Tests

Stress Tests sollen zum Beispiel ein schlechtes Speicher-Management der App simulieren. Ein möglicher Stress Test für einen Server besteht zum Beispiel in der Simulation von extrem vielen gleichzeitigen Anfragen durch mehrere Clients. Nach der Publikation einer App wird diese wahrscheinlich nicht sofort von tausenden Benutzer aktiv genutzt. Doch wenn dieser Fall später einmal auftritt, sollte man sich bereits frühzeitig dafür gewappnet haben. Stress Tests sind genau für solche Szenarien geschaffen.

Compatibility Testing

Vor allem im Android Segment gibt es viele verschiedene Versionen des Betriebsystems. Doch dies ist nicht die einzige Hürde. Außerdem gibt es mittlerweile viele verschiedene Hersteller die auf Android setzen. Hierzu zählen zum Beispiel Samsung, Sony, HTC, oder Motorola. Alle Hersteller verbauen unterschiedliche Arten von Hardware. Der größte Unterschied sind hierbei wohl die unterschiedlichen Displaygrößen. Sie unterscheiden sich außerdem nicht nur in der Größe sondern auch in der Auflösung. Durch sogenannte Compatibility Tests sollen gerade diese Unterschiede auf Herz und Nieren überprüft werden. Schließlich soll eine App auf allen Geräten gut aussehen und ohne Probleme bedienbar sein.

Performance Tests

Nicht jedes mobile Endgerät ist ein High-End Gerät. Dies bedeutet, dass zum Beispiel auf einem langsameren Gerät eine Operation länger dauert als auf einem anderen. Ein wichtiger Performance Test besteht darin, Apps auch auf einem Gerät mit sehr begrenztem freien Restspeicher zu testen. Denn viele sich im Umlauf befindenden Geräte besitzen nur einen begrenzten internen Speicher und stellen ein Risiko für ungeahnte Fehlerquellen dar.

Wie können Apps getestet werden?

Vorallem durch die verschiedenen Arten von Betriebssystemen wie Android, iOS oder Windows Phone und mobilen Endgeräten ist es unmöglich, Applikationen auf allen unterschiedlichen Systemen zu testen. Doch wie kann trotzdem eine stabil laufende Version bereitgestellt werden?

Einsatz von Emulatoren

Durch den Einsatz von Emulatoren können Apps auf verschiedensten Geräten getestet werden. Solche Emulatoren stehen zum Beispiel für die Betriebssysteme Android und iOS kostenlos zur Verfügung, und wir bei creative workline entwickeln tag-täglich damit. Emulatoren können verschiedene Geräte und unterschiedliche Betriebssystem Versionen emulieren ohne jedoch das Gerät selbst kaufen zu müssen. Dies stellt natürlich eine Kostenersparnis in der Anschaffung solcher Geräte dar. Trotzdem wird beim Einsatz von Emulatoren eine App immer nacheinander auf verschiedenen simulierten Geräten getestet. Ein gleichzeitiges oder automatisiertes Testverfahren ist hierdurch allein noch nicht möglich.

Cloud Testing

Anbieter wie TestObject oder Xamarin bieten sogenannte Cloud Tests für mobile Applikationen des Android Betriebssystems an. Reale mobile Geräte werden zum Beispiel über ein Web-Interface bedient. Hierbei lässt sich die App außerdem gleichzeitig auf mehreren Geräten testen. Dies stellt eine große Zeitersparnis dar.
Absturzberichte werden aufgezeichnet und dem Tester bzw. Entwickler zur Verfügung gestellt. Solche Dienste werden meist minutengenau abgerechnet. Man bezahlt also nur das, was man wirklich verbraucht.

Automatisierte Tests

Automatisierte Tests sind das Mittel zur effektiven Vorbeugung gegenüber Fehlern. Sie sollten vom Entwickler bereits während der Entwicklungsphase implementiert werden um eine hohe Qualität von Anfang an zu gewähren. Bereits zuvor erwähnte Anbieter von Cloud Testing Diensten unterstützen meist auch die Einbindung von automatisierten Tests. Diese können dann gleichzeitig auf mehreren Dutzend Geräten in der Cloud ausgeführt werden. Diese Art von Tests sind als sehr effektiv anzusehen. Es folgt eine Auswahl an Frameworks welche das automatisierte Testen auf den Platformen Android und iOS ermöglichen:

Android

• Robotium
• Espresso
• InstrumentationTestRunner

iOS

• Automation Instrument

Android und iOS

• Calaba.sh
• Appium

Fazit

Die Verwendung von unterschiedlichen Testverfahren ist für die hohe Qualität einer App unerlässlich. Dieser Artikel sollte einen Einblick in verschiedene Testverfahren geben und verdeutlichen wieso vor allem mobile Apps auf Tests angewiesen sind. Dies ist deshalb von so großer Bedeutung, weil es so viele verschiedene Arten von Betriebssystem Versionen und Gerätetypen gibt. Vor allem durch den Einsatz von Cloud-Testing können die Kosten für Tests gering gehalten werden, denn diese bieten die Möglichkeit zur gleichzeitigen Ausführung einer App auf verschiedenen Geräten. Werden zusätzlich automatisierte Tests durch den Entwickler implementiert, können diese im Verbund mit Cloud-Testing als ein sehr effektives Mittel zur Fehleridentifizierung und damit bereits frühzeitig als Mittel zur Qualitätssteigerung von Apps eingesetzt werden.

In the last years the importance of gestures has risen constantly. Although we all know gestures as a form of non-verbal communication, we also use them to interact with various devices. This post is about the evolution of gestures in the world of mobile devices.

The basic input commands for displays are touches, swipes, drags and pinches. With variations or combinations like double touching, long pressing or long press dragging a none too small repertoire is available. Besides these basic gestures, new forms of interactions evolve constantly. The focus here lies on natural behaviour and intuitive workflows.

Starting off with some basic platform specific gestures from Android and iOS I will go on to analyse some patterns throughout selected apps.

Notification Screens

An essential component of mobile OS are notifications. Android and iOS go a similar way by providing a gesture to pull the notification screen down from the top edge of the screen.

In Android an additional gesture for notifications is available: When pinching a notification element horizontally, it expands. That presumes that the notification element carries more information than it can show in a regular notification. With a swipe to the left or right the notification can be dismissed.

Quick Actions

Like to the notification screen the quick action screen is represented on Android and iOS. The quick actions under Android are accessible by a two-finger-swipe-down from the top or the settings icon on the notification screen. iOS follows a different approach with a swipe up (from the bottom). Android handles this gesture with the launch of Google Now.

App Switcher

Android’s app switcher is a great example of natural behaviour. The running apps are listed vertically and with a swipe to the left or right the app can be closed. With iOS 7 a app switching pattern established which is very similar to Android’s. The running apps are listed horizontally and with a swipe up the app can be closed.

Patterns

Now that we have covered the system dependent gestures it’s time to take a look at various gesture patterns using exemplary apps.

Youtube

A very interesting gesture has found it’s way to the Youtube app which should empower people to search for other content without aborting the current video. By dragging the video down, a decent, transparent overlay appears behind the video to indicate a view change. The video can be brought up again with the inverse gesture, or closed with a swipe to the left. It’s like throwing the view away – similar to the app switcher.

Another gesture element in the Youtube app is the Navigation Drawer, a pattern which has established in the last few years on mobile devices. It implies that a view is hidden on the left side of the screen. By now thousands of developers have adapted this pattern to their apps. Here is a great overview of the functionality from the Android developer site:

Hangouts

Google’s messaging app Hangouts is also built on an interesting concept: The conversation overview indicates a detail view on the right border. By swiping left or right the particular view shows up. This type of navigation creates a highly dynamic impression. A scope of application could also be a master-detail implementation.

Gmail

A rather common gesture is illustrated by the Gmail app: The swipe-to-delete gesture. It inhabits the same principles as the app switcher. When content is presented in a list which can be modified (delete, archive…) this gesture represents maybe the most natural way to get rid of an item.

Another wide spread pattern is the swipe-down-to-refresh gesture, which is also integrated in the gmail app. This gesture makes sense, because it replaces the regular boundary with a kind of enhanced boundary, which communicates more dynamics. Of course the functionality is well-known from refresh icons, but this way of updating a list is clearly more intuitive.

Timely

Bitspin – a little company from Switzerland – created this alarm app. They joined Google in January 2014. With a strong focus on design they stand out in an ocean of alarm apps. The most interesting gesture here is when setting an alarm: On the left edge the numbers (0-24) are displayed. With a swipe from this left edge toward the right side a decent animation starts and you can choose the time by dragging your finger up/down. To remove an alarm just swipe the alarm to the right; again a great implementation of the swipe-to-delete gesture.

Chrome

Switching tabs in a mobile browser can be an unpleasant task. Formerly Chrome implemented the tab switching logic with a swipe from the left/right edge to the other (similar to the navigation drawer). But now it has become more precise by limiting the gesture to the action bar. Although it’s unlikely that Google ever implements a navigation drawer in the Chrome app (which would require three top-level views), this step makes sense to avoid gesture conflicts and to ensure further consistency.

The second gesture is a swipe down from the action bar to access the tab overview. That kind of visualisation is a prime example of multiple layers in a view.

Play Music

Yet another Google app: Play Music is a sophisticated app that offers various gestures, of which the “next/previous song” gesture lies in focus of this section. The classic controls are still available, but supported by the horizontal swipe gestures: Swiping leftwards brings the next song to the foreground and swiping to the right leads to the previous song.

A future prospect: At the end of 2013 Google acquired Flutter, a startup developing a hand-gesture interface. It’s the company behind control navigation for iTunes, Windows Media Player and Winamp. For future updates it’s very likely that Google will somehow integrate this new knowledge to offer a hands free gesturing experience.

Paper

On February 3rd 2014 Facebook launched it’s standalone app Paper, which should herald nothing less than a new way of storytelling and content consuming. The basic structure is: cover images on top (sections) and stories on the bottom.

One way to use the app is to scroll through horizontally in half-screen mode. When selecting (tapping on) a story it is maximized with a fine animation and emphasizes on the content. In this fullscreen mode the stories can be switched with a swipe to the left or right. If you see a story you like, you can just pull (swipe) up and it opens the webpage. This gesture is inspired by unfolding/opening a newspaper.

When scrolling through the sections in the upper half you can easily add new content by pulling down the view. There you can add, remove or even reorder sections with drag and drop. This process feels a lot more natural than selecting various sections in a listview.

Photos are looking especially great thanks to some UI tricks like panoramic viewing: When opening a picture that’s bigger than the portrait view you can tilt the phone left and right to get kind of a augmented reality view for photos.

With this new approach of consuming media, people are more likely to slow down and think about the posts. Classical newsfeeds are mostly just scrolled through and overflown. But this lean-back and
one-content-at-a-time (fullscreen) style has the potential to raise the user’s focus on selected content.

Sailfish OS

This section gives a brief insight into the Sailfish operating system which is driven by Jolla (former Nokia employees). At the end of 2013 the Jollaphone was released. There are no control buttons on the Jollaphone. That’s because the Sailfish OS is specially designed for gesture based interaction:

Apps & Homescreen

• Swiping from the left or right edge minimizes a running app (in the foreground) and returns to the homescreen.
  
• The homescreen shows an overview with up to 9 running apps. On the bottom are four app icons positioned.
  
• Scrolling down the homescreen gets the user to all installed apps. With a long press, a known pattern from other mobile os, the icon can be repositioned or deleted.
  

Swipe

• If an app provides menu options, they indicated at the top of the screen. A swipe down then enables the access to the menu options.
• A swipe from the top edge (Android: notification screen) closes the respective app.
• The notifications are shown with a swipe from the bottom edge of the screen.
• The back- and forward actions inside a app is implemented with simple left and right swipe gestures (not from the edges!).
• When a dialog appears it can be accepted by swiping it to the left, or cancelled with a swipe to the right.

Additional stuff

• The menu in the lockscreen provides quick access to camera and phone.
• The phone can be activated by a double tap on the display.

Conflicts

It’s also possible to run Android apps on the Sailfish OS. And when two different operating systems meet, some basic (gesture-)patterns are predestined to clash. Especially apps which are using a navigation drawer: With a swipe from the left edge it collides with a essential gesture from Sailfish OS.

Conclusion

We have seen various approaches to bring more natural and intuitive gestures to touchscreens. Google does a good job when it comes to designing new ways of interactions, which is not surprising, as the company is the root point for Android. And recent developments like Sailfish OS or Facebook’s Paper app show that we haven’t reached the zenith of gesture interactions. They are becoming more and more relevant for the next wave of successful apps.

Bluetooth Low Energy (BLE) ist auch unter den Namen Bluetooth Smart und iBeacons bekannt. Es handelt sich hierbei um eine Funktechnik mit der Geräte über eine Distanz bis zu 10m miteinander kommunizieren können. Im Gegensatz zur klassischen Version von Bluetooth verbraucht BLE deutlich weniger Energie und auch die Herstellungskosten für einen BLE Chip sind geringer. Die Kommunikation zwischen BLE Geräten und älteren Versionen von Bluetooth ist durch eine Softwareaktualisierung ab Bluetooth 2.1 möglich.

Welche aktuellen Geräte unterstützen Bluetooth Low Energy?

Bereits 2011 brachte Apple die ersten BLE Geräte heraus. Hierbei handelte es sich um das MacBook Air und den Mac Mini. Seit dem iOS 7 Update sind alle Modelle ab dem iPhone 4S und alle iPads ab der dritten Generation in der Lage über BLE zu kommunizieren. Auch Google unterstützt BLE seit der Android Version 4.3 Jelly Bean. Windows 8 untersützt BLE ebenfalls.

Welche neuen Möglichkeiten eröffnen sich?

Als zwei Beispiele für neue Anwendungsmöglichkeiten sollen hier auf die Themen Indoor Ortung und Kommunikation mit mobilen Tags eingegangen werden.

Indoor Ortung

Eine genaue Ortung innerhalb von Gebäuden ist durch die gedämpfte Empfangsqualität von GPS meist nicht möglich. Auch die Technik NFC (Near Field Communication) erweist sich als untauglich, da sie nur über eine Reichweite von ein paar Zentimetern funktioniert. Würden mehrere sogenannte iBeacon Tags im Raum verteilt werden, kann eine bis auf einen Meter genaue Ortung ermöglicht werden. Mit solchen iBeacon Tags, welche die ungefähre Größe einer Knopfbatterie haben, lassen sich zum Beispiel über ein taugliches Smartphone Schlüssel oder andere Gegenstände wiederfinden. Desweiteren sind Anwendungen für Blinde oder Museumsführer erdenklich. Ortsgebundene Werbung oder die Verteilung von Gutscheinen auf mobile Endgeräte wären zum Beispiel in einer Einkaufspassage denkbar.

Kommunikation mit mobilen Tags

Gegenwärtig und zukünftig können Smartphones mit mobilen BLE Tags kommunzieren. Diese Tags beinhalten zum Beispiel verschiedene Sensoren und können diese Werte in Echtzeit zum mobilen Endgerät übermitteln. Die entsprechende App auf dem Smartphone würde die Sensordaten auswerten und je nach Einsatzzweck reagieren. Zu den Sensoren könnten Temperatur-, Feuchtigkeits-, Beschleunigungs- oder Drucksensoren gehören. Auch Schrittzähler könnten in die Tags integriert werden. In Kombination mit einer App könnten Sie zur Analyse der körperlichen Aktivitäten dienen.

Im Gesundheitswesen können solche Tags als Patientenüberwachung dienen um zum Beispiel EKG Werte abzutasten.

Fazit

Bluetooth Low Energy kann in einiger Zeit die Technik in der Nahfeldkommunikation werden. Sowohl die App-Entwickler, die Unternehmen als auch die Benutzer von Apps auf Plattformen wie Android und iOS profitieren davon. Der große Vorteil gegenüber NFC ist die deutlich größere Reichweite. Dadurch das immer mehr mobile Endgeräte BLE unterstützen, werden in Zukunft immer mehr Menschen in der Lage sein die Vorteile von Bluetooth Low Energy zu nutzen. Ob zur Indoor Ortung, zum Wiederauffinden von wichtigen Gegenständen oder zur gesundheitlichen Überwachung der eigenen Großeltern. Der Stromverbrauch zum herkömmlichen Bluetooth wurde enorm reduziert und liegt in der gemittelten Stromaufnahme im Mikro-Ampere-Bereich. Für die verschlüsselte Datenübertragung wird übrigens AES 128 Bit benutzt. Dieses Verschlüsselungsverfahren wird auch in vielen WLAN-Netzwerken eingesetzt und gilt auch in Zukunft als sicher.

ich bin Michael und seit September als iOS Entwickler bei creative workline. Meine erste App habe ich für Android im Rahmen des Studiums entwickelt. Nach dem ersten Kontakt mit Android ist bei mir das Feuer entfacht worden. Seitdem gehört das Smartphone neben der Erfindung des Rades zu den besten Errungenschaften der Menschheit. Noch lieber als neue Apps zu entdecken, entwickle ich sie selbst. Inzwischen habe ich mich auf iOS eingeschossen und um nicht eine große Restaurantkette zu zitieren muss ich sagen “Ich liebe es”.

Heute möchte über meine Erfahrungen bei der Entwicklung von iOS 7 berichten. Apple hat mit iOS 7 viele Änderungen in seinem Betriebssystem gemacht. Für den Nutzer fällt natürlich als erstes das neue Design auf. Hier hat sich alles komplett geändert. Das Motto ist jetzt “Flat Design” und ich muss sagen es kann sich wirklich sehen lassen. Neben dem Design hat sich für den Benutzer auch einiges an der Bedienung geändert, hier sei das verbesserte Multitasking sowie die neue Kamera App zu erwähnen.

Es gibt noch zahlreiche weitere Änderungen, aber in diesem Beitrag soll es um die Änderungen gehen die das neue SDK mit sich gebracht hat. Was hat sich alles für den Programmierer geändert? Worauf muss man sich gefasst machen, wenn man ein bestehendes Projekt mit iOS Version 6 oder kleiner nun für iOS 7 lauffähig machen möchte? Es sei im Vorhinein erwähnt, dass hier natürlich nicht alles angesprochen werden kann, dafür sind die Änderungen doch zu umfangreich.

Wenn man für iOS 7 programmieren möchte benötigt man zu allererst mal Xcode 5. Die Entwicklungsumgebung beinhaltet das iOS 7 SDK. Das setzt aber auch eine Mindestanforderung an das OS X voraus. Hier wird mindestens die Version 10.8 benötigt, also Mountain Lion. Nach Download und Installation, das kann schon mal länger dauern, ist man auch schon bereit um loszulegen.

Apple hat bei Xcode viele Änderungen vorgenommen. Auch hier ist alles im “Flat Desgin”. Das Menü hat sich etwas geändert und manche Sachen befinden sich an einen neuen Platz. Eine Übersicht zu “What’s new in Xcode 5 ” gibt es hier und ist recht nützlich. Aber im Grunde ist alles sehr intuitiv und im Netz findet man immer Hilfe.

Verschobene Ansichten
Als ich ein bestehendes, laufendes, Pixel perfektes Projekt erstmals mit Xcode 5 kompiliert habe und es auf iOS 7 startete habe ich nicht schlecht geguckt. Hier war der Button verschoben dort hing der View unter der transparenten Statusbar, der Scrollview versteckte sich unter der Tabbar und mehr. Kurz die Elemente der Views waren teilweise verschoben oder nicht mehr an der richtigen Stelle.

Dem ist aber schnell Abhilfe geschaffen. Das Storyboard stellt hierfür Einstellungen zur Verfügung. Man wählt einen View Controller aus und ändert die Ansicht.

Unter “View as” ist es möglich ein Projekt für die verschiedenen iOS Versionen anzeigen zu lassen. Wechselt man zwischen Ansichten zum jeweiligen iOS hin und her sieht man die verschobenen Elemente auf dem Storyboard. Nun wählt man eine beliebige Ansicht aus. Ich würde vorschlagen, man nimmt die, in der noch alles am rechten Fleck ist.

Ist unter der Ansicht “iOS 7.0 and Later” ein Element zu weit nach oben gerückt kann man das mittels der iOS 6/7 Deltas korrigieren.

Hier gibt man den gewünschten Wert ein um wie viel das Element verschoben werden soll. Der aktuelle View wird nicht beeinflusst, aber der View für die andere iOS Version. Wechselt man nun wieder die Ansicht, Tada, das Element befindet sich nun an der richtigen Position. Diese Schritte muss man nun wahrscheinlich öfters wiederholen. Diese Vorgehensweise bringt deutliche Vorteile gegenüber Änderungen der Position im Code mit sich. Zum einem muss nicht ständig abgefragt werden auf welcher iOS Version die App gerade läuft und man sieht die Änderungen sofort.

Bewerten im App Store
Gerne möchte man seine App auch im Store von den Nutzern bewerten lassen. Hat unter iOS 6 noch alles funktioniert wundert man sich jetzt vielleicht das man jetzt nur eine leere Seite im App Store angezeigt bekommt. Der Grund dafür ist das Apple unter iOS 7 eine andere URL für die iTunes App verwendet.

Die alte URL
itms-apps://itunes.apple.com/app/idYOUR_APP_ID

ist weiter hin für alle Versionen kleiner als iOS 7 gültig und funktioniert.

Für alle Versionen ab iOS 7 und größer muss jetzt folgende URL verwendet werden
itms-apps://itunes.apple.com/WebObjects/MZStore.woa/wa/viewContentsUserReviews?type=Purple+Software&id=YOUR_APP_ID

Das lässt sich beispielsweise folgender maßen realisieren:

NSString *iOSAppStoreURLFormat = @"itms-apps://itunes.apple.com/app/id%@";
NSString *iOS7AppStoreURLFormat = @"itms-apps://itunes.apple.com/WebObjects/MZStore.woa/wa/viewContentsUserReviews?type=Purple+Software&id=%@"
NSString *urlString = [NSString stringWithFormat:([[UIDevice currentDevice].systemVersion floatValue] >= 7.0f)? iOS7AppStoreURLFormat:
iOSAppStoreURLFormat, @(self.appStoreID)];
[NSURL URLWithString:urlString];

AlertViews via Code bestätigen
Unter iOS 6 ist ein AlertView Bestandteil eines Windows. Das heißt, wenn ein AlertView aufpoppt, wird dieser ein Subview vom Window. Möchte man alle AlertView die angezeigt werden erhalten kann man unter iOS 6 folgendes machen: man geht alle Window Objekte durch und für jedes dieser Objekte geht man die Subviews durch und prüft ob der Subview von der Klasse UIAlertView ist und drückt dann beispielsweise den cancelButton via Code.

Verdeutlicht am folgenden Codebeispiel:

for (UIWindow *win in [UIApplication sharedApplication].windows){
   for (NSObject *obj in win.subviews){
      if ([obj isKindOfClass:[UIAlertView class]]){
         [(UIAlertView*)obj dismissWithClickedButtonIndex:[(UIAlertView*)obj cancelButtonIndex] animated:YES];
      }
   }
}

Unter iOS 7 hat sich das geändert. Ein AlertView ist jetzt nicht mehr Teil eines Windows und erscheint auch nicht unter [UIApplication windows]. Da ein UIAlertView niemals zu einem Window hinzugefügt wird, ist im obigen Codebeispiel die Abfrage niemals wahr. Somit hat man keine Möglichkeit eine Referenz auf das UIAlertView Objekt zu bekommen. Das AlertView gehört jetzt zu der Klasse UITransitionView und das kann alles sein. Leider gibt Apple selbst keine genaueren Auskünfte über diesen Sachverhalt.

Die einzige Option die man hat ist es, sich selbst über die Referenzen der AlertViews zu kümmern. Da gibt es verschiedene Ansätze. Beispielsweise kann man jeden UIAlertView der angezeigt wird in einem Array sammeln und bei Bedarf selbiges durchlaufen und bei allen UIAlertView programmatisch den cancelButton drücken. Jedenfalls muss man sich selbst um die Referenzen kümmern.

Navigation Bar anpassen
Nicht selten kommt es vor, dass die Navigation Bar nach seinen Wünschen angepasst werden soll. Unter iOS 6 kann man folgendes machen um beispielsweise die Farbe anzupassen.

self.navigationController.navigationBar.tintColor = [UIColor colorWithRed:COLOR_RED green:COLOR_GREEN blue:COLOR_BLUE alpha:ALPHA_TOTAL];

Hier wird die Farbe über das Attribut tintColor gesetzt.

Unter iOS 7 hat das leider keinen Effekt mehr. Hier ist ein kleiner aber feiner Unterschied. Das Attribut welches für die Farbe zuständig ist hat sich geändert, nämlich zu:

self.navigationController.navigationBar.barTintColor = [UIColor colorWithRed:COLOR_RED green:COLOR_GREEN blue:COLOR_BLUE alpha:ALPHA_TOTAL];

also von tintColor zu barTintColor. Hier ist aber Vorsicht geboten, denn iOS 6 kennt barTintColor nicht. Es ist eine Abfrage der Systemversion erforderlich. Das könnte in etwa so aussehen.

if([[UIDevice currentDevice].systemVersion floatValue] >= 7.0f){
   self.navigationController.navigationBar.barTintColor = [UIColor colorWithRed:COLOR_RED green:COLOR_GREEN blue:COLOR_BLUE alpha:ALPHA_TOTAL];
}else{
   self.navigationController.navigationBar.tintColor = [UIColor colorWithRed:COLOR_RED green:COLOR_GREEN blue:COLOR_BLUE alpha:ALPHA_TOTAL];
}

Ansonsten kracht es.

Fazit
Befindet man sich in der Lage sein bestehendes Projekt unter iOS 6 auf iOS 7 anzupassen geht das nicht ohne weiteres. Je nach Umfang, Funktionalität und Anzahl der Views sollte man mit entsprechenden Mehraufwand rechnen. Dafür lässt sich das Endprodukt wirklich sehen.

Zusammenfassend kann man sich auf folgendes gefasst machen:
Mit hoher Wahrscheinlichkeit müssen die Views für iOS 7 angepasst, da sich einige Elemente wohl verschoben haben. Eine Anpassung beim Bewerten muss ebenfalls gemacht werden, da die Nutzer sonst nur eine blanke Seite vorfinden werden. Ebenfalls ist mit Mehraufwand bei einer angepassten UITabBar zu rechnen. Zu guter Letzt sei nochmals daran erinnert das man sich um die Referenz eines UIAlertView jetzt selbst kümmern muss.

In diesem Sinne: Happy Coding