Background Fetch, Remote Notifications und Background Transfer Service

Systemressourcen bei der App-Entwicklung für iOS schonen

09.04.2015
Von   
Mark Zimmermann leitet hauptberuflich das Center of Excellence (CoE mobile) zur mobilen Lösungsentwicklung bei der EnBW Energie Baden-Württemberg AG in Karlsruhe. Er weist mehrere Jahre Erfahrung in den Bereichen Mobile Sicherheit, Mobile Lösungserstellung, Digitalisierung und Wearables auf. Der Autor versteht es, seine Themen aus unterschiedlichsten Blickwinkeln für unternehmensspezifische Herausforderungen darzustellen. Neben seiner hauptberuflichen Tätigkeiten ist er Autor zahlreicher Artikel in Fachmagazinen.

Mögliche Risiken und Nebenwirkungen...

Background Fetch, also die beschriebene Möglichkeit, im Hintergrund regelmäßig auf Updates zu prüfen, kommt bei falscher Konfiguration einem zerstörerischen Bot-Netz gleich. Jede verteilte Kopie der eigenen Anwendung stellt periodisch Anfragen über deren Internet-Verbindung. Lediglich die Steuerung von iOS selbst (pro Gerät) sorgt für eine theoretische Begrenzung der Anfragen. Wenn die Anwendung nun an Beliebtheit und Popularität gewinnt, steigt der Traffic auf ein nicht absehbares Ausmaß. Neben dem Risiko einer dadurch entstehenden DoS Attacke gegen einen WebServer sind Abfragen an Bezahldienste ein nicht zu unterschätzendes Finanzrisiko. Auch die Nutzung kostenpflichtiger Dienste unter Verwendung von API-Keys kann so zur Kostenfalle werden.

Remote notifications

Remote Notifications sind eine Art "silent push notification". Der Unterschied zu den einher bekannten Push Notifications ist, dass die App selbst diese Benachrichtigungen empfängt und unmittelbar darauf reagieren kann. Eine User-Interaktion ist nur dann notwendig, wenn die App diese explizit anfordert.

Eine Remote Notification kann über die bestehende Push Infrastruktur abgesetzt werden - lediglich in der Payload der Notification muss der Wert "content-available" mit dem Wert 1 versehen werden. iOS interpretiert diese notifications dann entsprechend und reicht sie direkt an die App und deren Delegates weiter um individuell darauf reagieren zu können.

Mit der Remote Notifications API ist es hierdurch möglich auf individuelle Ereignisse zu reagieren und entsprechenden Programcode im Bedarfsfall auszuführen.

Hierdurch können regelmäßige Poll-Versuche von Apps reduziert werden - ein sinnvoller Einsatz dieser Technik kann somit merklich zu einer Reduzierung des Energieverbrauchs führen.

Eine App kann somit durch einen Server informiert werden, wenn neue Daten zur Verarbeitung vorliegen, diese dann abrufen und verarbeiten. Gerade bei unregelmäßigen Updates stellt dies eine energieeffiziente und ressourcenschonende Lösung dar.

Um diese Art des Multitasking nutzen zu können, muss dies ebenfalls in dem "Capabilities" Tap des Projektes aktiviert werden (Background Mode: Remote Notifications).

Ergänzend zur Aktivierung des Modus in den Projekteinstellungen muss im Anschluss auch der entsprechende Eventhandler "application:didReceiveRemoteNotification:fetchCompletionHandler" implementiert werden. Diese Protokollmethode wird in der App vom System aufgerufen, sobald der jeweilige Event eintritt. Auch diese API unterliegt der 30 Sekunden Verarbeitungszeit. Zusätzlich ist auch eine Besonderheit bei den hier verwendeten Notifications zu beachten: Alle Notifications laufen über das Backend von Apple. Silent Push Notifications werden von Apple gesammelt und mit "normalen" Notifications zum Endgerät mitgeschickt. Bleiben normale Notifications aus, überträgt Apple diese zu einem festen intern definierten Zeitpunkt.