Leestijd 6 min

Christophe Senesael

Mobiele ontwikkeling is tegenwoordig veel complexer en functioneler dan tien jaar geleden. Wat ooit begon als eenvoudige projecten met een paar functies zijn nu geëvolueerd tot geavanceerde systemen met alles van biometrische authenticatie en AI tot geavanceerde camera-integraties. Deze groei vereist een architectuurstrategie die de complexiteit effectief beheert met behoud van codebases van hoge kwaliteit. In dit artikel verkennen we een robuuste architecturale oplossing voor deze uitdaging: een modulaire of samenstelbare architectuur in mobiele ontwikkeling, geïnspireerd op de microservicearchitectuur die gangbaar is in backendontwikkeling. Wat is een modulaire architectuur? Net als bij microservices splitsen we een grote applicatie op in kleine, gerichte mobiele bibliotheken, die zich elk richten op een specifiek domein of een specifieke functionaliteit. Deze modulaire architectuur maakt het mogelijk om meerdere applicaties te bouwen met behulp van deze herbruikbare componenten, waarbij ervoor wordt gezorgd dat elke module losjes gekoppeld blijft. Dit maximaliseert de flexibiliteit, testbaarheid en aanpasbaarheid van elke component. Laten we eens dieper ingaan op de voordelen van een modulaire architectuur bij mobiele ontwikkeling. Waarom een modulaire architectuur gebruiken bij mobiele ontwikkeling? Separation of Concern afdwingen met een modulaire architectuur Het gebruik van een modulaire architectuur bij mobiele ontwikkeling zorgt voor een duidelijke scheiding van zorgen. Dit gaat verder dan de onderliggende code tot de organisatiestructuur van het project. Elke module functioneert als een op zichzelf staande eenheid, die een afzonderlijk verantwoordelijkheidsdomein vertegenwoordigt en afzonderlijk wordt ontwikkeld en onderhouden. Dit verbetert niet alleen de leesbaarheid en beheersbaarheid van het project, maar stroomlijnt ook de samenwerking en het debuggen. Bijgevolg creëert de ontwerpfilosofie van de modulaire architectuur een samenhangend systeem waarin de grenzen van de componenten onmiddellijk duidelijk zijn, zelfs zonder in de codebase te duiken. Modulaire architectuur bevordert herbruikbaarheid en onderhoudbaarheid van code Een modulaire architectuur verduidelijkt de projectstructuur en bevordert de herbruikbaarheid en onderhoudbaarheid van de code aanzienlijk. Door de app op te delen in modules creëren we herbruikbare componenten die kunnen worden geïntegreerd in verschillende delen van de applicatie of zelfs in geheel nieuwe projecten. Dit hergebruik van code minimaliseert overbodig werk, waardoor ontwikkelaars zich kunnen richten op innovatie in plaats van het wiel opnieuw uit te vinden voor elke nieuwe functie. Bovendien vereenvoudigt een modulaire architectuur het onderhoud en updaten van apps. Modules werken onafhankelijk van elkaar, waardoor verbeteringen of fixes op de ene module kunnen worden toegepast zonder andere modules onbedoeld te verstoren. Deze scheiding vereenvoudigt het testen en maakt gerichte validatie van wijzigingen mogelijk, wat zorgt voor een stabielere en betrouwbaardere applicatie. Het resultaat is dat de modulaire aanpak een codebase oplevert die niet alleen robuuster is, maar ook flexibeler, zodat de app zich snel kan aanpassen aan nieuwe vereisten of technologische vooruitgang. Modulaire architectuur verbetert testbaarheid Een van de grootste voordelen van een modulaire architectuur in grote mobiele ontwikkelingsprojecten is de verbeterde testbaarheid. In grote monolithische mobiele projecten kunnen bouwtijden aanzienlijk zijn, wat vaak resulteert in inefficiënte workflows. Stel je bijvoorbeeld voor dat je werkt aan een grote Xamarin-applicatie zonder hot reload-mogelijkheid. Als de UI zich misdraagt, moet je de hele applicatie bouwen en de hele flow doorlopen. En als deze flow afhankelijk is van web calls die worden onderhouden door een klantenteam, dan weet je dat je te maken hebt met een ongelooflijk tijdrovend en inefficiënt proces. Voordelen van modulaire architectuur bij mobiel testen Het gebruik van een modulaire architectuur voor je mobiele ontwikkelingsprojecten biedt een reeks belangrijke voordelen op het gebied van testen: Geïsoleerd testen Met een modulaire architectuur kun je alle gegevensafhankelijkheden van een module mocken en deze testen als een op zichzelf staande app. Deze isolatie maakt het mogelijk om gericht te testen op specifieke functionaliteiten zonder de overhead van het draaien van de hele applicatie. Kortere bouwtijden Het bouwen van de hele applicatie voor elke wijziging is niet nodig, waardoor de end-to-end testtijden aanzienlijk worden verkort. Deze efficiëntie leidt tot snellere ontwikkelcycli en snellere iteratie, cruciaal voor het behouden van een hoge productiviteit. Stabiele testomgeving Het ontkoppelen van modules minimaliseert het risico dat de ene component de andere beïnvloedt, wat zorgt voor betrouwbaardere tests en eenvoudiger opsporen van bugs. Parallel ontwikkelen en testen Teams kunnen verschillende modules gelijktijdig ontwikkelen en testen zonder te wachten tot een gedeelde codebase gestabiliseerd is, waardoor het ontwikkelproces versnelt en dynamische, flexibele workflows mogelijk worden. Een modulaire architectuur resulteert in een efficiënter, betrouwbaarder en schaalbaarder mobiel ontwikkelproces en beperkt de risico's van monolithische architecturen. Door te focussen op modulariteit verbeteren we zowel de ontwikkelings- als de testfase, wat leidt tot een betere algehele softwarekwaliteit. Modules definiëren bij mobiele ontwikkeling Bij het ontwikkelen van applicatiemodules is samenwerking met domeinexperts cruciaal om de verschillende functies binnen een organisatie volledig te begrijpen. Door deze samenwerking wordt duidelijk hoe de applicatie logisch kan worden gesegmenteerd. Het documenteren van rollen, gekoppeld aan domeinspecifieke vereisten, moet worden opgelost als een iteratief proces, waarbij voortdurende verfijningen mogelijk zijn die zijn afgestemd op de veranderende behoeften van de organisatie. De basismodule In onze modulaire architectuur gebruiken we een basismodule. Zie dit als de genetische code van de applicatie - de kern waarvan elke andere module erft. Deze basismodule bevat alle gedeelde, domeinagnostische functies, waaronder universele ontwerpelementen en besturingselementen. Het centraliseren van deze gemeenschappelijke aspecten zorgt voor een consistente look en feel in de hele app. Elke gespecialiseerde module die op deze basis is gebouwd, neemt inherent deze gedeelde kenmerken over, waardoor de ontwikkeling wordt gestroomlijnd en ervoor wordt gezorgd dat wijzigingen aan fundamentele aspecten slechts eenmaal hoeven te worden doorgevoerd, wat doorwerkt in de hele applicatie. Onze eerste module maken Zodra de basismodule klaar is, is de volgende stap het maken van de eerste samenstelbare module. De structuur bootst de klassieke gelaagde architectuur na (Data, Domain en Presentation projecten), met een extra Test project om het testen van de module te vergemakkelijken. Dit Test-project roept de module rechtstreeks aan. Het is een eenvoudige mobiele toepassing, meestal bestaande uit een knop om de component op te starten. De rol is om mock definities te bieden voor alle vereiste afhankelijkheden van de module, zodat deze kan worden ingezet op een apparaat of emulator om te testen. Projectstructuur voor modulaire architectuur Gegevensproject: Definieert gegevensentiteiten en vereiste gegevensinterfaces. Domeinproject: Bevat kernbedrijfslogica en domeinmodellen. Definieert use cases en bedrijfsregels die op de gegevens werken. Presentatie Project: Beheert UI-componenten en presentatielogica. Bevat views en UI-gerelateerde hulpprogramma's. Test Project: Standalone project dat rechtstreeks met de module interageert. Biedt schijnimplementaties voor afhankelijkheden. Maakt geïsoleerd testen van de functionaliteit van de module mogelijk. Gegevensafhankelijkheden definiëren in een modulaire architectuur Voor elke samenstelbare bibliotheek is het van cruciaal belang om gegevensafhankelijkheden te definiëren via contracten (bv. interfaces) in plaats van gegevensbronnen hard te coderen. Dit zorgt ervoor dat de bibliotheek agnostisch blijft wat betreft de herkomst van gegevens, of ze nu afkomstig zijn van een lokale database of een web-API. Dependency injection levert de juiste gegevensimplementaties aan de module. Met deze aanpak kunnen consumenten de gegevensbron kiezen. Door ervoor te zorgen dat de samenstelbare bibliotheek zich alleen bezighoudt met het type gegevens dat nodig is, in plaats van met de herkomst van de gegevens, wordt het mocken van gegevenscontracten en de emulatie van verwachte functionele scenario's vereenvoudigd. Deze modulaire en testbare aanpak verbetert de flexibiliteit en onderhoudbaarheid van de codebase aanzienlijk. Een module of component gebruiken in mobiele ontwikkeling Het integreren van een ontwikkelde module in je applicatie is eenvoudig dankzij duidelijk gedefinieerde interfaces en afhankelijkheden: Importeer de module: Neem de module op in je project. Dit houdt vaak in dat je een afhankelijkheid toevoegt aan de buildconfiguratie van je project. Afhankelijkheden injecteren: Gebruik injectie van afhankelijkheden om de nodige gegevensbronnen en services te leveren die de module nodig heeft. Dit houdt de component agnostisch over de oorsprong van zijn gegevens, wat flexibiliteit en herbruikbaarheid bevordert. De module initialiseren: Stel alle initiële configuraties of toestanden in die nodig zijn voor de module, zoals initiële gegevens of specifieke instellingen. De API van de module gebruiken: Communiceer met de module via de openbare API, meestal inclusief methoden om flows te starten die gegevens retourneren of weergaven integreren met uw applicatie. Conclusie: de toekomst van mobiele ontwikkeling ligt in modulaire architectuur Het omarmen van modulaire architectuur in mobiele ontwikkeling biedt talloze voordelen, die zowel het ontwikkelproces als het eindproduct verbeteren. Door applicaties op te splitsen in kleinere, beheersbare componenten dwingen we scheiding van zorgen af, bevorderen we herbruikbaarheid van code en verbeteren we de onderhoudbaarheid aanzienlijk. Modules maken geïsoleerd testen mogelijk, verkorten bouwtijden en creëren een stabiele testomgeving, wat uiteindelijk leidt tot een efficiëntere en betrouwbaardere ontwikkelworkflow.

Leestijd 5 min

Stijn Huygh

Als ontwikkelaars begrijpen we dat GPS-nauwkeurigheid de ruggengraat vormt van veel mobiele toepassingen, van navigatie tot locatiegebaseerde diensten. De nauwkeurigheid van de GPS-functionaliteit van je app kan de gebruikerservaring maken of breken. In dit artikel geven we je vijf praktische manieren om de GPS-nauwkeurigheid van je mobiele applicatie te verbeteren en ervoor te zorgen dat je gebruikers zich nooit meer verloren voelen. Hoe een slechte GPS-locatienauwkeurigheid het succes van mobiele applicaties om zeep helpt: praktijkvoorbeeld Laten we beginnen met een voorbeeld uit de praktijk van hoe een slechte GPS-nauwkeurigheid je mobiele applicatie kan laten mislukken. Voorbeeld Elise heeft je nieuwe mobiele applicatie Commuter gedownload. De app belooft haar woon-werkervaring te verbeteren door haar tijdig meldingen te geven over bushaltes en verwachte aankomsttijden. Tot haar grote schrik presteert de app echter niet altijd even goed. Op sommige dagen biedt de app nauwkeurige realtime updates, maar op andere dagen ontvangt ze de meldingen te laat of te vroeg. Het is begrijpelijk dat Elise gefrustreerd is en haar ontevredenheid over uw mobiele applicatie deelt via een negatieve review. Wat gaat er mis met de GPS-nauwkeurigheid? Jij, als ontwikkelaar, staat perplex. Je hebt immers de standaard GPS-algoritmen van het platform geïntegreerd, dus waarom de inconsistentie? De app berekent haar gemiddelde snelheid op basis van het verschil tussen de GPS-locaties en de tijd tussen deze updates. De app is geprogrammeerd om haar te waarschuwen voor haar bushalte zodra haar GPS-coördinaten binnen een straal van 100 meter van het station vallen. Hoewel dit logisch klinkt, komen de resultaten in de praktijk niet overeen met de verwachtingen. Wat veroorzaakt de slechte nauwkeurigheid van GPS-locaties? Het kernprobleem komt voort uit de inherente onnauwkeurigheden in GPS-locatiegegevens. Hoewel GPS-locaties een foutmarge bevatten, meestal uitgedrukt in meters met een betrouwbaarheidsinterval van 68%, houdt deze marge geen rekening met de invloed van weerkaatsingen van het GPS-signaal , ook bekend als multipadfouten. Multipadfouten treden op wanneer GPS-signalen weerkaatsen op objecten of oppervlakken voordat ze de antenne van de GPS-ontvanger bereiken. Stedelijke gebieden met hoge gebouwen en een dichte infrastructuur zijn bijzonder gevoelig voor GPS-signaalreflecties. De weerkaatsing van signalen tegen wolkenkrabbers, voertuigen en andere structuren kan een complexe signaalomgeving creëren, wat leidt tot onvoorspelbare locatieonnauwkeurigheden. GPS-signaalreflecties kunnen het signaal kilometers ver omleiden, waardoor de app mogelijk ten onrechte aangeeft dat Elise haar bestemming al heeft bereikt of nog kilometers ver is. Uitdagingen van GPS-signaalreflecties voor ontwikkelaars van mobiele apps GPS-signaalreflecties stellen ontwikkelaars van mobiele apps voor verschillende uitdagingen: Onnauwkeurige positionering : GPS-signaalreflecties kunnen ervoor zorgen dat de GPS-ontvanger een onjuiste positie berekent. Wanneer het gereflecteerde signaal iets later aankomt dan het directe signaal, kan de ontvanger het interpreteren als komende vanuit een andere hoek, wat leidt tot onnauwkeurige positiebepalingen. Inconsistente metingen : GPS-signaalreflecties zijn vaak inconsistent, waardoor het moeilijk is voor ontwikkelaars om te voorspellen wanneer en waar ze zullen optreden. Deze inconsistentie kan resulteren in verschillende niveaus van onnauwkeurigheid, wat een uitdaging vormt bij het ontwerpen van locatie-afhankelijke diensten. Hoe kan de GPS-locatienauwkeurigheid worden verbeterd? Om de uitdagingen van GPS-signaalreflecties tegen te gaan en de gebruikerservaring te verbeteren, is een vernieuwde strategie nodig. Hier volgen enkele innovatieve strategieën om de GPS-locatienauwkeurigheid van de mobiele app Commuter in het bovenstaande voorbeeld te verbeteren: GPS-locaties filteren : Het is cruciaal om alle locatie-updates met een onnauwkeurigheid van meer dan 100 meter te verwijderen. Dit zorgt ervoor dat alleen de meest betrouwbare gegevens worden gebruikt voor berekeningen. Extra sensorgegevens gebruiken : Neem versnellingsmetergegevens op om de GPS-nauwkeurigheid te verbeteren. Gebruik een snelheidsverletalgoritme om locaties te voorspellen op basis van de versnellingsmetergegevens. Combineer deze voorspellingen met behulp van een Kalman Filter, waarbij rekening wordt gehouden met de onzekerheid van elke gegevensbron, het locatiesignaal wordt gestabiliseerd en een nauwkeurigere voorspelling wordt verkregen. Projectiealgoritmen voor busroutes: Aangezien Elise met de bus reist, kunnen projectiealgoritmen worden gebruikt om haar locatie af te stemmen op de route van de bus. Dit kan worden bereikt door de route te benaderen met behulp van gegevens van verschillende bushaltes. Crowdsourced Wi-Fi SSID's: Een andere innovatieve aanpak is het crowdsourcen van Wi-Fi SSID's (Service Set Identifiers). Deze SSID's kunnen fungeren als locatiemarkeringen en extra gegevenspunten leveren om de nauwkeurigheid van de locatie te verfijnen. Bluetooth-bakens voor verbeterde nauwkeurigheid : Het detecteren van crowdsourced Bluetooth beacons kan ook dienen als locatie-updates. Door gebruik te maken van deze BLE-bakens kun je de nauwkeurigheid van de app verder verbeteren. Door deze strategieën toe te passen, verbetert de nauwkeurigheid van de Commuter-app aanzienlijk en wordt een consistente en betrouwbare gebruikerservaring gegarandeerd. Als gevolg daarvan kunnen Elise en veel gebruikers zoals zij genieten van tijdige en nauwkeurige updates, wat leidt tot positieve beoordelingen en algehele klanttevredenheid. Conclusie Hoewel de uitdagingen voor de Commuter-app uniek lijken, weerspiegelen ze de echte hindernissen die veel ontwikkelaars van mobiele apps tegenkomen. Bij ACA hebben we deze uitdagingen met succes aangegaan met behulp van de hierboven beschreven strategieën. Hoewel GPS een waardevol hulpmiddel is, is het begrijpen van de beperkingen en het aanvullen van de gegevens met andere technologieën de sleutel tot betrouwbare locatiegebaseerde diensten. Op zoek naar een ervaren partner voor het ontwikkelen van mobiele toepassingen? {% module_block module "widget_137b2ccd-e194-4a50-a7ff-05def1e6085b" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"Contact us"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":{"content_id":230950468795,"href":"https://25145356.hs-sites-eu1.com/en/contact","href_with_scheme":null,"type":"CONTENT"},"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}

Leestijd 4 min

Jurgen Geys

Mobiele apps zijn onmisbaar geworden in ons dagelijks leven. Of we nu consument, burger, student, patiënt of werknemer zijn, we vertrouwen voor bijna alles op apps. Veel apps zijn echter moeilijk te gebruiken voor mensen die niet in het "standaard" gebruikersprofiel passen, zoals mensen met visuele, auditieve of motorische beperkingen. Omdat apps niet meer weg te denken zijn uit het dagelijks leven, worden deze gebruikers geconfronteerd met aanzienlijke barrières zonder voldoende alternatieven. De Europese Toegankelijkheidswet gaat hier verandering in brengen. In dit artikel lees je er alles over, inclusief wat het betekent voor jouw apps. Waarom toegankelijke apps belangrijk zijn Het aantal mensen dat baat heeft bij toegankelijke apps is groter dan je zou denken. Ongeveer 25% van de bevolking heeft een of andere handicap die het gebruik van een standaardapp bemoeilijkt (bron: EU-statistieken over handicaps ). Hieronder vallen mensen met visuele beperkingen (zoals blindheid of slechtziendheid), gehoorproblemen, kleurenblindheid, motorische beperkingen, ADHD, epilepsie en lees- of spraakproblemen. Vele anderen zonder handicap hebben ook baat bij toegankelijkheidsopties, zoals oudere volwassenen of iedereen die grotere tekst, een donkere modus of betere leesbaarheid buitenshuis nodig heeft. Investeren in toegankelijkheid helpt je app niet alleen om aan de wettelijke normen te voldoen, maar verhoogt ook de klanttevredenheid en de productiviteit van je werknemers . Europese toegankelijkheidswet maakt toegankelijkheid een wettelijke vereiste Vanaf juni 2025 moeten alle websites en apps voldoen aan de Europese toegankelijkheidseisen onder de Europese Toegankelijkheidswet . Deze wetgeving geldt niet alleen voor overheidsinstellingen, maar ook voor particuliere bedrijven. Belangrijkste EU-toegankelijkheidseisen voor apps Hoewel de Web Content Accessibility Guidelines (WCAG) van de EU voornamelijk gericht zijn op websites, zijn er ook specifieke vereisten voor apps. Mobiele apps brengen unieke uitdagingen met zich mee, zoals aanraakbediening en gebaren. Hier volgen enkele belangrijke richtlijnen: Visuele toegankelijkheid voor visueel gehandicapten : Blinde mensen gebruiken schermlezers om de inhoud te laten voorlezen. Dit vereist een logische structuur van links naar rechts en van boven naar beneden. Algemene elementen zoals koppen en menu's moeten overgeslagen kunnen worden. Afbeeldingen en video's hebben tekstbeschrijvingen en bijschriften nodig, en het formaat van de tekst moet kunnen worden aangepast of ingezoomd zonder dat dit ten koste gaat van de bruikbaarheid. Duidelijke kleuren voor kleurenblindheid : Zorg voor voldoende contrast tussen voor- en achtergrondkleuren en vermijd het gebruik van kleur alleen om informatie over te brengen (bijv. "tik op de groene knop"). Alternatieven voor audio-inhoud : Zorg voor visuele alternatieven voor audiofuncties om slechthorenden te ondersteunen. Alle geluiden of gesproken berichten moeten een overeenkomstige visuele weergave hebben. Gebruiksgemak voor mensen met motorische beperkingen : Handelingen zoals vegen of schudden van het apparaat kunnen moeilijk zijn voor sommige gebruikers. Bied alternatieve navigatieopties, zoals toegang via het toetsenbord, en test of gebruikers door de app kunnen navigeren zonder vast te lopen. Toegankelijke ervaring voor mensen met leesproblemen : Duidelijke instructies in invoervelden en foutmeldingen zijn van vitaal belang. Houd de gebruikerservaring rustig en ongecompliceerd, wat goed is voor mensen met ADHD of epilepsie. Ontdek hoe De Lijn zich inzet voor een inclusieve reiservaring, met speciale aandacht voor toegankelijkheid voor mensen met een handicap. Bekijk het webinar voor meer informatie over de ontwikkeling van hun mobiele app! Hoe maak je je app toegankelijk Het verbeteren van de toegankelijkheid van een bestaande app hoeft niet duur te zijn. Kleine, stapsgewijze aanpassingen kunnen een groot verschil maken. Een korte review kan helpen bij het identificeren van belangrijke gebieden die voor verbetering vatbaar zijn. Voor nieuwe apps is het ideaal om vanaf het begin rekening te houden met toegankelijkheid . Dit betekent dat je app-elementen logisch moet structureren, zodat screenreaders en andere ondersteunende technologieën er soepel doorheen kunnen navigeren. Testen is essentieel : hoewel interne tests nuttig zijn, zorgt het betrekken van mensen met een handicap voor realistische en waardevolle feedback. Mobiele apps als katalysator voor meer inclusiviteit Toegankelijke apps zijn niet alleen noodzakelijk, ze kunnen ook krachtige hulpmiddelen zijn voor mensen met een beperking. Met moderne smartphones en AI-technologie kunnen apps een extra laag ondersteuning bieden. We hebben bijvoorbeeld een app ontwikkeld voor EMVI die blinde gebruikers helpt hun omgeving te scannen en visuele informatie te interpreteren . Voor de geleidehondenorganisatie Licht en Liefde maken we een app om blinden te helpen bij het navigeren in het verkeer . Nieuwsgierig naar hoe je jouw app toegankelijker kunt maken? {% module_block module "widget_49fe050b-91bf-43ab-8b1a-56666f7ef684" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"Let's talk"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":{"content_id":230950468795,"href":"https://25145356.hs-sites-eu1.com/en/contact","href_with_scheme":null,"type":"CONTENT"},"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}

Leestijd 4 min

Stijn Huygh

Met Flutter is het mogelijk om applicaties te maken die soepel draaien op meerdere platformen met behulp van een enkele codebase. Dit betekent dat in theorie alle mobiele applicaties die met Flutter gebouwd zijn ook als web- of desktopapplicaties kunnen functioneren . Dit klinkt te mooi om waar te zijn. Dus besloten we zelf de proef op de som te nemen met onze eigen applicatie die al in productie is, de Immovlan app . Met deze vastgoedapplicatie kunnen gebruikers hun eigendommen te koop of te huur aanbieden. Uitdagingen overwinnen met Flutter Onze reis begon met het integreren van de nodige webmap in onze mobiele app. Deze stap verliep vlekkeloos en we gingen verder met het testen van de app op het web om gebieden te identificeren die moesten worden aangepast voor webspecifieke vereisten. Als eerste was er onze integratie met Firebase Crashlytics , die momenteel geen webplatforms ondersteunt. Om dit aan te pakken hebben we voorwaardelijke controles toegevoegd om te voorkomen dat Crashlytics wordt geïnitialiseerd en events worden verzonden bij het bouwen voor het web. Een andere oplossing zou kunnen zijn om op zoek te gaan naar een goed alternatief voor Firebase Crashlytics dat wel webplatformen ondersteunt. Vervolgens werden we geconfronteerd met uitdagingen bij het instellen van onze gebruikerstracering voor advertenties. We gebruiken Didomi als onze toestemmingsbeheerder, maar helaas is deze niet compatibel met Flutter Web .* Volgens een vergelijkbare aanpak als Firebase Crashlytics, hebben we controles geïmplementeerd om het uit te schakelen als het op het web draait. Met deze wijzigingen konden we de applicatie op het web draaien. Er waren echter nog een paar dingen die we moesten aanpassen. * Opmerking : De bestaande Flutter SDK biedt op dit moment geen webondersteuning. Didomi biedt echter een aparte web SDK (https://developers.didomi.io/cmp/web-sdk) . De integratie van deze web SDK maakte geen deel uit van ons initiële testplan. De laatste obstakels om de Flutter mobiele app op het web te laten draaien We kregen te maken met Cross-Origin Resource Sharing (CORS) problemen omdat de API in eerste instantie was ontworpen voor mobiel gebruik. Omdat CORS op het web anders wordt beheerd, schakelden we over van de HTML renderer naar CanvasKit. De CORS-problemen kunnen eenvoudig worden opgelost door de juiste headers in de antwoorden op te nemen, maar voor dit project hadden we de backend niet in handen. Nadat we de API-uitdagingen hadden aangepakt, stuitten we op een ander obstakel met de locatiegebaseerde kaartzoekopdrachten van onze app. Ons bestaande kaartenpakket, dat afhankelijk was van standaardkaarten (Apple Maps voor iOS en Google Maps voor Android), werd niet ondersteund. Dit kleine probleem konden we eenvoudig oplossen door het zelf toe te voegen. Na deze aanpassingen was onze mobiele app succesvol operationeel op het web. Van mobiele app naar webplatform: geleerde lessen en toekomstige overwegingen We hebben binnen een kort tijdsbestek met succes een nieuw webplatform gelanceerd door een paar aanpassingen te maken aan de codebasis van een mobiele app. Dit proces zou normaal gesproken veel meer tijd kosten als het afzonderlijk zou worden uitgevoerd. Als je een webapp kunt maken door dezelfde bedrijfslogica te hergebruiken die in de mobiele app is gebruikt, kun je de implementatiekosten aanzienlijk verlagen. Bovendien maakt het een uniform klanttraject op alle platforms mogelijk. Ook het oplossen van bugs kan op alle platforms tegelijk worden gedaan, wat tijd en moeite bespaart. Deze aanpak brengt echter ook een aantal nieuwe uitdagingen met zich mee: Terwijl de functionaliteit van de app consistent bleef op zowel mobiele als webplatforms, was de gebruikersinterface (UI) niet geoptimaliseerd voor het web, wat leidde tot een enigszins onsamenhangende gebruikerservaring. Het is noodzakelijk om prioriteit te geven aan verdere UI-optimalisaties voor het web om naadloze gebruikersinteracties op elk platform te garanderen. Door platformbewuste componenten te implementeren, kunnen we eenvoudig de verschillen tussen mobiele en webinterfaces opvangen zonder de onderliggende bedrijfslogica aan te tasten. Deze componenten passen zich op intelligente wijze aan op basis van het platform waarop ze draaien, waardoor de technische schuld wordt geminimaliseerd en tegelijkertijd een gepolijste gebruikerservaring op alle apparaten wordt gegarandeerd. Het is noodzakelijk om functies achter de schermen zoals Firebase Crashlytics of Didomi aan te passen zodat ze compatibel zijn met het web. Deze uitdagingen kunnen eenvoudig worden aangepakt door naar alternatieven te zoeken en bindingen te leveren voor de native bibliotheken. SEO (Search Engine Optimization) wordt nog niet ondersteund door Flutter. Terwijl Flutter de nadruk legt op dynamische applicatie-ervaringen, ook op het web, kan de focus op prestaties en consistentie niet volledig overeenkomen met de behoeften van zoekmachine-indexering. Dit kan beperkingen opleveren voor de zichtbaarheid en vindbaarheid op het web. Het is echter mogelijk om webtechnologie en Flutter te combineren. Je landingspagina, die SEO vereist, kan gebaseerd zijn op webtechnologie, terwijl de rest, die geen SEO vereist, Flutter-gebaseerd kan zijn. Moet je Flutter overwegen voor het web? Het antwoord hangt af van het specifieke doel van je webapplicatie. Als u een landingspagina, marketing website of content site ontwikkelt die geoptimaliseerd moet worden voor zoekmachine indexering, raden we aan om alternatieve benaderingen te verkennen in plaats van Flutter Web te gebruiken. Als het echter je doel is om een webapplicatie te maken die ontworpen is voor geauthenticeerde gebruikersinteracties, zoals een bank-app of dashboard voor energieverbruik, en die niet geïndexeerd hoeft te worden door zoekmachines, dan kan Flutter een uitstekende keuze zijn. Met Flutter kun je een naadloze gebruikerservaring leveren op verschillende platformen, waardoor het een aanrader is voor dit soort applicaties.