Gestore Lidi consente di gestire il tuo lido e tenere sotto controllo i tuoi ombrelloni con un touch.
Potrai disegnare il tuo lido definendo il numero di file e colonne e collocando gli ombrelloni come meglio credi.
Puoi gestire più di un lido
Puoi gestire i posti giorno per giorno indicando quali posto sono occupati.
Nell’articolo di oggi vedremo come rendere raggiungibile un server liferay disponibile su rete interna.
Per ragioni di sicurezza qualora si decide di rendere una risorsa disponibile su indirizzo pubblico, le porte che vengono aperte sono le porte 80 e 443, rispettivamente responsabili delle risorse in chiaro e delle risorse criptate in ssl. Le porte 80 e 443 sono porte di sistema dedicate al protocollo http e su un server linux sono assegnate al demone httpd.
La configurazione standard di liferay prevede la sua esposizione su porta 8080, porta tipica di un server tomcat. Pertanto non possiamo accedere direttamente a liferay ma dobbiamo mettere in piedi una infrastruttura che ci consenta di farlo.
Per gestire questo scenario possiamo avvalerci dell’http server di apache opportunamente configurato come proxy. Configuriamo Apache in modo tale da veicolare le richieste che arrivano verso liferay.
Sono presenti 2 possibili approcci:
La configurazione basata su mod_jk è sicuramente la scelta più indicata: la configurazione standard di liferay presenta il modulo ajp in ascolto sulla porta 8009, pertanto dobbiamo solo configurare apache per configurare il modulo mod_jk.so.
Il modulo mod_jk.so non è disponibile nella configurazione standard di Apache, a seconda della versione linux è possibile installarla tramite il gestore dei pacchetti oppure scaricando i sorgenti dal sito e compilandoli. Una volta installato il modulo mod_jk.so occorre configurare il file httpd.conf per abilitare il modulo tramite le direttive
LoadModule jk_module <path>/mod_jk.so –> indica dove è presente il mod_jk.so
JkWorkersFile percorso <path>/workers.properties –> indica dove si trova il file workers.properties
JkLogFile <path>/mod_jk.log –> indica il file di log
JkLogLevel <level> –> indica il livello di log
JkMount /* worker1 –> indica il livello
Resta da configurare opportunamente il file workers.properties, dove definiamo le regole di integrazione con liferay, tramite le direttive
|
1 2 3 4 |
worker.list=worker1 worker.worker1.port=8009 worker.worker1.host=<ip di liferay> worker.worker1.type=ajp13 |
A questo punto riavviamo apache e proviamo ad accedere all’indirizzo pubblico, se abbiamo operato bene verremo rediretti su liferay.
Qualora non possiate usare mod_jk (non mi viene in mente nessun motivo) usate l’approccio 2. Per configurare il reverse proxy usate le seguenti direttive
ProxyPass /liferay http://x.x.x.x:8080/ –> redirige le chiamate verso il server liferay
ProxyPassReverse /liferay http://x.x.x.x:8080/
Non è sufficiente, poichè con questa configurazione avremmo accesso alla home page di liferay ma non a tutte le risorse, poichè liferay restituisce le url alle risorse della pagina in formato assoluto.
Per ovviare all’inconveniente ci viene in soccorso il modulo mod_proxy_html che consente di implementare delle regole di sostituzione all’interno delle pagine html restituite da liferay tramite la direttiva
|
1 2 3 4 5 6 7 8 |
LoadModule proxy_html_module modules/mod_proxy_html.so LoadModule xml2enc_module modules/mod_xml2enc.so ProxyHTMLURLMap http://x.x.x.x:8080/ /app<Location /app1/> ProxyPassReverse / ProxyHTMLEnable On ProxyHTMLURLMap / /app1/ RequestHeader unset Accept-Encoding </Location> |
Il modulo mod_proxy_html non è presente nella distribuzione standard di Apache, a carico vostro installazione e configurazione reperibile sul sito
In questo breve articolo vedremo come integrare un mail server in liferay.
Per le versioni 6.x e 5.2.x la configurazione del mail server può essere effettuata tramite interfaccia grafica, andando sotto la sezione Control Panel -> Server Administration -> Mail. Siccome una immagine vale più di mille parole, osservate lo screenshot successivo:
Potete configurare il mail server e i parametri di connessione tramite il file portal-xxx.properties. Le variabili da usare sono
|
1 2 3 4 5 6 7 |
mail.session.mail.imap.host=xxxx mail.session.mail.pop3.host=xxxx mail.session.mail.smtp.host=xxxx mail.session.mail.smtp.password=xxx mail.session.mail.smtp.user=yyyy mail.session.mail.store.protocol=xxxx mail.session.mail.transport.protocol=smtp |
Per le versioni precedenti e per gli amanti dei file di configurazione dovete modificare il file ROOT.xml disponibile al path $tomcat_home\conf\Catalina\localhost\ROOT.xml
In questo file dovete aggiungere la risorsa che descrive i paramatri di accesso al db
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
<Resource name="mail/MailSession" auth="Container" type="javax.mail.Session" mail.imap.host="localhost" mail.pop.host="localhost" mail.store.protocol="imap" mail.transport.protocol="smtp" mail.smtp.host="smtp.gmail.com" mail.smtp.port="465" mail.smtp.auth="true" mail.smtp.starttls.enable="true" mail.smtp.user="username" password="password" mail.smtp.socketFactory.class="javax.net.ssl.SSLSocketFactory" /> |
Per verificare il corretto funzionamento provate a registrare un nuovo utente, se avete fatto tutto bene dovreste ricevere la mail di avvenuta registrazione.
Buona sperimentazione
Nell’articolo di oggi vedremo come integrare il CAS server con una base dati MySql e per comodità sfrutteremo la stessa di Liferay.
Se avete seguito i passi del precedente articolo dovreste avere la vostra istanza liferay attiva e funzionante con il meccanismo di autenticazione demandato al CAS, che si preoccupa di verificare se username e password sono uguali.
Nell’articolo precedente abbiamo usato la versione CAS messa a disposizione da Liferay, che è ferma alla versione 3.0.5 e pertanto installiamo la versione nuova 3.5.0 disponibile qui, che risulta essere più stabile e anche più esaustiva dal punto di vista dei log.
Scaricato il file sostituiamo, rinominiamo il file war in cas-web.war, in modo da non dover cambiare le impostazioni effettuate precedente su liferay.
Una volta attivo accediamo alla cartella webapp/cas-web/WEB-INF sotto la directory del tomcat e analizziamo il file deployerConfigContext.xml: in questo file sono definite le regole di autenticazione e nella configurazione di default troviamo il bean
|
1 2 3 |
<bean class="org.jasig.cas.authentication.handler. support.SimpleTestUsernamePasswordAuthenticationHandler"> </bean> |
che come già detto applica come meccanismo di autenticazione che username e password coincidano.
Sostituiamo il bean con quello responsabile di implementare il meccanismo di autenticazione. Il cas mette a disposizione 3 implementazioni differenti:
Per integrare il bean occorre definire il datasource, tramite la seguente configurazione
|
1 2 3 4 5 6 7 8 9 10 |
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"> <property name="driverClassName"> <value>com.mysql.jdbc.Driver</value> </property> <property name="url"> <value>jdbc:mysql://localhost:3306/lportal</value> </property> <property name="username"><value>lportal</value></property> <property name="password"><value>lportal</value></property> </bean> |
e successivamente potete scegliere liberamente tra il secondo e il terzo bean, da sostituire al bean SimpleTestUsernamePasswordAuthenticationHandler.
|
1 2 3 4 |
<bean class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler"> <property name="dataSource" ref="dataSource" /> <property name="sql" value="select password_ from user_ where lower(emailAddress) = lower(?)" /> </bean> |
Nel caso del bean QueryDatabaseAuthenticationHandler dovremo definire la query per ottenere la password da confrontare con quella inserita dall’utente.
|
1 2 3 4 5 6 |
<bean class="org.jasig.cas.adaptors.jdbc.SearchModeSearchDatabaseAuthenticationHandler"> <property name="tableUsers"><value>user_</value></property> <property name="fieldUser"><value>emailAddress</value></property> <property name="fieldPassword"><value>password_</value></property> <property name="dataSource" ref="dataSource"/> </bean> |
Nel caso del bean SearchModeSearchDatabaseAuthenticationHandler dovremo specificare la tabella coinvolta e i campi su cui mappare username e password inseriti nel login del CAS.
Entrambi i bean considerano il caso di password salvate in chiaro. Siccome Liferay di default applica la codifica SHA dovete allineare il comportamento e avete di fronte due possibilità:
In questo articolo vedremo come realizzare un portale con LIFERAY, il celebre portale open source realizzato in java, che consente di realizzare portali completi di tutte le funzionalità web 2.0. Inoltre integreremo LIFERAY con il database MySQL e un sistema di single sign on, il CAS server, realizzato originariamente dall’università di Yale e adesso progetto del consorzioYASIG.
Prima di tutto scarichiamo il progetto dalla sezione download del sito principale di liferay. Nel momento in cui scrivo è disponibile la versione 6.1 che promette grandi migliorie e tra le tante disponibili scegliamo la versione integrata con Tomcat.
Una volta scaricato il file zip scompattatelo (usate 7zip, alcuni file hanno nomi molto lunghi e l’utility di windows va in errore).
Avviamo tomcat e restiamo in attesa, fino a quando non viene aperta la finestra di configurazione del wizard. Con il Wizard possiamo configurare il nome del sito, la lingua di default e i dati di accesso dell’amministratore. Inoltre possiamo scegliere di modificare la base dati cui appoggiare il nostro portale. Di default è configurato HSQL, che va bene per un’installazione di prova, ma è sconsigliato per un’installazione di produzione.
In questo articolo integreremo MySQL:
Inizia una serie di articoli dedicati ai principali design pattern della programmazione ad oggetti.
La prima cosa da fare è chiarire cos’è un pattern. Per pattern si intende un metodo preciso di svolgere un determinato lavoro, frutto dell’esperienza maturata. Esso, pertanto, costitusce un modo per risolvere un determinato problema, ma non è l’unico e starà al programmatore scegliere di volta in volta se affidarsi ad un pattern o ad una soluzione differente. Si tratta di valutare di volta in volta il grado di complessità della soluzione e scegliere la strada migliore.
In questo primo articolo vedremo una carrellata dei principali design pattern, che approfondiremo di volta in volta in articoli dedicati.
Adapter
Viene usato quando occorre adattare il nostro codice alle esigenze di un client, fuori dal nostro controllo.
Facade
Viene usato quando si vuole una interfaccia di alto livello che nasconde la complessità del sottosistema cui si appoggia.
Composite
Viene usato quando occorre modellare oggetti in cui alcuni elementi possono contenere gruppi di oggetti. Un tipico esempio è l’albero.
Bridge
Viene usato quando si vuole disaccoppiare una astrazione dalla sua implementazione. Un tipico esempio sono i driver.
Singleton
Viene usato quando si vuole che una classe abbia una sola istanza e un solo punto di accesso ad essa.
Observer
Viene usato per gestire il caso in cui più oggetti dipendono dal comportamento di uno specifico oggetto.
Mediator
Viene usato quando si vuole centralizzare le regole di interazione tra un gruppo di oggetti.
Proxy
Viene usato quando si vuole demandare ad un altro oggetto l’accesso alle proprie funzionalità.
Chain Of Responsability
Viene usato quando si vuole consentire a più oggetti di gestire una chiamata in sequenza, ognuno responsabile di una determinata azione
Builder
Viene usato quando si vuole spostare la logica della costruzione della classe al di fuori della classe stessa.
Abstract Factory
Viene usato quando si consente ad un client di poter istanziare oggetti che fanno parte di una famiglia di classi correllate
Prototype
Viene usato quando si istanzia un nuovo oggetto a partire da una già presente
Template Method
Viene usato quando si rimanda la definizione di un algoritmo ad una sottoclasse. Tipico esempio è l’interfaccia Comparator.
State
Viene usato quando si è in presenza di una logica a stati e la si distribuisce su più classi.
Command
Viene usato quando si incapsula una richiesta all’interno di un oggetto, che sarà invocabile da un client. Tipico esempio sono i menù.
Decorator
Viene usato quando si vuole estendere il comportamento di un oggetto esistente.
Iterator
Viene usato quando si vuole consentire ad un client di accedere sequenzialmente agli elementi di una collezione.
Alla prossima
Nell’articolo di oggi vediamo l’utilizzo dell’action bar, il componente introdotto con Android 3.0 (Api level 11) e supportato con le versioni precedenti tramite la Support Library. L’action bar è un componente che svolge diverse funzioni: innanzitutto identifica l’app, permette di gestire funzioni contestuali alla navigazioni e di avere accesso immediato a funzioni trasversali come potrebbe essere il modulo search.
Nell’action bar sono individuate 4 aree funzionali con queste caratteristichie:
Qualora lo spazio non sia sufficiente le azioni sono disponibili nell’area di overflow, oppure è possibile attivare una bottom area in cui tutto lo spazio a disposizione è occupato dalle azioni rimaste.
Passiamo alla nostra app e attiviamo la action bar. Nel nostro esempio l’app deve essere compatibile con dispositivi con Android 2.1, pertanto definiamo la nostra activity principale così
|
1 |
public class MainActivity extends ActionBarActivity {} |
dove ActionBarActivity è una classe della Support Library disponibile nel package android.support.v7.app;
A questo punto l’action bar è già disponibile e mostra la nostra icona e nient’altro. Qualora volessimo rimuoverla è sufficiente nasconderla in modo semplice:
|
1 2 |
ActionBar actionBar = getSupportActionBar(); actionBar.hide(); |
Adesso abilitiamo il pulsante di Up che consente di gestire la navigazione ed accedere alle funzioni precedentemente visualizzate. Per farlo sono sufficienti due comandi:
|
1 |
getSupportActionBar().setHomeButtonEnabled(true); |
(abilita il comportamento sull’icona dell’app )
o
|
1 |
getSupportActionBar().setDisplayHomeAsUpEnabled(true); |
(abilita una icona dedicata )
Per gestire il comportamento occorre implementare il metodo onOptionsItemSelected(MenuItem item) nella nostra activity e in particolare per gestire l’evento occorre implementare qualcosa di simile:
|
1 2 3 4 5 |
@Override public boolean onOptionsItemSelected(MenuItem item) { switch (item.getItemId()) { case android.R.id.home: finish(); } return super.onOptionsItemSelected(item); } |
In questo caso mi limito a chiudere l’app, quello che è importante notare è come il pulsante di Home sia identificato univocamente tramite la costante android.R.id.home
Se adesso volessimo aggiungere dei pulsanti occorre definire un menu in formato xml
|
1 2 3 4 5 6 7 8 9 10 11 12 |
<?xml version="1.0" encoding="utf-8"?> <menu xmlns:android="http://schemas.android.com/apk/res/android" xmlns:yourapp="http://schemas.android.com/apk/res-auto" > <item android:id="@+id/edit" android:title="@string/edit" android:icon="@drawable/ic_action_edit" yourapp:showAsAction="ifRoom" /> <item android:id="@+id/delete" android:title="@string/delete" android:icon="@drawable/ic_action_cancel" yourapp:showAsAction="ifRoom" /> </menu> |
Per gestire l’action bar Big G ci mette a disposizione un set di icone per gli usi più comuni disponibili qui. E’ interessante notare l’attributo showAsAction, che stabilisce il comportamento del pulsante. Big G consiglia di usare il valore ifRoom con cui consentiamo al sistema di spostare il pulsante nell’area di overflow qualora lo spazio non sia sufficiente.
A questo per abilitare il pulsante implementiamo il metodo onCreateOptionsMenu, in questo caso mi trovo all’interno di un fragment
@Override public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) { inflater.inflate(R.menu.action_list_market, menu); super.onCreateOptionsMenu(menu, inflater); }
e posso pilotare la sua comparsa tramite il comando setHasOptionsMenu, che mi permette di attivarlo in base alle mie esigenze.
Nel mio caso ho collegato il menù ad una lista in modo che si attivi alla selezione di un elemento.
Nell’articolo vedremo come aggiungere un banner alla nostra applicazione usando il Google Mobile Ads Sdk. Il precedente SDK è stato dichiarato deprecato, pertanto da Agosto 2014 il supporto di Google viene interrotto e occorre aggiornare le nostre app per gestire il nuovo SDK basato sui Google Play Services. Con la nuova soluzione offerta da Google eventuali aggiornamenti saranno gestiti automaticamente dal device senza la necessità di rilasciare un nuovo apk, cosa che prima era necessaria per risolvere bug o godere di nuove funzionalità aggiuntive.
Come prima cosa dobbiamo installare e configurare il Google Play Sdk all’interno del nostro ambiente di sviluppo.
Avviate l’SDK Manager, selezionate la sezione Extras e selezionate le voci:
Una volta che l’SDK è stato aggiornato dobbiamo integrare le librerie nel nostro ambiente di sviluppo. Avviamo Eclipse e usiamo l’opzione:
File > Import, select Android > Existing Android Code into Workspace
Selezionate la directory <android-sdk>/extras/google/google_play_services/libproject/google-play-services_lib/ ed effettuate l’import della libreria nel nostro workspace.
A questo punto create un nuovo progetto Android e integrate la libreria all’interno del progetto tramite la sezione Android del progetto.
Non resta che agganciare il nostro banner all’interno della nostra app. Secondo le best practices di Google il banner non deve essere invasivo, pertanto verrà collocato nel footer dell’app. Occorre dichiarare l’activity nel nostro manifest
|
1 2 3 4 5 |
<meta-data android:name="com.google.android.gms.version" android:value="@integer/google_play_services_version"/> <activity android:name="com.google.android.gms.ads.AdActivity" android:configChanges="keyboard|keyboardHidden|orientation |screenLayout|uiMode|screenSize|smallestScreenSize"/> |
e fornire i permessi per l’accesso internet
|
1 2 |
<uses-permission android:name="android.permission.INTERNET"/> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/> |
A questo punto è sufficiente instanziare l’oggetto Adview e il banner apparirà nella zona desiderata
|
1 2 3 4 5 6 |
AdView adView = new AdView(layout.getContext()); adView.setAdSize(AdSize.SMART_BANNER); adView.setAdUnitId(Costanti.MY_AD_UNIT_ID); layout.addView(adView); AdRequest adRequest = new AdRequest.Builder().build(); adView.loadAd(adRequest); |
Per testarlo occorre usare un adv con il supporto alle google api
Uno dei componenti più importanti di Android è lo spinner, ovvero la versione android della classica combobox. La gestione dello spinner può essere fatta in maniera dichiarativa o in maniera programmatica.
In maniera dichiarativa occorre definire per il nostro spinner la sua fonte dati, disponibile in una delle risorse xml. Ad esempio possiamo dichiarare uno spinner che contiene l’elenco degli anni in questo modo:
|
1 2 3 4 |
<Spinner android:id="@+id/spinnerAnnoSottoscrizione" style="@style/Spinner" android:entries="@array/annoIscrizione" /> |
l’attributo id individua unicamente il nostro spinner all’interno dell’app, l’attributo style contiene le specifiche grafiche dell’oggetto e il tag entries individua l’elenco dei valori che lo spinner può assumere. Tale elenco è definito nel file strings.xml
|
1 2 3 4 |
<string-array name="annoIscrizioneLabel"> <item>2012</item> <item>2011</item> </string-array> |
In questo modo abbiamo definito uno spinner che conterrà due voci (2012 e 2011), selezionabili dall’utente.
Possiamo ottenere lo stesso risultato programmaticamente in questo modo.
|
1 2 3 4 5 6 7 |
ArrayAdapter<String> adapter= new ArrayAdapter<String> (this, android.R.layout.simple_spinner_item , getResources().getStringArray(R.array.annoIscrizioneLabel)); adapter.setDropDownViewResource(android.R.layout.simple_spinner_dropdown_item); Spinner spinner =(Spinner) findViewById(R.id.annoIscrizioneLabel); spinner.setAdapter( adapter ); |
All’interno della nostra activity recuperiamo il nostro spinner e settiamo l’adapter che fa al caso nostro. L’Adapter è un oggetto che definisce la logica di visualizzazione dello spinner e dei suoi elementi. In questo esempio ho usato il simple_spinner_item, che definisce l’aspetto grafico dello spinner, e il simple_spinner_dropdown_item, che definisce l’aspetto grafico dell’elenco mostrato per la selezione.
Se occorre modificare l’aspetto dello spinner o rendere dinamico l’elenco delle voci da mostrare la gestione programmatica è la scelta obbligata.
Android mette a disposizione adapter che soddisfano la maggior parte delle nostre esigenze, ma se il nostro layout è complesso o la logica di business è più evoluta possiamo definire un nostro adapter, estendendo una delle classi già presenti.
Per gestire l’effetto di selezione dobbiamo definire un listener, tramite la chiamata
spinner .setOnItemSelectedListener(this);
Con questa chiamata sto dicendo che l’activity è responsabile di implementare l’interfaccia OnItemSelectedListener e di conseguenza il metodo onItemSelected. Avrei potuto in alternativa definire una inner class e demandare a lei la gestione degli eventi di selezione. Personalmente scelgo cosa fare in base alla complessità della classe.
Il listener (sia inner class che activity) si attiva per ogni evento di selezione. Fate attenzione, perchè si attiva anche allo start della nostra activity, quando viene popolato il nostro oggetto.
Buona sperimentazione.
Nell’articolo di oggi vedremo come gestire al meglio il banner pubblicitario all’interno della nostra app. Quello che vedremo ben si adatta anche a situazioni in cui si vuole che solo una parte dello scherma supporti lo scrolling.
Sulle modalità per integrare un banner, rimando al sito di AdMob, recentemente acquisito da Google, dove potete scaricare l’SDK da integrare.
E’ mio interesse mostrare le modalità per integrare il banner all’interno dell’app, in modo da rendere l’operazione facile e indolore.
Approccio Dichiarativo
E’ possibile inserire direttamente il seguente blocco xml all’interno del nostro layout. Il parametro keywords deve essere valorizzato con l’ID Editore rilasciato da AdMob all’atto della creazione del profilo della nostra app.
|
1 2 3 4 5 |
<com.admob.android.ads.AdView android:id="@+id/ad" android:layout_width="fill_parent" android:layout_height="wrap_content" app:keywords="xxxxxxxxxxx" /> |
In questo modo alla visualizzazione del nostro layout verrà anche visualizzato il banner. Con questo approccio, se vogliamo avere il banner in più activity della nostra app, dobbiamo inserire il blocco in ogni layout relativo all’activity.
Approccio Programmatico
E’ possibile gestire il banner programmaticamente, ovvero instanziare l’oggetto e configurarlo in uno dei metodi legati al ciclo di vita della nostra Activity, tipicamente il metodo onCreate.
|
1 2 3 4 5 |
AdView adView = new AdView(this, AdSize.BANNER, Costanti.MY_AD_UNIT_ID); LinearLayout layout = (LinearLayout) findViewById(R.id.linearLayout); layout.addView(adView); AdRequest request = new AdRequest(); adView.loadAd(request); |
Con questo approccio possiamo strutturare le nostre classi in modo da rendere trasparente per le nostre activity l’invocazione del banner, ad esempio tramite una activity astratta responsabile della gestione del banner, da cui ereditare le activity responsabili della logica della nostro app.
Tipici Problemi
Il problema che si può riscontrare è la mancata visualizzazione del banner. Fortunamente i log di Android ci danno tutte le indicazioni sulle possibili cause. Un motivo può essere il layout con spazio insufficiente per mostrare il banner e questo avviene tipicamente su dispositivi con display piccoli, dove abbiamo previsto di usare del padding. In questo caso l’errore che Android mostra è Not enough space to show ad! Wants: <320, 50>, Has: <270, 430>. Il problema si risolve agganciando il nostro banner al layout con una dimensione sufficiente a contenere il banner.
Altro problema è la posizione del banner, che può essere infelice o nella posizione non attesa. Per assicurarci la posizione desiderata possiamo usare il RelativeLayout e posizionare il banner nella posizione desiderata. Nell’esempio di sotto ho posizionato il banner in basso rispetto al container e l’oggetto ScrollView al di sopra del banner. In questo modo garantiamo la visualizzazione del banner nella posizione desiderata.
|
1 2 3 4 5 |
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" > <LinearLayout android:layout_alignParentBottom="true" /> <ScrollView android:layout_above="@id/mainAdv" > </RelativeLayout> |
