Nell’articolo in cui tentavamo di capire le ragioni per cui Apple avesse deciso di non lasciare agli sviluppatori indipendenti la possibilità d’usufruire del multitasking nelle loro applicazioni, esprimevamo il nostro parere positivo alla scelta.
Infatti sullo schermo di iPhone, non grande come quello di un computer, non c’è un reale motivo di mantenere aperta un’applicazione mentre ad esempio si sta telefonando.
Questo, ipotizzavamo, anche per una questione di ottimizzazione della durata della batteria.
Questo, ipotizzavamo, anche per una questione di ottimizzazione della durata della batteria.
A confermare le nostre ipotesi arriva un post sul blog di Craig Hockenberry, il programmatore di Twitterrific.
Lui ha avuto modo di sviluppare su di un iPhone sbloccato la versione “mobile” del suo client twitter, andando incontro, a suo dire, ad
un errore di design enorme: dopo l’esecuzione di query XML a intervalli regolari di 5 minuti, la batteria di iPhone si esauriva dopo 4 ore.
Infatti le applicazioni create al di fuori del SDK di Apple possono funzionare tranquillamente in background, come dicevamo nel post scorso l’hardware di iPhone è assolutamente adatto.
Il problema è l’uso che se ne fa, del multitasking e dell’esecuzione in background.
Infatti, secondo Craig Hockenberry, nel suo caso il problema stava nelle componenti radio del device, GPRS e Wifi, il cui funzionamento continuo, avendo una richiesta di sincronia da parte di Mobile Twitterrific, portava ad un veloce scaricarsi della batteria.
Continua Hockenberry:
Sono necessari diversi mesi di sviluppo vero e proprio sulla piattaforma iPhone per arrivare a capire che iPhone necessita di un cambio radicale di prospettiva e di modus operandi. Prima di arrivare a questa realizzazione, si daranno per scontate moltissime cose basandosi sull’esperienza di sviluppo di applicazioni desktop; e questo a sua volta porterà a parecchie scelte di design sbagliate.
Per evitare inconvenienti, allora, Apple ha fatto una scelta radicale: per ora niente multitasking, come fino a poche settimane fa niente applicazioni native.
Il mondo degli sviluppatori indipendenti, comunque, è spaccato in due: da un lato ci sono sviluppatori come Hockenberry che concordano con la scelta di Apple, dall’altro ci sono sviluppatori come il team di Rogue Amoeba che preferirebbero una maggior libertà di movimento.
Libertà di movimento, comunque, che Apple stessa non si è concessa.
Solo le applicazioni Telefono, Mail, Safari ed iPod vengono eseguite in background. Tutte le altre, no.
Sarebbe bello sapere da quanti hanno un iPhone od un iPod Touch e si sono lamentati della restrizione di Apple se si erano mai accorti che gli SMS, la Calcolatrice, le Note, le Widgedts, ecc erano ogni volta chiuse e riaperte.
Solo le applicazioni Telefono, Mail, Safari ed iPod vengono eseguite in background. Tutte le altre, no.
Sarebbe bello sapere da quanti hanno un iPhone od un iPod Touch e si sono lamentati della restrizione di Apple se si erano mai accorti che gli SMS, la Calcolatrice, le Note, le Widgedts, ecc erano ogni volta chiuse e riaperte.
Quindi, se è Apple stessa a non aver avuto bisogno del background per le applicazioni originali dell’iPhone, senza compromettere l’esperienza utente, perchè dovrebbero averne bisogno gli altri programmatori?
Può essere che, comunque, nel momento in cui gli sviluppatori siano abituati a nuove scelte di design conformi al dispositivo, Apple decida di allargare le maglie delle restrizioni del SDK per iPhone.
[Via]
Le prese di posizioni radicali in questo contesto non tengono. “Non aver bisogno di eseguire applicazioni in background” è un modo eccessivamente forte di esprimersi. Per affermare qualcosa di più pragmatico e più vicino alla realtà, bisogna individuare la giusta prospettiva. Ovvero, farsi la seguente domanda: “pur avendo la possibilità di eseguire app in background, necessito realmente di farlo?”.
Questa domanda è assolutamente necessaria se si svuole ottimizzare al massimo lo sviluppo di app su iPhone. In pratica, bisogna sempre cercare di evitare di abusare di certe features su dispositivi mobili, per non abusare delle limitate risorse. È QUESTO il motivo per cui apple fa girare in background solo lo STRETTO necessario. Ed è questo che rende iphone un dispositivo reattivo, usabile e performante.
Il punto è: visto che esiste una classe di applicazioni per le quali è necessario girare in background (e ipod, telefono, etc. sono un esempio lampante), negare totalmente la firma di applicazioni che girino in background è assurdo. Più che altro, bisognerebbe analizzare caso per caso, ideare una licenza (e firma) particolare per quelle applicazioni che non possono farne a meno, e di conseguenza ideare una procedura di checking che controlli che effettivamente l’applicazione sia stata ottimizzata al massimo per girare in background. Ovviamente questo avrebbe un suo prezzo (anche in termini puramente economici) per chi va a sviluppare un tal tipo di applicazione.
Nonostante sia filosoficamente contrario a un tale elevato livello di controllo, mi rendo conto che una tale politica è l’unico modo per garantire una piattaforma mobile performante e responsiva quale è già attualmente iphone (e ipod touch). Non fare in questo modo, vorrebbe dire rendere iphone un aggeggio instabile e inusabile come ogni altro dispositivo mobile sul mercato.
E con “ogni altro” esprimo una mia personale opinione riguardo tutto il resto del mondo mobile.