Bild

B-Wise XA - MobileClient: Native App

Unterstützung aller Eigenschaften der Zielplattform

Der Mo­bi­leC­li­ent ist eine na­ti­ve An­wen­dung (d.h. eine An­wen­dung, die in der Tech­no­lo­gie bzw. Pro­gram­mier­spra­che der je­wei­li­gen Platt­form im­ple­men­tiert ist), die Zu­griff auf alle im ent­spre­chen­den Gerät ver­bau­ten Kom­po­nen­ten hat. Die­se wer­den über ein ab­stra­hier­tes API (App­li­ca­ti­on Pro­gram­ming In­ter­face) an­ge­steu­ert, so dass z.B. eine Ka­me­ra auf dem iPho­ne vom Ser­ver aus mit den­sel­ben Be­feh­len an­ge­spro­chen wer­den kann wie eine Ka­me­ra auf ei­nem An­dro­id- oder ei­nem WP7-Gerät. Das­sel­be gilt für alle an­de­ren Kom­po­nen­ten wie z.B. GPS-Sen­sor oder das Te­le­fon.

Gerätespezifisches Look&Feel

Auch die De­fi­ni­ti­on der Dia­lo­ge bzw. An­zei­ge­sei­ten er­folgt für alle Gerä­te nur ein­mal, gleich­gül­tig, ob es sich um ein iOS-Gerät (z.B. iPho­ne oder iPad), ein An­dro­id-Gerät (z.B. Sam­sung Gala­xy S) oder ein Win­dows Pho­ne 7-Gerät han­delt. Da der B-Wi­se XA Ser­ver eine in­halt­li­che bzw. struk­tu­rel­le De­fi­ni­ti­on, nicht je­doch eine Lay­out-De­fi­ni­ti­on vor­gibt, kann der ent­spre­chen­de Dia­log auf je­dem Gerät mit den ge­rä­te­s­pe­zi­fi­schen Merk­ma­len und im Sti­le des je­weil­gen Geräts ge­ren­dert wer­den.

Ne­ben den platt­for­m­über­grei­fen­den APIs und dem Dia­lo­gren­de­ring ste­hen ggf. wei­te­re, platt­forms­pe­zi­fi­sche Schnitt­stel­len zur Ver­fü­gung, so dass alle Mög­lich­kei­ten des je­wei­li­gen Geräts op­ti­mal ge­nutzt wer­den kön­nen. So wer­den bei­spiels­wei­se auf dem iPad auch PopUp-Dia­lo­ge, der Sp­lit-Con­tai­ner so­wie wei­te­re spe­zi­fi­sche Ele­men­te un­ter­stützt. Das­sel­be gilt für die Ta­blet­t-Ver­si­on von An­dro­id (Ver­si­on 3.0, "Ho­ney­comb" oder 4.0 "Ice Cream Sand­wich").

Einfache, flexible und mächtige Dialogdefinition

Die platt­for­m­neu­tra­le bzw. in­halt­lich-struk­tu­rel­le De­fi­ni­ti­on der Dia­lo­ge er­folgt mit Hil­fe der in B-Wi­se XA be­währ­ten Aus­zeich­nungs­spra­che BML. Da­bei han­delt es sich um die­sel­be Aus­zeich­nungs­spra­che, die auch für die De­fi­ni­ti­on von Dia­lo­gen und An­zei­ge­sei­ten auf dem Desktop (Win­dows) ver­wen­det wird. Da­mit muss der Ent­wick­ler kei­ne neue Spra­che und kei­ne neu­en Ent­wick­lungs­kon­zep­te ler­nen. Die Ent­wick­lung der Be­nut­ze­ro­ber­flä­che für iPho­ne, iPad, An­dro­id, Win­dows Pho­ne 7 oder Win­dows er­fol­gen da­her mit ei­ner ein­heit­li­chen Tech­no­lo­gie an­statt mit un­ter­schied­li­chen Spra­chen und Kon­zep­ten wie Ob­jec­ti­ve-C, Ja­va/Dal­vik, Sil­ver­light, Win­dows Forms oder XCo­de.

Das nachfolgende Beispiel zeigt einen einfachen Dialog in BML, der sowohl für mobile Geräte (Smartphoens oder Tablets) als auch Windows-Systeme wie Laptops oder Desktop-Rechner verwendet werden kann (das layout auf einem Desktop-Gerät kann dabei mit Hilfe von Layout- bzw. Styling-Dateien beeinflusst werden):

<?xml version="1.0" encoding="iso-8859-1"?>
<bw:portlet
  xmlns:bw="http://www.biss-net.com/2001/bwise/ehtml"
  id="VIP_Mobile_HauptPortal"
  title="Hauptportal"
  target="cont">

  <bw:include src="VIP_Mobile_Standards.pts" />

  <bw:mlist id="LI_1">
	<bw:mcontent>
		<bw:mdata element="Prozesse.*Group">
			<bw:mgroup title="{.Label1}" id="{.ID}" element=".Children.*Group">
				<bw:mli access="expand" id="{.ID}">
					<bw:mlii src="{path('images/*/proc.png')}"/>
					<bw:mlit><bw:var expr=".Label1"/></bw:mlit>
					<bw:mlid><bw:var expr=".Label2"/></bw:mlid>
				</bw:mli>
			</bw:mgroup>
		</bw:mdata>
	</bw:mcontent>
	<bw:events>
		<bw:event name="validate" method="{event( 'processSelected', '@lid')}"
			category="vcaction" />
	</bw:events>
  </bw:mlist>

</bw:portlet>

Auch hier hat der Ent­wick­ler je­doch die Mög­lich­keit, die Be­son­der­hei­ten ein­zel­ner Gerä­te zu nut­zen, in dem er die ent­spre­chen­den platt­forms­pe­zi­fi­schen Ele­men­te ein­setzt. Wird eine An­wen­dung für eine Viel­zahl von Platt­for­men ent­wi­ckelt, las­sen sich die­se spe­zi­el­len Ele­men­te wie oben ge­zeigt kap­seln. Er­folgt die Ent­wick­lung le­dig­lich für eine ein­zel­ne Platt­form (z.B. für die fir­me­nei­ge­nen iPho­nes), so kön­nen auch alle Be­son­der­hei­ten der je­wei­li­gen Platt­form voll ge­nutzt wer­den.

Rei­chen also die neu­tra­len APIs für die ent­spre­chen­de An­wen­dung nicht aus, kann auf den ge­sam­ten Fun­dus an Funk­tio­nen des je­wei­li­gen End­ge­räts zu­ge­grif­fen wer­den. Im Quell­co­de kön­nen die­se, ggf. nur ver­ein­zel­ten, API-Funk­tio­nen mit Platt­for­m-s­pe­zi­fi­schen Be­din­gun­gen ge­kap­selt wer­den, wie im fol­gen­den Bei­spiel ge­zeigt:

<bw:if expr="Android and Version > 3">
	<!-- Android ab Version 3 spezifisches Markup -->
<bw:if>
<!-- Markup für alle Versionen und Betriebssysteme -->