• [ << ]
  • [ 0 ]
  • [ 1 ]
  • [ 2 ]
  • [ 3 ]
  • [ >> ]
Oct '03
05

Java GUI's : Disaster Area ?


Ondanks dat iedere zichzelf respecterende Java ontwikkel omgeving een Grafische User Interface (GUI) teken pakket in zich heeft blijft het ontwikkelen van Java Swing GUI's significant meer tijd kosten dan een vergelijkbare Windows user interface in Delphi of .Net.
Dit artikel probeert mogelijke verklaringen hiervoor te vinden en doet een aantal suggesties voor een alternatieve aanpak.

Junior doet de GUI

Laten we de junior de User Interface doen is een veel gehoorde kreet. Met een Visual Basic of Delphi is dat een prima idee. Behoorlijk intuitief, weinig echte weetjes en direct zichtbaar resultaat van zijn werk. Perfect! Echter in Java moeten er naast wat geteken allerlei event handlers geļæ½mplementeerd worden. Daarnaast doen Swing componenten zelden wat je precies wilt. Dus voor je het weet heeft junior zijn eerste aangepaste component al geschreven. En dan gaan we het nog niet hebben het sorteerbaar maken van tabellen... Het resultaat moge duidelijk zijn: een (meestal) werkende maar volslagen niet onderhoudbare user interface. Gelukkig kunnen we daarvoor het broertje van junior inhuren..

Moet er dan een ervaren programmeur schermpjes gaan zitten maken? Tja, de meeste ervaren programmeurs hebben betere en spannendere dingen te doen. Echter, iemand met ervaring, visie en wat tijd in de buurt kan de productiviteit en kwaliteit aanzienlijk verbeteren.

To Swing or not To Swing

Swing is de defacto standaard voor Java GUI's. Het zit er namelijk standaard bij. Dat wil echter niet zeggen dat het niet zo z'n problemen kent. Veel mensen klagen dat het niet af is en inderdaad sommige dingen moet je inderdaad zelf maken. Gelukkig is voor het meeste een uitbreidings punt voorzien in het systeem zodat dat ook makkelijk gaat. Nadeel is natuurlijk wel weer dat je ze moet zien te vinden en dat kost tijd. Maar met iedere nieuwe versie van Java wordt Swing weer een stukje beter.

Er zijn alternatieve systemen om gebruikers interfaces te maken. Uiteraard de Abstract Window Toolkit (AWT), ook standaard erbij in Java, alleen die gebruikt alleen de (native) componenten die op alle desktop platformen waarop Java draait beschikbaar zijn. Wat automatisch betekent dat je geen dingen zoals tabellen en tree-controls hebt. Wel een voordeel is dat het relatief weinig overhead met zich mee brengt aangezien het grootste deel van het werk door het onderliggende operating system wordt gedaan.

Swing heeft wel de beschikking over tabellen en tree-controls, want alle componenten zijn in Java zelf gebouwd. Het fijne daarvan is dat je (nagenoeg :-) 100 % controle kan hebben over hoe componenten zich gedragen en er uit zien. Je kan ze ook aan aanpassen. Echter de standaard implementatie lijkt functioneel en visueel wel op de native componenten van het operating system maar zijn het vaak (net) niet. Tot grote frustratie van gebruikers.

Het derde alternatief is de SWT - Standard Widget Toolkit - die een best of both worlds scenario hanteert : Als het native component beschikbaar is gebruik je dat en anders implementeer je het component zelf in Java. De SWT is overigens geen standaard Java, maar een herbruikbaar onderdeel van het (open source) Eclipse platform, een Java ontwikkel omgeving. De SWT maakt gebruik van een platform afhankelijke module, die gelukkig voor veel operating systems beschikbaar is. (Zie http://www.eclipse.org voor meer informatie.)

Vaak wordt bij project niet van te voren nagedacht welk systeem het beste geschikt is voor de GUI en wordt direct voor Swing gekozen. Dat is niet altijd de beste keuze.

Alle GUI logica zit in.. het Scherm zelf.

Een nieuw scherm is... een soort van scherm denkt de gemiddelde GUI programmeur met Object Orientatie (OO) kennis. Zo ook de meeste GUI tekenpakketen (Java en niet Java). Vervolgens wordt gesteld, volgens 'goede' OO regels, alle bijbehorende scherm logica ook in dat scherm geprogrammeerd moeten worden. Goed idee. Totdat. Er door voortschrijdend inzicht of een gesprek met een aanstaande gebruiker besloten word om delen van het scherm te verplaatsen naar bijvoorbeeld een ander scherm. Aangezien alles een geheel vormt wordt dat al heel snel een behoorlijke wijziging.

Een alternatieve strategie zou kunnen zijn om GUI functionaliteit op panel niveau te realiseren. Een verzameling van componenten die gecombineerd een functie hebben binnen de applicatie zoals het bewerken van een business object. Het voordeel is dat een paneel gemakkelijk herplaatst en nog een keer geplaatst kan worden in tegenstelling tot een compleet scherm. Nadeel is natuurlijk wel dat je er van te voren over moet nadenken :-)

  • [ << ]
  • [ 0 ]
  • [ 1 ]
  • [ 2 ]
  • [ 3 ]
  • [ >> ]