Dopo aver completato la Component Gallery e aver testato altre classi messe a disposizione dalla libreria di RIM (ad esempio, trovo veramente notevole la coppia PersistentStore / PersistentObject per memorizzare oggetti Java generici nella memoria del dispositivo), ho iniziato lo sviluppo di una vera applicazione per BlackBerry. Vi voglio anticipare solo che le funzionalità sono in ambito bancario e che appena completata sarà liberamente scaricabile.
Abbiamo completato la registrazione e la configurazione di tre nuovi domini Internet relativi alla Performance Attribution, cioè www.performanceattribution.it, www.performance-attribution.it e www.performance-attribution.com. Per il momento li abbiamo fatti puntare tutti sul sito Web di DataFox, tuttavia stiamo studiando altre soluzioni, in particolare la realizzazione (con Joomla! 1.5, in modo da sfruttare le nostre competenze su questo CMS) di un sito Web con contenuti e approfondimenti specifici su questa tematica.
martedì 30 settembre 2008
domenica 28 settembre 2008
Nuova versione della Component Gallery per BlackBerry
Come avevo promesso qualche post fa, ho completato la Component Gallery con i componenti grafici del BlackBerry e questa volta penso di averli utilizzati tutti, o quasi. Il file aggiornato è scaricabile qui e, come il precedente, contiene sia i sorgenti che i file di supporto per il JDE di Eclipse.
In questa nuova versione sono presenti due Screen diversi e per passare dal primo al secondo è sufficiente cliccare sul pulsante presente nella prima schermata. Il primo (visibile nella figura seguente) è lo stesso della versione precendente, a cui è stato aggiunto un Field custom che disegna un rettangolo colorato.
Il secondo (visibile nella figura successiva) è quello più interessante, in quanto mette alla prova i seguenti componenti:
Per quanto riguarda il ListField, ho creato una sottoclasse ad hoc, MyListField, in modo da poter intercettare gli eventi generati dalla trackwheel e dalla tastiera e per associare a questo componente un menù custom. Quindi, quando il focus è su questo componente e si preme il pulsante che apre il menù, appare una nuova voce creata da codice.
Il TreeField è interessante in quanto con il metodo addChildNode si aggiungono nodi all'albero e con il metodo drawTreeItem (definito in un'apposita interfaccia richiamata dal Framework) si vanno invece a disegnare sullo schermo. In tal modo si è ottenuta la separazione fra dati e presentazione (model e view) e risulta più facile personalizzare l'aspetto grafico dell'albero.
Prima di concludere, vi segnalo che sul sito di DataFox, nella sezione Corsi di Formazione, sono presenti i programmi dei nuovi corsi, come il Corso su Joomla! 1.5, il Corso su PHP e MySQL, il Corso di programmazione base e il Corso di Programmazione ad Oggetti.
In questa nuova versione sono presenti due Screen diversi e per passare dal primo al secondo è sufficiente cliccare sul pulsante presente nella prima schermata. Il primo (visibile nella figura seguente) è lo stesso della versione precendente, a cui è stato aggiunto un Field custom che disegna un rettangolo colorato.
Il secondo (visibile nella figura successiva) è quello più interessante, in quanto mette alla prova i seguenti componenti:- contenitori (HorizontalFieldManager e VerticalFieldManager)
- ListField
- TreeField
Per quanto riguarda il ListField, ho creato una sottoclasse ad hoc, MyListField, in modo da poter intercettare gli eventi generati dalla trackwheel e dalla tastiera e per associare a questo componente un menù custom. Quindi, quando il focus è su questo componente e si preme il pulsante che apre il menù, appare una nuova voce creata da codice.
Il TreeField è interessante in quanto con il metodo addChildNode si aggiungono nodi all'albero e con il metodo drawTreeItem (definito in un'apposita interfaccia richiamata dal Framework) si vanno invece a disegnare sullo schermo. In tal modo si è ottenuta la separazione fra dati e presentazione (model e view) e risulta più facile personalizzare l'aspetto grafico dell'albero.
Prima di concludere, vi segnalo che sul sito di DataFox, nella sezione Corsi di Formazione, sono presenti i programmi dei nuovi corsi, come il Corso su Joomla! 1.5, il Corso su PHP e MySQL, il Corso di programmazione base e il Corso di Programmazione ad Oggetti.
mercoledì 24 settembre 2008
Aggiornamento sito DataFox e Joomla!
Finalmente, dopo diversi giorni di lavoro molto intenso, siamo riusciti a pubblicare su Internet il nuovo sito Web di DataFox. Le modifiche, anche se poco visibili a prima vista, sono importanti e riguardano sia gli aspetti tecnologici che i contenuti.
Relativamente al fronte tecnologico posso dire che siamo passati da Internet Information Server ad Apache (installato in bundle con PHP 5 grazie a XAMPP), in modo da poter sfrutture il motore di rewrite degli URL messo a disposizione da questo Server HTTP. Grazie ad esso e alle funzionalità di Mambo e di un'apposita estensione, adesso gli URL del sito sono molto più significativi e parlanti di quelli precedenti.
Il lavoro più importante riguarda i contenuti, in quanto abbiamo rivisto e corretto tutte le sezioni relativi ai notri prodotti finanziari, Desmo Finanza e Desmo Monitor Investimenti. Inoltre abbiamo completato le schede di PerfeCtA (brochure), il nostro motore di calcolo per la Performance di Portafoglio, la Performance Contribution, la Performance Attribution e il Rischio di Portafoglio.
Nel frattempo ho continuato a lavorare ad un progetto di sito Web per il gruppo musicale formato da alcuni amici (maggiori dettagli appena sarà reso pubblico). Come strumento per la gestione dei contenuti ho scelta Joomla! (la versione 1.5.7 in italiano), che mi è sembrato il CMS più semplice e completo, molto ricco di estensioni e temi grafici alternativi. Dopo alcuni giorni di utilizzo, devo riconoscere il valore di questo software, a parte per un aspetto, che mi ha lasciato abbastanza perplesso, cioè la gestione degli utenti e delle autorizzazioni. Ho trovato questa funzionalità relativamente limitata e poco flessibile, soprattutto per un CMS. Ho letto su Internet che una gestione evoluta delle ACL (Access Control List) sarà disponibile nella versione 1.6, ma nel frattempo sembra che l'unico modo per ovviare a questa lacuna sia l'acquisto di qualche estensione a pagamento. Altre soluzioni o suggerimenti sono ben accetti...
Relativamente al fronte tecnologico posso dire che siamo passati da Internet Information Server ad Apache (installato in bundle con PHP 5 grazie a XAMPP), in modo da poter sfrutture il motore di rewrite degli URL messo a disposizione da questo Server HTTP. Grazie ad esso e alle funzionalità di Mambo e di un'apposita estensione, adesso gli URL del sito sono molto più significativi e parlanti di quelli precedenti.
Il lavoro più importante riguarda i contenuti, in quanto abbiamo rivisto e corretto tutte le sezioni relativi ai notri prodotti finanziari, Desmo Finanza e Desmo Monitor Investimenti. Inoltre abbiamo completato le schede di PerfeCtA (brochure), il nostro motore di calcolo per la Performance di Portafoglio, la Performance Contribution, la Performance Attribution e il Rischio di Portafoglio.
Nel frattempo ho continuato a lavorare ad un progetto di sito Web per il gruppo musicale formato da alcuni amici (maggiori dettagli appena sarà reso pubblico). Come strumento per la gestione dei contenuti ho scelta Joomla! (la versione 1.5.7 in italiano), che mi è sembrato il CMS più semplice e completo, molto ricco di estensioni e temi grafici alternativi. Dopo alcuni giorni di utilizzo, devo riconoscere il valore di questo software, a parte per un aspetto, che mi ha lasciato abbastanza perplesso, cioè la gestione degli utenti e delle autorizzazioni. Ho trovato questa funzionalità relativamente limitata e poco flessibile, soprattutto per un CMS. Ho letto su Internet che una gestione evoluta delle ACL (Access Control List) sarà disponibile nella versione 1.6, ma nel frattempo sembra che l'unico modo per ovviare a questa lacuna sia l'acquisto di qualche estensione a pagamento. Altre soluzioni o suggerimenti sono ben accetti...
mercoledì 17 settembre 2008
Grails e ZK su Eclipse
Oggi una piccola variazione sul tema, visto che affronto alcune problematiche che ho incontrato e risolto utilizzando i plugin di Eclipse per Grails e ZK (ZK-Studio).
Con il primo, cioè il plugin per Grails, ho riscontrato un problema nell'esecuzione dell'applicazione tramite l'apposita configurazione per Eclipse generata da Grails stesso. Infatti ad ogni tentativo viene lanciato il seguente errore:
Error starting Sun's native2ascii:
e l'applicazione termina prematuramente. Dopo alcune ricerche, ho scoperto che il tool native2ascii fa parte del JDK, mentre l'applicazione viene lanciata con il JRE. Tuttavia, anche configurando ed utilizzando il JDK, l'errore persiste. La soluzione che ho trovato consiste nell'aggiungere manualmente il tools.jar (presente nel JDK) alle librerie associate da Eclipse al JRE, come si può vedere nella figura seguente:
A questo punto, l'applicazione parte senza problemi.
Dopo aver installato l'ultima versione di ZK-Studio (la 0.8.2), ho provato a creare una pagina ZUL tramite il wizard messo a disposizione da questo plugin:
Selezionando la voce "use variable-resolver..." (come si vede nella figura precedente), si ottiene un file contenente la riga:
<?variable-resolver use="org.zkoss.zkplus.spring.DelegatingVariableResolver"?>
che è sbagliata, in quanto l'attributo giusto non è "use" ma "class". Cioè la riga corretta è:
<?variable-resolver class="org.zkoss.zkplus.spring.DelegatingVariableResolver"?>
Se non si esegue manualmente questa correzione e si prova comunque a richiamare la pagina, si ottiene un errore:
org.zkoss.zk.ui.UiException: The class attribute is required, [SYS file:/C:/Eclipses/eclipse_332/workspace/Prova/web-app/new_file.zul line 4 col 79]
Ho segnalato l'anomalia sul tacker del progetto ZK in SourceForge e waterbottle (alias Dennis Chen, uno degli sviluppatori di ZK) ha riconosciuto che si è trattato di un errore di scrittura.
Con il primo, cioè il plugin per Grails, ho riscontrato un problema nell'esecuzione dell'applicazione tramite l'apposita configurazione per Eclipse generata da Grails stesso. Infatti ad ogni tentativo viene lanciato il seguente errore:
Error starting Sun's native2ascii:
e l'applicazione termina prematuramente. Dopo alcune ricerche, ho scoperto che il tool native2ascii fa parte del JDK, mentre l'applicazione viene lanciata con il JRE. Tuttavia, anche configurando ed utilizzando il JDK, l'errore persiste. La soluzione che ho trovato consiste nell'aggiungere manualmente il tools.jar (presente nel JDK) alle librerie associate da Eclipse al JRE, come si può vedere nella figura seguente:
A questo punto, l'applicazione parte senza problemi.Dopo aver installato l'ultima versione di ZK-Studio (la 0.8.2), ho provato a creare una pagina ZUL tramite il wizard messo a disposizione da questo plugin:
Selezionando la voce "use variable-resolver..." (come si vede nella figura precedente), si ottiene un file contenente la riga:<?variable-resolver use="org.zkoss.zkplus.spring.DelegatingVariableResolver"?>
che è sbagliata, in quanto l'attributo giusto non è "use" ma "class". Cioè la riga corretta è:
<?variable-resolver class="org.zkoss.zkplus.spring.DelegatingVariableResolver"?>
Se non si esegue manualmente questa correzione e si prova comunque a richiamare la pagina, si ottiene un errore:
org.zkoss.zk.ui.UiException: The class attribute is required, [SYS file:/C:/Eclipses/eclipse_332/workspace/Prova/web-app/new_file.zul line 4 col 79]
Ho segnalato l'anomalia sul tacker del progetto ZK in SourceForge e waterbottle (alias Dennis Chen, uno degli sviluppatori di ZK) ha riconosciuto che si è trattato di un errore di scrittura.
domenica 14 settembre 2008
Component Gallery per BlackBerry
Ho completato una prima versione della Component Gallery per BlackBerry, in cui sono utilizzati tutti i componenti grafici di base contenuti nel package net.rim.device.api.ui.component. Ho preferito rimandare ad una seconda versione i componenti più complessi, come il ListField e il TreeField, e i vari contentori presenti nel package net.rim.device.api.ui.container.
Come si può vedere nella figura seguente, all'interno del simulatore il programma può essere lanciato tramite una semplice icona che si trova nella cartella Downloads:
Una volta partito, viene visualizzata una schermata con tutti i componenti disposti verticalmente; poiché sono molti, non entrano tutti in una singola pagina e si possono vedere spostandosi verso il basso.
Il codice sorgente e i file di supporto per Eclipse con plugin JDE si possono scaricare da qui. Oltre che con questo ambiente, il codice può essere utilizzato anche con il JDE standard, dopo aver creato e configurato i contenitori previsti da questo tool (workspace e project).
Come si può vedere nella figura seguente, all'interno del simulatore il programma può essere lanciato tramite una semplice icona che si trova nella cartella Downloads:
Una volta partito, viene visualizzata una schermata con tutti i componenti disposti verticalmente; poiché sono molti, non entrano tutti in una singola pagina e si possono vedere spostandosi verso il basso.
Il codice sorgente e i file di supporto per Eclipse con plugin JDE si possono scaricare da qui. Oltre che con questo ambiente, il codice può essere utilizzato anche con il JDE standard, dopo aver creato e configurato i contenitori previsti da questo tool (workspace e project).
venerdì 12 settembre 2008
JDE e Eclipse
Dopo un po' di tempo, riesco finalmente a scrivere un nuovo post. In questi giorni siamo stati molto impegnati ad aggiornare il sito Web di DataFox e le brochure di Desmo Finanza e Desmo Monitor Investimenti, in particolare per presentare le nuove funzionalità di Performance Contribution e Performance Attribution. Abbiamo anche pubblicato una demo statica del nuovo modulo "Portafogli WEB".
Ma torniamo a noi e allo sviluppo di applicazioni per BlackBerry. Come anticipato nel post precedente sto preparando una piccola demo dei componenti grafici messi a disposizione dalla libreria di RIM; ho iniziato utilizzando, come ambiente di sviluppo, il JDE 4.6.0 (di cui è appena uscita la versione definitiva), ma ho sentito la necessità di tornare ad Eclispe, vista la familiarità che ho con questo tool. Quindi ho installato la beta del JDE Plug-in for Eclipse, appoggiandolo ad uno degli Eclipse presenti sul mio computer. Fin qui tutto bene, ho creato il workspace per il BlackBerry e un progetto, in cui ho copiato quanto realizzato con il JDE. Anche l'emulatore ha funzionato senza problemi.
Quando ho iniziato a modificare il codice ho avuto una brutta sorpresa: il completamento automatico (Ctrl+Space) non funziona! Ma come è possibile? All'interno della classe principale, sottoclasse di MainScreen il Code Assist di Eclipse non fornisce nessun suggerimento, neanche per le classi base come String; al contrario, in altre classi figlie di Object tutto va a meraviglia. Poiché ritengo che questa funzionalità sia fondamentale, ho cercato di capire il motivo di questo strano comportamento. Dopo un po' di indagini e di tentativi, ho scoperto che alcune classi presenti nel JAR fornito con il JDE (net_rim_api.jar) risultano contenere una o più inner class, ma il corrispondente file .class (riconoscibile dalla presenza del $ nel nome) manca. Quando si crea una sottoclasse di queste classi (ad esempio UiApplication o MainScreen), il Code Assist non fornisce nessun suggerimento. In modo forse non molto ortodosso (ma bisogna fare di necessità virtù, no?), ho creato i file .class delle inner class mancanti, li ho aggiunti ad una mia versione del file JAR di libreria e mettendo quest'ultimo nel Build Path del progetto l'auto completamento ha iniziato a fare il suo dovere. Anche a run time non ci sono problemi, in quanto il JAR "arricchito" serve solo per l'editing e la compilazione e quindi le inner class fittizie non vengono neanche considerate dall'emulatore.
Pur avendo raggiunto il mio scopo, resto con due dubbi:
Ma torniamo a noi e allo sviluppo di applicazioni per BlackBerry. Come anticipato nel post precedente sto preparando una piccola demo dei componenti grafici messi a disposizione dalla libreria di RIM; ho iniziato utilizzando, come ambiente di sviluppo, il JDE 4.6.0 (di cui è appena uscita la versione definitiva), ma ho sentito la necessità di tornare ad Eclispe, vista la familiarità che ho con questo tool. Quindi ho installato la beta del JDE Plug-in for Eclipse, appoggiandolo ad uno degli Eclipse presenti sul mio computer. Fin qui tutto bene, ho creato il workspace per il BlackBerry e un progetto, in cui ho copiato quanto realizzato con il JDE. Anche l'emulatore ha funzionato senza problemi.
Quando ho iniziato a modificare il codice ho avuto una brutta sorpresa: il completamento automatico (Ctrl+Space) non funziona! Ma come è possibile? All'interno della classe principale, sottoclasse di MainScreen il Code Assist di Eclipse non fornisce nessun suggerimento, neanche per le classi base come String; al contrario, in altre classi figlie di Object tutto va a meraviglia. Poiché ritengo che questa funzionalità sia fondamentale, ho cercato di capire il motivo di questo strano comportamento. Dopo un po' di indagini e di tentativi, ho scoperto che alcune classi presenti nel JAR fornito con il JDE (net_rim_api.jar) risultano contenere una o più inner class, ma il corrispondente file .class (riconoscibile dalla presenza del $ nel nome) manca. Quando si crea una sottoclasse di queste classi (ad esempio UiApplication o MainScreen), il Code Assist non fornisce nessun suggerimento. In modo forse non molto ortodosso (ma bisogna fare di necessità virtù, no?), ho creato i file .class delle inner class mancanti, li ho aggiunti ad una mia versione del file JAR di libreria e mettendo quest'ultimo nel Build Path del progetto l'auto completamento ha iniziato a fare il suo dovere. Anche a run time non ci sono problemi, in quanto il JAR "arricchito" serve solo per l'editing e la compilazione e quindi le inner class fittizie non vengono neanche considerate dall'emulatore.
Pur avendo raggiunto il mio scopo, resto con due dubbi:
- come mai le inner class mancano dal JAR? dimenticanza o protezione del codice dagli attacchi dei decompilatori?
- perché Eclipse non gestisce in modo migliore questa situazione anomala?
venerdì 5 settembre 2008
Dove sono finite le applicazioni?
Mi riaggancio al post precedente, a proposito dell'utilizzo dell'emulatore del BlackBerry all'interno del JDE. Grazie alle preziose indicazioni che ho trovato su dev|sushi, sono finalmente riuscito ad eseguire le applicazioni di esempio e quelle scritte da me, sia nella versione stabile 4.5.0 che nella beta 4.6.0. Ma qual è il mistero finalmente svelato? A differenza di tutti gli altri emulatori che ho utilizzato in passato (ad esempio quello per Windows Mobile o per J2ME), in questo caso l'applicazione che si vuol testare non parte automaticamente, ma viene semplicemente caricata nella memoria dell'ambiente emulato. Per certi versi, questo comportamento è più realistico, visto che sul dispositivo vero le applicazioni devono essere lanciate dall'utente, quando ha intenzione di utilizzarle.
Nell'emulatore predefinito del JDE 4.5.0, corrispondente al BB 8300, le applicazioni create nell'ambiente di sviluppo si trovano insieme alle altre, come si vede in figura, dove è stata evidenziato l'esempio "Hello World".
Nell'emulatore del JDE 4.6.0, corrispondente al BB 9000, le applicazioni su cui si sta lavorando si trovano nella cartella Downloads, come si vede in figura, dove, oltre al solito "Hello World", si possono vedere altri esempi.
In un prossimo post presenterò una piccola applicazione dimostrativa, corredata di codice sorgente, in cui sono utilizzati i vari componenti grafici (lista, albero, radio, check, ecc.), messi a disposizione da RIM per creare le interfacce utente. Lo scopo è di mettere a disposizione una galleria di componenti con cui fare esperimenti e toccare con mano i risultati ottenibili con ciascuno di essi.
Nell'emulatore predefinito del JDE 4.5.0, corrispondente al BB 8300, le applicazioni create nell'ambiente di sviluppo si trovano insieme alle altre, come si vede in figura, dove è stata evidenziato l'esempio "Hello World".
Nell'emulatore del JDE 4.6.0, corrispondente al BB 9000, le applicazioni su cui si sta lavorando si trovano nella cartella Downloads, come si vede in figura, dove, oltre al solito "Hello World", si possono vedere altri esempi.
In un prossimo post presenterò una piccola applicazione dimostrativa, corredata di codice sorgente, in cui sono utilizzati i vari componenti grafici (lista, albero, radio, check, ecc.), messi a disposizione da RIM per creare le interfacce utente. Lo scopo è di mettere a disposizione una galleria di componenti con cui fare esperimenti e toccare con mano i risultati ottenibili con ciascuno di essi.
martedì 2 settembre 2008
Sviluppo per BlackBerry e attacchi NDR su Exchange
Oggi avrei voluto parlare dei primi risultati conseguiti nello sviluppo di software per BlackBerry. Purtroppo, dopo diversi tentativi e ricerche su Internet, non sono riuscito a far funzionare correttamente l'emulatore integrato nella versione 4.6.0 (beta) del JDE (ambiente intergrato fornito da RIM). Il comportamento è stato abbastanza singolare, in quanto l'emulatore partiva senza problemi, ma non riusciva a caricare i programmi compilati, il tutto senza fornire la minima spiegazione. Al contrario, i programmi di sistema, ad esempio il browser Web, hanno funzionato benissimo. Quindi ho deciso di disinstallare tutto e di cominciare da capo, provando prima con la versione stabile (4.5.0) e solo successivamente con la beta. Vi aggiornerò in un prossimo post.
Per fortuna è andata meglio con un problema che ci tormentava da molto, cioè un attacco di tipo NDR (Non Delivery Report) al nostro server Exchange. Stamani ne è stato portato un altro molto intenso, che di fatto bloccava tutte le nostre mail, in quanto il provider le rifiutava a causa del troppo traffico. Dopo una ricerca su Internet e la lettura di alcuni articoli della Knowledge Base di Microsoft (http://support.microsoft.com/kb/842851 e http://support.microsoft.com/?kbid=294757), abbiamo deciso di bloccare l'invio degli NDR, usando l'apposito pannello di Exchange (voce "Consenti rapporti di mancato recapito").
Agendo in questo modo il problema è stato risolto, spero definitivamente.
Per fortuna è andata meglio con un problema che ci tormentava da molto, cioè un attacco di tipo NDR (Non Delivery Report) al nostro server Exchange. Stamani ne è stato portato un altro molto intenso, che di fatto bloccava tutte le nostre mail, in quanto il provider le rifiutava a causa del troppo traffico. Dopo una ricerca su Internet e la lettura di alcuni articoli della Knowledge Base di Microsoft (http://support.microsoft.com/kb/842851 e http://support.microsoft.com/?kbid=294757), abbiamo deciso di bloccare l'invio degli NDR, usando l'apposito pannello di Exchange (voce "Consenti rapporti di mancato recapito").
Agendo in questo modo il problema è stato risolto, spero definitivamente.
Iscriviti a:
Post (Atom)
Ricerca personalizzata