Java >> Java tutorial >  >> Tag >> native

6 grunde til native Android-udvikling

native

2016 var endnu en gang et succesrigt år for mobilmarkedet. Operativsystemerne Android og iOS når tilsammen en markedsdækning på 99,3 %.

Det lyder lovende at udvikle apps på tværs af platforme og dele visse komponenter mellem dem for at reducere kodeduplikering. Baseret på erfaringerne med Xamarin.Android-platformen viser dette indlæg et par grunde til, hvorfor dette måske alligevel ikke er så god en idé.

Om Xamarin.Android

Konceptet med Xamarin.Android-platformen er lovende ved første øjekast. Kombinationen af ​​et fantastisk sprog som C# med en cross-platform administreret runtime (Mono) skulle gøre det muligt for udviklerne at fokusere mere på at producere nye funktioner i stedet for
at vedligeholde kode til Android og iOS separat.

Det faktum, at C# leverer funktioner på sprogniveau for nogle Java- og Android-specialiteter (dvs. manifestgenerering ved hjælp af annoteringer, implicitte casts via generiske metoder, baggrundstråde via async-nøgleordet) og deling af kode ved hjælp af Mono-runtime ser ud til at gøre mobiludvikling mere effektiv for udviklere.

Jeg tror, ​​at denne tilgang har nogle ulemper, som fik mig til at opgive Xamarin.Android og fortsætte med ren Android-udvikling. Selvom titlen siger "native development", er dette indlæg ikke et skænderi mod hybridudvikling, men en bøn om vanilla Android, som blev så meget nemmere end for et par år siden.

Årsag #1:Det enorme økosystem af indfødte biblioteker

Siden starten af ​​Android er antallet af biblioteker, som er udviklet til eller forbedret til at understøtte Android, vokset. Kun en lille del af det bliver overført til C# og tilgængelig som NuGet-pakker til Xamarin-platformen.

Årsag #2:Den direkte leverandørsupport fra Google

Fællesskabet og leverandørsupporten omkring Android er langt mere omfattende end for Xamarin.Android. Bugs kan oprettes og diskuteres ved hjælp af Android-fejlsporingen (https://source.android.com/source/life-of-a-bug.html).
De nyeste Android SDK-versioner er tilgængelige, så snart Google frigiver dem, er der ingen grund til at vente på, at nogen porterer dem, som det er tilfældet med Xamarin.Android.

Den velkendte diskussion om, hvem der er ansvarlig for fejlen, er mellem Android-projektet og udvikleren, der er ingen tredjepart som Xamarin involveret.

Årsag #3:Stackoverflow AKA udviklerkærlighed

Stackoverflow er *kilden til problemløsninger inden for IT. I øjeblikket (pr. 27.12.2016) er der 931.615 spørgsmål tagget med Android og kun 18.590 tagget med Xamarin.

Årsag #4:Android Studio

Siden Google droppede Eclipse, skiftede til IntelliJ-platformen og tilbyder Android Studio, er IDE blevet meget bedre. Selvom jeg bruger IntelliJ IDEA, og der er Android-plugin'et tilgængeligt, bruger jeg stadig Android Studio separat, fordi det er en så god tilpasning af Android-udviklerens brug.

Mine yndlingsfunktioner er:

  • den utroligt fantastiske layoutdesigner
  • den omfattende mængde af fnugregler for kode- og layoutoptimering
  • Instant Run

Årsag #5:Værktøjer

Værktøjerne, der følger med Android SDK, er meget godt integreret i Android Studio. Derudover bruger Android det ensartede, gennemsigtigt beskrevne, udvidelige byggesystem Gradle, som også kan bruge de omfattende Maven-depoter som kilde til tredjepartsbiblioteker. Produktiviteten som udvikler er meget god, fordi alt passer fint ind og fungerer godt sammen.

Derudover er Android Studio tilgængelig til Windows og macOS. Indtil nu skal du til Xamarin.Android bruge Xamarin Studio til macOS og Visual Studio til Windows. Men dette kan ændre sig i den nærmeste fremtid:https://www.visualstudio.com/vs/visual-studio-mac/

Årsag #6:Starttid og størrelse på apps

Apps udviklet med Xamarin.Android bruger Mono runtime til at udføre koden skrevet i C#. Denne runtime skal startes hver gang appen starter i modsætning til JVM i Android, som altid kører. Dette resulterer i øgede implementeringstider, mens det udvikler sig i forhold til Android Studios Instant Run.

Mono runtime og dele af Mono.Android skal integreres i appen, hvilket fører til en større applikationsstørrelse.

Konklusion

Et par af disse grunde er selvfølgelig personlig smag, men jeg tror, ​​at native app-udvikling er mere omkostningseffektiv, end man almindeligvis tror. Hvilken erfaring har du med Xamarin og Android? Del dine tanker og efterlad en kommentar!


Java tag