Mobiilne
Xamariniga platvormidevaheliste rakenduste loomine: Androidi arendaja perspektiiv
Koodi üks kord kirjutamine ja selle kasutamine mitmel platvormil on paljude tarkvaraarendajate unistus. Kuigi see on juba mõnda aega olnud võimalik, tuli see alati hooldatavuse, testimise lihtsuse või veelgi hullem - kehva kasutuskogemuse hinnaga.
Natiivse SDK abil mobiilirakenduste väljatöötamine on tõenäoliselt lähtepunkt kõigile arendajatele, kelle juured on lauaarvutirakenduste arendamise valdkonnas. Programmeerimiskeeled muutuksid mõnele takistuseks: kui keegi oleks kogenud Java töölaua- või tagarakenduste arendamist, liikuks a mobiilirakenduste arendusfirma ja Androidiga töötamine tunduks palju lihtsam kui iOS-i jaoks nullist alustamine Objective-C-ga.
Olin platvormidevaheliste rakenduste arendamise suhtes alati skeptiline. JavaScripti-põhised raamistikud nagu Sencha, Cordova, Titanium jms ei osutu kunagi targaks valikuks, kui jõudlus on oluline. API-de puudumine ja omapärane kasutuskogemus olid nende raamistike puhul antud.
Kuid siis sattusin Xamarinile.
Sellest artiklist saate teada, kuidas saate Xamarini abil koodi jagada mitmel platvormil, kahjustamata ühtegi teist mobiilirakenduste arendamise aspekti. Artikkel keskendub eelkõige Androidile ja iOS-ile, kuid võite kasutada sarnast lähenemisviisi, et lisada tuge mis tahes muule platvormile, mida Xamarin toetab.
Mis on Xamarin?
Xamarin on arendusplatvorm mis võimaldab teil kirjutada platvormideüleseid, kuid omakeelseid rakendusi iOS-i, Androidi ja Windows Phone'i jaoks C # ja .NET.
Xamarin pakub C # -seoseid Androidi ja iOS-i native API-dele. See annab teile võimaluse kasutada kõiki Androidi ja iOS-i kohalikke kasutajaliideseid, märguandeid, graafikat, animatsiooni ja muid telefoni funktsioone - seda kõike kasutades C # -d.
Kõigile uutele Androidi ja iOS-i versioonidele sobib Xamarin koos uue versiooniga, mis sisaldab nende uute API-de sidumisi.
Xamarini .NET-i port sisaldab selliseid funktsioone nagu andmetüübid, geneerilised ained, prügivedu, keelte integreeritud päring (LINQ), asünkroonsed programmeerimismustrid, delegaadid ja Windowsi suhtlusfondi (WCF) alamhulga. Raamatukogusid hallatakse nii, et need hõlmaksid ainult viidatud komponente.
Xamarin.Forms on kiht teiste kasutajaliidese sidumiste ja Windows Phone API peal, mis pakub täielikult platvormidevahelist kasutajaliidese teeki.
Platvormidevaheliste rakenduste kirjutamine
Xamariniga platvormidevaheliste rakenduste kirjutamiseks peavad arendajad valima ühe kahest saadaolevast projektitüübist:
- Kaasaskantav klassikogu (PCL)
- Jagatud projekt
PCL võimaldab teil kirjutada koodi, mida saab jagada mitme platvormi vahel, kuid ühe piiranguga. Kuna kõik .NET-i API-d pole kõigil platvormidel saadaval, piirate PCL-i projekti korral selle käitamist platvormidel, millele see on suunatud.
Alltoodud tabel näitab, millised API-d on millistel platvormidel saadaval:
| Tunnusjoon | .NET Framework | Windowsi poe rakendused | Silverlight | Windowsi telefon | Xamarin |
|---|---|---|---|---|---|
| Tuum | Y | Y | Y | Y | Y |
| LINQ | Y | Y | Y | Y | Y |
| IQueryable | Y | Y | Y | 7,5+ | Y |
| Serialiseerimine | Y | Y | Y | Y | Y |
| Andmete märkused | 4.0.3+ | Y | Y | Y | Y |
Ehitamisprotsessi käigus kompileeritakse PCL eraldi DLL-ideks ja Mono laadib käitamise ajal. Käitusaja jooksul saab pakkuda sama liidese erinevat rakendust.
Teisalt annavad jagatud projektid teile suurema kontrolli, võimaldades teil kirjutada igale platvormile, mida soovite toetada, platvormispetsiifiline kood. Jagatud projekti kood võib sisaldada kompilaatori direktiive, mis lubavad või keelavad koodilõigud olenevalt sellest, milline rakendusprojekt koodi kasutab.
Erinevalt PCL-ist ei tooda jagatud projekt DLL-i. Kood lisatakse otse lõppprojekti.
MvvmCrossiga oma platvormiülese koodi ülesehitus
Korduvkasutatav kood võib arendusmeeskondadele säästa raha ja aega. Hästi struktureeritud kood muudab arendajate elu aga palju lihtsamaks. Keegi ei hinda kenasti kirjutatud veatut koodi rohkem kui arendajad.
Xamarin pakub iseenesest mehhanismi, mis muudab korduvkasutatava platvormidevahelise koodi kirjutamise palju lihtsamaks.
Mobiiliarendajad tunnevad stsenaariume, kus nad peavad iOS-i, Androidi ja muude platvormide toetamiseks kirjutama sama loogika kaks või enam korda. Kuid Xamariniga, nagu eelmises peatükis selgitatud, on ühe platvormi jaoks kirjutatud koodi lihtne taaskasutada ka mõne muu platvormi jaoks.
Kus siis MvvmCross paigale tuleb?
Nagu nimest võib aimata, võimaldab MvvmCross kasutada MVVM-i mustrit Xamarini rakendustes. Kaasas on terve hulk raamatukogusid, API-sid ja utiliite, mis on platvormidevaheliste rakenduste arendamisel tõesti käepärased.
MvvmCross võib oluliselt vähendada katlakoodi koodi, mille oleksite kirjutanud (mõnikord mitu korda erinevates keeltes) mis tahes muus rakenduse arendamise lähenemises.
MvvmCrossi lahenduse struktuur
MvvmCrossi kogukond soovitab MvvmCrossi lahenduse struktureerimiseks üsna lihtsat ja tõhusat viisi:
.Core .UI.Droid .UI.iOS MvvmCrossi lahenduse põhiprojekt on seotud korduvkasutatava koodiga. Põhiprojekt on Xamarini PCL-projekt, kus põhirõhk on korduvkasutamisel.
Kõik tuumikirjutatud koodid peaksid olema võimalikult platvormi agnostilised. See peaks sisaldama ainult loogikat, mida saab kõikidel platvormidel uuesti kasutada. Põhiprojekt ei tohi kasutada ühtegi Androidi ega iOS-i API-d ega pääseda juurde ühegi platvormi spetsiifilisele versioonile.
Äriloogikakiht, andmekiht ja tagasiside on ideaalsed kandidaadid põhiprojekti kaasamiseks. Vaate hierarhia (tegevused, killud jne) kaudu navigeerimine toimub tuumikus.
Enne jätkamist on vaja mõista ühte arhitektuurset kujundusmustrit, mis on MvvmCrossi ja selle töö mõistmiseks ülioluline. Nagu nimest näha, sõltub MvvmCross suuresti MVVM-i mustrist.
MVVM on arhitektuurne kujundusmuster, mis hõlbustab graafilise kasutajaliidese eraldamist äriloogikast ja taustandmetest.
Kuidas seda mustrit MvvmCrossis kasutatakse?
Noh, kuna me tahame saavutada oma koodi kõrge korduvkasutatavuse, tahame, et meie Core'is, mis on PCL-projekt, oleks nii palju kui võimalik. Kuna vaated on ainsad koodiosad, mis erinevad platvormiti, ei saa me neid enam platvormidel kasutada. Seda osa rakendatakse platvormiga seotud projektides.
MvvmCross annab meile võimaluse juhtida rakenduste navigeerimist tuumast ViewModelsi abil.
Kuna põhitõed ja tehnilised üksikasjad jäävad kõrvale, alustame Xamariniga, luues omaenda MvvmCross Core projekti:
MvvmCrossi põhiprojekti loomine
Avage Xamarin Studio ja looge lahendus nimega ApeeScapeExampleSolution:
Kuna loome põhiprojekti, on hea mõte jääda nimetamiskonventsioonile. Veenduge, et Core projekti nimele lisatakse järelliide.
MvvmCrossi toe saamiseks on vaja lisada meie projekti MvvmCrossi teegid. Lisades, et saame Xamarin Studio'is kasutada NuGeti sisseehitatud tuge.
Teegi lisamiseks paremklõpsake kaustas Paketid ja valige Pakettide lisamine ... valik.
Otsinguväljal saame otsida MvvmCrossi, mis filtreerib välja MvvmCrossiga seotud tulemused, nagu allpool näidatud:
Klõpsates nuppu Lisa pakett nupp lisab selle projekti.
Kuna meie projekti on lisatud MvvmCross, oleme valmis kirjutama oma põhikoodi.
Määratleme oma esimese ViewModeli. Selle loomiseks looge kaustade hierarhia järgmiselt:
Kõik kaustad on järgmised:
- Mudelid: Domeenimudelid, mis esindavad tegelikku olekusisu
- Teenused: Kaust, mis hoiab meie teenust (äriloogika, andmebaas jne)
- ViewModel: Kuidas me oma mudelitega suhtleme
Meie esimene ViewModel kannab nime FirstViewModel.cs
public class FirstViewModel : MvxViewModel { private string _firstName; private string _lastName; private string _fullName; public string FirstName { get { return _firstName; } set { _lastName = value; RaisePropertyChanged(); } } public string LastName { get { return _lastName; } set { _lastName = value; RaisePropertyChanged(); } } public string FullName { get { return _fullName; } set { _fullName = value; RaisePropertyChanged(); } } public IMvxCommand ConcatNameCommand { get { return new MvxCommand(() => { FullName = $'{FirstName} {LastName}'; }); } public IMvxCommand NavigateToSecondViewModelCommand { get { return new MvxCommand(() => { ShowViewModel(); }); } } } Nüüd, kui meil on esimene ViewModel, saame luua oma esimese vaate ja siduda asjad omavahel.
Androidi kasutajaliides
ViewModeli sisu kuvamiseks peame looma kasutajaliidese.
Esimene samm Androidi kasutajaliidese loomiseks on praeguses lahenduses Androidi projekti loomine. Selleks paremklõpsake lahendi nimel ja valige Lisa -> Lisa uus projekt ... . Valige viisardis Androidi rakendus ja veenduge, et nimetaksite oma projekti ApeeScapeExample.UI.Droid
Nagu varem kirjeldatud, peame nüüd Androidile lisama MvvmCrossi sõltuvused. Selleks järgige NuGeti sõltuvuste lisamiseks samu samme nagu Core projekti puhul.
Pärast MvvmCrossi sõltuvuste lisamist on vaja lisada viide meie põhiprojektile, et saaksime kasutada seal kirjutatud koodi. Viite lisamiseks PCL-projektile paremklõpsake kaustal Viited ja valige Redigeeri viiteid ... valik. Valige vahekaardil Projektid eelnevalt loodud põhiprojekt ja klõpsake nuppu OK.
Järgmine osa võib olla veidi keeruline mõista.
Nüüd peame MvvmCrossile ütlema, kuidas see peaks meie rakenduse seadistama. Selleks peame looma Setup klass:
namespace ApeeScapeExample.UI.Droid { public class Setup : MvxAndroidSetup { public Setup(Context context) : base(context) { } protected override IMvxApplication CreateApp() { return new Core.App(); } } } Nagu klassist näha, ütleme MvvmCrossile CreateApp põhineb Core.App rakendus, mis on Core'is määratletud ja allpool näidatud klass:
public class App : MvxApplication { public override void Initialize() { RegisterAppStart(new AppStart()); } } public class AppStart : MvxNavigatingObject, IMvxAppStart { public void Start(object hint = null) { ShowViewModel(); } } Väljal App klassi, loome AppStart eksemplari, mis näitab meie esimest ViewModeli.
Ainus järelejäänud asi on nüüd luua Android-paigutuse fail, mis on seotud MvvmCrossiga:
EditTextPaigutusfailis on meil köited, mille MvvmCross lahendab automaatselt. View Jaoks loome seose atribuudi Tekst jaoks, mis saab olema kahesuunaline. Kõik ViewModeli küljelt kutsutud muudatused kajastuvad automaatselt vaates ja vastupidi.
[Activity(Label = 'ApeeScapeExample.UI.Droid', Theme = '@style/Theme.AppCompat', MainLauncher = true, Icon = '@mipmap/icon')] public class MainActivity : MvxAppCompatActivity { protected override void OnCreate(Bundle bundle) { base.OnCreate(bundle); SetContentView(Resource.Layout.Main); } } klass võib olla tegevus või fragment. Lihtsuse huvides kasutame tegevust, mis laadib antud paigutuse:
ContactNameCommandEsimese nupu jaoks on meil käsu sidumine, mis tähendab, et kui klõpsame nupul, kutsub MvvmCross Setup ViewModelilt.
Teise nupu jaoks näitame veel ühte ViewModeli.
iOS-i kasutajaliides
IOS-i projekti loomine ei erine tegelikult Android-projekti loomisest. Uue projekti lisamiseks peate järgima sarnaseid samme, ainult seekord looge Androidi asemel lihtsalt iOS-i projekt. Lihtsalt veenduge, et nimetamiskord oleks järjepidev.
Pärast iOS-i projekti lisamist peate lisama MvvmCross iOS-i sõltuvused. Sammud on absoluutselt samad mis Core ja Androidi puhul (paremklõpsake iOS-i projektis valikut Viited ja klõpsake nuppu Lisa viited ... ).
Nagu Androidi jaoks, on nüüd vaja luua public class Setup : MvxIosSetup { public Setup(MvxApplicationDelegate appDelegate, IMvxIosViewPresenter presenter) : base(appDelegate, presenter) { } protected override MvvmCross.Core.ViewModels.IMvxApplication CreateApp() { return new App(); } } klass, mis ütleb MvvmCrossile, kuidas meie rakendus üles seada.
SetupPange tähele, et AppDelegate klass nüüd pikeneb MvxIosSetup ja Androidi jaoks see pikenes MvxAndroidSetup .
Üks täiendus on see, et peame muutma oma AppDelegate klass.
[Register('AppDelegate')] public class AppDelegate : MvxApplicationDelegate { // class-level declarations public override UIWindow Window { get; set; } public override bool FinishedLaunching(UIApplication application, NSDictionary launchOptions) { Window = new UIWindow(UIScreen.MainScreen.Bounds); var presenter = new MvxIosViewPresenter(this, Window); var setup = new Setup(this, presenter); setup.Initialize(); var startup = Mvx.Resolve(); startup.Start(); Window.MakeKeyAndVisible(); return true; } } iOS-is vastutab kasutajaliidese käivitamise eest, seega peame ütlema, kuidas vaateid iOS-is esitatakse. Saate saatejuhtide kohta rohkem teada siin .
NavigateToSecondViewModelCommandOma VIewModeli esitlemiseks peame looma vaate. Sel juhul loome ViewControlleri, paremklõpsates projekti ja valides Lisa -> Uus fail ja valige iOS-i jaotisest ViewController, millele hakkame panema nime FirstViewController.
Xamarin loob kolm faili, milles me määratleme, millised meie sidemed olema hakkavad. Erinevalt Androidist peame iOS-i jaoks oma sidemed määratlema erineval viisil, koodi kaudu (ehkki saame seda teha ka Androidis ja mõnel juhul on see vajalik).
Kui vaadete vahel navigeerimine on vajalik, tehakse seda ViewModeli kaudu. Käsus ShowViewModel() meetod MvxAppCompatActivity leiab sobiva vaate ja navigeerib sinna.
Aga kuidas saab MVVMCross teada, millist vaadet laadida?
Selles pole mingit maagiat. Kui loome Androidi vaate (tegevus või fragment), laiendame ühte baasklassi tüübiparameetritega (ShowViewMolel). Kui helistame View, otsib MvvmCross üles Activity mis ulatub Fragment või VM klass tüübiparameetritega public interface IPasswordGeneratorService { string Generate(int length); } . Sellepärast ei tohi teil sama ViewModeli jaoks olla kahte vaateklassi.
Kontrolli inversioon
Kuna Xamarin pakub ainult C # ümbriseid kohalike API-de ümber, ei paku see mingisugust sõltuvuse süstimise (DI) ega juhtimise inversioonimehhanismi vormi.
Ilma sõltuvuste käitamise sisselogimiseta või aja kompileerimise kompileerimiseta pole lihtne luua vabalt ühendatud, korduvkasutatavaid, testitavaid ja hõlpsasti hooldatavaid komponente. IoC ja DI idee on teada olnud tõesti pikka aega; üksikasju IoC kohta leiate paljudest veebiartiklitest. Nende mustrite kohta saate lisateavet Martin Fowleri sissejuhatav artikkel .
IoC on olnud saadaval alates MvvmCrosses'i varasematest versioonidest ja see võimaldab sõltuvuste sisestamist käituse ajal, kui rakendus käivitatakse, ja alati, kui neid vajatakse.
Vabalt ühendatud komponentide saamiseks ei tohiks me kunagi nõuda klasside konkreetseid rakendusi. Konkreetsete juurutuste nõudmine piirab võimalust juurutamise ajal juurutuste käitumist muuta (te ei saa seda teise rakendusega asendada). See muudab nende komponentide testimise keeruliseks.
Sel põhjusel kuulutame välja liidese, mille jaoks meil on üks konkreetne rakendus.
public class PasswordGeneratorService : IPasswordGeneratorService { public string Generate(int length) { var valid = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890'; var res = new StringBuilder(); var rnd = new Random(); while (0 Ja rakendamine:
IPasswordGenerationServiceMeie ViewModel võib nüüd nõuda liidese PasswordGeneratorService eksemplari, mille pakkumise eest vastutame meie.
Selleks, et MvvmCross süstiks App.cs juurutamise ajal, peame MvvmCrossile ütlema, millist rakendust kasutada. Kui soovime mõlema platvormi jaoks kasutada ühte rakendust, võime rakendused registreerida public override void Initialize() { RegisterAppStart(new AppStart()); Mvx.LazyConstructAndRegisterSingleton(); } -s, pärast rakenduse registreerimist:
LazyConstructAndRegisterSingletonÜlaltoodud üleskutse staatilisele meetodile Mvx.RegisterSingleton() registreerib süstitava rakenduse. See meetod registreerib sobiva rakenduse, kuid ei loo objekti.
Objekt luuakse ainult siis, kui see on vajalik, ja ainult üks kord, kuna see on registreeritud üksikuna.
Kui tahame kohe luua üksikobjekti, saab selle saavutada helistades Mvx.RegisterType()
On juhtumeid, kus me ei soovi, et meie rakenduses oleks ainult üksikud singlid. Meie objekt ei pruugi olla niidikindel või võib olla mõni muu põhjus, miks me tahame alati uut eksemplari. Sellisel juhul pakub MvvmCross meetodit public class DroidPasswodGeneratorService : IPasswordGeneratorService { public string Generate(int length) { return 'DroidPasswordGenerator'; } } , mida saab rakenduse registreerimiseks viisil, mis kiirendab uue eksemplari alati, kui see on vajalik.
Kui peate igale platvormile pakkuma eraldi konkreetseid rakendusi, saate seda alati teha platvormispetsiifilistes projektides.
Setup.csJa meie rakenduse registreerimine toimub protected override void InitializePlatformServices() { base.InitializePlatformServices(); Mvx.LazyConstructAndRegisterSingleton(); } klass Droidi projekti raames:
InitializePlatformServicesPärast PCL-koodi initsialiseerimist helistab MvvmCross
|_+_|
ja registreerige meie platvormispetsiifilised rakendused. Kui registreerime mitu üksikut rakendust, kasutab MvvmCross ainult viimati registreeritud rakendust. Kõik muud registreerimised hävitatakse.
Ehitage Xamariniga platvormidevahelisi rakendusi
Selles artiklis olete näinud, kuidas Xamarin võimaldab teil koodi jagada erinevatel platvormidel ja säilitada rakenduste loomulik tunne ja jõudlus.
MvvmCross annab veel ühe abstraktsioonikihi, parandades Xamariniga platvormidevaheliste rakenduste loomise kogemust. MVVM-i muster annab võimaluse luua navigeerimis- ja kasutajate suhtlusvooge, mis on tavalised kõigi platvormide jaoks, muutes platvormispetsiifilise koodi hulga, mille peate kirjutama, piirduma ainult vaadetega.
Loodan, et see artikkel on andnud teile põhjuse piiluda Xamarinisse ja motiveerinud teid sellega oma järgmist platvormiülest rakendust üles ehitama.
