An Introduksjon til Xamarin: Part 3
42
Del
8
Del
Dette Cyber ​​mandag Envato Tuts + kurs vil bli redusert til bare $ 3. Ikke gå glipp av
Dette innlegget er en del av en serie som heter An Introduction to Xamarin.An Introduksjon til Xamarin. Del 2
1. Før du begynner

Forhåpentligvis til dette punktet, har du fulgt med disse innledende opplæring på hva Xamarin er og hvordan du bruker den. Hvis du har, så du er primet og klar for neste steg i din Xamarin opplæring, på tvers av plattformer. Hvis ikke, så hodet tilbake og ta en titt på de tidligere opplæringsprogrammer for å få en bedre forståelse av hvordan denne fantastiske teknologien fungerer. Når du har det grunnleggende kunnskap, kan du komme tilbake og følge med.

2. Angi misforståelse

For flere år siden, da mange av de kryssplattform løsninger begynte å dukke opp, så gjorde misforståelse av Skriv Når Run Anywhere
eller Wora
. Mange utviklere begynte å sikle ved tanken på å være i stand til å skrive sine programmer i et enkelt språk, og har det kjøres på ulike mobile plattformer. Ideen er ikke feil, det bare ble litt feilinformert i begynnelsen.

Drømmen om Wora blir virkelighet når du vurderer den vanlige logikken i søknaden din. Hva regnes som vanlig logikk? Nesten alt som ikke har å gjøre med brukergrensesnittet. Dette kan bety domenet gjenstander eller modeller, datatilgang lag, service lag, etc. Alle disse komponentene holdes atskilt fra brukergrensesnittet. De er bitene i puslespillet som gjør din søknad viktig for brukerne.

De drømmer om Wora begynner å bryte ned når du begynner å se på kosmetiske aspekter av programmet ditt. På dette punktet du begynner å håndtere ulike SDK med ulike måter å beskrive elementene i brukergrensesnittet. En knapp er ikke lenger bare en knapp. En knapp er nå et knappeobjekt rives med XAML og C # (blant andre mulige språk) på Windows Phone. En knapp er et knappeobjekt som er beskrevet i AXML og Java på Android. En knapp er en UIButton eksempel beskrevet i et proprietært XML-format og Objective-C på iOS.

Gitt de verktøyene du har til rådighet, det beste du kan gjøre er å lage en separasjon av disse brukergrensesnittkomponenter fra din funksjonell kode. Alt dette begynner å forandre seg med innføringen av Xamarin.Forms i den siste utgaven av Xamarin tre, men vi vil dekke det i en annen tutorial.

Når du ønsker å lage en kryssplattform app i Xamarin økosystemet , vil du vanligvis går med formelen for å skape minst n + 1
prosjekter for hver app som er rettet mot n
plattformer. Hvorfor i det minste? Hvorfor n + 1? N + 1 er den enkle delen. Den vanligste måten er å dele din søknad opp i separate prosjekter som dette:

App.Core

App.iOS (Xamarin.iOS prosjekt)

App .Android (Xamarin.Android prosjekt)

Du vil ønske å skape et konkret prosjekt for hver plattform. I ditt tilfelle ville du oppretter en Xamarin.iOS prosjekt og en Xamarin.Android prosjekt. Beste praksis vil fortelle deg å legge inn navnet på plattformen på slutten av prosjektet navn bare for å gjøre fordelingen mer åpenbar. Det tredje prosjektet er 1
, prosjektet der du holde alle dine plattformuavhengig kode som kan gjenbrukes av andre prosjekter i din løsning eller i andre løsninger.

minst
del er mer av en personlig preferanse. Avhengig av hvor du vanligvis liker å bryte opp koden din, kan det tredje prosjektet (Core) enten være en klassebibliotek eller flere. Det er helt opp til deg. Det er der du får til å bøye kreative muskel. Men det er ikke like enkelt som å lage en ny klassebibliotek prosjekt og banging ut noen kode. Hvis det var så enkelt, alle ville være å gjøre det. Heldigvis har du noen prøvde og sanne alternativer for å dele denne koden.

3. Dele Kode

Hvis du ønsker å skrive kode i C # og dele den på tvers av flere plattformer i en Xamarin prosjekt, har du tre grunnleggende alternativer:

Fil Linking

Portable Class Libraries

felles prosjekter

Som Xamarin fortsetter å utvikle seg, Fil Linking
en tendens til å falle av kartet, men vi vil diskutere hvert alternativ separat for å lar deg velge den som passer best.

Fil linking

Fil linking er et levedyktig alternativ i Xamarin Studio og har eksistert i Visual Studio for en stund. Det er et alternativ som lar deg skrive kode i en fysisk fil og har alle andre prosjekter har tilgang til som en fil. Dette betyr at eventuelle endringer du gjør i knyttet
fil, vil føre til endringer i opprinnelige
fil. Dette er fordi det er egentlig bare en fil.

Det motsatte tilnærmingen fil linking er å lage kopier av originalfilen på annen prosjekt i din løsning som trenger tilgang til en bestemt kode. På den måten når du gjør endringer i disse filene i noen av prosjektene, blir endringene begrenset til at fysisk fil og ikke den opprinnelige.

Hvordan lenke filer

Prosessen med å knytte filer til forskjellige prosjekter i løsningen er svært like, enten du bruker Xamarin Studio eller Visual Studio. La oss begynne med å lage en ny klassebibliotek prosjekt i enten IDE.

I dette eksemplet navnet ditt første prosjekt SourceLibrary
. Innenfor denne klassebibliotek, opprette en ny klasse og name it Bruker. Bytt implementering klassens med følgende:
public class User {public String fornavn {får; sett; } Public string Lastname {får; sett; }}

Du har nå en enkel klasse som representerer en bruker i programmet. Hvis du ønsket å dele at konseptet med et annet prosjekt i din løsning, kan du legge til en
. Først må du opprette en ny klassebibliotek prosjekt i din løsning. La oss kalle dette en LinkLibrary
. Når du har opprettet prosjektet, kan du legge en link til din bruker klassen ved å høyreklikke på LinkLibrary
prosjektet og velge Legg til filer
i Xamarin Studio eller Legg til eksisterende filer
i Visual Studio. Naviger til filen du vil koble til i Åpne fil
dialogboksen. Når du klikker på Åpne
knappen Xamarin Studio vil du bli presentert med en dialogboks som ser slik ut:

For å legge til en kobling, velger det siste alternativet, Legg til en kobling til filen
, og klikk OK
. Du har nå opprettet en kobling til den opprinnelige filen.

I Visual Studio, når du finner filen du vil koble til i Åpne fil
dialog, vil du se at det er litt rullegardinmenyen til høyre kant av Legg
knappen. Hvis du klikker på denne menyen, vil du bli presentert med et par alternativer:

Legg
, standardvalget som skaper en kopi av denne filen i det aktuelle prosjektet

Legg til som link
, skaper en kobling til den opprinnelige filen i det aktuelle prosjektet

Etter å ha klikket Legg til som link
, Visual Studio vil opprette en kobling til bruker filen i LinkLibrary
prosjekt. Når du oppretter en kobling til en fil, vil du se at koblede filen i din nåværende løsning med en merkelig ikon i hjørnet for å markere at det er en koblet fil.

Nå, redigere bruker klassen i LinkLibrary
prosjekt for å se slik ut
public class User {public string fornavn {få.; sett; } Public string Lastname {får; sett; } Public string Username {får; sett; }}

Etter å lagre endringene og gå tilbake til
User klasse i SourceLibrary
prosjekt, bør du se at begge versjonene har endret seg.

Dette kan virke som mye arbeid. Hvorfor ikke lage alt dette delt logikken i et typisk klassebibliotek prosjektet og legge referanser til denne forsamlingen fra plattformspesifikke forsamlinger? Svaret er at du ikke kan.

Når du oppretter en iOS eller Android søknad fra Xamarin.iOS eller Xamarin.Android prosjektmaler, du er veldig begrenset til samlinger som du kan referere til. Menighetene som er opprettet i denne prosessen er begrenset i funksjonalitet og biblioteker som støttes. Problemet er at, som standard, inneholder typisk klassebibliotek prosjektet tilgang til mye mer funksjonalitet enn de Xamarin bibliotekene støtte. Frykt ikke, er det noen midlertidige løsninger.

Bærbar klassebiblioteker

Bærbare Class Libraries eller PCLs er den neste evolusjonen i å skape kryssplattform kode i verden av .NET. PCLs er strippet ned versjoner av klasse bibliotekprosjekter som bare inneholder bare-bones funksjonalitet stand til å bli referert og kjøre, uten endringer, i flere forskjellige typer prosjekter. Listen over støttede plattformer og funksjoner fortsetter å vokse. For å få flere detaljer om PCLs og for å se de støttede plattformer og funksjoner, ta en titt på den bærbare Class Library side på MSDN.

Generelt måten PCLs arbeid er ved å lage alle dine delte logikk i en PCL prosjektet og deretter legge henvisninger til at prosjektet fra plattformspesifikke prosjekter. Den eneste forskjellen i denne prosessen fra å lage en normal klasse bibliotek prosjektet er en ekstra trinn.

Opprette en PCL

Start med å lage et nytt prosjekt i Xamarin Studio eller Visual Studio, velger du klasse
Bibliotek
som prosjektmalen, og navnet på prosjektet TypicalLibrary
. Deretter legger du et nytt prosjekt til din løsning. Velg Class Library (Portable)
som mal og gi den navnet PortableLibrary
. Avhengig av din IDE, kan denne prosessen avvike noe.

Hvis du lager din nye Bærbar Class Library
prosjekt i Visual Studio, en dialog som ligner den nedenfor vises.
< p> Avhengig av hvilken versjon av Visual Studio, .NET Framework, og Xamarin verktøy installert, kan du se forskjellige alternativer, men begrepene er de samme. Du har valget mellom å velge de ulike plattformene du ønsker å støtte. Kombinasjoner av plattformene du velger her er bare begrenset av fantasien. Bare sørg for å bare velge de plattformene som du trenger. Jo flere plattformer du velger, jo mer begrenset utvalg av funksjoner du kan få tilgang til i din PCL.

Hvis du bruker Xamarin Studio, vil du ikke se dialogboksen ovenfor. Xamarin Studio vil sette lignende alternativer for deg som standard. For å endre de støttede plattformene, høyreklikker du på PortableLibrary
prosjektet og velg Alternativer
. I Prosjekt alternativer
dialogboksen, velger du Generelt
under Bygg
delen. Du skal se et sett med alternativer som ligner de som er vist nedenfor.

Siden dette er bare en demonstrasjon, kan du velge noen av plattformene som du liker. For å bevise poenget skjønt, sørg for at du i det minste har valgt Xamarin.Android
som en av de støttede plattformene.

Til slutt legger et annet prosjekt til din løsning. Velg Android Application
mal og navngi prosjektet BasicAndroidApplication
. For å bruke den funksjonaliteten du har opprettet i en klasse bibliotek, legge til en referanse til det fra Android-appen. Hvis du bruker Xamarin Studio, gjør du dette ved å høyreklikke på Referanser
mappe under BasicAndroidApplication
prosjektet og velge Rediger Referanser
. I Rediger Referanser
dialogboksen, velger du kategorien Prosjekter
å referere en forsamling i din nåværende løsning. Dette er hva du vil se:

Du kan velge PCL ( PortableLibrary
), men som du kan se normal klassebibliotek ( TypicalLibrary
) er inkompatible.

Forsøk denne øvelsen i Visual Studio til slutt vil ende på samme sted, men Visual Studio kommer til å være litt mindre opplagt. Det vil la deg legge til en referanse til den vanlige klassebibliotek, men under BasicAndroidApplication Refereces
ser du TypicalLibrary
oppført med et advarselsikon.

Når du bygge prosjektet, vil du motta en advarsel i Feilliste
lik den som er vist nedenfor.

Selv om dette kan virke litt bedre enn Xamarin Studio bare smelle døren i ansikt, men dette vil føre til andre problemer nedover veien når du prøver å teste og feilsøke programmet. Du vil kjøre inn feil og andre problemer som kan gjøre debugging vanskelig, så vil du definitivt ønsker å være klar over disse typer advarsler når du bruker en PCL.

Bruke PCLs

Når du bruker PCLs i din løsning, er det svært få forskjeller med å bruke vanlige klassebiblioteker. Under utviklingen når du ønsker å bruke noen klasser som er definert innenfor PCL, du bare legge en referanse til det og vekk du går. Under byggeprosessen, er resultatet av en PCL en
DLL-fil, akkurat som en vanlig klassebibliotek.

Når du oppretter og referanse PCLs i prosjektet, at fysisk
DLL-filen er inkludert i søknaden, så ved første påføring forsamlingen alltid har tilgang til den. Dette kan komme som noen overraskelse for deg, men det er en karakteristiske kjennetegn når man sammenligner det med det tredje alternativet, som vi skal diskutere nå.

Shared Projects

felles prosjekter og støtte for sin tilsvarende prosjektmaler ble lagt i Xamarin Studio 5 og Visual Studio 2013 Update 2. Selv om navnet er heller beskjeden, disse prosjektene fungerer ganske annerledes enn sine klassebibliotek og PCL fettere. Disse prosjektene har ikke de begrensningene som en PCL gjør. De har full tilgang til innebygde biblioteker og samlinger i .NET Framework, med unntak av at du ikke er i stand til å legge til flere referanser og komponenter til disse prosjektene.

Opprette en delt Prosjekt
< p> Start med å lage en ny Løsning /Project i Xamarin Studio eller Visual Studio. Velg C #
som språk og velg Delt Prosjekt
mal. Hvis du bruker Visual Studio og du ser ikke dette som et alternativ, så må du laste ned og installere Fellesprosjektet Reference Manager forlengelse. Når installasjonen er ferdig og du har startet Visual Studio, bør du se dette alternativet.

Når du har opprettet prosjektet, vil du se at det er litt tom. Det er ingen Resources
eller Komponenter
mapper. Det er ingen Egenskaper
eller standard klasser opprettet. Du får bare en blank tavle.

Du vil også legge merke til at det er færre egenskaper når du høyreklikker på prosjektet og velg Egenskaper
fra kontekstmenyen.

det eneste valget du har for å bytte valg i en delt Prosjektet er det Root Navnerom
. Root Navnerom
er standard navneområde gis til alle klasser er opprettet i den delte prosjektet slik at du ikke trenger å oppdatere dem manuelt.

Støtte for kompilator direktiver

En av de viktigste aspektene ved felles prosjekter er deres støtte til kompilatoren direktiver. Dette er en av grunnene til at de passer så godt inn i cross-platform prosjekter. Det finnes en rekke direktiver som inngår i Xamarin og Windows Phone prosjekter.

__ MOBILE__, definert i både Xamarin.iOS og Xamarin.Android prosjekter

__ IOS__, definert i Xamarin.iOS prosjekter

__ ANDROID__, definert i Xamarin.Android prosjekter

WINDOWS_PHONE, definert i Windows Phone-prosjekter

Silverlight, er definert i Windows Phone prosjekter

i tillegg til disse generiske direktivene, gir Xamarin.Android en rekke konkrete direktiver for å målrette en bestemt versjon av Android SDK. Det er ikke uvanlig å se et direktiv som ligner __ANDROID_11__, for eksempel. Disse direktivene kan brukes i betingede preprosessor uttalelser å la kompilatoren vet å bare forsøke å kompilere koden i dem hvis de spesielle direktivene er definert.
Ta en titt på følgende eksempel bruker public class {#if __ANDROID__ offentlig String fornavn {få.; sett; } #endif Offentlig string Lastname {får; sett; }}

Dette kan være litt av en contrived eksempel, men det tjener et formål. Når kompilatoren kommer over denne blokken med kode i en Xamarin.Android prosjekt, vil brukeren klassen har både fornavn og etternavn egenskaper. Hvis du var å bygge dette i en Xamarin.iOS prosjekt, ville Bruker klassen inneholder bare Etternavn- eiendom.

Denne prosessen med betinget kompilering kommer i hendig når du arbeider med plattformspesifikke forskjeller. Disse forskjellene kan komme inn i bildet når du bruker enheten eller plattformspesifikke funksjoner som lokal lagring. Med direktiver, har du muligheten til å skrive plattformspesifikk kode i en fil i motsetning til flere filer på tvers av flere prosjekter. Veldig hyggelig.

Bruke felles prosjekter

Når du bruker felles prosjekter i et program, er det et par ting du må se opp for. Du har kanskje lagt merke til når man ser på egenskapene forbundet med en felles prosjektleder at det var ingen valg for å velge en Target rammeverk
eller Output typen
. Det er fordi disse små skjønnheter ikke er faktisk utarbeidet i egne samlinger. Kode som er skrevet i en delt prosjektet er kompilert inn i ethvert prosjekt som refererer den.

Hva skjer hvis du har en delt Project i din løsning som ikke er referert til av andre prosjekter? Ikke noe. Koden er ikke utarbeidet og senere ikke inkludert hvor som helst. Det samme vil skje hvis du legger til en referanse til en Xamarin.iOS prosjekt som peker til en delt prosjektet som inneholder bruker klasse over. Siden __ANDROID__ direktivet ikke er definert innenfor Xamarin.iOS, vil Fornavn eiendommen ikke kompilert inn i Xamarin.iOS prosjektet.

4. Dele Kode Retningslinjer

Basert på ovennevnte strategier for å dele kode blant tvers av plattformer, har du noen beslutninger å gjøre. Den følgende diskusjonen skisserer fordeler og ulemper med hver strategi og presenterer en rekke retningslinjer for å hjelpe deg med dette vedtaket. Husk at det ikke er rett eller beste strategien. Noen av disse alternativene fungerer, men man kan være litt mer ønskelig over en annen.

Fil Linking

Fil Linking er prosessen med å opprette logiske koblinger fra ett prosjekt til en fysisk fil i et annet prosjekt eller katalogen.

Pros

bare en fysisk fil for å opprettholde

endrer koden bare må gjøres en gang

Cons


endringer i koblede filer vil påvirke all kode henviser dem

knytte flere filer og kataloger er en flertrinnsprosess

bærbar Class Libraries

en PCL er et spesialisert klassebibliotek prosjekt som kan inkluderes og kjøres på flere forskjellige plattformer uten forbehold.

Pros

genererer en forsamling som kan refereres til av andre prosjekter

all refactoring og testing kan gjøres på ett sted

Cons

kan ikke referere til noen ikke-PCL eller plattformspesifikke forsamlinger

bare omfatter et delsett av funksjonene i .NET Framework

felles prosjekter

en felles prosjektet er en spesialisert prosjekt mal slik at du kan skrive kode som er direkte kompilert inn i ethvert prosjekt som refererer til det . Det tillater bruk av preprosessor direktiver for å inkludere alle plattformspesifikk kode for å leve i det samme prosjektet.

Pros

kan bruke direktiver for å målrette spesifikke plattformer i en enkelt fil

ha tilgang til andre refererte forsamlinger prosjekter henviser dem

Cons

det er ingen effekt filen slik kode kan ikke deles med prosjekter utenfor løsningen
< li> refactorings inne inaktive kompilatordirektiver vil ikke oppdatere prosjektet

tommelfingerregler

med utviklingen av Xamarin og innføring av felles Prosjektstrategi strategi~~POS=HEADCOMP, Fil Linking
alternativet har alle, men falt til veikanten. Det betyr ikke at du ikke kan eller bør ikke bruke dette alternativet, det betyr bare at i de fleste tilfeller den Bærbar Class Library
eller Delt Prosjekt
strategier kan være den beste passform. Her er enkle scenarier for å bestemme hvilken du vil gå med.

Bærbar Class Library
, og skaper en cross platform applikasjon der delt kode er ikke plattformspesifikk og er ment å være delt eller gjenbrukt utenfor dagens løsning

delt Prosjekt
, og skaper en kryssplattform program med kode som kan være plattformspesifikk og bare hører hjemme i din løsning og er ikke ment å bli delt eller gjenbrukes utenfor den sammenheng

5. La oss bygge en App

Det er nok teori for nå. La oss få skrive noen kode. I de foregående to innledende opplæring på Xamarin opprettet du det samme RSS-leser. Selv om det kan ha virket overflødig på den tiden, vi gjorde det av to grunner.

vise likheter i å skape Xamarin.iOS og Xamarin.Android applikasjoner

fører opp til sammenslåing felles kode i en enkel kryssplattform program

Prosjektoppsett


for å lage denne versjonen av programmet, vil du følge de grunnleggende n + 1
retningslinje. Start med å lage en ny iOS
prosjekt ved hjelp av Tøm Prosjekt
mal, navngi prosjektet XamFeed.iOS Hotell og løsningen XamFeed
.


Deretter legger du til en ny Android
prosjektet til løsning ved hjelp av Android Application
prosjektmalen. Gi den nye prosjekt XamFeed.Android
.


Nå er det tid for 1
. Du kan velge hvilken som helst av de kodedelingsalternativene som er beskrevet i denne opplæringen for å lage dette programmet. Siden koden som kommer til å bli delt mellom iOS og Android-programmer er ikke spesifikke for noen en plattform, og kan være nyttig for andre prosjekter og programmer, vil jeg ta Bærbar Class Library
ruten. Legg til en ny C #
prosjektet til løsning ved hjelp av Bærbar Bibliotek
mal og gi den navnet XamFeed.Core
.


Hvis du bruker Visual Studio, vil du se en dialogboks som lar deg velge de støttede plattformene. Hvis du bruker Xamarin Studio, må du se nærmere på prosjektegenskaper for XamFeed.Core
prosjekt. Du kan velge nesten hvilken som helst kombinasjon av plattformer så lenge du har .NET Framework 4.5 eller nyere
, Xamarin.iOS
, og Xamarin.Android
, og gjøre Pass på å ikke velge Windows Phone 8 Hotell og Windows Phone Silverlight 8
. Grunnen til at du ikke kan velge de to plattformene er fordi de ikke støtter
Httpclient klassen som vi skal bruke i vår søknad.


Du kan slette standard klassen filen i XamFeed.Core
bibliotek, fordi vi ikke vil bli som trenger det. Til slutt, sørg for å legge til en referanse til XamFeed.Core
prosjekt både i XamFeed.iOS Hotell og XamFeed.Android
prosjekter. Du er nå klar til å legge noen kode.

Legge Delt Kode


Vi starter med å lage domenet objekt, RssItem. Denne klassen vil inneholde fire eiendommer. Du kan legge til flere hvis du vil.


1. tittel, navn på artikkelen
   
   pubDate, datoen da artikkelen ble publisert
   
   Creator, forfatteren av artikkelen
   
   Link, nettadressen til artikkelen
   

   Legg til en ny klasse til XamFeed.Core
   prosjekt kalt RssItem. Erstatte standard gjennomføring med følgende:
   public class RssItem {public String tittel {får; sett; } Public string pubDate {får; sett; } Public string Creator {får; sett; } Public string Link {får; sett; }}

   Opprett en annen klasse og name it FeedRetriever. Oppgaven til denne klassen skal hente en rekke RssItem objekter fra en gitt URL. Når du har opprettet denne klassen, legge til en ny metode til den med følgende gjennomføring:
   offentlig async Task < RssItem [] > GetItems (string feedurl) {hjelp (var klient = new Httpclient ()) {var xmlFeed = avvente client.GetStringAsync (feedurl); Var doc = XDocument.Parse (xmlFeed); XNamespace dc = "http://purl.org/dc/elements/1.1/"; Var elementer = (fra element i doc.Descendants ( "element") velge ny RssItem {Tittel = item.Element ( "title"). verdi, pubDate = item.Element ( "pubDate"). verdi, Skaperen = item.Element (dc + "skaperen") verdi, Link = item.Element ( "link") Verdi}) ToArray ()...; returnere elementer; }}

   For å få denne metoden for å kompilere inn i prosjektet, må du legge til fire ved hjelp av uttalelser til toppen av FeedRetriever
   file:
   
   med System. Linq;
   
   hjelp System.Net.Http;
   
   hjelp System.Xml.Linq;
   
   hjelp System.Threading.Tasks;
   

   du har nå en hendig liten klasse som kan brukes til å hente artikler fra en gitt RSS feed URL. Denne funksjonaliteten vil bli lagt til iOS og Android-programmer. La oss starte med Android applikasjon.
   
   XamFeed.Android
   

   Å sette RssItem objekter i en liste krever en tilpasset adapter. I XamFeed.Android prosjektet, lage en ny klasse, name it FeedAdapter, og erstatte det er gjennomføring med følgende:
   public class FeedAdapter: BaseAdapter < RssItem > {private RssItem [] _items; privat aktivitet _context; offentlig FeedAdapter (Activity sammenheng RssItem [] stk): base () {_context = sammenheng; _items = elementer; } Public override RssItem denne [int posisjon] {få {return _items [posisjon]; }} Public override int {få {return _items.Count (); }} Public override lang GetItemId (int posisjon) {return stilling; } Public override Vis GetView (int posisjon, Utsikt convertView, ViewGroup forelder) {var view = convertView; if (view == null) {view = _context.LayoutInflater.Inflate (Android.Resource.Layout.SimpleListItem2, null); } View.FindViewById < TextView > (Android.Resource.Id.Text1) .text = _items [posisjon] .Title; view.FindViewById < TextView > (Android.Resource.Id.Text2) .text = string.Format ( "{0} på {1}", _items [posisjon] .Creator, _items [posisjon] .PubDate); tilbake view; }}

   Avhengig av hvor du opprettet denne klassen, må du kanskje legge til noen eller alle av følgende ved hjelp av uttalelser til klassen. Dobbeltsjekk at de er alt inkludert
   
   med Android.Widget;.
   

2. hjelp XamFeed.Core;
   
   hjelp Android.App;
   < li> bruker Android.Views;
   
   hjelp Android.OS;
   
   hjelp System.Linq;
   

   Du har nå en mekanisme for å hente RssItem gjenstander og en adapter å vise dem. Alt du trenger er en Listview. Erstatte innholdet i Main.axml product: ( Resources > layout
   ) med følgende:?
   ≪ xml version = "1.0" encoding = "utf-8" >?; < LinearLayout xmlns: android = "http://schemas.android.com/apk/res/android" android: orientering = "vertical" android: layout_width = "fill_parent" android: layout_height = "fill_parent" > ≪ List android: id = "+ id /TutsFeedListView" android: layout_width = "fill_parent" android: layout_height = "fill_parent" /> < /LinearLayout >

   Listen layout legger en Listview til skjermen, så du kan fylle det med data. Alt som gjenstår for oss å gjøre, er kabling opp MainActivity klasse til layout, fylle listen med RssItem objekter, åpne hver av linkene når ett av elementene tappes av brukeren. For å oppnå dette, trenger du bare å endre innholdet i MainActivity.cs
   som vist nedenfor. Product: [Activity (Label = "XamFeed", MainLauncher = true, ikon = "@ teikne /ikon") ] public class FeedActivity: ListActivity {private FeedRetriever _retriever; private RssItem [] _items; beskyttet asynkron override void onCreate (Bundle bundle) {base.OnCreate (bundle); _retriever = new FeedRetriever (); _items = avvente _retriever.GetItems ( "http://blog.xamarin.com/feed"); ListAdapter = ny FeedAdapter (dette, _items); } Beskyttet ride void OnListItemClick (List l, Utsikt v, int posisjon, lang id) {base.OnListItemClick (l, v, posisjon, id); Var uri = global :: Android.Net.Uri.Parse (_items [stilling] .link); Var hensikten = ny Intent (Intent.ActionView, uri); StartActivity (intensjon); }}

   Du er nødt til å legge til en bruker statement å inkludere XamFeed.Core navnerom for å få dette til å kompilere.
   

   Det du har det. Du har nå en fullt funksjonell Android-applikasjon som benytter kjernefunksjonalitet som befinner seg i en Bærbar
   Class Library
   . Nå er det på tide å vende oppmerksomheten til XamFeed.iOS
   prosjektet.
   
   XamFeed.iOS
   

   
   grunnleggende prosessen for å få iOS-prosjektet i gang kommer til å være lik den Android-prosjektet. Vi bruker FeedRetriever klassen for å få RssItem objektene og deretter skrive tilpassede brukergrensesnitt kode for å vise det til brukeren. For å oppnå dette, vil vi lage en visning kontrolleren som inneholder en liste over RssItem gjenstander og sette denne visningen kontrolleren som roten visning kontrolleren av søknaden.
   

   Start med å legge en ny iOS Table View Controller
   til XamFeed.iOS
   prosjektet og gi den navnet RssItemView
   . Dette resulterer i etableringen av RssItemViewController, RssItemViewSource, og RssItemViewCell klasser.
   

   Disse klassene utgjør tabellvisningen som skal vise RssItem stedene. Erstatte standard gjennomføring av RssItemViewController klassen med følgende:
   public class RssItemViewController: UITableViewController {private FeedRetriever _retriever; private RssItem [] _items; offentlig RssItemViewController (): base () {_retriever = new FeedRetriever (); } Public override void DidReceiveMemoryWarning () {//utgivelser visningen hvis den ikke har en Super. base.DidReceiveMemoryWarning (); //Slipp noen bufrede data, bilder, etc som ikke er i bruk. } Public asynkron override void viewDidLoad () {base.ViewDidLoad (); _items = avvente _retriever.GetItems ( "http://blog.xamarin.com/feed"); //Registrer Tableview datakilde TableView.Source = ny RssItemViewSource (_items); TableView.ReloadData (); }}

   I viewDidLoad metoden bruker vi FeedRetriever klassen for å få RssItem gjenstander fra Xamarin blogg, tilordne dem til RssItemViewSource objekt, og kaller ReloadData metoden på Tableview eksempel. Denne metoden sikrer at tabellvisningen oppdateres etter at den er vist, slik at data vises på skjermen.
   

   Deretter oppdatere RssItemViewSource klassen til å håndtere RssItem [] at vi kjører til det. For å gjøre det, erstatte standard gjennomføring med følgende:
   public class RssItemViewSource: UITableViewSource {private RssItem [] _items; offentlig RssItemViewSource (RssItem [] varer) {_items = eks; } Public override int NumberOfSections (UITableView Tableview) {//TODO: returnere det faktiske antall seksjoner returnere en; } Public override int RowsInSection (UITableView tabellvisning, int seksjon) {//TODO: returnere det faktiske antall elementer i avsnittet retur _items.Length; } Public override UITableViewCell GetCell (UITableView Tableview, NSIndexPath indexPath) {var celle = tableView.DequeueReusableCell (RssItemViewCell.Key) som RssItemViewCell; if (celle == null) celle = new RssItemViewCell (); //TODO: fylle cellen med riktige data basert på indexPath cell.TextLabel.Text = _items [indexPath.Row] .Title; cell.DetailTextLabel.Text = string.Format ( "{0} på {1}", _items [indexPath.Row] .Creator, _items [indexPath.Row] .PubDate); returnere cellen;

   
   
   
   Previous:Lag en Plane slåssespill i Corona: Ferdigstilling Gameplay
   Next Page:En introduksjon til Xamarin: Part 2