Android e il mito dei task killer

Oggi mi sono appena ricordato di avere ancora un blog dove poter scrivere, condividere idee, esperienze e informazioni.
La mia esperienza come sviluppatore Android è aumentata notevolmente e devo ammettere che il sistema operativo di Google dedicato ai dispositivi mobili (mentre scrivo queste righe alla versione 4.2.x) ha raggiunto livelli accettabili rispetto alla concorrenza, e soprattutto rispetto alle versioni precedenti dello stesso.
Aspettatevi quindi una valanga di articoli e consigli per trick, approfondimenti, delucidazioni e casi di studio in merito al sistema e su come impostare e sviluppare adeguatamente applicazioni Android.

Ora basta con le sviolinate e concentriamoci sull’articolo di oggi che vuole prefiggersi altro. Infatti la motivazione della stesura di queste righe riguarda tutte quelle applicazioni che circolano da tempo e che istigano gli utenti a quello che io chiamo un vero e proprio “appicidio”, ovvero la pratica di killare (uccidere) applicazioni che Android mostra dalla lista dei processi. Sto pensando davvero di sviluppare la InvestigationApp per arrestarle tutte 😀 :D.

Scherzi a parte la premessa sulla gestione della memoria di Android è doverosa:
come tutti sappiamo i dispositivi che montano Android sono alimentati da batteria, pertanto tale sistema operativo è stato progettato per un consumo minimo dell’energia, al contrario dei sistemi operativi desktop, i quali assumono che il dispositivo sia connesso perennemente all’impianto elettrico domestico o industriale che sia, Android fa del suo meglio per gestire la memoria RAM in modo da mantenere i consumi al minimo.

Quando una Android app non è più in uso il sistema la mette in “suspend”, cambia quindi lo stato dell’applicazione, questa informazione aiuta il gestore della memoria a capire cosa deve fare quando si trova in condizioni critiche. Di fatti il processo relativo ad una app sospesa è tecnicamente aperto, ma sostanzialmente non sta consumando risorse poiché l’utente non sta utilizzando quell’applicazione. Tecnicamente infatti l’applicazione è sospesa in un limbo finché l’utente non ne richiederà di nuovo l’utilizzo.
Oltre che ottimizzare la gestione in termini di spazio e di consumo della memoria, tale approccio apporta benefici in termini di tempi di risposta ai comandi impartiti dall’utente, poiché le app non hanno bisogno di essere riaperte ogni volta che l’utente le richiede. Il picco di consumo si ottiene solo la prima volta che l’utente richiede l’utilizzo di un’applicazione.

Inoltre Android gestisce le app in memoria automaticamente: ad esempio se la memoria disponibile dovesse essere troppo bassa, il sistema operativo di sua iniziativa comincerà a “killare” le applicazioni che l’utente non usa da più tempo, o meglio che sono rimaste inattive!!

Tale fase di gestione della memoria è invisibile all’utente e questo cari lettori è l’unico motivo valido per cui mi spiego possano esistere le forzose killapp :).

Come molti stenteranno a credere, un uso massiccio delle app task killer può far degenerare il sistema, infatti molti utenti presi dalle buone intenzioni di voler liberare la memoria e killare continuamente delle app in realtà non sanno che stanno dicendo al sistema di mettere quella app nello stato “mai aperta” costringendo il sistema operativo a gestire ogni volta la fase di creazione della app in memoria (come se fosse stata aperta per la prima volta) scatenando un consumo di risorse in termini di I/O, CPU e batteria ingente.

Insomma se quella app vi serve state pur certi che non vale la pena killarla lasciate fare ad Android ci penserà lui.

Nello stesso discorso rientrano anche le app che fanno uso dei servizi in background, ma per questa tipologia di applicazione c’è da fare sicuramente una serie di precisazioni, al più presto fornirò un articolo in merito.

A presto

NonSoLo1x

Annunci

Experience with Google Web Toolkit

Salve a tutti,

questo articolo si propone di condividere la mia esperienza con questo strumento messo a disposizione dalla grande G, nel corso delle sue evoluzioni con l’obiettivo di trasmettere pro e contro (difficile trovarne..) di questo potente tool.

-cos’è GWT ??

Il primo errore che ho commesso nel valutare il Google Web Toolkit è stato considerarlo un framework, (WARNING) , GWT non è un framework, bensì un insieme di strumenti che permettono lo sviluppo,  la manutenzione e il debugging di grosse applicazioni Javascript/AJAX. Infatti esistono quelli che possiamo definire dei veri e propri framework basati (chi più, chi meno) su GWT.

Parliamoci chiaro: a chi è che piace programmare in Javascript? Considerando specialmente aspetti come il debugging e la manutenzione non è una passeggiata, soprattutto se si proviene da una realtà come Java(SE o EE) andare su Javascript è come tornare alla preistoria.

Un primo punto di forza di questo strumento (e credo il fondamentale) è la possibilità di sviluppare le applicazioni attraverso il linguaggio Java portando con sè tutti i suoi vantaggi già affermati al giorno d’oggi specialmente per il packaging , la manutenzione,  per non parlare della facilità dei processi di sviluppo del software, che la tecnologia Java mette a disposizione.

Un altro problema del linguaggio Javascript e la tecnologia AJAX annessa, è la portabilità che i vari browser rendono sempre più difficile, il principio write once, run everywhere motto di Java viene propagato da GWT grazie al grosso lavoro del team di sviluppatori di questo toolkit che ha reso la vita facile a tanti altri sviluppatori.

Veniamo a noi:

Innanzitutto voglio premettere che non sono un “filoGoogle” d’altro canto bisogna dare a Cesare quel che è di Cesare, e Google merita un bel 10 su 10 se consideriamo aspetti come: portabilità del software, potenzialità del web, modelli di sviluppo. Su questo ed altro il tool di Google offre ampia versatilità ma allo stesso tempo riesce a dare all’utente poco esperto la consapevolezza delle potenzialità del web.  GWT si propone come un tool completo per scrivere e debuggare applicazioni: web come lo fa? Ti fa scrivere codice Java e te lo compila in Javascript. Un altro, a mio avviso, grosso errore che commettono molti utenti (me compreso) è di considerarlo un semplice compilatore, in realtà il compilatore è il cuore di GWT e fa parte dell’insieme di strumenti offerti per gestire: creazione di interfacce grafiche stile web2.0, modalità di deploy dell’applicazione, controllo del download delle risorse, ottimizzazione del codice.

Inoltre il Google Web Toolkit, offre delle API per sviluppare anche la parte server della nostra applicazione. L’invocazione della parte server è basata su chiamate RPC il cui protocollo è trasparente allo sviluppatore nel senso che non deve conoscere i dettagli del payload HTTP o dell’header, il tutto continua ad essere sviluppato in Java. Inoltre la parte server si appoggia alla specifica Servlet già ampiamente diffusa e conosciuta sul mercato.

Possibili svantaggi di GWT si possono ricondurre ad una vera e propria dipendenza dal tool che a mio avviso dovrebbe essere evitata creando disaccoppiamenti applicativi o con la consapevolezza di cosa si sta utilizzando e perché.

A presto.

NonSoloUniX

 

 

 

Ajax o non Ajax questo è il problema…

Ultimamente mi sto imbattendo in molti progetti con tecnologia Ajax (Asynchronous Javascript and Xml), una tecnica molto utilizzata ultimamente per creare applicazioni web-2.0, stile applicazioni stand-alone. Molte applicazioni quali Facebook, Gmail, e tante altre sfruttano questa tecnica per implementare le lo funzionalità, ma ci si sta imbattendo sempre di più nel solito problema: qua ognuno fa come vuole.

La nascita di Ajax è dovuta soprattuto al fatto che molti browser, oggi la maggior parte, mettono a disposizione una funzionalità per creare richieste http, la peculiarità di Ajax sta nel fatto che queste richieste Http sono state rese asincrone, per farla breve quando accedete ad un sito in realtà state facendo una richiesta Http richiedendo ad un server di fornirvi la pagina che avete appunto richiesto, quando il server esaudirà la vostra richiesta il vostro browser prenderà in carico la risposta e la processerà interpretando l’html restituito. Ora immaginate se al clic di un qualsiasi pulsante di questa pagina appena scaricata venisse innescata una nuova richiesta http e che la risposta di tale richiesta modificasse una porzione della pagina che avete inizialmente scaricato senza dare all’utente la percezione di quel fastidioso refresh… in realtà tutto ciò funziona perché la richiesta è asincrona e il browser non si mette in attesa della risposta dando la possibilità all’utente di poter fare altro.

Ma come mai Javascript and Xml? Javascript è un linguaggio di programmazione messo a disposizione dalla maggior parte dei browser ed è tramite questo che è possbile creare richieste http e processare le risposte, in una risposta il server potrebbe piazzare qualsiasi contenuto ma per la tecnica Ajax è stato usato spesso XML e poi per renderlo ancora più veloce JSON che sta per JavaScriptObjectNotation, è infatti come dice la parola, un modo per definire oggetti con notazione Javascript. Con entrambi è possibile definire qualsiasi tipo di protocollo per processare le risposte ricevute nella nostra web-application.

Bene, ora che avete capito cos’è Ajax, possiamo svelare quelle che non sono come sempre tutte rose e fiori. Come già accennavo prima prima purtroppo, non esiste ancora uno standard ben preciso di supporto allo sviluppo di applicazioni del genere, nè tanto meno esiste uno standard per i browser su come mettere a disposizione un oggetto XHR (XmlHttpRequest) e al momento chi vuole imbattersi in sofisticate applicazioni Ajax da solo dovrà gestire numerose casistiche dettate dai diversi comportamenti dei browser.

Questo articolo termina qui e sarà di spunto per molti altri articoli che cercano di spiegare come ad oggi sono stati risolti molti problemi, come l’utilizzo di svariati framework ajax, e le varie architetture messe a disposizione, inoltre verrà dedicato un articolo alla predisposizione della comunità verso nuovi standard rivolti verso questa che al momento possiamo solamente chiamare tecnica di programmazione.

Saluti

NonSoloUnix

Eclipse come editor HTML,PHP,CSS

Ritorniamo su Eclipse, famoso IDE per los viluppo di applicazioni JAVA e non solo!!!

A volte di questo IDE viene sottovalutata la sua qualità di essere un OPEN IDE. Infatti una delle caratteristiche più interessanti di Eclipse è quella della estendibilità dell’applicazione attraverso dei Plugin che sfruttano le caratteristiche di quello che risulta già essere un editor con altre, più particolari che lo rendono più specifico a seconda dell’utlizzo che vogliamo farne.

In questi giorni ho voluto provare Eclipse come tool di sviluppo per siti web, e sono rimasto davvero soddisfatto dalla cosa, ovviamente sto parlando di plugin open-source, ce ne sono di altri commerciali molto ben fatti, ma con questo qui che vi sto per presentare si possono fare già la maggior parte delle cose.. e avere il tutto aggratise mi sembra un buon compromesso!

Per chi non avesse Eclipse può scaricarlo da qui

Per sistemi operativi Ubuntu si può installare dando il comando “sudo apt-get install eclipse” , ma consiglio di scaricare sempre l’ultima versione aggiornata dal sito ufficiale.

Ora vediamo come installare il plugin:

Una volta aperto Eclipse andiamo nel Gestore aggiornamenti da Help->Software Updates->Find And Install

Clicchiamo su “Search for new features to install” e andiamo avanti.

Alla nuova schermata clicchiamo su “New Remote Site” e inseriamo il seguene link http://update.phpeclipse.net/update/stable/1.2.x

Confermiamo tutto selezioniamo la nuova sorgente e proseguiamo con l’installazione del plugin seguendo le semplici istruzioni a video, tenendo presente che quando ci chiederà di selezionare cosa installare noi spunteremo tutto.

Se tutto è andato a buon fine avete appena instalalto il PHP-Plugin. Non fatevi trarre in inganno dal nome del plugin perchè in realtà c’è molto di più di un semplice editor php, ma anche un editor html, un editor css, la gestione di progetti per un intero sito, l’avviatore per il server mysql e per il server Apache.

Inoltre i vari editor dispongono delle rispettive funzioni di completamento automatico durante la scrittura dei vostri programmi php o di codice html… e se voglio vedere l’output delle mie modifiche a volo?? Niente paura, il browser interno ad Eclipse non vi farà perdere la percezione di utilizzare un unico tool per il development del vostro sito… Quindi non mi resta che augurarvi buon lavoro e non esitate e dirmi la vostra dopo averlo provato!

Plugin PHP Eclipse

JavaFX: Swing un pò più facile…

Mi addentro nei meandri del sito Sun Java come ogni settimana e mi ritrovo un piccolo link nella side bar destra… “JavaFX”. Mi chiedo cosa sarà mai? Come ho fatto a non vederlo prima? (Sinceramente non so questo progetto da quanto tempo esiste…).Mi cimento in una traduzione istantanea di un breve Getting Started e cosa mi ritrovo? Un altro linguaggio by Sun che potrà essere integrato alle applicazioni Java per sviluppare interfacce Swing.

A mio avviso non è malvagia l’idea di separare lo sviluppo della parte grafica, specie se questa separazione è tra virgolette “imposta” dal linguaggio stesso. C’è da dire però che Sun ha precisato che JavaFx non vuole essere un rimpiazzo a Swing ma soltanto uno strumento rivolto ai programmatori per facilitare lo sviluppo di interfacce grafiche…

Capitolo performance: Sun alla domanda “performance?” risponde: JavaFX oltre a poter creare Frame Pannelli etc. vuole anche essere di beneficio alle applicazioni che lo useranno …. come? Il gestore del dispatching degli eventi e della loro creazione sarà ottimizzato per JavFX e tutte le GUI sviluppate attraverso questa tecnologia ne beneficeranno…

Intanto scopro anche che JavaFX potrà essere utilizzato per sviluppare delle RIAs (Rich Internet Applications), alla stregua di Adobe con Flex se ho capito bene, solo che JavaFx (suono di trombe e tamburi: tattarataaaa) è OpenSource!!! 😀 A sposare questa tecnolgia ben presto arriverà JavaFx Mobile … il nome dice già tutto!!!

Intanto mentre corro subito a provare questo linguaggio di scripting beccatevi questa:

Una riproduzione parziale del sito di Motorola con JavaFx