sì, è un progetto di eclipseSDK...
il .zip è veccio, bisogna usare il .rar ora controllo che non sia corrotoo ma in casoè un problema perchè il PC l'ho lasciato a lavoro...uffi
edit: bhe per ora guarda lo zip, ti fai un'idea di come si usa la grafica. da notare che attraverso il pulsante posso aggiungere elementi.. quì il discorso è complesso.
Una App (ma tutto ciò che è grafico di solito) gira di base in un suo "thread UI".
Questo thread si occupa di gestire gli eventi, che non sono altro che interrupt lato software. In pratica se tut fai qualcosa tipo un tocco, il SO andorid legge l'evento, lo pre-elabora, lo da in pasto al thread UI dell'applicazione in fullscreen (non è detto che sia sempre così, devo ancora studiare), e il thread UI lo da in pasto all'eventuale listener(ascoltatore di eventi) associato.
Un listener è un interfaccia (quindi un qualcosa che ti obbliga a credare delle funzioni con determinati paramentri, equivalentio alle fuinzioni di interrupt), quindi la tua classe diventa ANCHE (puoi avere più interfaccie) una classe di TIPO interfaccia, e a questo punto puoi fare applicazione.addListener(classeInterfaccia);
PROBLEMA: se blocchi il thread UI blocchi anche l'interfaccia grafica e la gestione degli eventi (ES i bottoni non funzionano... capita anche con i programmi PC, mai fatto caso?)
i signori della android, hanno avuto un ottima idea; se il thread UI rimane impallato per più di 5 secondi, l'app viene vista cone non responsiva.
Even worse, if the UI thread is blocked for more than a few seconds (about 5 seconds currently) the user is presented with the infamous "application not responding" (ANR) dialog.
(il procedimento è uguale alle applicazioni swing di java e di tutti gli altri linguaggi e grafica non credere, sto semplicemente aggiungendo qualche info specifica da Processes and threads overview | App quality | Android Developers)
Quindi, ora cosa succede: quando premi il bottone, viene creato un thread a parte (vengono chiamati worker), che prende in input un url e un listener, e va per la sua strada.
Il listener è appunto una semplice interfaccia in cui ho definito 2 funzioni: setMessage(ArrayList di classe Messaggio che vredremo poi) e setError(String).
Ovviamente la classe Activity (la classe main, che poi è una FragmentActivity per mantenere la compatibilità con gli android 2.2, ma lo spiego poi), implementa il listener.
Quindi cosa succede? nulla, il thread grafico vive come se nulla fosse, intanto il worker apre la URL, scarica il contenuto della pagina, lo converte byte per byte in UTF8 (quindi NON ASCII, in teoria il server risponde con l'encoding, o meglio il charset, della pagina, ma non uso questo dato per ora), poi dall'HTML con i tag sopra estrae per ogni mesaggio i vari dati, e crea quindi l'array di classe messaggio.
La classe messaggio non solo contiene i dati, ma in realtà è un Fragment, una cosa che usa andorid apposta per fare grafiche molto dinamiche...
ora, quando i dati sono caricati, il worker non fa altro che listener.setMessage(array di messaggi), ed ecco che alla nostro listener arrivano i messaggi MA siamo ancora nel thread worker...
e il thred UI non è thred safe, ciò vuol dire che se lo modifichi da altri thread senza prenderele giuste e complesse precauzioni fai solo (grossi) casini.
Nel mio caso i fragment hanno qualche sbattimenro grafico ma più o meno funzionano,o ma la cosa mi dava problemi era in caso di errore (setError) veniva creata un AlertBox dal thread worker e faceva crashare tutto...
ora ci sono vari metodi ad esempio mettere i dati in una variabile, e poi intercettare un eveto del thredUI che controllo se i dati co sono/sono cambiati e fa la parte grafica...
ma ci sono già le soluzioni precoinfezionate_
Activity.runOnUiThread(Runnable)
View.post(Runnable)
View.postDelayed(Runnable, long)
e ancora meglio la classe AsyncTask, che ti da 2 metodi:
doInBackground, che è chiamata dal "thread worker" e
onPostExecute, che è eseguita dal "thread UI"
Notare che in pratica è il sistema di parcheggiare i dati in una variabile vista da entrambi i Thread, solo che anzichè come nel mio caso ricevere eneti solo dal Wroker, riceve eventi anche dal UI, e quindi "fa da ponte"