The Android Developer Challenge is open to individuals, teams of individuals, and business entities. While we seek to make the Challenge open worldwide, we cannot open the Challenge to residents of Cuba, Iran, Syria, North Korea, Sudan, and Myanmar (Burma) because of U.S. laws. In addition, the Challenge is not open to residents of Italy or Quebec because of local restrictions.

per saperne di piu' ecco le faq

tratto da http://www.minimarketing.it/

 http://www.bugnetproject.com/

BugNET is an issue tracking and project issue management solution built using the ASP.NET web application framework. Email notifications, reporting and per project configuration of fields and values allows efficient management of bugs, feature requests, and other issues for projects of any scale.

Supponiamo di avere una applicazione che abbia tre colonne, in una ho un elenco di regioni, se clicco su una regione nella seconda colonna ho un elenco di province e cliccando su una provincia ho l'elenco dei comuni di quella provincia.

Ovviamente regioni, province e comuni sono tutti nel loro bel database.

Ci sono tre strade:
La piu' ovvia è quella di fare tre pagine dinamiche che interrogano il db e chiedono di volta in volta l'elenco delle regioni, province e comuni in base ad un parametro di ingresso.

pro:

• è semplice e naturale
• permette di cambiare facilmente il template grafico
• è veloce da scrivere e da manutenere

contro:

• troppe interrogazioni al db per avere sempre gli stessi risultati

la seconda invece fa si che le pagine dei comuni e delle province siano tutte precalcolate. In genere questa è la fase successiva alla precedente, data la pagina che genera dinamicamente le province, mi creo le 100 e passa pagine statiche, una per provincia. Analogamente per i comuni.

pro:

• non interrogo il db
• la pagina viene restituita piu' velocemente
• non ho parametri nelle pagine (riduco la possibilità di fare sql injection)

contro:

• se uso dei template grafici che che cambiano spesso, questa soluzione non va bene

l'ultima strada è intermedia ed è valida quando il livello di presentazione del nostro sito è variabile e quindi non posso precalcolarmi la pagina. In pratica per non interrogare il db posso precalcolarmi l'elenco di comuni e province ad esempio sotto forma di files xml o binari (dipende un po' dall'algoritmo che voglio usare) e poi deserializzarli per applicarli al livello di presentazione.

pro:

• non interrogo il db
• posso continuare ad utilizzare il template engine

contro:

• non è performante come la soluzione precedente

 

Anche se il termine globale e locale è usato in modo improprio, rende bene il concetto di parametri che vengono passati nelle URL e che vengono utilizzati in gran parte delle pagine della nostra applicazione e parametri che vengono utilizzati solo in poche (o addirittura una) pagine.

Una buona regola è quella di gestire i parametri utilizzando una sola funzione il cui codice è condiviso da tutta l'applicazione e che abbia come scopo, per ogni possibile parametro di ingresso ammissibile dall'applicazione, quello di:

• verificare se il parametro esiste oppure no e impostare il relativo valore di default, se necessario
• verificare se il tipo che ci aspettiamo dal parametro è quello giusto
• accedere al dbms per prendere quelle informazioni che nel 90% dei casi dobbiamo andare a prendere ogni volta che quel parametro è settato.

i vantaggi di questa metodologia sono i seguenti:

• si evitano inutili ripetizioni di codice e copia-incolla suscettibili di bug
• si ha un unico punto centralizzato che gestisce i parametri di ingresso, cosa che rende estremamente piu' semplice e immediata la manutenzione del codice.

Lo svantaggio piu' evidente è che viene eseguito del codice anche quando non è necessario.