Share
Helt siden Xamarin kom på scenen for flere år siden, har C # -utviklere vært glade for å kunne lage mobile applikasjoner som retter seg mot ikke-Microsoft-plattformer. Det er med litt spenning at vi nå kan skrive programmer på et språk som er veldig kjent for oss, og kunne distribuere dem til de store aktørene i mobilrommet, iOS og Android.
Siden disse appene kan skrives på et enkelt språk, er det bare fornuftig å skrive en enkelt kodebase som kompilerer til separate apper for de forskjellige plattformene, og til slutt gir oss mulighet til å nå verden av Skriv en gang, kjør overalt / hvor som helst. Dette høres bra ut på papir, men det var ikke helt tilfelle.
Konseptet med å skrive en applikasjon en gang og å kunne kjøre den på flere plattformer er ikke en ny. Utviklere har forsøkt å oppnå dette i mange år med skrivebords- og serverprogrammer skrevet i Java eller C / C ++, og kompilert til de spesifikke plattformene. Hvorfor skal mobilappene være forskjellige? Det enkle svaret er, det er de ikke. Som mobilapputviklere løper vi inn i de samme store plattformsprosessene som andre gjør, brukergrensesnittet.
Når det kommer til å skrive noen form for programvare som du vil kunne kjøre på forskjellige plattformer, lett en del er logikken. Av lett, Jeg mener delen av programmet som ikke endres uansett hvilken plattform du målretter mot. Uansett hvilken plattform du målretter mot, må du fortsatt få data fra tjenester, databaser, filer, etc. Odds er at dette vil svært sjelden endres. Den delen som endrer seg er brukergrensesnittet. Dette skyldes hovedsakelig de ulike forskjellene i de ulike plattformene. Hver plattform vil ha sin egen SDK, definere plattformens evner, så vel som deres visuelle komponenter og egenskaper.
Når du ser på dagens mobile landskap, vil du raskt finne ut at det er tre store spillere, iOS, Android, og Windows telefon. Disse tre er i konstant konkurranse for å prøve å upå de andre for å få mer markedsandel. Men i overskuelig fremtid er disse plattformene du vil målrette mot. Grunnen til at tversplattformsutvikling på mobil kan være vanskelig skyldes de grunnleggende forskjellene i brukergrensesnitt. En knapp er ikke lenger bare en knapp. En knapp er a UIButton med XML på iOS, a Knapp med AXML på Android, og a Knapp med XAML på Windows Phone.
Som med de fleste kryssplattformsrammer har Xamarin vanligvis hatt en lignende strategi når det gjelder å begrense hodepine som brukergrensesnittet forårsaker, dele logikken fra brukergrensesnittet.
I verden av C #, vil denne strategien vanligvis forlate deg med minst N + 1 prosjekter innenfor løsningen din. Du vil ha minst ett prosjekt for hver av de N plattformer du målretter mot og du må også ha minst ett prosjekt som vil inneholde all den delte koden som programmet bygger på. På den måten kan du få de plattformspesifikke prosjektene bare å referere til delt kodeprosjektet og bare trenger å bekymre deg for hvordan du visualiserer dataene. Takket være ny funksjonalitet i .NET og Mono-rammene har du et par alternativer.
Bærbare klassebiblioteker eller PCL kom først på scenen. Det er lettest å tenke på PCLer som vanlige klassebiblioteker, bare med begrenset funksjonalitet. Det er lettere å forstå dette konseptet med et eksempel. Start med å opprette en ny løsning / prosjekt og nevne det PCLDemo og velg Klassebibliotek (bærbar) som prosjektmal.
Når du klikker OK i Visual Studio ser du et annet vindu som dukker opp som ser ut som dette:
Avhengig av verktøyene du har installert, kan det se litt annerledes ut. På denne skjermen har du muligheten til å målrette mot så mange eller så få plattformer som du ønsker. Tommelfingerregelen her er å bare velge plattformene du absolutt må målrette mot. Årsaken til dette er at jo flere plattformer du ønsker å målrette, jo færre funksjoner vil bli inkludert i dette biblioteket. For en oppdatert liste over funksjoner som støttes av de ulike plattformene, sjekk ut Cross Platform Development med Portable Class Library-siden på MSDN.
Hvis du ikke velger de riktige plattformene i denne dialogboksen, kan du løpe inn i inkompatibilitetsproblemer senere. For å se dette i handling fjerner du de tre nederste alternativene:
Nå lager et nytt prosjekt av en av de typene du fjernet støtte fra i PCL. Som et eksempel kan du opprette et nytt Xamarin.Android-prosjekt ved hjelp av noen av de medfølgende maler. Når prosjektet er opprettet, høyreklikk på referanser og velg Legg til referanse. I Referansesjef dialog, velg Løsning> Prosjekter fra filteret til venstre og merk av i boksen ved siden av PCLDemo prosjekt.
Når du klikker OK, Du får se en feil som følgende:
Denne feilen gjør at du kan vite at prosjektet du er inne i, ikke er kompatibelt med målene som er tilgjengelige i den valgte PCL. Du kan jobbe rundt dette ved å gå inn i PCL-prosjektets egenskaper og endre målene. Men husk, jo flere mål, jo færre støttede funksjoner.
Selv om det er noen ting du må passe på når du bruker PCL, er det noen veldig gode fordeler.
Når du velger en ny teknologi eller plattform å bruke, betaler den også å forstå ulempene som må løses.
Hvis PCL ser for begrensende for deg som et valg for delt kode, er det et annet alternativ.
I den nylig utgivelsen av Visual Studio 2013 Update 2, har Microsoft lagt til støtte for delte prosjekter. Delte prosjekter er en annen måte å dele kode mellom forskjellige plattformer på, på noen måter ligner på PCLer og på andre måter drastisk forskjellige. La oss begynne med å lage et enkelt eksempel.
Begynn med å opprette en annen løsning / prosjekt i Visual Studio og gi det navnet på SharedDemo og velg Delt prosjekt (tom) som din mal.
Hvis du ikke ser Delt prosjekt (tom) Som et alternativ må du sørge for at du har den nyeste versjonen av Visual Studio 2013 Update 2. Hvis du bruker den nyeste versjonen og fortsatt ikke ser den, må du kanskje installere utvidelsen for delt prosjektreferansebehandler.
Når du klikker OK, Visual Studio vil skape et nytt prosjekt for deg i Solution Explorer, men det vil se litt annerledes ut enn du er vant til.
Det virker litt ensomt, va? Det er ingen Eiendommer mappe og nr referanser mappe. Hva skjer? Det er skjønnheten og ofte kilden til forvirring for de fleste utviklere. Som standard inneholder et delt prosjekt ikke egentlig tilgang til noen funksjonalitet i det hele tatt. Det er noe magi som skjer bak kulissene i Visual Studio / Xamarin Studio, men du vil se det snart.
En annen merkelig egenskap ved et delt prosjekt er at du faktisk ikke kan bygge den. Hvis du skulle høyreklikke løsningen eller prosjektet, ville du ikke se noen alternativer for bygging, kjøring eller feilsøking av dette prosjektet. For å forstå hvorfor dette er, må du ta et skritt tilbake et øyeblikk.
Hva er formålet med å bygge et prosjekt? Hensikten er å forvandle koden fra tekst til en faktisk fil som kan brukes av systemet du kjører på eller et annet program. Derfor kan du ikke faktisk bygge et delt prosjekt, ingen utdatafil genereres av den. Dette spesialiserte prosjektet har en helt annen hensikt.
Når du oppretter et delt prosjekt og skriver kode i det, kan du legge til referanser til det fra andre prosjekter så mye du vil. Det er ingen plattformer å målrette mot eller regler som skal følges. Dette er den første differensieringen fra PCL. La oss fortsette med et eksempel. Lage en ny Xamarin.Android og / eller Xamarin.iOS prosjektet i løsningen og navn dem på riktig måte, SharedDemo.Android og / eller SharedDemo.iOS.
Nå som du har et nytt prosjekt, høyreklikker du på referanser mappe og velg Legg til delt prosjektreferanse. Hvis du ikke ser dette som et alternativ, kan det hende du må vurdere å legge til utvidelsen for delt prosjektreferansebehandler.
Herfra klikker du OK og du bør se noe som ligner på dette:
Dette er hvor magien kommer inn i spill. Koden som finnes med et delt prosjekt vil være samlet inn i eventuelle prosjekter som refererer til det. Det er derfor du ikke kan bygge dem direkte, de trenger noe å referere dem før de kan bygges og kompileres. Det faktum at de kan legges til et hvilket som helst prosjekt som referanse er en del av grunnen til at de er så gode kandidater for utvikling av tversplattform.
Den andre grunnen til at de er gode kandidater for tversplattformutvikling, er deres støtte til kompilatordirektiver. Du kan plassere sjekker for spesielle direktiver i dine delte prosjekter, slik at bare bestemte plattformer får visse funksjoner, eller at ting håndteres annerledes på forskjellige plattformer. Følgende direktiver finnes i plattformprosjekter:
Accentsconagua
__MOBIL__ Xamarin.Android og Xamarin.iOS prosjekter__IOS__ Xamarin.iOS prosjekter__ANDROID__ Xamarin.Android prosjekter__ANDROID_xx__ Xamarin.Android prosjekter hvor xx erstattes av den målrettede Android API-versjonenWINDOWS TELEFON Windows Phone prosjekterSilverlight Windows Phone prosjekterDu kan bruke disse retningslinjene inni # ifdef blokker for å sjekke hvilken plattform du kjører på, og bruk betinget kompilering for å bare inkludere hva som trengs for hvert prosjekt. Dette er gjort for deg av kompilatoren. La oss se et eksempel.
I din SharedDemo prosjekt, legg til en ny klasse som heter Oppskrift og erstatt standard implementering med følgende:
offentlig klasse Oppskrift offentlig streng ShortName get; sett; #if __iOS__ offentlig streng LongName get; sett; #endif offentlig listeIngredienser get; sett; offentlig liste Veibeskrivelse get; sett;
Dette er litt av et godt eksempel, men det tjener til å illustrere et enkelt punkt. Siden jeg refererer til denne koden fra et Xamarin.Android-prosjekt, inneholder oppskrifts klassen kun 3 egenskaper, Kort navn, ingredienser, og Veibeskrivelse. Hvis denne koden er referert av et Xamarin.iOS-prosjekt, vil det også inneholde LongName eiendom.
Du er mer sannsynlig å bruke disse direktivene i situasjoner hvor du går inn i plattformdivergens. Vanlige divergensavvik på disse mobilplatformene har å gjøre med å få tilgang til maskinvare, filsystemet, etc. Du kan nå plassere plattformskode i delt prosjekt delt på retningslinjene, og Visual Studio håndterer den plattformspesifikke samlingen til de riktige prosjektene. Veldig fint.
Delte prosjekter inneholder noen veldig fine funksjoner som hjelper til med opprettelsen av tversplattformprosjekter.
Mens delte prosjekter har gode funksjoner, er det noen få ikke så ønskelige egenskaper.
Du er nå klar over de grunnleggende strategiene for å dele applogikken din. Det er på tide å begynne å se på appens brukergrensesnitt. I den nyeste versjonen av versjon 3 av Xamarin er en av de mest spennende funksjonene innføringen av Xamarin.Forms. Xamarin.Forms er et bibliotek som inneholder abstraksjoner av typiske brukergrensesnittkontroller som inneholder appens brukergrensesnitt. Når disse kontrollene brukes på de spesifikke plattformene, blir de kartlagt for å gjengi innfødte brukergrensesnittkontroller, slik at du får utseendet på innfødte komponenter.
Den grunnleggende strukturen til ditt tversplattformsprogram endres ikke. Du vil fortsatt følge N + 1-regelen når det gjelder prosjekter, men du vil nå flytte din plattformspesifikke brukergrensesnittkoden fra de plattformspesifikke prosjektene til de delte prosjektene. Før vi blir forut for oss selv, må vi forstå behovene og kravene til ikke bare å kjøre, men utvikle Xamarin.Forms apps.
Det er et par krav hvis du vil dra full nytte av Xamarin.Forms. For å bruke Xamarin.Forms må appen din målrette mot følgende plattformer:
Dette betyr at hvis du planlegger å målrette mot noen av de eldre versjonene av disse plattformene, vil du ikke kunne bruke Xamarin.Forms. I tillegg til målplattformrestriksjoner, er det også noen utviklingssystemkrav.
Når du har alt nedlastet og konfigurert, er du klar til å komme i gang.
Grunnleggende ideen bak Xamarin.Forms er enkel, du refererer til vanlige brukergrensesnittkontroller på samme måte, uavhengig av plattformene du målretter mot. En knapp er en knapp er en knapp. Du lager disse kontrollene og gir dem visuelle egenskaper og funksjonalitet. Deretter bruker du en Oppsett å plassere kontrollene på skjermen og vise alt på a Side. Hvis du er vant til å bruke plattformspesifikk terminologi for å beskrive brukergrensesnittkomponentene i appene dine, kan det ta litt tid å venne seg til de nye vilkårene. Heldigvis er det bare noen få begreper å forstå.
I Xamarin.Forms representerer Pages de faktiske skjermbildene i søknaden din. Med hensyn til andre plattformer, a Side er en Aktivitet på Android, a UIViewController på iOS og a Side på Windows Phone. De Side er hovedobjektet du vil håndtere når du arbeider med overganger og navigering. Også en Side inneholder bare et enkelt barn, som i de fleste situasjoner er en eller annen type Oppsett.
Layouts er kontroller som brukes til å organisere brukergrensesnittkomponenter på din Side på en logisk måte. Innenfor en Oppsett, Du kan angi egenskaper til brukergrensesnittkontrollene, for eksempel posisjon og størrelse. Du kan legge til et hvilket som helst antall UI-komponenter til et layout, inkludert kontroller og andre Oppsett objekter.
I Xamarin.Forms er visningene det du vanligvis refererer til som kontroller. Felles Utsikt objekter i Xamarin.Forms er Knapp, Merkelapp, og Listevisning, for å nevne noen. De Oppsett klassen arver faktisk fra Utsikt klasse, noe som betyr at de kan behandles på samme måte og legges til Oppsett objekter.
Cellene er spesialiserte brukergrensesnittkomponenter som brukes til å tilpasse det som vanligvis vil bli referert til som rader innenfor Listevisning og UITableView objekter. Det er pre-bygget Celle typer for å legge til en rekke forskjellige tilpasninger til din Utsikt objekter.
For å lage et grunnleggende Xamarin.Forms-program, åpne Visual Studio, velg Fil> Nytt prosjekt, velg Mobile Apps kategori, og velg riktig mal. Jeg har valgt Blank App (Xamarin.Forms Delt) mal. Dette vil opprette en Xamarin.Forms-applikasjon ved hjelp av Delt prosjekt mal.
etter å ha klikket OK, Din løsning vil bli opprettet med fire prosjekter. Som diskutert før vil du ha tre plattformspesifikke prosjekter og ett delt prosjekt. Det delte prosjektet inneholder applikasjonslogikken, samt alle Xamarin.Forms-koden som skal være ansvarlig for å lage skjermene (Side objekter) av søknaden din.
Hvis du åpner SampleFormsApp prosjekt, vil du se en enkelt klasse som heter App.cs. Dette er hovedfilen til prosjektet som inneholder Side definisjoner som til syvende og sist vil vises på målplattformene. Det er en enkel klasse som bare inneholder følgende:
offentlig klasse App offentlig statisk side GetMainPage () returner nytt ContentPage Content = ny etikett Text = "Hei, skjemaer!", VerticalOptions = LayoutOptions.CenterAndExpand, HorizontalOptions = LayoutOptions.CenterAndExpand,,;
Klassen app er ganske enkelt fordi den bare inneholder en enkelt statisk metode som returnerer a Innholdsside gjenstand. EN Innholdsside objekt er den mest grunnleggende, uten frills Side som du kan opprette. Det er lettest å tenke på a Innholdsside som et tomt lerret som du kan gjøre alt du vil ha med. Det er svært liten funksjonalitet innebygd i den.
Du finner vanligvis det meste Side objekter har a Innhold eiendom som lar deg tildele Utsikt protestere mot det. I dette tilfellet er det enkelt Merkelapp se det utskrifter "Hei, skjemaer!" til skjermen samtidig som den gir noen grunnleggende formatering for å sentrere den.
For å få dette Innholdsside å laste på hver plattform som vi målretter mot, er det noen tilpassede plattformspesifikke kode som må inkluderes i hvert av plattformsprosjektene. La oss se på iOS-prosjektet først. Åpne SampleFormsApp.iOS prosjekt og ta en titt på AppDelegate.cs fil. Dette er filen som inneholder ledninger i Xamarin.Forms verden.
offentlig overstyring bool FinishedLaunching (UIApplication app, NSDictionary alternativer) Forms.Init (); window = new UIWindow (UIScreen.MainScreen.Bounds); window.RootViewController = App.GetMainPage (). CreateViewController (); window.MakeKeyAndVisible (); returnere sant;
Først initierer vi Xamarin.Forms-biblioteket ved å påkalle Forms.Init (). Deretter setter den eneste egendefinerte koden inn window.RootViewController eiendom til resultatet av App.GetMainPage (). CreateViewController () anrop. Den linjen vil starte i Xamarin.Forms verden, og alt fra det punktet fortsetter å bruke Xamarin.Forms.
Prosessen for å initialisere Xamarin.Forms i Android og Windows Phone er veldig lik. Du ringer til I det metode og sett inn initialen Side å være et resultat av App.GetMainPage () metode. Dette er hvordan det ser ut i SampleFormsApp.Android prosjekt i MainActivity.OnCreate metode.
beskyttet overstyring ugyldig OnCreate (Bundle Bundle) base.OnCreate (bunt); Xamarin.Forms.Forms.Init (dette, bunt); SetPage (App.GetMainPage ());
Og i SampleFormsApp.WinPhone prosjekt i Hovedside konstruktør av delklassen Hovedside:
offentlig MainPage () InitializeComponent (); Forms.Init (); Innhold = SampleFormsApp.App.GetMainPage (). ConvertPageToUIElement (dette);
Du bør nå ha en grunnleggende forståelse av Xamarin.Forms, så vel som hva du kan oppnå ved å bruke dem. Reisen inn i denne fantastiske teknologien stopper ikke der. Du vil ha et annet valg foran deg når du bruker Xamarin.Forms, som har å gjøre med layout. Og det er nettopp det som blir dekket i neste opplæring.
Hvis du vil lære mer om Xamarin, så sjekk ut kurset vårt. Bygg Multi-Platform Apps med C # i Xamarin.
I løpet av kurset lærer du hvordan du oppretter et kryssplattformsprogram fra en enkelt kodebase som vil kjøre på tre forskjellige plattformer: iOS, Android og Windows Phone 8. Tror det ikke kan gjøres? På bare en liten stund vil du gjøre det selv. La oss komme på jobb.
Du kan ta det straks med en helt gratis 14 dagers prøve av et Tuts + abonnement. Ta en titt på abonnementsalternativene våre for å komme i gang, eller hvis du bare er interessert i dette kurset, kan du kjøpe det individuelt for $ 15! Her er en forhåndsvisning for å komme i gang:
