iOS4-Multitasking, wie es nicht sein sollte …

Apple bewirbt das neue iOS 4 unter anderem mit «Multitasking – So, wie es sein sollte». Im Alltag spüre ich leider wenig davon, insbesondere können Apps weiterhin nicht dauerhaft im Hintergrund laufen. So muss man bei Twitter-Apps nach dem Starten jeweils darauf warten, dass die neusten Tweets geladen werden, und Instapaper zum Beispiel kann neue Texte auch erst nach dem App-Start synchronisieren …

… lesenswert in diesen Zusammenhang ist ein Blogeintrag von Instapaper-Entwickler Marco Arment.

9 Comments

  1. sebbo
    6. Juli 2010

    Wenn jede App im Hintergrund einfach so ihr Zeug machen könnte, wäre der Akku raz faz leer. Und der Akku des iPhones hält schon so nicht gerade lange…

    Reply
    • Martin (MacMacken)
      6. Juli 2010

      … als Benutzer fühle ich mich mündig genug, solche Fragen zu entscheiden – ich muss schliesslich heute schon entscheiden, mit welchen Apps ich meinen Akku ruinieren möchte. Im verlinkten Artikel beschreibt Marco Arment ausserdem, wie auch unter iOS Anwendungen im Hintergrund funktionieren könnten.

    • sebbo2002
      6. Juli 2010

      Unbestreitbar ist, dass Apple meistens versucht die Technik so einfach wie möglich dem Nutzer rüberzubringen. Deswegen hatte das iPhone auch bis vor kurzem eine überaus übersichtliche und einfach zu verstehende Oberfläche und der Computer überhaupt eine grafische Oberfläche.

      Von daher finde ich den Denkansatz von Apple an dieser Stelle nicht verkehrt: „Lass den Nutzer mal machen; der muss sich um nichts kümmern. Und damit der Akku nicht drunter leidet kürzen wir ein bisschen beim Multitasking, das reizt die Mehrheit sowieso nicht aus“.

      So wie das im verlinkten Artikel steht würde der Akku des iPhones trotzdem ganz schön leiden. Stell dir mal vor du hast auf dem iPhone 10 Apps installiert, die diese Funktion nutzen würden (Twitter, RSS-Reader, Facebook, VZs, da kommen einige zusammen…).

      Jetzt wird von eben diesen 10 Apps alle 15 Minuten mehrere HTTP-Requests abgesendet. Denn mit einem wäre das nicht abgedeckt, allein Twitter würde meine ich 3 Requests brauchen (Timeline, @replies, Direct Messages). Avatare ausgenommen, die müssten natürlich auch bei Bedarf gecached werden. So summieren sich die Requests und irgendwann ist der Akku leer. Und das meistens schneller als gewollt.

  2. flexo
    6. Juli 2010

    Ich halte Apples Zwischenlösung als sehr gut. Es gäbe wohl noch kleinere Verbesserungen wie z.B. die Idee von Marco Armet mit dem NSURLRequest.

    Im Fall einer Twitter App würde dies wohl nicht sehr viel nützen. Auch wenn die App im Hintergrund die Tweets jede Minute holt, der Benutzer wird ganz sicher als erstes auf den Refresh Knopf drücken – wer weiss wann das Programm zuletzt die Daten geholt hat (kein Vertrauen) und der Benutzer könnte ja einen gaanz wichtigen Tweet verpassen der gerade erst gepostet wurde.

    Dürfte jedes Programm im Hintergrund weiterlaufen müsste man als Benutzer Apps immer wieder schliessen um Akkusaft zu sparen. Dann würde dies sicher auf MacMacken stehe „Mühsames Beenden von Apps“ oder „Apps saugen Akku leer im Hintergrund“ 😉

    Reply
    • Martin (MacMacken)
      6. Juli 2010

      Wieso denn jede Anwendung? Bei den meisten Anwendungen ist nicht notwendig, dass sie im Hintergrund aktiv sind …

      Anwendungen, die Daten im Hintergrund aktualisieren können, wären jeweils sofort verwendbar. Man müsste bei Facebook, Twitter, usw. nicht jeweils warten, bis die neusten Daten heruntergeladen wurden. Ebenfalls nützlich wäre die Funktion für Mobile Safari – im Safari-Browser auf dem Desktop kann ich Seiten im Hintergrund in einem Tab laden lassen, in Mobile Safari hingegen kommt das Laden nicht vom Fleck.

    • flexo
      6. Juli 2010

      Weil es jeder Programmierer machen würde. Sein Programm ist ja schliesslich die wichtigste App im Universum 😉 Das gleiche Problem kennt man bei Echtzeit Datenpakete (z.B. RTSP) wo eine Priorität angegeben werden kann. Kein Programmierer gibt eine tiefe Priorität an, jeder wählt die allerhöchste Priorität.

      Anwendungen: Facebook ist ein gutes Beispiel, auch wenn die App den halben Tag im Hintergrund läuft und thoeretisch jede Minute sich die neusten Daten holt, ~80% Benutzer wird beim (erneuten) Öffnen der App auf den Refresh-Knopf drücken. Man könnte ja etwas verpasst haben in der letzten Minute wo noch nicht abgeholt wurde oder die App hat vielleicht vergessen die Daten zu holen.

      Andererseits müssest du dann die App IMMER schliessen wenn du nicht möchtest, dass sie im Hintergrund weiterläuft. Und falls du es mal vergisst saugt dir die App den Akku leer.

      MobileSafari: Muss Apple implementieren im Safari, keine Frage von Multitasking von iOS4.

  3. Jan
    6. Juli 2010

    Ich finde es auch genial wie das Apple gelöst hat, ich muss mir keinerlei Sorgen oder Gedanken über laufende Programme machen, und der Akku hält immer die maximale länge (je nach Einstellungen).

    Ein Haken ist meiner Meinung nach eher dass bisher immer noch nicht alle Apps das „fast-app-witching“ und die anderen OS4-Features beherrschen, diese trüben einem dann immer ein bisschen die Laune.

    Reply
    • Martin (MacMacken)
      6. Juli 2010

      Es werden nie alle Anwendungen «Fast App Switching» beherrschen können – jede Anwendung, die erst Daten laden muss, ist dazu schlicht nicht in der Lage … leider.

  4. macuserX
    9. Juli 2010

    Das Fast App Switching kommt nur, wenn die app gegen das iOS 4 SDK kompiliert wird. Und zwar, ohne code zu schreiben! 😀
    Das einzige was Apps in dem fall hier tun können ist „Task Completion“…

    Ansich ist das Multitasking von Apple einfach geil… die Apps bleiben auch bei Reboot im BG-state. das soll mal mein Nokia mit S60 machen 😀

    Reply

Leave a Reply