Share
Sinds Xamarin 3 is geïntroduceerd, is er nogal wat geroezemoes omheen geweest. Het idee van het kunnen maken van een mobiele applicatie, inclusief de gebruikersinterface, met behulp van een enkele codebasis is verbazingwekkend. Maar Xamarin.Forms is zoveel meer dan dat. Een van de vaak over het hoofd geziene functies in Xamarin.Forms is het concept van Messaging en dat is het onderwerp van deze tutorial.
Als u ervaring hebt met het schrijven van software in bedrijfsomgevingen, hebt u mogelijk ook ervaring met berichten of hebt u er al van gehoord in uw toepassingen. Berichten is een term die wordt gebruikt om toepassingen te beschrijven die misbruik maken van de publish / subscribe (pub / sub) ontwerppatroon. De publish / subscribe-architectuur bestaat uit drie primaire spelers:
De centrale focus van dit proces ligt rond de berichten. Berichten zijn gewoon een manier om informatie over een bepaalde te verzenden evenement dat is gebeurd. Deze gebeurtenis is meestal gekoppeld aan een of ander bedrijfsproces en bevat informatie die vereist is door systemen die deze gegevens uiteindelijk zullen gebruiken om een andere bewerking uit te voeren.
De andere twee spelers, uitgevers en abonnees, zijn de leveranciers van deze berichten. Zoals de namen impliceren, zijn de uitgevers het afzenders van de berichten en de abonnees zijn de ontvangers van de berichten.
Het basisproces van berichten is vrij eenvoudig. Binnen een systeem vindt een bepaalde gebeurtenis plaats. Deze gebeurtenis kan iets eenvoudigs zijn, zoals een gebruiker die op een knop klikt, of zo complex als een bedrijfsregel die wordt geactiveerd door de handelsapp van een groot financieel bedrijf. In de wereld van berichten is er weinig verschil tussen deze twee dingen. Het enige dat u moet weten, is dat er iets is gebeurd.
Wanneer een gebeurtenis plaatsvindt, neemt een uitgever de informatie over deze gebeurtenis en bundelt deze in een bericht. Dit bericht zal een soort hebben type verbonden en aanvullende gegevens die de gebeurtenis beschrijven. Het type is erg belangrijk later in het proces. Zodra dit bericht is gemaakt, stuurt de uitgever het naar een bepaald systeem. Vanaf dat moment geeft de uitgever niet langer meer om deze gebeurtenis of bericht. Er zijn enkele soorten uitgevers die een reactie moeten krijgen, maar dat is in ons geval niet erg belangrijk.
Aan de andere kant van de vergelijking staan de abonnees. Abonnees zijn precies het tegenovergestelde van de uitgevers. Ze wachten op het publiceren van berichten van een bepaald type. Dit is waar hun naam vandaan komt, ze zijn geabonneerd op bepaalde soorten evenementen. Wanneer een abonnee ziet dat een gebeurtenis waarbij ze zijn geabonneerd zich heeft voorgedaan, zal deze dit bericht en alle bijbehorende gegevens meenemen en er iets mee doen. Zodra dit proces voltooid is, gaat de abonnee terug naar het wachten op meer berichten.
Met deze architectuur in gedachten, vraag je je misschien af waarom of wanneer je het zou moeten gebruiken. Gewoonlijk kiezen ontwikkelaars ervoor om dit type architectuur om twee redenen te gebruiken, losse koppeling en schaalbaarheid.
Wat de ontwikkeling van software betreft, is losse koppeling het concept om verschillende componenten binnen uw toepassing zo apart mogelijk te houden, zodat zij zo min mogelijk van elkaar weten. Door deze scheiding kunnen ontwikkelaars zich meer richten op de functionaliteit van een systeem en minder op de interactie van verschillende componenten of delen van het systeem. Dit zorgt voor eenvoudigere veranderingen in functionaliteit en testen van verschillende componenten.
Schaalbaarheid heeft te maken met hoe een systeem kan groeien zonder voortdurend de hele oplossing opnieuw te moeten ontwerpen en opnieuw te ontwerpen. Als het om berichten gaat, als u een soort extra verwerking moet doen wanneer een bepaald bericht wordt gedetecteerd, wordt een nieuwe abonnee gemaakt om die functionaliteit af te handelen in plaats van een bestaand stuk code open te moeten maken en wijzigingen aan te brengen.
Laten we nu kijken hoe we deze extreem krachtige architectuur kunnen gebruiken in onze mobiele applicaties met Xamarin.
Het betreden van de wereld van messaging in Xamarin. Forms is eigenlijk vrij simpel nu we de basisbegrippen van messaging begrijpen. Alles wat we nu nodig hebben, is een construct om toegang te krijgen. Gelukkig voor ons is er maar één klasse waar we ons echt zorgen over moeten maken en dat is MessagingCenter. De MessagingCenter class is onderdeel van Xamarin.Forms en heeft methoden om ons te helpen met zowel het publiceren als abonneren op berichten. Laten we ze eens bekijken.
De eerste methode die we gaan bekijken in de MessagingCenter klasse is Sturen. Hoewel het concept in een berichtencontext is gepubliceerd, wordt de implementatie van Xamarin.Forms gebruikt Sturen. Er zijn twee versies van de Sturen methode die kan worden gebruikt om gegevens te publiceren.
Accentsconagua
MessagingCenter.Send(Zender van zender, stringbericht) MessagingCenter.Send(Afzender van TSender, stringbericht, TArgs args) Beide opties zijn generiek. Met de eerste kunt u de afzender van dit bericht opgeven en met de tweede kunt u ook een secundair argument, het payload-type, gebruiken.
Het is belangrijk om erop te wijzen dat de TArgs generieke parameter kan van elk type zijn. Het kan iets eenvoudigs zijn als een draad of zo complex als een aangepast type.
Nu we begrijpen hoe te publiceren, of Sturen, berichten in het systeem, is het tijd voor iets om zich op te abonneren. Om dat te doen, zullen we de abonneren methode op de MessagingCenter klasse.
Vergelijkbaar met de twee versies van de Sturen methode, de abonneren methode heeft ook twee overbelastingen.
MessagingCenter.Subscribe(objectabonnee, stringboodschap, actie callback, TSender sender = null) MessagingCenter.Subscribe(objectabonnee, stringboodschap, actie callback, TSender sender = null) Voor de abonneren methoden, geven we aan wie de abonnee is. Meestal specificeren we dit deze voor de eerste parameter. De tweede parameter bevat dezelfde berichtnaam die is opgegeven in de Sturen methode, zodat we op de hoogte kunnen worden gesteld wanneer dat specifieke bericht is verzonden. De derde parameter is een generieke afgevaardigde die de afzender en mogelijk args accepteert, afhankelijk van de versie van de methode die wordt gebruikt. De gedelegeerde is een callback die wordt uitgevoerd wanneer een bericht van dit type wordt gepubliceerd. Eindelijk is een parameter nullable die specificeert welke TSender er moet op dit bericht worden geabonneerd. Het kan worden gelaten zoals nul om dit type bericht van een afzender te accepteren.
Geweldig, nu abonneren we ons op berichten, maar wat als we niet langer om bepaalde berichten geven? Goede vraag. Er is nog een methode om rekening mee te houden.
Een proces dat vaak over het hoofd wordt gezien in de berichtenwereld, is uitschrijven. Wanneer u in een zeer grote enterprise-klasse infrastructuur werkt, is het misschien niet zo belangrijk. Als u daarentegen in een kleinere omgeving werkt, zoals een telefoon, wordt deze belangrijker.
Hoewel het gebruik van de berichtenarchitectuur meer flexibiliteit en schaalbaarheid mogelijk maakt, zijn er nog steeds systeembronnen voor nodig. Vanwege dit kunnen we niet doorgaan met het oneindig vergroten van het aantal abonnees in een systeem. Als dat zo is, moeten we de middelen zo goed mogelijk respecteren. In Xamarin.Forms, is de manier waarop we dit doen door het te noemen Afmelden methode. Met deze methode kunnen we zeggen dat we ons niet langer bekommeren om een bepaald bericht dat wordt gepubliceerd naar het systeem.
De Afmelden methode heeft ook twee overbelastingen.
MessagingCenter.Unsubscribe(objectabonnee, stringboodschap) MessagingCenter.Unsubscribe(objectabonnee, stringboodschap) U zult merken dat de generieke argumenten zich niet in de parameterlijst manifesteren. Alleen de ontwikkelaars hebben een goed idee over waarom precies, maar ik denk dat het waarschijnlijk meer een formaliteit is. Hoe dan ook, ik kies ervoor om consistent te zijn in al mijn oproepen naar Sturen, abonneren, en Afmelden, en gebruik dezelfde handtekeningen en argumenten om elke vorm van verwarring te elimineren.
Nu we de basisbegrippen van berichten begrijpen, is het tijd om een eenvoudig voorbeeld te maken met behulp van deze ideeën.
In dit voorbeeld maken we een eenvoudige Xamarin.Forms-app die alle drie de methoden van de MessagingCenter klasse die eerder in dit artikel is genoemd. De app zelf lijkt nogal onbelangrijk, maar het zal een handige illustratie zijn van hoe je deze concepten in de komende tijd in je apps kunt gebruiken.
We beginnen met het maken van een nieuwe Xamarin.Forms-app. Om dit te bereiken, opent u eenvoudig Xamarin Studio (of Visual Studio) en selecteert u Bestand> Nieuwe oplossing. In de Nieuwe oplossing dialoogvenster, selecteert u de Mobiele apps sjabloonfamilie en kies een van de sjablonen. Ik zal het selecteren PCL versie, maar je zou het kunnen gebruiken Gedeeld project versie als je wilt.
Zodra de oplossing is gemaakt, voegen we wat code toe. Maak in het gedeelde project een nieuwe klasse en noem deze Hoofdpagina. Dit is het scherm in de applicatie dat zowel de gebruikersinterface als de logica zal bevatten. Dit kan natuurlijk worden uitgesplitst in meer logische stukken, maar deze applicatie is eenvoudig genoeg dat ik het niet nodig vond.
Vervang de inhoud van de MainPage.cs bestand met het volgende:
