Digital samhandling

Det skulle være to typer funksjonalitet i applikasjonen:

• søke frem produsenter hos Matvaretilsynet for å se detaljinformasjon
• hente frem informasjon om alle merker en produsent hadde.

Elektronisk samhandling er veldig i vinden om dagen, men det er åpenbart at veldig mange har veldig mye å lære når det gjelder hva dette innebærer. Tilgjengeligheten på tjenestene fra Mattilsynet sett fra en programmerer si ståsted er ekstremt dårlig. De to kallene jeg behøvde å gjøre hadde et API som ikke lignet i det hele tatt. Det kunne like gjerne vært fra to ulike aktører. Dette er selvsagt altfor dårlig. Elektronisk samhandling er mulig dersom aktørene forstår hva slags ansvar det innebærer og er profesjonelle nok til å sørge for å ha konsistente APIer på tvers av sine tjenester.

Enkel brukerflate for en enkel applikasjon

Applikasjonen består av to helt enkle skjermbilder hvor brukerne kan søke frem produsenter. Begge skjermbildene var med i første leveranse som ble utviklet.

En utfordring ved å benytte WebServices støtten i Flex 3 er manglende støtte for vanlig HTTP autentisering, men takket være god hjelp fra andre utviklere som har vært i samme situasjon var dette løst raskt. Utover dette var det datamengden i skjermbildet for visning av antallet merker som var en stor utfordring og er noe som skal løses i kommende leveranser.

Tur-retur på fire timer

Hurtig utvikling ved hjelp av Flex rammeverket kombinert med AIR teknologien gjorde det mulig å implementere og installere hos kunden en applikasjon i løpet av 4 timer. Siden den gang har applikasjonen blitt utvidet med mer funksjonalitet, men dette har vært tillegg og ikke store omskrivninger. Du kan jobbe utrolig raskt og med høy kvalitet takket være Flex rammeverket’s muligheter til å bygge datadrevne applikasjoner. Å ta en rask prototype for så å bygge den ut er enkelt når du følger dette ene prinsippet.

Overgangen fra prototype til ferdig applikasjon opphører og det sparer en for tid og penger. AIR rammeverket sin innebygde støtte for automatisk oppdatering gjør det enkelt å stadig legge ut nye versjoner til brukerne uten at det blir noen drift- eller forvaltningskostnader i forbindelse med utrullingen.

Å starte med Flex er ikke noe stort problem og de fleste utviklere klarer veldig lett å komme igang med å lage applikasjoner. Tilsvarende lett er det å gå i en del fallgruver og gjøre en del feil. Jeg har arbeidet med Flex en stund og har dermed også vært nedi de fleste fallgruvene. Derfor tenkte jeg å dele noen av mine beste tips og triks som jeg har lært meg til å bruke for å ennå raskere levere Flex applikasjoner.

• Ha alltid en modell i bunnen også når du lager mockups og prototyper.
• Data Driven Application Design: sørg for at det alltid er dataene som driver applikasjonen din ved hjelp av data binding
• Les dokumentasjonen om klassen Binding Utils og sørg for å laste ned koden til Observere og ObervereValue.
• Logging: lag deg en logger som gjør det mulig for andre brukere og sende deg logg når det oppstår feil situasjoner. Et slikt eksempel er en logger som bruke Firebug.
• Evolutionary Application Architecture: ikke bygge rammeverk og komponenter i tilfelle du trenger de. Flex rammeverket gjør det veldig enkelt å gradvis bygge ut en prototype til en ferdig applikasjon. Lag for eksempel aldri en gjenbrukbar komponent før du faktisk skal bruke den for andre gang.

Mange av disse tingene vil du kanskje si at er vanlige regler for god systemutvikling, og det er selvsagt helt riktig. Likevel er det viktig å påpeke at disse tingene selvsagt også gjelder når man jobber med Flex. Det er veldig lett å tro at fordi det er en ny teknologi så gjør man ting anderledes. Å følge prinsippene i objekt orientert programmering (OOP) gjør det enklere å utvikler og vedlikeholde Flex applikasjoner også.

Test drevet Flex utvikling

Mange spør meg om hvordan kan man drive testdervet utvikling når man jobber med Flex. Svaret ligger i tipsene ovenfor, nemlig å ha en data drevet applikasjon hvor hendelser i grensesnittet gjøres gjennom å manipulere en modell klasse. Hvis du gjør dette gjennom å implementere presentation model mønsteret vil du merke at å jobbe test drevet ikke er noe problem i Flex.

Gjennom å ha en modell klasse som brukes til å manipulere data (og dermed også grensesnittet) kan du veldig enkelt skrive enhetstester for modell klassen. Dermed får du dokumentert oppførselen i applikasjonen gjennom testene samtidig som kvaliteten på koden din øker. Min gode venn Børre Wessel har holdt en presentasjon på Scotch On The Rock hvor han snakker om hvordan du implementerer presentation model mønsteret i Action Script.
Anbefalt lesning om testing av grensesnitt er artikkelserien til Adobe Consulting’s Paul Williams som tar for seg en lang rekke mønster som gjør testing av Flex applikasjoner enklere.

Dette fordi det rett og slett ikke var nok påmeldte. Det er ikke på grunn av manglende interesse blant utviklere eller selskaper rundt om i Norge, men snarere på grunn av litt problemer rundt organiseringen av eventen som gjorde at vi kom litt vel sent i gang. Derfor vil Flex Camp nok bli arrangert en gang i starten av 2009 i stedet. Takk til alle som har vist interesse for Flex Camp og beklager…

Demo applikasjonen

I tillegg til denne artikkelen har jeg laget en ekstremt enkel demo applikasjon som kan brukes som utgangspunkt for videre abreid. Applikasjonen er ekstremt enkel og er en applikasjon for å samle noteter og lenker.
Demo applikasjonen inneholder en Flex 3 Web- og AIR applikasjon og en standard Java web applikasjon.

Alt du trenger å gjøre er å pakke ut filene og kjøre to enkle kommandoer. Sørg for at du har installert følgende programvare:

• Maven
• Java 1.6.x or later
• Flash Player 9

Når du har disse tingene installert så er det bare å følge instruksjonene nedenfor:

1. Last ned kildekoden til eksempelet: Blaze POC v3
2. Pakk ut ZIP filen til en katalog
3. Åpne filen deploy/blazeds-poc.properties og endre linjen med echo.db.path slik at den passer med stedet du pakket ut kildekoden
4. Åpne en command promt of kjør scriptet install-flex-libs
   Dette scriptet installerer alle BlazeDS JAR-filer i ditt Maven repository
   
5. Åpne command prompt og kjør følgende: mvn install
6. Gå til katalogen blaze-poc-web og kjør kommandoen: mvn jetty:run
7. Åpne adressen: http://localhost:8081/blaze-poc-web/

Nå som du har sett eksempel applikasjonen er du kanskje interresert i å vite hvordan man konfigurerer BlazeDS? Bare fortsett å les så skal vi se litt på hvordan dette gjøres. For at du skal kunne bygge Flex versjonen bør du installere Flex Builder 3. Alt du trenger for å kunne bygge et Flex prosjekt er Flex SDK’en som er tilgjengelig som Open Source. Likevel vil jeg anbefale å installere Flex Builder 3 som gir deg mange fordeler når du jobber med Flex og hjelper deg til å jobbe langt raskere. Du kan bruke Flex Builder gratis i over 30 dager før du bestemmer deg.

Konfigurere BlazeDS i en Java webapplikasjon

Opprett en Java web applikasjon i Eclipse (du kan bruke MyEclipse or eller lignende for å gjøre jobben enklere). Last ned siste versjon av BlazeDS og pakk ut filene et sted på din maskin. Filen blazeds.war pakker du ut i rot katalogen av din webapplikasjon. Du skal ha følgende struktur:

WEB-INF\flex
WEB-INF\lib
meta-inf

Slett alle JAR-filene i WEB-INF/lib katalogen. Disse filene trenger vi ikke ettersom Maven skal ta hånd om avhengighetene. Adobe virker ikke særlig interessert i Maven og har derfor ikke publisert offesielle BlazeDS artifakter til noe Maven deopt. Derfor ligger det ved et script som installerer BlazeDS artifaktene i ditt lokale Maven depot (takket være Per-Otto).

Spring and BlazeDS

BlazeDS kan veldig enkelt integreres med Spring Framework for å hjelpe deg til å utvikle spennende tjenester ennå raskere. Alt du trenger å gjøre er å lage en SpringFactory klasse. Christophe Coenrates har skrevet artikkelen Using Flex and Spring som beskriver detaljene i hvordan dette gjøres. I eksempel prosjektet er det en SpringFactory klasse som er konfigurert i filen WEB-INF/flex/services-config.xml

<factories>
  <factory id="spring" class="com.moneytalks.blaze.poc.SpringFactory"/>
</factories>

Hvordan du best konfigurerer tjenestene i Blaze DS

Remote Object kalles teknologien som gjør det mulig å invokere metoder på Java klasser direkte fra Action Script. Rådet fra Adobe er at du skal legge med et kompilator argument, -services, som forteller MXML kompilatoren hvor BlazeDS konfigurasjonen ligger. Dette mener jeg er et veldig dårlig råd ettersom det tving deg til å ha samme katalogstruktur i alle miljøer du har tenkt å rulle ut din applikasjon.
En langt bedre og mer fleksibel løsninger er å sende konfigurasjonsparameter for Remote Object- og Messaging services ved bruk av Flash Vars. Dette gjør det meget enkelt å endre konfigurasjon for endpoints, fil stier, server navn, osv i ulike miljøer. Denne måten å løse dette på ble jeg først oppmerksom på etter å ha lest Mike Nimer sin artikkel Bye bye -services.

La utviklingen begynne!

Det er igrunn alt du trenger å vite for at du skal kunne begynne utvikle løsninger med BlazeDS. Du vil forhåpentligvis få en langt mer harmonisk hverdag hvor fokus ligger på å utvikle spennende tjenester for dine brukere snarer enn å skrive boiler plate kode som flytter data fra A til B.

Mer informasjon om BlazeDS og hvordan du kan bruke det kan du finne på noen av lenkene nedenfor:

• BlazeDS hos opensource.adobe.com
• Christophe Coenraets sin blog har veldig mange eksempler på hvordan du kan bruke BlazeDS

Artikkelen er også tilgjengelig på engelsk og i tillegg publisert hos ITPro.no