Technology Experience
.NET WorldVisualStudioTips.net

[Ammy.5] Modifiche a runtime del codice

Il linguaggio Ammy supporta una feature a mio avviso straordinaria, anche se ad oggi presenta dei piccoli bug, già segnalati.

Mentre la vostra applicazione WPF è in running, potete tranquillamente continuare a lavorare sul codice della UI – scritta in Ammy – senza interromperne l’esecuzione.

Per farlo, il runtime di Ammy utilizza i socket. Ecco il motivo per cui la prima volta che fate F5 con Visual Studio il firewall di Windows intercetta la comunicazione di rete:

image

Ovviamente dovete cliccare su Consenti accesso. Fatto questo potete mantenere l’applicazione in esecuzione (magari su un monitor secondario), tornare in Visual Studio ed editare in tutta libertà il codice Ammy. Ogni volta che salverete il file, Visual Studio scatenerà un refresh della Window.

Sulla homepage ufficiale di Ammy c’è un bel video di poco meno di 30 minuti che vi mostra questa caratteristica del linguaggio. Cito testualmente dalla fonte: “Note that application was always running during the development, never needing to restart”.

Voglio farvi notare un’ultima cosa, prima di salutarvi. Nell’editor di codice Ammy c’è un pallino che indica la validità del codice Ammy (lo ricordo, che riprende la sintassi dal JSON). Quindi:

  • Pallino verde: tutto ok
  • Pallino rosso: qualcosa non va in Ammy

image

Personalmente, ad oggi trovo piuttosto ostico scrivere Ammy. Dopo 10 anni di XAML, è dura cambiare linguaggio per la UI, ma i vantaggi ci sono, cerco di adeguarmi, per cui butto sempre un occhio a questo indicatore per avere una conferma visiva. Per ora non sto usando Ammy in alcun progetto reale per un cliente, ma non si sa mai.

Ok! Mi hai detto che ci sono dei bug, quali sono?
I bug di Ammy sono tanti, essendo un linguaggio in fase di sviluppo. Per rimanere sul tema di questo post, accade la seguente cosa. Supponiamo di avere un po’ di code-behind, legato ad un evento di un qualsiasi controllo della UI. Ricordate la PasswordBox di cui abbiamo parlato nell’ultimo post? Supponiamo di sottoscriverne l’evento PasswordChanged.

PasswordBox {
    #Cell(1, 1),
    VerticalAlignment: Center,
    HorizontalAlignment: Stretch,
    PasswordChanged: "changed"
}

E’ esattamente come faremmo con lo XAML. L’intellisense ci viene in aiuto, fino ad un certo punto. Purtroppo dobbiamo scrivere noi l’event handler legato a questo evento. Una volta che avete sottoscritto l’evento e predisposto l’event handler nel code-behind, ovviamente tutto funziona. Fate per scrivere una password, e passate dal codice del vostro handler. Nulla di strano fino a qua.

Se successivamente modificate il codice Ammy a run-time e salvate, la Windows viene aggiornata, ma l’event handler si sgancia. Morale: dovete stoppare e riavviare l’applicazione. Da tener presente che tutto questo accade se lavorate con eventi ed un po’ di code-behind. Se approcciate con MVVM il problema non si pone, ma c’è comunque.

Happy coding!

Send to Kindle

Igor Damiani

La sua passione per l'informatica nasce nella prima metà degli anni '80, quando suo padre acquistò un Texas Instruments TI-99. Da allora ha continuato a seguire l'evoluzione sia hardware che software avvenuta nel corso degli anni. E' un utente, un videogiocatore ed uno sviluppatore software a tempo pieno. Igor ha lavorato e lavora anche oggi con le più moderne tecnologie Microsoft per lo sviluppo di applicazioni: .NET Framework, XAML, Universal Windows Platform, su diverse piattaforme, tra cui spiccano Windows 10 piattaforme mobile. Numerose sono le app che Igor ha creato e pubblicato sul marketplace sotto il nome VivendoByte, suo personale marchio di fabbrica. Adora mantenere i contatti attraverso Twitter e soprattutto attraverso gli eventi delle community .NET.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.