VCards and QRCodes

Voor mijn werkgever hebben we visite kaartjes met een QRCode ontwikkeld. Deze QRCode bevat een link naar een website waar de VCard van de medewerker te downloaden is. Een VCard is een standaard http://en.wikipedia.org/wiki/VCard voor electronische Business Cards.

WP_20130417_001

Het idee van de QRCode was dat je VCard van de medewerker kunt downloaden en de Prodware medewerker eenvoudig kunt toevoegen aan je adresboek. We hadden de VCard kunnen opnemen in de QRCode, maar dan zou de QRCode ook moeten veranderen als de medewerker een nieuwe functie krijgt of mobiel nummer etc. Dat leek ons niet handig. Daarom hebben we gekozen om naar een website te gaan, waar je de VCard kunt downloaden.

Voor het maken van de QRCode hebben we gebruik gemaakt van de standaard ZXING barcode library (http://code.google.com/p/zxing/downloads/list). Maar Prodware is een Microsoft georienteerd bedrijf en dus hadden we de C# variant van deze lib nodig. Geen probleem daar is een Nuget package voor (https://nuget.org/packages/ZXing).

De code snippet om de code te maken is relatief simpel.

image

Overigens kun je deze library ook gebruiken om een QRCode/Barcode scanner in je WP8 of Windows 8 app in te bouwen. Ik heb dat nu voor twee demo’s gedaan, daarover later meer.

De VCard standaard is handig, maar heeft een probleem. In de loop der tijd zijn de internet browsers argwanend geworden mbt een VCard. Op je gewone Windows 8/Windows 7 computer kun je de VCard zonder problemen downloaden en de data toevoegen aan je adresboek van Windows of Outlook. Dat werkt ook zo op een Windows Phone 7.x. Maar Windows Phone 8, Android en iPhone behandelen een VCard niet zoals je zou verwachten, er is geen standaard applicatie gekoppeld aan de extensie etc.

Omdat probleem op te lossen moest ik op zoek naar een oplossing. Wat blijkt nu, als de VCard via de mail komt, dan werkt het allemaal wel. Dus wordt de website zo aangepast, dat je de mogelijkheid krijgt om de VCard te mailen. Maar dat willen we natuurlijk wel afhankelijk maken van het device.

Mobile:

wp_ss_20130417_0004 wp_ss_20130417_0001

Desktop:

wp_ss_20130417_0002 wp_ss_20130417_0003

Dit is heel simpel te doen in C# en MVC 4. Sowieso gaat MVC 4 al beter om met het tonen van de site in een mobiele browser. In de view neem je deze code op.

image

image

Probleem opgelost. Nu nog even deployen naar onze on-premise server. De test omgeving draait uiteraard op Windows Azure 😉

Silverlight vs HTML5

Een collega MVP-ers mailde eens: “I’ve got friends that were heavy into SL development that now do none. It’s gone from their #1 technology to now being banned for development within their company. What changed? The first time that one of their clients said “now show me how it looks on my iPad” and they had no answer.”

Dit geldt overigens voor mijn gevoel voor elke plugin gebasseerde technologie (Flash, Java (tot op zekere hoogte)). Het succes van iPad en de combi iPad/Safari laat de kwetsbaarheid zien van tooling die afhankelijk is van functionaliteit van browser plugin’s.

Het lijkt mij niet verstandig om een plugin gebasseerde technologie nog aan te prijzen bij een SAAS product. Is het een on premise oplossing met strakke regie op hardware/software of de besturingsconsole van een groot apparaat (dat niet remote overgenomen hoeft te worden) dan zou ik zeker bouwen met Silverlight en valt de weegschaal naar de andere kant uit.

Maar ook waar geldt ‘bring your own device’ (nb waarbij device ook een browser of choice zou kunnen zijn) maakt een plugin gebasseerde technologie niet meteen een first class choice of een no brainer.

Kort gezegd: bij software in een SAAS omgeving dan is een plugin based technologie niet handig, tenzij je regie kunt uitoefenen op de client of hardware gebonden (zoals bijv Windows Phone, Xbox etc).

Een klant van ons, deze heeft ook een SAAS product, heeft ervoor gekozen om hun product te ontwikkelen in Silverlight. Met als reden dat deze technologie voldoende volwassen is en zij hun klanten best tot de Silverlight plugin kunnen verplichten. Ook vonden zij het belangrijk dat hun klanten moesten kunnen kiezen voor een lokaal geïnstalleerde out-of-browser applicatie.

Ten aanzien van mobiele devices zal het (vermoedelijk) nooit zo zijn, dat alle functionaliteiten van een client product via een dergelijk platform beschikbaar gemaakt zal worden. Meestal gaat het om delen of deelgebieden van een product, waarbij het device zijn pros ten volle kan benutten. iPad is bijzonder als het gaat om de web browser. De overige mobiele devices hebben vaak te kleine schermen, waar de volledige functionaliteit niet tot zijn recht komt en nauwelijks bruikbaar.

Ik ben in elk geval wel van mening, dat de keuze tussen Silverlight en HTML5 geen zwart-wit keuze is.

Ik hoor graag in de comments wat jullie mening is.