IHttpHandler ha la Session null!

State usando un IHttpHandler (.ashx) nel vostro progetto asp.net e quel maledetto script ajax crasha perché l'oggetto Session nel context dell'handler è nullo?

Niente paura, la soluzione c'è ed è tremendamente semplice: basta dichiarare l'handler come implementazione dell'interfaccia IRequiresSessionState o, in alternativa, di IReadOnlySessionState, a seconda dei gusti.

 Le due interfacce fungono praticamente da attributi, dato che sono vuote! Ma il risultato è tutt'altro che vuoto: la Session sarà ora correttamente popolata.

 Buon coding!

.NET e la OpenFileDialog che fa crash!

Appunto di viaggio: se stai usando una OpenFileDialog e improvvisamente tutta la tua applicazione diventa instabile con crash nei punti più strani, non disperare. Il web ti dirà tante cose, come usare la Dispose o impostare la dialog a null dopo il suo utilizzo, oppure ancora aprire la dialog all'interno di un child MDI. Non dargli retta. Fai invece così, prima di chiamare la fatidica ShowDialog:

dialog.RestoreDirectory = true;

E vai con fiducia.

Android: Only the original thread that created a view hierarchy...

... can touch its views.

Sì, il maledetto messaggio che vi da il log degli errori quando una funzione invocata da un thread secondario cerca di modificare qualcosa nella GUI dell'Activity, ad esempio nascondere una progress bar attiva.

Si risolve facilmente, per fortuna. E' sufficiente dare a Cesare quel che è di Cesare, ovvero forzare l'esecuzione della funzione incriminata all'interno del thread che gestisce la user interface. Così:

runOnUiThread(new Runnable(){
   @Override
   public void run() {
      
      // qui il codice che crea l'errore
      // ...
   }     
});

E il gioco è fatto. Tanto semplice quanto facile da dimenticare.

Buon coding!

HowTo: Primi passi per sviluppare un Flash Game

Circa sei mesi fa ho deciso di smettere di snobbare ActionScript e cimentarmi nell'esperimento di produrre un gioco Flash. Tutt'ora non sono ben sicuro sull'usare il termine Flash piuttosto che Flex, ma ci siamo capiti.

La prima bella sorpresa è stata essersi trovati di fronte ad un linguaggio, ActionScript 3 appunto, che nulla aveva a che fare con lo script, termine che personalmente ho sempre relegato, sbagliando per carità, a qualcosa di riduttivo, disordinato, poco elegante e anche un po' sporco. No, quello che mi trovavo tra le mani era un vero linguaggio di programmazione, con tutta la dignità di un Java o un C# (e, a mio personale giudizio, anche la medesima comoda curva di apprendimento e immediata produttività).

La seconda bella sorpresa è stata scoprire un ottimo IDE free e ottime librerie a supporto. Ma...

...c'è un ma, e anche bello grosso. Prima di arrivare a tutto questo, infatti, mi sono trovato veramente spaesato in mezzo ad una miriade di possibilità e opzioni, senza una vera bussola che non fosse bussare in qualche forum, pigiare tasti Cerca e, naturalmente, chiedere a Google. Alla fine di questo processo di documentazione sono giunto ad una mia configurazione. La reputo produttiva, completa e, soprattutto, semplice, quindi la condivido qui su questa pagina.

Step 1: un IDE di nome FlashDevelop

Naturalmente non possiedo una licenza per Adobe Flash in nessuna sua forma o versione ma, anche se fosse, non avrei di certo perso l'occasione di provare un ottimo IDE open source quale FlashDevelop.

Il download per Windows sono circa 16 mega di ambiente fresco e pulito, con già tutte le librerie necessarie per partire con lo sviluppo di numerose tipologie di progetti con target non solo il noto Player di Adobe, ma anche AIR, l'ambiente (sempre di Adobe) per applicazioni desktop.

Come IDE, a parte essere bello (ho una passione per gli editor di testo, per cui passatemi l'aggettivo), è anche piuttosto completo e performante, comprendendo features come l'autocompletamento, l'intellisense (ma che funziona, non come quella di Code::Blocks...), un buon debugger (non come... ah, l'ho già detto), opzioni per il refactor e via dicendo.

La prima cosa da fare, quindi, è andare sul sito di questo ottimo progetto, scaricarselo e installarlo.

Step 2: una libreria di nome FlashPunk

Non intendevo affrontare il framework Flex di petto, lo ammetto. Frequentando come giocatore diversi giochi Flash mi ero reso conto che molti condividevano parecchie caratteristiche comuni, vuoi nei font, vuoi nei loghi in apertura. Le paroline Powered by riportate nei credits indicavano quasi sempre un paio di nomi: FlashPunk o Flixel.

Dilemma. Alla fine ho scelto FlashPunk con la stessa angoscia con cui in terza media decidiamo dove indirizzare le nostre vite. Anche la conoscenza di cosa scartavo era più o meno la stessa, così come la profondità delle motivazioni di tale scelta: di FlashPunk mi è piaciuto di più il sito. Ma anche la documentazione.

Step 3: Hello World

Provenendo dal C++ ed essendo FlashPunk un framework opensource di cui avevo appena scaricato i sorgenti ero già pronto a perdere non meno di 4 ore nel farli accettare al compilatore e farli trovare al linker, e invece mi sbagliavo. Mi ci sono voluti 30 secondi, 20 dei quali spesi in pausa di sorpresa.

E' infatti sufficiente fare copia/incolla della cartellina con i sorgenti di Flashpunk all'interno della cartella src del vostro progetto (creata dall'IDE) e il gioco è fatto.

Quale tipo di progetto creare? Già, in effetti se c'è una cosa un po' spaesante è proprio la quantità di tipologie di progetti realizzabili con FlashDevelop, ma quello che interessa a noi è AS3 Project!

A questo punto si tratta di utilizzare FlashPunk per istanziare il suo Engine e iniziare a creare i Worlds, qualcosa che somiglia moltissimo ad una gestione degli stati. Ma tutto questo è spiegato benissimo nei tutorial sul sito di FlashPunk quindi, as usual,

buon coding!

Android: impostare un context grafico OpenGL ES

E così vuoi fare un gioco per Android.
Benvenuto compagno di viaggio.
Non hai ancora deciso se sarà un 3D o un 2D, ma tanto non ti interessa, dato che non ti piegherai ad usare un Canvas o una semplice View per disegnare, tu vuoi codare the hard way, vuoi la potenza dell'accelerazione hardware, vuoi OpenGl ES.

E allora eccoci qui. La prima cosa da fare è capire come si imposta il contesto grafico, e arrivare alla mitica schermata monocolore. Da lì in avanti, lo sappiamo, è tutta in discesa... (chi ha detto caduta libera?)

Suppongo tu sappia già come funziona una applicazione Android, e se non lo sai, beh, sappilo. Mi riferisco a inezie tipo il concetto di Activity (non ti servirà comunque molto altro).

Quindi, il nostro progetto partirà con una Activity vuota ma funzionante. Per impostare il nostro contesto grafico ci occorrono essenzialmente due cose:

1. Una istanza della classe GLSurfaceView
2. Una implementazione dell'interfaccia GLSurfaceView.Renderer

La prima ce la fornisce il framework, ma in un progetto reale vorremo probabilmente ereditare da quella base per accedere alle notifiche dell'input utente e, in generale, avere maggiore controllo sulla vita dell'applicazione. Per ora possiamo accontentarci, ad ogni modo, di usarla così come è.

La seconda necessita invece di un po' di codice. GLSurfaceView.Renderer è l'interfaccia dell'oggetto che si occupa di creare il contesto opengl, gestirne i cambiamenti (risoluzione dello schermo) e disegnare il frame. Implementandola, dovremo scrivere il codice per i metodi:

public void onDrawFrame(GL10 gl);
public void onSurfaceChanged(GL10 gl, int width, int height);
public void onSurfaceCreated(GL10 gl, EGLConfig conf);

Dove GL10 è l'oggetto wrapper sulle API OpenGL (1.0).

Ecco una semplice implementazione:

public class MyRenderer implements Renderer {
 
 @Override
 public void onDrawFrame(GL10 gl) {
  gl.glClear(GL10.GL_COLOR_BUFFER_BIT | GL10.GL_DEPTH_BUFFER_BIT);
  
  gl.glMatrixMode(GL10.GL_MODELVIEW);
  gl.glLoadIdentity();
 }

 @Override
 public void onSurfaceChanged(GL10 gl, int w, int h) {
  gl.glViewport(0, 0, w, h);
  gl.glMatrixMode(GL10.GL_PROJECTION);
  gl.glLoadIdentity();
  GLU.gluPerspective(gl, 45f, (float)w / (float)h, 0.1f, 450f);
  gl.glMatrixMode(GL10.GL_MODELVIEW);
  gl.glLoadIdentity();
 }

 @Override
 public void onSurfaceCreated(GL10 gl, EGLConfig conf) {
  gl.glShadeModel(GL10.GL_SMOOTH);
  gl.glClearDepthf(1.0f);
  gl.glEnable(GL10.GL_DEPTH_TEST);
  gl.glDepthFunc(GL10.GL_LEQUAL);
  gl.glHint(GL10.GL_PERSPECTIVE_CORRECTION_HINT, GL10.GL_NICEST);
  gl.glClearColor(0.0f, 1.0f, 0.0f, 1.0f);
 }

}

Per un gioco 2D, naturalmente, imposteremo la GL_PROJECTION con una glOrtho, o gluOrtho2D... insomma, OpenGL rimane sempre lei.

Il main, oops, scusate, la OnCreate dell'Activity, resta banale:

public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        MyRenderer renderer = new MyRenderer();

        GLSurfaceView surface = new GLSurfaceView(this);
        surface.setRenderer(renderer);

        setContentView(surface);
}

Tutto quel che facciamo è istanziare il Renderer e la GLSurfaceView e passare a quest'ultima la nostra implementazione, quindi assegnare la View all'Activity.

E adesso via a scrivere il vostro gioco!

Unit Test in C++ con MiniCppUnit

Continua la carrellata di tool utilissimi e semplici da usare per arricchire la nostra cassetta degli attrezzi C++.

Dopo aver visto quanto sia facile fare parsing ed editing di documenti xml con TinyXML, vi segnalo una libreria molto pratica per lo unit testing: MiniCppUnit.

MiniCppUnit condivide con TinyXML l'approccio lib-free, ovvero non la trovate compilata come libreria da includere nel vostro progetto, ma come due semplici file (un header e la relativa implementazione) da aggiungere e compilare assieme al vostro codice (C++ standard, STL e nessuna dipendenza esterna... good!).

L'utilizzo segue la logica del più noto JUnit per Java, di cui esiste il porting C++, CppUnit, del quale il nostro MiniCppUnit non è altro che la versione semplificata. Per chi non conoscesse JUnit (o NUnit per .Net) facciamo un rapidissimo ripassino:

• si crea un progetto per il test di un altro progetto/classe/sottosistema
• si creano una o più classi speciali marcate come TestFixture e contenenti metodi marcati come Test
• si scrivono test basati sull'utilizzo di asserzioni
• si danno tutte le TestFixture in pasto ad un motore che le esegue e riporta i risultati (successo/fallimento)

NB: per info più precise sullo Unit Testing si veda la Rete.

Cosa mi fa testare?

MiniCppUnit permette di verificare vari tipi di asserzioni:

ASSERT(3==1+2);
ASSERT_MESSAGE( 2==1+1, "2 should be 1 plus 1 ");
ASSERT_EQUALS(expected, result);
ASSERT_EQUALS_EPSILON(expected, result, 0.05);

...e pure una macro sul controllo delle eccezioni!

Sono poche e semplici, ma sicuramente l'essenziale per mettere in piedi un sistema di testing più evoluto di un main con tanti cout, o peggio ancora di no tests at all.

Come lo lancio?

Il main è quanto di più banale possa esistere:

#include "MiniCppUnit.hxx"

int main()
{
   return TestFixtureFactory::theInstance().runTests() ? 0 : -1;
} 

Il singleton TestFixtureFactory va in automatico a prendersi tutte le classi TestFixture (registrate tramite apposita macro REGISTER_FIXTURE()) e le esegue, riportando il risultato in una schermata di console. Semplice, pratico e pulito.

Il pacchetto che scaricate, oltre ai due file da includere nel vostro progetto, contiene anche altri due file con un esempio d'uso, da cui ho preso il codice d'esempio. Sono più che sufficienti a togliere ogni dubbio residuo sull'utilizzo, ma se servisse altro c'è pure una ottima documentazione doxygen online.

Concludendo

Niente scuse, quindi: il vostro prossimo progetto C++ godrà di unit testing, perché if it ain't tested, it's broken!