i3Factory World

Your Iphone, iPad & Android Application Factory

Browsing Posts published in March, 2010

Djembe Drum Machine for iPad

Djembe Drum Machine for iPad

Eseguita la submission utilizzando OS 3.2 Beta 5. Apple ci ha approvato la review.

Ri-compilata usando L’ SDK 3.2 GM potremo compilare il codice sorgente usando il nostro GM Seed potremo uplodare il nuovo binary per la review finale.

Application Name: Djembe Drum Machine
Application Version Number: 1.0

Apple Store Icon

Apple Store Icon

Wired Italia (n.13 marzo 2010) ha pubblicato una pagina contenente tutti i grandi numeri dell’apple app store.

App Explosion:

70 milioni gli Iphone e Ipod Touch venduti sul mercato mondiale

150.000 apllicazioni presenti in app store

60% del totale sono applcazioni gratuite

1,56 us dollars e il costo medio di un’applicazione a pagamento

65 applicazioni in media possedute da un’utente

10 minuti media di utilizzo di una singola applicazione

3 milardi di applicazioni scaricate fino a dicenmbre 2009

Categorie piu’ diffuse:

Giochi: 21.816 applicazioni presenti
Libri: 21.046
Entertaiment: 18.248
Educazione: 9.262
Utilities: 8.538

Perfect Day Guitar Tuner

Perfect Day Guitar Tuner

Una nuova applicazione presente in Apple Store, un accordatore per chitarra con grafica orizzontale.

Apple Store Icon

Apple Store Icon

Alla luce di questo articolo: http://techcrunch.com/2010/03/07/apple-cookie-cutter-apps/ che e’ riassunto sotto, sembrerebbe che Apple stia rigettando sempre piu’ quelle app prodotte automaticamente e che non siano nient’altro che degli RSS reader, a meno che non si aggiungano nuove funzionalita’ o comunque contenuti tali da rendere l’app veramente utile o comunque non sostituibile da una web-app (accessibile con Safari).


TechCrunch discusses a picture that is being pieced together from reports from App Store developers suggesting that Apple is looking to crack down on “cookie cutter” iPhone applications that offer little more than could be offered through a web app.

Between the developers I spoke to, the consensus was this: Apple doesn’t appear to be opposed to ‘app generators’ and templates per se, but in the last month or so it has started cracking down on basic applications that are little more than RSS feeds or glorified business cards. In short, Apple doesn’t want people using native applications for things that a basic web app could accomplish.

The report offers a lengthy quote from Medialets CEO Eric Litman, who notes that Apple is looking to ensure that iPhone applications offer high-quality experiences that set the iPhone apart from other devices.

Apple wants iPhone apps to be superior to Web experiences because they are extremely sticky and drive people specifically to buy the iPhone over competing smartphone platforms. Apps that are too simple or largely indistinguishable from the Web, other apps or particularly other apps on other platforms send the message to end users that the iPhone app ecosystem might not be particularly special.

In particular, Apple appears to be focusing on submissions from app-building services that utilize only basic templates to generate their products, many of which are little more than spammy regurgitations of Web content. Others involve partnerships with quality content providers but do not offer features that drive a compelling user experience.

According to the report, some app-building services like¬†Appmakr have embraced the shift, working to incorporate more advanced tools such as in-app purchasing, push notifications, and offline access in order to offer the richer experience Apple is looking for. Appmakr hopes that its efforts will not go unnoticed by Apple, allowing it to become a “trusted” developer that could streamline the review process for its applications.A

iPhone web browsers
iPhone Web Browser

1.0 La visualizzazione di una pagina web con l’iphone (viewport):
Quando, utilizzando safari, l’iPhone carica una pagina Web esegue uno scaling, viene ridotta la risoluzione della pagina per farla visualizzare sul display.
Il funzionamento dello scaling avviene poiche’ l’iPhone controlla la larghezza della pagina ad una risoluzione, considerata la piu’ comune, di 980 pixel per poi scalarla, in un secondo passaggio, alla risoluzione di 320 pixel (se il telefono e’ in posizione verticale) o 480 pixel (se e’ in orizzontale).Pertanto per quei siti la cui risoluzione e’ meno di 980 pixel (in larghezza) verra’ mostrato uno spazio bianco ai lati che rendera’ meno leggibile il testo pubblicato.

Per evitare problemi di visualizzazione e’ necessario aggiungere un “meta tag” che imposti la viewport dell’iPhone alla larghezza della pagina.
Nel caso di una pagina web con una larghezza di 700 pixel quindi il nostro viewport dovra’ essere di 700 pixel:

< meta name=”viewport” content=”width=700″ />

Sara’ anche possibile bloccare il minimo (minimum-scale), il massimo (maximum-scale) zoom possibile sulla pagina e settare uno zoom¬† predefinito iniziale (initial-scale).

< meta name=”viewport” content=”initial-scale=0.6, minimum-scale=0.4, maximum-scale=0.8″ />

I valori che impostano lo scaling vanno calcolati in relazione alla dimensione in pixel della pagina che altrimenti e’ preimpostata a 980 pixel: 0.6 corrisponde cosi’ a 588 (588 = 980 x 0.6).

2.0 Il doppio Tap , come funziona l’auto zoom (gesture)
Come e’ noto, si puo’ eseguire uno zoom toccando velocemente due volte sull’elemento che si vuole ingrandire (doppio-tap).

Il disegnatore del sito deve progettare un design che renda questa azione piu’ efficace possibile. Quando si esegue un doppio-tap su un oggetto, l’iPhone puo’ eseguire due azioni: se l’elemento in questione e’ un’immagine questa verra’ automaticamente ingrandita e centrata nello schermo; se invece si fa il doppio Tap su una porzione di testo l’iphone verifichera’ in quale blocco e’ inclusa, quindi espandera’ e centrera’ il blocco a tutto schermo.

Tre regole importanti:
1) Strutturare sempre la pagina in diversi blocchi di contenuto in modo da consentire un piu’ facile ingrandimento della porzione che interessa al’utente.
2) Evitare di disegnare un layout con delle colonne troppo larghe.
3) Assolutamente da evitare un layout senza colonne.

In questi ultimi casi se si esegue uno doppio-tap sulla pagina web l’iPhone non riuscira’ ad impostare la grandezza del blocco, non eseguira’ lo zoom e lascera’ il contenuto non del tutto leggibile poiche’ un layout ad una colonna rende impossibile eseguire uno zoom sui contenuti della pagina.

Android SDK

Jeff LaMarche e’ un programmatore e autore attualmente impegnato nello sviluppo di applicazioni per iPhone e Mac, nonche’ autore di un seguitissimo (e autorevole) blog e del libro “Beginning iPhone Development”.
Riportiamo in questa pagina la traduzione dell’articolo Android SDK from an iPhone Developer’s Perspective. Ringraziamo Jeff per averci concesso l’autorizzazione a riportare la traduzione del testo integrale.
Riconosciamo l’onesta’ intellettuale di Jeff nel sostenere che le sue opinioni sono polarizzate da un amore sviscerato per l’ambiente di sviluppo per iPhone. Nonostante cio’ condividiamo in gran parte le sue affermazioni e siamo perfettamente d’accordo con lui nel ritenere l’SDK per Android meritevole di attenzione se non altro per le sue enormi potenzialita’ di sviluppo.
Vi lascio adesso alla lettura del testo, davvero istruttivo.

Ho gia’ riportato la mia opinione sul dispositivo Nexus One (leggi l’articolo originale oppure la nostra traduzione delle parti salienti). E’ arrivato il momento di veder le cose dal punto di vista della programmazione. E’ arrivata quindi l’ora per una mia opinione sull’ambiente di sviluppo (SDK) di Android.

Permettemi di cominciare dicendo un’ovvieta’, dato che conosco alcune persone che dimenticheranno quanto segue: sto per formulare la mia opinione personale e assolutamente soggettiva riguardo l’SDK di Android. Questa opinione puo’ differire dalla vostra, e questo va bene. Veramente. E’ proprio cosi’. La terra continuera’ a girare anche se voi pensate che io mi stia sbagliando al 100%.

Permettetemi anche di porre in evidenza i miei punti di vista: io non amo Java. Ho usato Java per molto piu’ tempo di Objective-C e ho tutto sommato fatturato molte piu’ ore e guadagnato molto piu’ denaro usando Java piuttosto che Objective-C, ma dal momento in cui ho letto i volumi sul linguaggio e la programmazione in Objective-C, negli anni 1997 e 1998, ho avuto l’impressione che Java stesse intraprendendo la direzione sbagliata. Ogni passo nell’evoluzione di Java ha rinforzato questa sensazione. L’approccio usato in NextSTEP (il quale si e’ evoluto in Cocoa e quindi Cocoa Touch) avvalora il mio pensiero. Io credo in questo approccio. Sia la metodologia che il linguaggio mi piacciono cosi’ tanto, infatti, che ho preferito tagliare i miei guadagni in maniera sostanziosa pur di poter lavorarci sopra a tempo pieno. Cosicche’, basandovi su questo, dovreste capire che Android parte gia’ svantaggiato dal mio punto di vista.

Ho cercato di rimandare il piu’ possibile la pubblicazione di questo articolo per evitare di cadere nell’errore commesso da molte persone con l’SDK di iPhone e Xcode, che e’ quello di scrivere un articolo relativamente al fatto che non funziona nella maniera che desidero io e che quindi non va bene. Dato che ho una notevole esperienza con il linguaggio e l’ambiente di sviluppo (IDE) e dato che ho gia’ alcune settimane alle spalle con l’SDK di Android, posso tranquillamente fornire un’opinione che non e’ esclusivamente una mia protesta per il fatto che non e’ quello che io so fare e che mi piace fare, anche se ovviamente il fatto che faccia molte cose in una maniera che a me non piace certamente influisce sulla mia opinione.

Quindi, dopo aver speso diverse settimane con Android, cosa ne penso?

Sicuramente non e’ male. E’ decisamente un SDK potente. Ha quasi tutto quel che ti serve e, essendo basato su Java, esiste una quantita’ notevole di codice e di librerie su cui fare affidamento. Il progetto dell’SDK e’ un tantino inconsistente (tutto sommato come l’esperienza del sistema operativo). Vi sono alcune parti che ricordano l’iPhone SDK molto da vicino, per quanto possibile date le differenze tra i linguaggi, e vi sono altre parti del tutto aliene.

Vi e’ sicuramente una mancanza di consistenza nella progettazione dell’SDK se confrontata con quella di iPhone. Molte parti dell’SDK sembrano scritte da gruppi completamente differenti che non necessariamente hanno comunicato o si son messi d’accordo sul modo migliore di far le cose. Vi sono alcune inconsistenze anche nell’SDK di iPhone, ma ci sono comunque dei principi guida e dei design pattern cosi’ dominanti nell’iPhone SDK che non hanno una controparte in Android. L’effetto finale e’ un Android un po’ caotico e disunito, ma comunque ancora valido.

Android ha anche un compito difficile da assolvere: esso e’ stato progettato per girare su una vasta gamma di dispositivi e si puo’ sviluppare su molti sistemi operativi e molte macchine. Google ha fatto un lavoro davvero ammirevole date le difficolta’ che occorre affrontare quando non hai opzioni hardware limitate e sulle quali hai il pieno controllo.

Uno dei modi in cui e’ stato affrontato il problema e’ stato nella realizzazione dell’emulatore. E’ possibile configurare l’emulatore per simulare differenti dispositivi con differenti caratteristiche e dimensioni dello schermo, permettendo quindi di impostare diversi dispositivi virtuali. Cio’ significa che puoi testare la tua applicazione su un “Nexus One virtuale”, quindi passare a un nuovo dispositivo virtuale a testarla su un “Motorola Droid virtuale”. Lavorare con l’emulatore e’ facile, ma non tanto quanto come il simulatore di iPhone. Ad esempio, quando lanci un’applicazione sull’emulatore, esso non diventa l’applicazione corrente e l’emulatore non si sblocca automaticamente. Ad ogni modo l’esperienza e’ accettabile, specialmente se si tengono conto delle sfide aggiuntive dovute al fatto che si tratta di una piattaforma aperta.

La stessa applicazione eseguita sul dispositivo ha girato molto bene. Sorprendentemente bene, in effetti. Ancora, l’esperienza non e’ agevole come quella di lanciare un’app sull’iPhone. Ci si imbatte in piccoli inconvenienti, ad esempio quando esegui un programma sul dispositivo il telefono non si sveglia o si sblocca cosi’ come fa l’iPhone. Ma alla fin fine esso lavora piuttosto bene e senza il peso di dover fornire profili di distribuzione o certificati di sviluppo.

Ho scoperto che il debugging su Android non e’ affatto agevole, ma questo magari e’ dovuto al fatto che conosco GDB molto meglio di JDB/ADB (Android Debugging Bridge) e che conosco le potenzialita’ di debugging di Xcode molto meglio di quelle di Eclipse.

Anche se non e’ necessario usare Eclipse per programmare per Android, di fatto esso e’ la scelta di default. O almeno e’ la scelta che presentera’ meno ostacoli al momento di effettuare il setup dell’ambiente. Eclipse e’ molto bene integrato con Android e i suoi tool. L’esecuzione e il debugging sul device o sull’emulatore sono un bijoux e vi sono addirittura dei tool per forzare dei dati all’interno del dispositivo virtuale in esecuzione, come la posizione geografica.

Ma odio Eclipse con tutto il cuore. Esso non si sposa minimamente col mio modo di lavorare. Considero la sua interfaccia utente imperscrutabile e le sue prestazioni sul Mac non proprio eccellenti. Se dovessi sviluppare molto su Android investirei molto probabilmente su qualche IDE alternativo con una buona integrazione di Android, o al limite lavorerei con TextMate e linea di comando.

Mi sento come se potessi scrivere ogni applicazione di cui ho bisogno con Android. Renderla bella e’ una sfida e ho speso piu’ tempo leggendo la documentazione di quanto abbia mai fatto per l’iPhone. Conoscere ogni dettaglio dell’SDK di Android non necessariamente fornisce dei suggerimenti su come puo’ lavorare un’altra parte e anche se si e’ degli esperti sviluppatori Java non si ottiene un vantaggio aggiuntivo a tal fine.

Disegnare le viste con Android e’ una delle aree su cui inequivocabilmente affermare trattarsi di un’esperienza peggiore che nell’iPhone, su ogni singolo aspetto. L’approccio utilizzato da Android per creare le viste non ha un qualsiasi valore che possa riscattarlo. Disegnare l’interfaccia per iPhone e’ facile, divertente e intuitivo. Su Android, e’ un casino. Sembra di lavorare con la stirpe maledetta di GridBagLayout e XML. E’ assolutamente orribile. Ma dopotutto Java non ha mai lavorato bene con le UI e la cosa non e’ mai stata particolarmente divertente, cosicche’ posso dire di non essere sopreso, anche se attualmente esso ha superato le mie aspettative nell’essere anche peggiore di quanto pensassi fosse umanamente possibile. L’intero processo e’ contro-intuitivo e richiede un sacco di tempo, e tutto questo per avere qualcosa che funzioni e basta. Il tutto e’ ancora piu’ dispendioso e penoso per ottenere qualcosa che non faccia schifo.

Ma questa e’ l’unica area finora che ho trovato orribile in Android. Complessivamente e’ un SDK abbastanza buono. Sicuramente non e’ divertente (almeno per me). Manca totalmente di ogni aspetto divertente. L’SDK non si toglie mai di mezzo quando voglio creare. E’ un continuo ostacolo. Non grande o insormontabile, ma sempre presente. L’SDK per iPhone, d’altro canto, e’ davvero divertente. Una volta capito l’aspetto generale di come fare le cose, e’ diventato facile per me dimenticare l’SDK e occuparmi semplicemente di creare le mie app.

Ho cercato di capire esattamente dov’e’ la differenza; che cos’e’ che rende una cosa divertente e l’altra no, e penso di averlo capito. L’SDK di Android in genere fallisce nel seguire un principio che Apple segue dannatamente bene, e cioe’:
Rendi sempre facili le cose che fai.
Come risultato, su Android le cose che tu non fai quasi mai sembrano essere ugualmente difficili e dispendiose quanto quelle che fai di continuo.

Un esempio: data la dimensione dello schermo relativamente piccola, una delle cose che fai continuamente nelle applicazioni per telefonini e’ muoverti tra le varie schermate. Nell’iPhone effettuiamo questo nella seguente maniera:

  1. Creare un’istanza della classe view controller per la vista che vogliamo mostrare
  2. Impostarne le proprieta’ per fornire i dati di cui ha bisogno per funzionare
  3. Mostrare la vista aggiungendo il view controller alla gerarchia delle viste, inserendola in una pila di navigation controller o presentandola in maniera modale, il tutto di solito in una sola linea di codice

Invece in Android questo non e’ cosi’ immediato:

  1. Aggiungere un riferimento all’Activity (l’analogo di UIViewController, anche se non esattamente la stessa cosa) nell’Android Manifest della tua applicazione per consentire ad Android di sapere quale classe puo’ essere lanciata
  2. Creare un Intent basato sulla classe dell’Activity
  3. Assicurarsi che ogni dato che si vuol passare all’altra Activity sia serializzabile oppure sia un tipo di dato di base
  4. Iniettare l’informazione che si vuol passare all’Activity come un “extra” all’Intent, serializzando gli oggetti
  5. Far partire l’Activity
  6. Nella classe dell’Activity riscrivere onActivityResult e recuperare gli extra di cui si ha bisogno, de-serializzando quelli che non sono tipi di dati nativi.
  7. Nell’Activity scavalcare il metodo onCreate() per specificare la vista che deve essere usata

In realta’ le due liste precedenti non rendono giustizia alla differenza di lavoro effettivamente impiegato. Questo compito diventa una seconda natura per lo sviluppatore iPhone poiche’ e’ intuitivo, fortunatamente. Queste sono le classiche tre o quattro linee di codice che inizi a scrivere senza neanche pensarci su. Su Android la quantita’ di cose che devi fare per ottenere lo stesso risultato e’ sparpagliata attraverso i tuoi file di progetto e il compito difficilmente puo’ diventare una seconda natura o quantomeno facile.

Ora, le persone che amano Android diranno che gli Intent sono potenti – molto piu’ che nell’approccio di iPhone – dato che gli Intent possono essere utlizzati per consentire ad altri programmi e al sistema operativo di avvantaggiarsi delle funzionalita’ del tuo programma.

In effetti gli Intent sono potenti. Il problema e’ che essi forniscono un potere di cui non hai bisogno nella maggior parte dei casi e delle applicazioni. E fanno tutto questo al costo di rendere qualcosa di cui hai bisogno tutto il tempo piu’ complicata e complessa di quel che dovrebbe essere (e quindi piu’ probabilmente fonte di bug). E’ una complessita’ indiscriminata, che non e’ una virtu’. Come OpenDoc e CyberDog possono confermare, dei concetti apparentemente buoni non sempre si manifestano in buone implementazioni o esperienze utente, e l’iPhone non ha mai sofferto molto per la sua mancanza di una funzionalita’ di condivisione tra le applicazioni.

A mio avviso, gran parte dell’SDK di Android (soprattutto le parti che non sono state pesantemente influenzate dall’SDK per iPhone) sembrano essere sovra-ingegnerizzate. Molta della complessita’ delle caratteristiche di Android sembra sia dovuta a un intento di complessita’. Quindici anni fa avrei amato tutto cio’ dato che ero nella mia fase di programmatore macho super ingegnerizzato1 e tutta quella complessita’ e la potenza teorica ad essa associata mi avrebbero fatto sentire davvero bene.

Oggi mi fa solo scuotere la testa e pensare che gli ingegneri di Google dovrebbero smetterla di mostrare quanto sono bravi e cominciare a scrivere codice elegante e complesso alla giusta maniera. Essi dovrebbero disegnare l’architettura del loro SDK con la consapevolezza del fatto che non tutti i compiti sono creati alla stessa maniera e che la semplicita’ e’, a volte, la scelta migliore in assoluto.

Ma, nonostanze la sensazione riguardo l’eleganza di Android, esso e’ senza dubbio un SDK per applicazioni mobili accettabile. Vi sono un sacco di funzionalita’ e un numero incredibile di librerie e codici di esempio su cui ti puoi basare senza dover re-inventare la ruota.

Non mi ci vedo a lavorare a tempo pieno su Android. Non mi ci vedo neanche nella ricerca attiva di lavoro basato su Android che non sia parte di un progetto piu’ grande che coinvolga un’applicazione iPhone. Ma, detto tra noi, non e’ male. A volte e’ poco elegante, inutilmente complesso e convoluto, ma e’ giovane e tutte le potenzialita’ per diventare un gran SDK.

Android decollera’? Probabilmente si’. Vi sono un sacco di telefoni Android pronti a entrare sul mercato. Le compagnie telefoniche e di telecomunicazioni amano i sistemi operativi gratuiti dato che incrementano i loro margini di profitto. E, non appena abbastanza persone disporranno di telefoni Android, allora le persone cominceranno veramente a scrivere applicazioni per tali telefoni. Non credo che si assistera’ mai allo stesso fenomeno dell’iPhone, in cui persone di tutti i generi e senza esperienza di programmazione hanno sviluppato un desiderio di imparare a scrivere software, ma credo che vi sara’ comunque un buon mercato per le applicazioni per Android e, parimenti, per gli sviluppatori Android.

Son contento di lasciare questo mercato agli altri.

1Ogni programmatore e’ passato per questa fase se ha lavorato con la programmazione abbastanza a lungo. Se tu stai programmando da un bel po’ di tempo e pensi di non essere passato per questa fase, allora vi sono ottime probabilita’ che tu ci stia proprio dentro.

i3Factoy Guitar Tuner

i3Factoy Guitar Tuner

Disponibile sull’ apple store un nuovo Guitar Tuner firmato i3Factory.

Segui Link Guitar Tuner i3F in Apple Strore

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close