Rääkige kõrgete ootuste seadmisest. Püha kolmainsus, ei midagi vähem!

Tõsi on see, et mitme platvormi sihtimisel on mobiilirakenduste väljatöötamine kulukas, kuna jagatud koodi pole. Apple nõuab, et kodeeriksite objektiiv-C või Swift, Android nõuab Java-koodi ja WinPhone .NET-i arendamist, sageli C #. Lisage sellele arvukalt raamatukogusid, mida iga platvorm pakub kaartide, jooniste, piltide või GPS-i haldamiseks - ühe mobiilirakenduse loomiseks on vaja tohutult aega ja teadmisi.

Ütlematagi selge, et enamik alustavatest ettevõtetest ei saa endale lubada oma kulutuste kolmekordistamist ja isegi asutatud ettevõtetel võib olla raske põhjendada mobiiliruumi sisenemise hinda.

Sellest artiklist saate teada, kuidas Xamarin Forms koos MVVMCrossi ja SkiaSharpiga võib olla elujõuline viis platvormidevahelise ehituse loomiseks mobiilirakendused rikkumata tuttavust, jõudlust ja ainulaadsust. Artiklis vaadatakse üle need kolm tehnoloogiat ja kuidas need saavad vähendada arenduskulusid, võimaldades koodi maksimaalset taaskasutust mitmel mobiiliplatvormil.

Oluline probleem

Platvormidevahelise mobiilirakenduse arendamise küsimus on reaalne ja sellisena on aastate jooksul tekkinud palju erinevaid lahendusi arenduskulud jagades koodi platvormide vahel. Näiteks videomängutööstuses pakuvad kõik suuremad mängumootorid platvormidevahelist lahendust, isegi Unreal ja Unity sihivad mobiiltelefone ja tahvelarvuteid.

Rakenduse esiküljel on seda platvormidevahelist turgu aastate jooksul korduvalt üritatud juhtida. Paljud jäid alla ja on kadunud kuristikku, kuid paar neist elab pärast mitmeaastast ellu jäämist. Nende hulgas on Xamarin, ainus .NET-lahendus, mis pakub tuge kõigile kolmele mobiiliplatvormile.

Pärismaalane või mitte, siin ma tulen

Nii et erinevate lahenduste vahel käib sõda ja kes ütleb, et sõda tähendab propagandat!

Sõda peetakse enamasti suurte rindel N : kohalik olla! Sõna peate olema ettevaatlik, kuna sellel pole selget tähendust. See on tänapäeval kõige enam kasutatav sõna mobiiliarenduse maailmas ja see on väga trendikas. Tõde on see, et keegi ei lepi kokku, mida see tegelikult tähendab.

Platvormiülese raamistiku valimisel ei ole kõik natiivsed valikud võrdsed, nii et olge ettevaatlik, võite võrrelda õunu apelsinidega. Mõne jaoks on see seotud programmeerimiskeelega, teiste jaoks riistvarafunktsioonide kasutamisega, kolmandate arvates platvormi API-de / kasutajaliidese kasutamisega ja sageli ainult veebirakenduse puudumisega.

Arutelu on mõlemal pool arutelu ja ma ei hakka süvenema, sest see on kasutu. Miks see kasutu on? Noh, lubage mul öelda teile raskesti neelatav tõsiasi: teie lõppkasutajad ei hooli sellest!

Jah, lugesite seda õigesti, ainult teie programmeerijad hoolivad sellest. Teie lõppkasutaja ei vali kunagi teie rakendust selle aluseks oleva tehnoloogia tõttu: ta valib teie rakenduse, kuna see vastab nende probleemile ja annab hea kogemuse.

Niisiis, selle asemel, et sõna tähenduse pärast võidelda, vaatame, kuidas Xamarin pakub tõhusat viisi oma kasutajatele kinkida.

Isa, Poeg ja Püha Vaim

Enne kui läheme edasi, selgitame lihtsalt kolme elementi, mis hõlmavad meie lahendust platvormidevahelise arendamise probleemile.

Isa: Xamarin

Nagu varem mainitud, on Xamarin .NET-lahendus mobiil- ja töölauarakenduste arendamiseks. Selle ostis Microsoft 2016. aastal, kuid see oli umbes neli aastat tagasi Mono projektiga. Tänapäeval pakub see kolme lahendust: Xamarin.iOS, Xamarin.Android ja Xamarin.Mac. Teised platvormid juba käsitsevad vaikimisi .NET-i rakendusi, olles Microsofti lahendused. Lühidalt, Xamarin pakub otselinki platvormi API-de jaoks .NET-is. Seetõttu saate kasutada .NET-rakenduse natiivfunktsioone. Xamarini jaoks on olemas ka laiendusmoodul nimega Forms, mis pakub kasutajaliidese abstraktsioonikihti.

Poeg: SkiaSharp

SkiaSharp on .NET-i ümbris Google'i Skia vektorgraafikakogu üle. Skia on Androidi, Chrome'i, ChromeOS-i ja Firefoxi kohalik renderdamismootor. SkiaSharpi abil saate oma .NET-i rakenduses asuvat teeki kasutada platvormidevaheliseks muutmiseks. See tähendab, et korraliku varju, mille teie disainer ütleb „muudab teie rakenduse nii palju paremaks”, saab kodeerida ainult ühe korra, selle asemel, et seda iga sihtplatvormi puhul korrata. Isiklikult arvan, et selle parim omadus on võimalus renderdada SVG-graafikat viisil, mis võimaldab teil vältida erinevate vormitegurite dubleerimist, säilitades samas karge, pikslitega täiusliku renderduse.

Püha Vaim: MVVMCross

Et kõik oleks hästi eraldatud ja lõdvalt ühendatud, tugineb meie pühitsetud lahendus MVVMCrossile. See raamistik rakendab MVVM-i (Model-View-ViewModel) infrastruktuuri, nii et kõike saab hoida sõltumatuna. Liiga tehniliseks muutmata jagunevad rakendused tavaliselt kolmeks osaks:

1. Mudel: meie andmete kujutis mälust
2. Vaade: meie kasutajaliides, mis esitab kasutajatele andmeid ja tegevusi
3. ViewModel: kiht, mis seob meie mudeli meie vaatega ja vastupidi

Tarkvaratehnikas püüame alati hoida vaate ViewModelist eraldi, nii et rakenduse loogikat (ViewModelis) saab uuesti kasutada isegi siis, kui muudame visuaalset esitust. MVVMCross aitab meil just seda saavutada, töödeldes andmesidemeid ning pakkudes mustreid ja tööriistu platvormi abstraktsiooniks.

Millest lõppkasutajad hoolivad

Lihtsalt kokkuvõtteks on erinevad asjad, mis eristavad edukaid rakendusi halbadest. Edukas rakendus:

1. Lahendab tegeliku elu probleemi
2. Pakub nauditavat elamust

Punkt number 1 pole ilmselgelt midagi pistmist teie valitud raamistikuga. Keskendugem siis punktile 2. Teie rakenduse nauditavusele aitavad kaasa kolm peamist aspekti:

1. Tuttavus
2. Performance
3. Ainulaadsus

Tuttavus

Tuttavus on seotud kasutusmugavuse ja rakenduse kaudu kiire leidmisega.

Teisisõnu tähendab see platvormi erinevate kasutajaliidese paradigmade kasutamist kogu süsteemi sidusal viisil. Näiteks lihtsustavad teie rakenduse tundlikkust lihtsad asjad, näiteks nuppude asukohad, kontekstitoimingute loetelu või navigeerimine.

Tuttavus on veebiliidesel põhinevate veebirakenduste või -raamistike peamine nõrk koht. Xamarin Forms pakub seevastu platvormidevahelisi kaardistusi müüja poolt pakutavate kasutajaliidese elementidega.

Seetõttu saavad teie kasutajad platvormi üldisele väljanägemisele vastava kogemuse, et nad tunneksid teie rakenduses end intuitiivselt.

Performance

Ausalt öeldes ei tähenda oma turunduspropagandas “emakeelena” mainimine midagi. Võta Jasonette näitena, mis on „kohalik HTTP kaudu“. Kasutajaliides on salvestatud veebiserverisse ... tere edasi-tagasi sõitu ja aeglustusi, nii et näeme, et emakeelena ei saa tingimata eeldada paremat jõudlust!

Niisiis, kui see müüt on kõrvale jäetud, tuleb Xamarin tegeliku elu võrdlusaluseid vaadates välja jõudluse osas kõige ümaram lahendus . Pakub Xamarin Forms, mis ei vaja märkimisväärselt rohkem kontekstilülitusi võrreldav toimivus emakeelsete rakendustega .

Minu järeldus on, et just teie rakenduse valikud võivad teie rakendust aeglustada, mitte Xamarin vs emakeel. Muud sealsed võimalused on jõudluse osas selgelt ebasoodsamas olukorras.

Ainulaadsus

Teie disainerite võimalus luua ainulaadse välimusega rakendus on samuti väga oluline kaaluda, kui soovite pakkuda parimat võimalikku kasutuskogemust ja eristada oma rakendust.

Mitu korda tähendab unikaalsus kohandatud väljanägemisega juhtnuppude, animatsioonide või žestide loomist. Kui see pole Xamarinis hõlpsasti saadaval, saate kasutada SkiaSharpi (mähis Google'i Skia vektorgraafika renderdamise teegi ümber) ja kasutada Xamarin Formsi kohandatud renderdaja kontseptsiooni, et saada riistvarale nii lähedal kui vaja, kodeerides alati ühes keelt, mida teised lahendused ei suuda pakkuda.

Mida te ettevõttena hoolite

Siinkohal mõtlete kõige tõenäolisemalt, et raamistiku valik on ka äriotsus. Lisaks teguritele, mis jäävad väljapoole seda artiklit, nagu inimressursside kättesaadavus, on Xamarinil palju pakkuda, eriti kui see on seotud MVVMCrossiga. Täpsustan nelja aspekti, mida soovite oma otsuses kaaluda:

1. Hind ja arenduskulud
2. Koodi taaskasutamine
3. Komponentide kättesaadavus
4. Toetus ja kogukond

Hind ja arenduskulud

Hoidkem see üks teelt. Kuna selle aasta alguses , Xamarin on vabakutselistele ja väikeettevõtetele, näiteks alustavatele ettevõtetele (koos Visual Studio kogukonna väljaanne ). Suuremate organisatsioonide jaoks on see «vabalt» kaasas Visual Studio litsentsiga, mis teil võib juba olla. Xamarin Forms, MVVMCross ja SkiaSharp on samuti kõik tasuta ja avatud lähtekoodiga!

Nagu ma juba mainisin, võimaldab .Net-marsruudi läbimine Xamariniga teil arendada oma rakendusi algusest lõpuni ühes keeles. Enamik teisi lahendusi eeldavad, et teie programmeerijad oskaksid erinevaid keeli. Juhul kui Cordova Näiteks peate olema sujuv mitte ainult HTML, Javascript, CSS, vaid ka Objective-C, Java ja / või C #, kui peate pääsema juurde hankija API-dele, millel pole saadaolevat pistikprogrammi.

Kasutatavate keelte mitmekesisus toob kaasa rohkem kontekstilülitusi ja rohkem tööriistu, et hallata tõhusust. Xamarin on seevastu kõik-ühes lahendus: Visual Studios saate ehitada, juurutada ja siluda kõikidel platvormidel.

Kuigi see pole otseselt seotud Xamariniga, saate C # -s ka palju funktsioone, mis kiirendavad arengut, valides .Net lahendus . Nimelt saavad teile kasu C # 4.5+ suurepärased funktsioonid, nagu lihtne mitmekeermine niitmine koos asünkroonimise / ootamise, sulgemiste ja peegeldumisega, mis kõik on näidanud tõhusust.

Koodi taaskasutamine

Tõenäoliselt olete mõelnud koodi taaskasutusele ja kõige tõenäolisemalt peate kõiki lahendusi selles osas mõnevõrra samaväärseks. Kahju, et ütlesin, et mate, aga eksite!

Programmeerijad teie seas võisid mõelda, miks pakuksin Maal MVVMCrossi kasutamist üle vormidesse sisseehitatud MVVM-i kihi? Noh, siin on midagi, mida tuleks kaaluda: kas ehitate tõesti ainult mobiilirakendusi?

Eraldades oma rakenduse loogika MVVMCrossiga ja kasutades selle pakutava juhtimise inversiooni, saate maksimaalset koodikogust taaskasutada mobiilseadmes, aga ka Windowsis ja Macis (kuna Xamarin.Mac on teie sõber).

See säästab mitte ainult teie raha, vaid pakub ka häid inseneritavasid, mis vähendavad teie koodi hoolduskulusid.

Komponentide kättesaadavus

Võib-olla pole te nagu mina, aga ma vihkan ratta uuesti leiutamist. Seetõttu on turule jõudmise aja kiirendamiseks ülioluline juurdepääs olemasolevatele komponentidele, mida saate hõlpsalt oma rakendusse integreerida, ja sageli vähendab see samal ajal ka teie kulusid.

Xamarini ja MVVMCrossi valimine pakub teile kahte võimalust olemasolevate komponentide valimiseks. Esiteks on Xamarini jaoks saadaval üha rohkem komponente koos vormidega või ilma. Xamarinil on Visual Studio sisse integreeritud komponentide pood, kust leiate mitmesuguseid lahendusi levinud rakenduse probleemidele ja teised ettevõtted müüvad otse, nii et otsige kindlasti enne, kui hakkate oma komponente kirjutama (või kaaluge nende müümist, kui need on ehitatud).

Teiseks soovite otsida Nugeti pakettidest, sest on tõenäoline, et keegi on juba koodi kirjutanud, et teha seda, mida vajate. Nende pakettide hulgast leiate korraliku loendi platvormidevahelistest MVVMCross pistikprogrammidest, mis lahendavad tavalisi probleeme nagu e-post, GPS või lokaliseerimine.

Kui olete C # -ga juba kogenud, on teil tõenäoliselt eelistatud komponendid. Muidugi ei taha te neid lahti lasta, nad tunnevad end nii mugavalt. Võite olla kindel, et saate olemasolevatele komponentidele luua C # -köited ja seejärel kasutada neid nii, nagu oleksime need Xamariniga komplekteeritud, isegi vormides, kus on kohandatud renderdajate natuke abi.

Sellest rääkides võiksite pilgu heita Xamarini köited Githubi hoidla enne oma loomist.

Toetus ja kogukond

Lõpuks on tugi ja näidete kättesaadavus raamistiku valimisel väga oluline tegur. Xamarin on olnud mõnda aega, nii et kogukond on täna üsna hea suurusega.

Google'ist teabe otsimine näitab tavaliselt üsna palju vastuseid (näpunäide: proovige otsida ka monotouchi ja monodroidi, Xamarini esivanemaid) ja Xamarin pakub oma veebisaidil palju näiteid ja suurepärast dokumentatsiooni.

Veelgi enam, kuna Xamarin on müüja API-de suhtes lihtsalt siduv, on Apple'i ja Google'i dokumentatsioon alati asjakohane ja vastab paljudele teie küsimustele. Seejärel saate luua oma MVVMCross-teenuse, et hankija API-d abstraktseks muuta teie jagatud koodi sees.

Mis puutub Xamarini tulevikku, siis kui Microsoft omandas selle eelmise aasta märtsis, siis panustan sellele, et see ei lähe kuhugi mujale kui edasi. Pärast seda müüki ja sobitamist vabamõõdulisele mudelile on kogukond ainult kasvanud, tugi paranenud ja toode on pidevalt paranenud, isegi kiiremas tempos!

Xamarini jaoks paistab tulevik helge.

Seame ennast valmis mürgliks!

Olen teadlik asjaolust, et võin selle artikliga avada ussikarbi. Ärge nüüd valesti aru saage, seal on ka muid võimalusi, mida tasub kaaluda, ja ma kutsun teid üles seda tegema, sest minu mured ei pruugi olla samad kui teie.

Pidage meeles, et kui teil on kuue nädala ajaskaala ja neli kuud hiljem pole teil rakendust veel valmis, siis te ei võida. See jätaks kaks ja pool kuud ning palju raha, et kedagi majas välja õpetada või asjatundlikku inimest palgata. Natiivse rakenduse ehitamise nõudmine sel hetkel võib olla teie projekti saatust üsna kahjulik.

Xamarin ja need kaasnevad tehnoloogiad pakuvad täpselt seda, mida teie kasutajad hoolivad ja mida te vajate. Loodan, et see artikkel aitab teil teha hästi teadliku otsuse raamistiku kohta, mille võite oma järgmise mobiilirakenduse jaoks valida.

Seotud: Paremad Androidi rakendused, kasutades MVVM-i puhta arhitektuuriga