by Njål

Grafiske grensesnitt i Java – Utvikling, installasjon og vedlikehold

What to choose… what to choose..

Dersom man skal utvikle en applikasjon som skal kjøre på Windows, Mac, Linux, Solaris etc. så er det ikke så ekstremt mange teknologier å velge i mellom. Java, QT og Mono er noen av kandidatene. Adobe Air er også en mulighet, men denne platformen har ekstremt dårlig ytelse, mangler støtte for flere tråder og dårlige grensensitt mot minne/disk. Har prøvd og forkastet. Mono har jeg aldri testet noe særlig, selv om jeg daglig sitter og koder C#. Skal definitivt sjekkes ut. Norske QT og deres C++ bibliotek/verktøy ser også veldig bra ut. Rå ytelse og mye bra omtale – visste du at Photoshop er utviklet i QT? Anyways… gjett hvilken teknologi hva vi valgte… crazy!

Utvikling med Java

Valget falt altså på Java når vi skulle utvikle noen Filemail applikasjoner for Windows/Mac/Linux. Vi har levert en del løsninger med Java før og visste på forhånd at vi ikke kom til å få nevneverdige problemer med ytelse. Et ganske trygt (men ikke direkte spennende) valg.

Utvikling av komprimering, hashing, kommunikasjon og filoverføring via egne protokoller gikk som fot i hose. Men vi ble fort gjort oppmerksom på GUI drawbacket til Java. Det er absolutt mulig å lage gode grafiske grensesnitt med Java, men det er tidkrevende i forhold til Windows Forms, Adobe Air, QT etc. Det kan også være litt tricky å få en Java applikasjon til å se ut som en native applikasjon (dvs. når den kjører på Mac så skal det se ut som en Mac applikasjon).

Etter litt fikling kom vi ca. i mål med et akseptabelt GUI (Netbeans + matisse + div 3. parts biblioteker):

Ikke superfett, men greit nok. (Applikasjonen lar folk sende store filer på 1-2-3. Brukes bl.a. av NRK, TV2 og VG. Sjekk www.filemail.com)

Innpakking og installasjon

Videre kom spørsmålet om installasjon av applikasjonen. En mulighet var å gjøre brukeren oppmerksom på at Java kreves, og la han/henne laste ned applikasjonen i form av en JAR fil. Ikke akkurat superelegant.

En bedre løsning som har fungert bra for oss er install4j. Denne applikasjonen tar JAR filen (programmet) og lager native install pakker for Windows, OS X og Linux. Videre finnes det mulighet for å inkludere Java VM’en i installasjonsfilen, slik at brukeren ikke får problemer dersom han/hun ikke har Java installert.

Det blir også generert .exe (.app /.sh) filer og snarveier for å starte applikasjonen etter at den er installert. Det eneste disse små launcher’ene gjør er å kjøre igang JAR filen som også blir installert. Uninstaller etc. blir også lagd. Nice.

Et annet alternativ for windows/linux er å bruke Excelsior JET – dette rekompilerer java programmet og java VM’en til en .exe/.sh fil. En fordel med denne kompileringen er at koden blir obfuskert (nesten umulig å dekompilere), samtidig som det er en ulempe at .exe/.sh filen blir ganske stor ettersom java vm’en inkluderes.

Oppdateringer og vedlikehold

Ettersom det er JAR filen som er selve programmet, er det relative lett å implementere oppdateringsfunksjonalitet. Det er bare å få applikasjonen selv til å hente ned en ny JAR fil, starte på nytt – og vips så er den oppdatert til nyeste versjon – på alle platformer!

Final words

Neste gang faller kanskje valget på QT når vi skal utvikle en applikasjon for flere platformer. Dette virker veldig spennende, man har mange muligheter og få begrensninger. Det ser også produktivt ut.

Hvilke teknologier benytter du for å lage applikasjoner som skal kjøre på flere platformer? Tips og triks mottas med takk!

Tags: