di  -  mercoledì 19 settembre 2012

Web VS Apps… ovvero: Libertà totale di sviluppo e compatibilità quasi assoluta VS Applicazioni device oriented con focus al 100% sull’uso che se ne fa.
Vantaggi del web:

1)i prodotti (siti/webapp/ria… i nomi si sprecano ormai) sono potenzialmente fruibili da chiunque con qualunque dispositivo

2)I siti, usando i webservices, possono interagire con praticamente qualunque cosa 3)Chiunque può sviluppare un sito web a costo 0, usando strumenti gratuiti

Svantaggi del web:

1) “troppa libertà di sviluppo”: 100 siti potranno avere 100 GUI diverse, molte delle quali probabilmente non saranno compatibili con tutti i dispositivi che vi accedono.

2)I siti web solitamente non sono ottimizzati per essere usati su un dispositivo mobile… Diciamo che ci sono versioni compatibili, ma che non possono sfruttare al 100% il dispositivo mobile che vi accede. Questo è il prezzo da pagare per l’universalità del protocollo.

Vantaggi delle app:

1)Consente di garantire una esperienza utente di qualità maggiore, potendo sfruttare al 100% le potenzialità del dispositivo di interfaccia e dell’hardware.

2)Prestazioni generalmente superiori (l’interfaccia gira sul dispositivo, solo i dati vengono caricati/scaricati).

Svantaggi delle App:

1)Incompatibilità tra sistemi diversi – Questo limita di molto la libertà di scelta dell’utente quando considera la migrazione ad altra piattaforma: l’app acquistata vale solo per lo store di riferimento, per cui se si cambia SO l’applicazione va acquistata di nuovo

2)Sviluppare applicazioni può costare per acquistare i kit di sviluppo e/o le licenze di accesso agli store come sviluppatori)

3)Le applicazioni possono accedere a una gran parte delle funzioni del telefono, per cui non si sa realmente a cosa accedano, che dati raccolgano e a chi li inviano.

Questi sono realmente gli elementi della bilancia: Html5 cerca di combattere efficacemente le App ma ovviamente risente di tutti i difetti dei siti web: prestazioni inferiori del codice nativo compilato per iniziare, e rischi di incorrere in interfacce inaccessibili dall’altro lato; di contro però è più che sufficiente per sviluppare il 95% delle applicazioni disponibili, giochi a parte (sono molto più complicati da sviluppare in Html5).
Io però voglio porre un’altra questione: L’accessibilità (orientata alle persone disabili) per le App… Come siamo messi?

4 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    ReaToMe
     scrive: 

    HTML5 è draft. Quale è il codec per i video?

  • # 2
    michelangelog
     scrive: 

    io a febbraio ho quasi due anni di esperienza di sviluppo html per il settore mobile, e aggiungo alcune considerazioni sulle performance.
    Su android e ios il motore javascript è piuttosto veloce, a parte un leggero sovraccarico iniziale le ottimizzazioni che fa il jit non sono poi così inferiori alle applicazioni native, e questo su android è ancora più vero.
    Il vero collo di bottiglia è l’html e di preciso la manipolazione del dom. Lato css, ombre, gradienti e trasparenze rallentano talmente tanto che se proprio ne avete bisogno fatelo con un jpeg.
    Mettere immagini in base64 nei nodi è una pessima idea.
    Spostare, appendere, eliminare nodi è un altra azione molto lenta, se dovete farlo fatelo in fase di prerenderizzazione della pagina, un innerhtml spesso è più veloce dei vari append.
    Le librerie non sono ottimizzate, una che va per la maggiore come jquery mobile si basa su jquery che ha dentro pure roba per ie6, le dimensioni contano la memoria è poca, usate altro.
    Le trasformazioni css3 sono fatte in hardware su ios recenti (>4) e su android (>2.3.3) queste sono piuttosto efficienti e si possono ottenere interessanti effetti di movimento, rotazione, ridimensionamento.
    Così efficienti che qualcuno ci ha fatto pure dei giochi, ma scordatevi le collisioni pixel perfect.
    é possibile sfruttare file storage e sql con alcune limitazioni ma ci sa fa velocemente il callo.
    Si può andare sugli store wrappando tutto con phonegap, il limite più grosso e su ios, invece di avere il motore javascript superotimizzato di safari le app che utilizzano una webview generica (come i browser web di terze parti, incluso chrome per ios) usano un motore javascript dato con webkit che non è il v8 si chiama corejavascript engine e non è molto performante, non raggiunge i livelli di v8 ne di nitro di safari per ios, più che motivi tecnici c’è la volontà di tenere il loro prodotto più performante e mettere dei paletti alle applicazioni ibride.
    Il canvas sfortunatamente è molto lento sia su ios che su android, praticamente inutilizzabile si ottengono solo bassisimi fps. (nei miei test cone easel.js da 6 a 12).
    Per le persone disabili si possono utilizzare alcuni trucchi come abilitare lo zoom sull’interfaccia o meglio ancora usare un altro foglio di stile, io ritengo che ci siano poche tecnologie assistite, specialmente su ios e che il mercato non fornisca margini utili per implementare particolari accorgimenti a livello applicativo.
    Per lo sviluppo di interfacce native cercando di restare cross platform si può citare sicuramente
    Appcelerator Titanium, widget nativi, logica in javascript, accesso ai db che si appoggia su api native, quindi zero limiti e molto veloce, unica pecca solo ios e android e android è un cittadino di seconda categoria, ma il framework è gratuito è può dare delle soddisfazioni, c’è anche un modulo open per lo sviluppo di videogiochi che si basa su opengl ma ha un occhio solo per i giochi 2d al momento.
    Su kivy non mi esprimo ma ne seguo lo sviluppo fare app crossplatform android e ios in python e il mio sogno proibito, ma il progetto è ancora troppo giovane. (e il processo di build su ios è qualcosa di terribile)
    Se lo sviluppo è fatto bene si può riusare molto della logica e delle classi di una web app con titanium, l’importante secondo me è scrivere una webapp già pensata come servizio ossia tipicamente un rest per l’interfaccia ai dati scritto server side, e un interfaccia javascript-html per tutto il resto e un adattamento come app con phonegap o con titanium, per i rest vedo bene: flask o bottle (python), sinatra (ruby) o slim (php) che sono quelli che ho provato personalmente flask è il più completo, slim si può installare pure su host a costi minimi (tipo aruba o tophost) ma ovviamente si deve fare i conti con la banda.
    Bottle è un singolo file e non richiede installazioni. (ma per le sessioni si deve guardare altrove).
    Quale è la differenza?
    secondo me solo sulla singola app si può decidere quale sviluppo seguire, un applicazione come:
    “BBC Olympics” è stata fatta con html5 e phonegap e gira su ios, android e blackberry e non è una schifezza anzi è una signora applicazione.
    Quindi dipende molto, la strada di quello che vogliamo chiamare “html5″ essendo giovane e poco battuta se si esce un minimo dalle soluzioni precotte si rischia di non trovare supporto, ma con l’avvento di firefox os alle porte e la possibilità di essere crossplatform a costi contenuti non è certo una strada che si può scartare senza motivi validi.

  • # 3
    Christian
     scrive: 

    Bravo, e adesso noi cosa scriviamo?

    Comunque non sono molto d’accordo su gradienti, trasparenze, css e base64, che specie gli ultimi ti permettono di ridurre le richieste e sono un vantaggio per piccole immagini.

    Non sono d’accorco perché su piccoli schermi devi scegliere cosa mettere e sono poche le cose che non si possono fare restituendo un’esperienza positiva all’utente. Io sono convinto che l’editoria abbia preso una strada sbagliata distribuendo i quotidiani in pdf. Il giornale ad es. Lo abbiamo sempre letto a colonne e pure in modalitá ritratto gli schermi sono leggermente più larghi delle colonne sulla carta stampata.

    In questo settore perciò le App potrebbero perdere peso in favore di HTML e ne deriverebbe anche un vantaggio economico per gli editori che oltre a ridursi le versioni da realizzare si sottrarrebbero al modello agenzia.

    Per i video il vero problema mi sembra che sia il costo della banda, per il resto la semplicità è sempre un valido aiuto. Concordo in pieno sulle librerie.

  • # 4
    michelangelog
     scrive: 

    Io stavo parlando ovviamente di nodi che muovi, se lo tieni li bellino fermo e buono come pure elemento decorativo questi problemi non ci sono ;-) se invece lo sposti, lo cloni, etc.. il peso si sente.
    Invece di utilizzare il base64 preferisco usare una “tilemap” con tutti gli asset e usare il background size e il posizionamento verticale e orizzontale nel css, ci sarebbe altro da aggiungere, almeno menzionare librerie minimali come zepto.js che un aiuto lo danno, è un mondo molto vasto e in continuo fermento ed evoluzione, quindi per me la strada dell’HTML5 sul mobile non si può scartare a priori, anzi!!!

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.