Potete leggere l’articolo completo qui.

E potete scaricare l’esempio da qui.

Utilizzare il Global Exception Handler è estremamente conveniente ma non deve essere una scusa per non gestire quando possibile le eccezioni. E’ bene gestire sempre le eccezioni dalle quali si può recuperare uno stato consistente dell’applicazione, e riservare l’utilizzo del gestore globale a quelle situazioni inaspettate che causerebbero problemi seri all’applicazione.

“Spesso, durante lo sviluppo di applicazioni Flex, ci siamo trovati ad utilizzare il component ComboBox per consentire la selezione di un elemento da una lunga lista di oggetti. Quando, però, i dataProvider assegnati alle combo box contengono molti elementi è scomodo utilizzare il component ComboBox e obbligare l’utente a ricercare l’elemento di interesse costringendolo a scorrere tutta la lista.

In sostituzione delle combobox possiamo utilizzare un component molto potente chiamato AutoComplete, che consente di gestire il riempimento di un campo di testo filtrando il dataProvider in stile Facebook.”

Per approfondire clicca qui.

E’ stato pubblicato su Html.it un mio articolo su Bark, un framework per la gestione dei messaggi all’utente di una web application senza utilizzare i fastidiosissimi popup.

E’ disponibile anche l’esempio: basta cliccare qui!!!

Apple, nel comunicato rilasciato il 9 Settembre, ha ridefinito gran parte delle linee guida per lo sviluppo di applicazioni mobile consentendo agli sviluppatori di utilizzare i tool di sviluppo che preferiscono, pur mantenendo delle stringenti constrains per quanto riguarda la sicurezza.

Gli sviluppatori Adobe hanno ricevuto una gran bella notizia, così come afferma un recente post sul blog ufficiale di Adobe stessa.

A mio avviso, un altro motivo (di sottofondo e non dichiarato) per cui Apple ha deciso di riaprire le porte dell’Apple Store riguarda la sicurezza delle applicazioni che sono hostate sullo store della mela. E’ vero che le applicazioni sono controllate prima di essere pubblicate ma di certo Apple non ha fatto una bella figura con l’applicazione Handy Torch che, oltre ad essere una semplice torcia, permetteva di approfittare del tethering della connessione wi-fi senza pagare una tariffa aggiuntiva (espressamente vietato negli Stati Uniti dall’unico concessionario iPhone).

In fin dei conti questa è una situazione che, se non risolta completamente, si avvia ad una rosea soluzione!

In questo articolo è presentata “solo” la libreria e non vengono illustrate le regole da seguire per poter scrivere correttamente i test delle nostre applicazioni!

La libreria

JUnit è un progetto open source gestito da Kent Beck e scaricabile all’indirizzo http://github.com/KentBeck/junit/downloads.

Mettiamoci all’opera

Quando si vuole testare il funzionamento di una classe, è necessario scrivere un’altra classe (!) che, per convenzione, viene sempre chiamata con lo stesso nome della classe da testare più il suffisso “Test”.

Supponiamo di avere una classe MathOp (di seguito) che svolge le operazioni di addizione e sottrazione, e di voler scrivere lo unit test.

Come accennato prima, è necessario creare un’altra classe, che deve essere chiamata MathOpTest. Per utilizzare la libreria JUnit è necessario aggiungerla al build path del progetto (lo si può fare direttamente dalle preferenze del progetto di Eclipse, ad esempio).

Importare le classi di JUnit

Per utilizzare i costrutti JUnit per effettuare le asserzioni sui risultati dei metodi è necessario importare, prima di tutto, la libreria e importare staticamente le classi del package org.junit.Assert:

La classe di test

A questo punto siamo pronti per scrivere la classe di test. Per indicare a JUnit quali sono i metodi che effettuano i test è necessario contraddistinguerli con l’annotazione @Test. In questo modo JUnit riconoscerà i metodi che contengono le asserzioni e li tratterà di conseguenza.

Le asserzioni

Con JUnit è possibile effettuare diversi tipo di test (con asserzioni diverse). Al momento dell’esecuzione, un test si considera superato se tutte le condizioni specificate risultano verificate.

• assertEquals(expected, actual), assertArrayEquals(expected, actual) : richiede che il valore ‘expected’ sia uguale a ‘actual’
• assertTrue(cond): richiede che ‘cond’ abbia come valore: ‘true’
• assertFalse(cond): richiede che ‘cond’ abbia come valore ‘false’
• assertNull(obj): richiede che ‘obj’ sia un riferimento nullo
• assertNotNull(obj): richiede che ‘obj’ sia un riferimento non nullo

@Before

Nell’esempio precedente, in ognuno dei due test case è stato istanziato un oggetto MathOp. JUnit mette a disposizione degli sviluppatori una funzionalità per eseguire delle istruzioni prima che vengano eseguiti i test. Il metodo setUp() ha un’annotazione @Before che serve ad indicare a JUnit che il metodo va eseguito prima dell’esecuzione dei test case. In questo modo, il codice per inizializzare oggetti o risorse (ad esempio una connessione al DBMS) è concentrato in un solo punto della classe di test.
Analogamente a @Before, l’annotazione @After indica a JUnit di eseguire il metodo dopo l’esecuzione dei test case.

Lanciare i test

I test possono essere lanciati direttamente da Eclipse selezionando la classe di test e cliccando su “Run as” -> “JUnit Test”.
E’ possibile utilizzare anche la linea di comando o i task junit e junitreport di Apache Ant.

Di seguito uno screenshot dei risultati del test in Eclipse:

I due test hanno avuto entrambi esito positivo! Nel caso si verifichino errori verranno conteggiati alla voce Errors, mentre le condizioni non verificate saranno conteggiate alla voce Failures.

Conclusioni

In questo articolo è stata fatta una semplice introduzione alla libreria, che dovrebbe essere utilizzata in ogni progetto software sviluppato in Java per garantire il test automatico del codice sorgente.
Per approfondimenti vi rimando al sito http://www.junit.org/.

Ma veniamo al vero scopo dell’articolo: tentare di fare un paragone tra i due linguaggi, anche se un vero e proprio confronto non è possibile.

Le origini

Java nasce come linguaggio totalmente ad oggetti, con una struttura solida e con il chiaro obiettivo di essere un linguaggio portabile, non legato al sistema su cui deve essere eseguito.
Php, invece, nasce come linguaggio di scripting totalmente procedurale, con lo scopo di fornire uno strumento per sviluppare velocemente pagine web dinamiche.

Il tipo dei dati

Java è un linguaggio strongly-typed: per ogni variabile deve essere dichiarato il tipo. Php invece è un linguaggio weakly-typed: non è necessario dichiarare il tipo delle variabili e il riconoscimento del tipo viene effettuato a tempo di esecuzione.

La vita degli oggetti

La durata della vita degli oggetti è il limite più grande di Php, poichè un oggetto “muore” quando termina l’esecuzione di uno script. Non esiste, in Php, il concetto di scope degli oggetti!
In Java, invece, è possibile decidere quanto un oggetto deve vivere:

• Page: gli oggetti sono accessibili solo all’interno della pagina in cui sono stati creati, e vengono distrutti alla chiusura della pagina.
• Request: gli oggetti sono accessibili esclusivamente nelle pagine che elaborano la stessa richiesta; l’oggetto resta in vita anche se la richiesta viene inoltrata ad un’altra risorsa.
• Session: gli oggetti sono accessibili solo alle pagine che elaborano richieste all’interno della stessa sessione di quella in cui l’oggetto è stato creato; alla chiusura del browser vengono distrutti.
• Application: gli oggetti sono accessibili alle pagine che elaborano richieste relative alla stessa applicazione; gli oggetti vengono distrutti quando il server viene spento o riavviato.

Ad esempio, Hibernate (ORM in Java) permette di effettuare un object mapping del database. In Hibernate la gestione del pool connessioni al db è effettuata con una SessionFactory che viene istanziata all’avvio dell’applicazione web e il cui ciclo di vita è lungo quanto quello dell’intera applicazione. In questo modo è necessario effettuare il parsing dei file XML che descrivono il mapping del database solo all’avvio dell’applicazione e non ad ogni richiesta che viene effettuata dai client. Con Php non è permesso gestire in questo modo gli oggetti! E come dicevo prima: questo è, secondo me, il più grande limite di Php.

L’architettura delle applicazioni

Php è un linguaggio semplice e, come tale, non impone agli sviluppatori di seguire una struttura ben precisa per lo sviluppo di un’applicazione web. Molte volte, data anche l’inesperienza dello sviluppatore, il codice prodotto è impossibile da riutilizzare: la logica è mischiata alle interfacce grafiche, non esiste un livello di interazione con il database ma le query sono fatte direttamente nel codice della business logic, ecc…
Java, al contrario, impone agli sviluppatori di seguire una struttura ben precisa: la logica applicativa va racchiusa nelle classi HttpServlet mentre la visualizzazione dei risultati deve essere effettuata attraverso le pagine JSP.
Java consente “nativamente” di separare la logica dalla visualizzazione, mentre in Php ciò è riservato all’esperienza e alle capacità del programmatore.

Velocità di sviluppo

Php, data la sua struttura e le sue caratteristiche, permette di sviluppare velocemente applicazioni web. Per visualizzare una semplice pagina dinamica è possibile scrivere anche un solo file “.php” e il gioco è fatto.
Per quanto riguarda Java, invece, le cose sono più complicate. Per prima cosa è necessario creare una classe che estende la classe HttpServlet (che si occupa di gestire la richiesta) di cui bisogna implementare i metodi doGet e doPost e poi bisogna mappare la servlet su di un url all’interno del file web.xml. Per visualizzare i risultati dell’elaborazione bisogna creare un file “.jsp” e legarlo alla servlet.

Conclusioni

Come avete potuto notare, Java e Php sono linguaggi completamente diversi e, quindi, aver tentato un paragone è stata una mossa un pò azzardata. Lo scopo non era quello di confrontare (nel vero senso della parola) e quindi scegliere il linguaggio migliore. Php e Java nascono per scopi diversi anche se ultimamente l’evoluzione di Php sta tendendo verso Java. Scegliere il linguaggio migliore non è possibile, almeno non è possibile farlo semplicemente.
C’è da dire che in ambito enterprise, Java è preferito a Php per la quantità di strumenti, framework e librerie disponibili sia a pagamento che open source e anche per il modo nel quale sono gestiti gli oggetti (Java in questo è molto più potente).
Java e Php sono i linguaggi per lo sviluppo web più utilizzati, ognuno ha delle potenzialità specifiche e la scelta di uno dei due deve essere fatta al momento valutando l’applicazione da sviluppare e le caratteristiche che essa deve presentare.

Per leggere l’articolo su Html.it clicca qui!

A questo punto, abbiamo maturato la decisione di utilizzare un framework MVC (Model View Controller), che ci permettesse di garantire il minimo accoppiamento tra i moduli, in modo da rendere il software riutilizzabile ed estendibile.
Dopo alcune ricerche, abbiamo ristretto il campo di decisione su PureMVC e Cairngorm, che sono i framework più utilizzati per lo sviluppo di rich internet applications in Flex.

Cairngorm
pro:

• è sviluppato da Adobe
• sono disponibili molte risorse

contro:

• non segue la metodologia DRY (don’t repeat yourself)
• bisogna scrivere molte classi per implementare una sola funzionalità

Lo svantaggio più grande di questo framework è la scrittura di molte classi per l’implementazione di una singola funzionalità. Inoltre, molto codice viene riscritto e ripetuto e, quindi, il software è molto soggetto alla presenza di bugs.

PureMVC
pro:

• è scritto come framework per Flex, Flash e Air
• la documentazione e gli esempi sono molto chiari

contro:

• per gli sviluppatori è necessario utilizzare un sistema di segnalazione diverso da quello nativo di Flex

Le classi da scrivere per implementare una funzionalità sono in numero minore rispetto a Cairngorm. Inoltre, PureMVC implementa un sistema di comunicazione tra i livelli basato sull’invio di messaggi, detti Notification, tra i component. Da questo punto di vista è assicurato un basso livello di accoppiamento tra i moduli. Seguendo le best practices illustrate nella documentazione del framework, il codice risulta molto chiaro e pulito.

In conclusione

Abbiamo scelto PureMVC e non siamo pentiti della nostra scelta. Anzi, siamo veramente entusiasti del framework e della rapidità con cui stiamo sviluppando le applicazioni. Il riutilizzo del codice ha raggiunto il massimo livello in azienda: basti pensare alla funzionalità di login che abbiamo sviluppato una sola volta e che ora stiamo usando in tutti i nostri progetti.

“FlexUnit è un framework per unit testing per ActionScript 3.0 e Flex e permette di eseguire i test attraverso un test runner grafico.
Per utilizzare FlexUnit, dobbiamo creare un’applicazione dedicata all’esecuzione dei test: l’applicazione deve sfruttare un component di tipo TestRunnerBase per l’esecuzione dei test unitari.”

Continua la lettura dell’articolo completo…