Mobil gelişim mimarisine derinlemesine ayrıntılı ama asla kesin bir rehber

Yerli, Web, PWA, melez, Çapraz Derlenmiş… Android ve iOS platformları için geliştirmenin “en iyi” yolu nedir? Ne makul görünüyor? Ve seçenekler arasında nasıl seçim yapmalısınız? Bu yazıda, hepsini açıklayacağım, böylece bilinçli bir karar verebilirsiniz.

Öncelikle ilk önce size biraz içerik sunmama izin verin. Ben bir BT kıdemli danışmanıyım ve bu kılavuzu bir araya getirme fikri, müşterilerimizden biriyle kendileri için en iyi yaklaşımın ne olabileceği konusundaki tartışmalardan doğdu. Evet, sadece onlar için. Doğru cevabı bulmamıza yardımcı olacak sağlam ve güvenilir bir temel olan iyi tanımlanmış bir stratejimiz olmadığını fark ettik.

Ve ne biliyor musun? İnternette hiçbir yerde böyle bir rehber bulamadım. Bu konuyla ilgili birkaç makale olmasına rağmen karşılaştığım hiçbiri mantıklı tamamlanmadı. Maalesef çoğunluk birçok kavramı gözden kaçırıyor veya daha da kötüsü aslında yanlış.

Şimdi, daha yakından bakmak istiyorum. Ve potansiyel olarak birisinin kendi kararlarını vermesine yardım ederken, ben de topluluğun etrafında konuyla ilgili daha fazla düşünce soruyorum.

Bu kılavuz iki bölümden oluşmaktadır:

  1. Mobil Geliştirme Mimari Katmanları (bu)
  2. Kararınızı nasıl alırsınız?

Ayrıca YouTube'da 10 video dizisi ve Udemy'de ücretsiz kurs olarak sunulmaktadır. Burada, burada olduğu gibi yazılı materyalleri, YouTube serisinin videolarını ve tüm konuları ve son sertifikaları düzeltmek için yapılan kısa sınavları bulacaksınız.

Öyleyse başlayalım.

Giriş

Mobil platformlara gelince, sadece iki büyük oyuncu olduğu tartışılabilir: Android ve iOS. Tizen, Blackberry veya Windows Phone gibi diğer teknolojiler de ya öldü ya da bir süredir piyasada ve önemli bir pazar payına ulaşma şansı bulunmuyor.

Bu büyük duopolise hızlı bir bakış, geliştiricilerin mobil uygulamalar oluştururken çok fazla seçeneği olmadığını düşünmenize neden olabilir. Yine de bu fikir gerçeklerden daha fazla olamaz. Orada kullanılan programlama dillerini hızlıca tespit edebilirsiniz: C / C ++, Java, Kotlin, Objective-C, Swift, JavaScript, TypeScript, C #, Dart, Ruby ve birkaç tane kaçırmadığımdan eminim Daha.

Aynısı mobil geliştirme çerçeveleri için de geçerlidir. Bir geliştirici değilseniz ya da son 10 yıldır yeni teknolojilerden habersiz değilseniz, muhtemelen sadece birkaç çarpı isminde Cordova / PhoneGap, Yerli Tepki, Xamarin, İyonik, Yerli Metin veya Flutter hakkında bir şeyler duymuşsunuzdur. mobil uygulamalar için platform çözümleri.

Öyleyse mimarlığın tüm bu parçalarına bakalım ve işleri biraz parçalayalım.

TL; DR

Net bir kazanan yok. Tüm yaklaşımların avantajları ve dezavantajları vardır ve bir sonraki projeniz için en uygun veya en kötü durum olabilir. Bu rehberde, mimarlıklarının yerel platformdan uzaklığına göre birçok farklı çözümü farklı katmanlara sınıflandırıyorum.

Yerel Uygulamalar

Başlamak için, doğrudan metale gidelim. İlk mimari katmanımız Native Apps.

Yerel Uygulamalar Katmanı - Her bir platform için geliştirdiğiniz yer (NDK göz önüne alındığında daha da spesifik olabilir)

Bu, her platformun kendine has özelliklerinden haberdar olmanız gereken katmandır. Onlara kazma niyetim değil, sadece bağlamda birkaç şeyden bahsetmek istiyorum.

iOS

İOS tarafında başlamak, çünkü daha basit olduğu için, sadece dünyayı yöneten Apple var. İlk olarak, geliştiricilerin SmallTalk'tan (ve delice uzun adlandırılmış bir API'den) ilham alarak C'nin tescilli nesne yönelimli bir varyasyonu olan Objective-C'yi öğrenmeleri gerekiyordu.

2014'te Apple, öncekinden çok daha kolay olan çoklu paradigma dili Swift'i duyurdu. Objective-C miras kodu ile uğraşmak hala mümkün, ancak Swift yüksek vade seviyelerine ulaştı. Yani, iOS için doğal olarak nasıl geliştirileceğini öğrenmeyi planlıyorsanız, Swift kesinlikle başlamanız gereken yerdir.

Android

Android tarafında, birkaç farklı üretici var. Bunların büyük çoğunluğu ARM işlemcilere güveniyor. Ancak, genel olarak konuşursak, Android uygulamaları potansiyel temel özellikleri (çok şaşırtıcı numaralar olmadan) ile başa çıkmak için sanal makine örneklerine (ART örnekleri) dayanıyor.

Bu yüzden, başlangıçta, tercih edilen dil Java idi. Neredeyse yirmi yıldır dünyadaki en popüler dil değil sadece (C ile birkaç pozisyon değiş tokuşuyla) değil, aynı zamanda Java Sanal Makinesi (JVM) için de dikkat çekicidir. Bu, geliştiricilerin kodlarını JVM tarafından okunabilecek ve çalıştırılabilecek ara bayt koduna kadar derlemelerini sağlamıştır.

Android Native Development Kit (NDK) ile, uygulamanın kritik bölümlerini doğrudan yerel kodda, C / C ++ yazarak geliştirmek de mümkündür. Bu durumda, altta yatan platform tuhaflıklarının farkında olmalısınız.

Kotlin, 2011 yılında JetBrains tarafından tanıtılan bir dildir. İlk çıktığında, esnekliği ve özlülüğüne rağmen, Scala, Clojure veya Groovy gibi daha başarılı rakipleri olan başka bir JVM dilinden daha fazla değildi. Bununla birlikte, 2016'daki ilk büyük sürümünden sonra, özellikle Google, Google I / O 2017'deki Android platformunda resmi olarak destekleneceğini açıkladıktan sonra hızla kalabalıktan sıyrılmaya başladı.

Kotlin, Google’ın birinci sınıf dili haline geliyor (şu anda Kotlin ve Java - bu sırayla - Android'in resmi belgelerinde kullanılıyor). ABD Federal Temyiz Mahkemesi'nin Google’ı Java’nın telif haklarını ihlal etmekle suçladığı yönündeki davaya karar vermesi nedeniyle, Java’nın tamamen yenilenmesi beklenmektedir.

Yerel bileşenler

Bu aşamada gelişen tüm yerel API'lerden ve özellikle de yerel bileşenlerden de yararlanabilirsiniz. Bu, uygulamanızı tekerleği yeniden icat etmekten kurtarır.

Xcode (iOS) ve Android Studio'da basit bir projenin nasıl oluşturulacağı üzerine bir video demosu yayınladım. Kontrol etmek istiyorsanız:

Yerel Uygulamalar avantajları

  • En iyi performans ve en iyi kullanıcı katılımı
  • Kanama kenarı yerel özellikleri
  • Belirgin derecede iyi IDE'ler Android Studio / Xcode
  • Modern üst düzey diller Kotlin / Swift
  • NDK ile çok düşük seviye yaklaşım

Yerel Uygulamalar dezavantajları

  • Bakım için iki kod tabanı
  • Kurulum gerektir (Android Instant Apps hariç)
  • SEO analiz etmek zor
  • Kullanıcıların uygulamayı indirmelerini sağlamak çok pahalı

ağ uygulamaları

Yelpazenin diğer tarafında, Web Uygulamalarımız var. Web Uygulamaları esasen tarayıcı tarafından çalıştırılan uygulamalardır. Platformu hedefleyen bir kod yazmazsınız, bunun yerine, üzerinde çalışan herhangi bir tarayıcı yoktur.

Web Apps Tier - Android ve iOS arasında oturan bir canavarı hedef alan bir tarayıcı çubuğunun üzerinde.

Bu aşamada birbirinizin boğazına atlayan çılgın sayıda yarışmacı bulacaksınız. Fakat hepsi aynı silahlardan oluşan bir cephanelik kullanıyor: HTML, CSS ve Javascript.

Web çerçeveleri ve kütüphaneleri, LESS veya SASS gibi CSS ön derleyicilerinden yararlanırken bile, TypeScript, CoffeeScript veya Flow gibi Javascript bile derlenmiş diller, JSX veya Elm gibi simbiyozlar bile, her şeyi Javascript'e dönüştürmek için Babel gibi araçları tek başına bırakarak ECMAScript yıllık spesifikasyonlarına göre yapılandırılabilir uygunluk seviyeleri (ES6 / ES7 / ES8 veya ES2015 / ES2016 / ES2017 / ES2018 tercih ediyorsanız).

Günün sonunda, hepsi HTML, CSS ve tarayıcı tarafından oluşturulan ve çalıştırılan JavaScript'tir. Kamera, titreşim, pil durumu veya dosya sistemi gibi yerel API'lere doğrudan erişim yoktur, ancak bazılarına Web API'leri aracılığıyla ulaşılabilir:

Uygulamamı oluşturmak için Web Platformu özelliklerine güvenebilir miyim?

Web API'leri ile ilgili en büyük sorun, olgunluk seviyeleridir. Çoğu, bazı tarayıcılar tarafından desteklenmiyor. Uygulamalarda, özellikle mobil tarayıcılar arasında farklılıklar var.

Web Uygulaması avantajları

  • Platformlar ve masaüstü tarayıcılar arasında paylaşılan kod
  • Önceki kurulumlara gerek yok, sadece gezin ve kullan
  • Onlarla gitmek için çok sayıda çerçeve ve kütüphane
  • SEO için en iyisi

Web Uygulaması dezavantajları

  • Düşük performans
  • Yerel kullanıcı deneyimi elde etmek zor
  • İnternet bağlantısı gerektir
  • Resmi uygulama mağazalarında mevcut değil
  • API, yerel API kadar olgun ve güvenilir değil

Altyapılar ve Web bileşenleri

Angular, React ve Vue muhtemelen 2018'den beri en popüler web çerçeveleridir. Kesin olmak gerekirse, React esnek ve az düşünülmüş doğası nedeniyle sadece bir kütüphane olarak kabul edilir. Öte yandan, açısal, kuvvetli bir şekilde düşünülmüş bir çerçevedir. Vue, aralarında bir noktada yaşıyor.

Açısal vs Reac vs Vue

Aslen AngularJS adı verilen açısal, 2010'da Google tarafından dünyaya sunuldu. O zamandan beri diğer kütüphanelere kıyasla paradigmaların tersine çevrilmesi nedeniyle hızla parlamaya başladı (o zamanki en popüler jQuery gibi). UI durumunu değiştirmek için doğrudan HTML öğeleriyle konuşmak yerine, AngularJS ile, JavaScript modeli her güncellendiğinde şablonlar sihirli olarak güncellenmiştir.

AngularJS gittikçe daha popüler hale geldiğinde, aynı zamanda amaç olarak büyüdü. SPA'ları (Tek Sayfa Uygulamalar) ciddiye alan ilklerden biri olan eksiksiz ve düşünülmüş bir çerçeveye dönüştü. Bu büyüme (her iki yönde de) bazı API şişirmelerinden ve performans sorunlarından sorumluydu.

Tepki, kendi gereksinimlerini sunum katmanında çözmek için Facebook tarafından yaratıldı. Sanal DOM, tek yönlü veri akışı (başlangıçta Flux, özellikle de Redux adlı bir uygulama kitaplığıyla popüler) gibi çok popüler hale gelen birçok yönü ortaya çıkardı ve JSX olarak adlandırılan HTML ve JavaScript karışımı.

Yalnızca 2016'da, uzun tartışmaların ve beklenmedik büyük değişikliklerin ardından, Google popüler web çerçevesinin ikinci sürümünü başlattı. AngularJS yerine Angular adını verdiler. Ancak, birçok kişi zaten "Açısal" ilk sürümünü ("JS" son eki olmadan) çağırdığı için, insanlar Açısal 2 yeni sürümünü aramaya başladılar. 6 ay.

Bence bu bir mamut hatasıydı. Bunu daha önce gördüm (örneğin Struts vs Struts 2 / WebWork ile). Platosuna ulaştıkları çok büyük bir ürüne sahipler ve övülmekten daha çok eleştirilmeye başlandı. Google sıfırdan yeniden oluşturmaya karar verirse, hiçbir zaman, yalnızca ana sürümünü değiştirmemeleri gerekir. İnsanlar her yeni büyük sürüm sürümünde tekrarlamayacaklarına nasıl güvenecekler? İkinci versiyonun kırılma değişiklikleri göstermesi gerekiyor, ancak bunun tamamen yenilenebileceği anlamına gelmiyor.

Açısal muhteşem bir web çerçevesi ve kendimi gerçekten tutkulu hissediyorum. Ancak, tamamen yeni bir canavar. AngularJS ile ilgisi yok. Başka bir şaşırtıcı çerçeve olan Vue bile (bu arada en çok çalışmak için en keyifli olanlardan biri) bile kuş bakışı ile AngularJS'e daha çok benziyor. Bunun Açısal'dan uzakta önemli bir harekete neden olduğuna ve React'in popülerliğine büyük ölçüde katkıda bulunduğuna inanıyorum.

Vue, büyük bir şirket tarafından desteklenmeyen en popüler üç web çerçevesinden yalnızca biridir. Aslında eski bir Google geliştiricisi tarafından başlatıldı. Müthiş basitliği ve küçük ayak izi nedeniyle, büyük ve hevesli bir topluluktan dikkat çekti.

Daha eksiksiz çözümler olmasına rağmen, hepsi web bileşenleri kavramı üzerinde çalışıyor. W3C'de halen devam etmekte olanları hakkında açık bir spesifikasyon ve Polymer, Stencil ve X-Tag gibi bazı ilginç uygulamalar var.

Serinin üçüncü videosunda, çerçeveleri tartışmak için fazla zaman harcamıyorum, fakat web bileşeni kütüphanelerini tartışıyorum:

Mobil Uygulamalar vs Web Uygulamaları

Farkında mısın, emin değilim ama burada sunduğum sıraların sırası, tüm yaklaşımları öğrenmenin en kolay yolu olduğunu düşündüğüm şeyi izler. En gerçek mobil gelişim olan Native Tier'den başladım. Daha sonra, ilk akıllı telefonlardan beri mevcut olan Web Seviyesini sunmak için doğrudan diğer uç uca uçmaya karar verdim.

Ancak şimdi, diyagramımın iki kenarı arasındaki bir karşılaştırmayı yaptıktan sonra, mobil uygulamalar oluşturmak için platformlar arası yaklaşımların çoğundan bahsetmeye başlayacağım.

Mobile Apps vs Web Apps arasında uzun bir tartışma var. Mobil Uygulamalar hakkında söylediğim her şey Yerel Seviyeye özel değil. Ayrıca daha sonra sunduğum tüm platformlar arası katmanlar için de geçerlidir.

Kullanıcı davranışı ikilemi

Kullanıcılar Mobil Uygulamalarda (% 87) Mobil Web Sitelerinde (% 13) daha fazla zaman harcıyor

2017 yılında yapılan bir Comscore anketine göre, bir kullanıcının bir mobil uygulamaya olan sadakati, mobil web sitelerine göre çok daha önemlidir. Forbes ile ilgili bir hizalanmış makaleye göre, bu genellikle kolaylık (örneğin, ana ekran düğmeleri, widget'lar, üst bildirimler), hız (örneğin, daha yumuşak arayüzler, neredeyse anında başlatmalar) ve saklanan ayarlardan (örneğin çevrimdışı) kaynaklanmaktadır. içeriği).

Mobil Web Siteleri daha fazla insana ulaşıyor (3,3 milyon Mobil Uygulamaya karşı aylık 8,9 milyon benzersiz ziyaretçi)

Öte yandan, aynı Comscore verilerinde, birkaç tercih uygulamasına bağlı olmadıklarından, müşterilerin mobil web sitelerinden daha kolay ulaşılabileceğini öğreniyoruz. En popüler web sitelerini en çok indirilen uygulamalar ile karşılaştırırsanız, ayda ortalama 8,9 milyon tekil web ziyaretçisinin ilk 1000 web sitesine eriştiği tahmin edilmektedir. Bu, en çok indirilen 1000 uygulamanın benzersiz benzersiz kullanıcılarının neredeyse üç katıdır.

Dağıtım (Web Uygulaması) x Katılım (Mobil Uygulama)

Hepsi dağıtım vs angajmanla ilgili. Kullanıcıların mobil tarayıcılarında gezinirken yeni şeyler denemeleri daha muhtemel olduğundan web uygulamanıza erişme şansı daha yüksektir. Ancak Mobile Apps'ın daha ilgi çekici olduğu ve kullanıcıların daha uzun süre dikkatini çektiği kanıtlandı.

Şimdi ikilemi anladınız, İlerici Web Uygulamalarına bir göz atalım. Bu, Web Apps katmanına o kadar bağlı bir yaklaşım ki, onu Web Apps için bir zeyilname olarak sınıflandırdım. Ancak, web ve mobil geliştirmede en öne çıkan yeni ve havalı şey için büyük bir yıkıcı ve ciddi bir aday.

Progressive Web Uygulamaları

Progressive Web Uygulamaları (PWA'lar), Web Uygulaması kullanıcılarına Mobil Uygulamaları çalıştırırken alıştıkları deneyimi sunmak için kullanılan bir dizi araç. Bu, Web Uygulamalarının daha iyi etkileşim düzeyleri ile potansiyel olarak daha yüksek dağıtım seviyelerinden yararlanabileceği anlamına gelir.

Web Apps katmanına aşamalı Web Uygulamaları eki

Google, PWA'lar için üç ana nitelik tanımlamıştır: Güvenilir, Hızlı ve Etkileyici olmaları gerekir.

Servis Çalışanları ve Uygulama Kabuğu adı verilen özellikler, Progressive Web Apps'ın temelini oluşturur. Cihazın bağlantı durumundan bağımsız olarak çalışmak üzere tasarlandıkları için uygulamaların güvenilirliğini artırmak için yaratıldılar. Bu, çevrimdışı modun yanı sıra zayıf bağlantılar içerir. Ayrıca, yerel olarak önbelleğe alınmış verileri kullanarak başlatılan ve senkronize içerik indirme işlemlerinde gecikmeleri ortadan kaldıran uygulamalar olarak algılanan önemli bir performans artışı sağlar.

Güvenilirliği dolaylı bir bağlılık vektörü olarak düşünebilirsiniz. Örneğin, trenle giderken kullanıcılar etkilenmez. Nişanlı kalabilirler.

Aynısı hız için de geçerlidir. Google’a göre:

Yüklemek 3 saniyeden uzun sürerse, kullanıcıların% 53'ü siteyi terk edecek!

Bununla birlikte, yalnızca güvenilir ve hızlı yükte olmak, mutlaka yüksek katılım garantisi vermez. PWA'lar, “Ana Ekrana Ekle” seçeneği ve Push Bildirimleri gibi, mobil uygulamalara özel olan mobil ile ilgili özelliklerden yararlanır.

“Ana Ekrana Ekle” özelliğine gelince, Apple'ın ilk iPhone'dan bu yana benzer bir özelliği olduğunu fark edebilirsiniz. Hatta bazı insanlar Progressive Web Apps’in Google’ın orijinal bir Apple fikri için yeni ve süslü bir isim olduğunu iddia ediyorlar.

Ve gerçekten tamamen aynı fikirde olamazsın. Bazı fikirler aslında bisiklete biniyor. Gelirler, giderler, ve sonra yeni bir isim ve bazı donanımlar (örneğin, Servis İşçileri) ile geri dönerler, böylece sonunda sadık kalabilirler.

Öte yandan, tamamen aynı fikirde olmak zor. Steve Jobs’un Web 2.0 + AJAX ve iPhone’un WWDC 2007’deki unutulmaz anonsları ile ilgili konuşması, onu PWA’ların babası, hatta peygamberi olarak çağırmak için yeterince ikna edici değil.

Adil olmak gerekirse, iPhone'daki Ana Ekrana Ekleme özelliği, Web Uygulamalarını tam ekran modunda başlatan masaüstü simgeleri oluşturmak için ince, neredeyse gizli bir özellikten başka bir şey değildi. Tüm HTTP istek yanıt döngüleri yüküne sahiptir ve önbelleklerin etrafında açık bir yol yoktur.

PWA'lar doğru noktadan başlar. Mobile Apps'ın istemci önyüklemesini kaybetmeden önceki Web Apps kurulumlarının nasıl gerekli olmadığını araştırıyorlar. Bu, bir kullanıcının başlangıçtan sonraki ilk etkileşimi için ihtiyaç duyduğu her şeyin yerel olarak önbelleğe alınabileceği (okuma: Uygulama Kabuğu) olabileceği ve “Ana Ekrana Ekle” düğmesine tıkladığında kullanılabilir durumda kalabileceği anlamına gelir.

PWA'ların iyi bilinen bir başka özelliğine ilerleyerek, Mobil Uygulamalar dünyasının süper ilgi çekici (veya yeniden ilgi çekici) özelliği hakkında konuşalım: Push Bildirimler. Kilit ekranlarının yanı sıra üst bildirim çubuğunda / alanda görünen alarm tarzı mesajlardır. Bildirimi aldıktan sonra kullanıcıları uygulamanıza geri çekme gücüne sahipler.

Google, PWA'ların çekiciliğini güçlendirmek için tüm modern Web API'lerini PWA şemsiyesi altına çekmektedir. Öyleyse, Progressive Web Apps bağlamında Ödeme İstekleri, Kimlik Bilgileri Yönetimi, WebVR, Sensörler, Web Bağlantısı ve WebRTC gibi şeyler görmeyi bekleyin. Ancak bu özellik mutlaka PWA'lara bağlı değildir ve bazıları PWA teriminden önce doğmuşlardır.

PWA ve Elma

Öte yandan Apple, yalnızca Mart 2018’de PWA’lara karşı ilk temel kilometre taşlarını açıkladı. Hala bazı sınırlamalar olsa da, ilerleme kayda değer. Sınırlamaların bazıları, Safari'nin rakiplerinin gerisinde kaldığı gerçeğiyle ilgili olabilir. Diğerleri Apple'ın sıkı kontrol felsefesine bağlanabilir.

Yine de, Apple’ın Google’dan daha karlı bir App Store’u var. Apple, uygulama yayınlarında daha fazla kriterin daha genel bir güvenilirlik sağladığını ve PWA'ların App Store'un gelirine zarar vermek zorunda olduğunu iddia ediyor. Bu, kasıtlı olarak uygulanmış gibi görünen bazı sınırlamaların (50Mb PWA maksimum önbellek boyutu gibi) iptal edilmesinin daha pahalı olacağını göstermektedir.

Ne yazık ki PWA'lar mükemmel değil

Web çözümleri ve farklı düzeylerde, tüm platformlar arası çözümler, Yerel Uygulamaların mükemmelliğini ve anlaşılırlığını elde etmek için mücadele eder. Her yeni özellik ve Android ya da iOS'a özgü her ayrıntı, uygulamanızı yerel katmandan uzak tuttuğunuzda, bu yerelin daha fazla ve daha zor hissetmesini sağlar.

Genel olarak, PWA'lar Web Uygulamaları katmanındaki bazı sorunları düzeltir. Ancak, bir tarayıcıda çalışan bir çözümle çözülemeyen başka sorunlar var.

PWA'lar düzeltildi

  • Daha fazla “yerli” deneyim
  • Daha hızlı yükleme süreleri
  • İnternet bağlantısı gerektirmez
  • Web geliştiricilerini, bağlantının olmadığı ve bağlantıların kötü olduğu durumların farkında olmaya zorlayın
  • Push Bildirimleri, Coğrafi Konum veya Konuşma Tanıma gibi Mobil Uygulamaların özelliklerini birleştirin

Ne yapmıyorlar?

  • İçsel yavaşlık
  • Uygulama mağazalarında mevcut değil (henüz değil)
  • Hala tüm tarayıcılar tarafından tam olarak desteklenmiyor
  • Hala NFC, Ambient Light, Geofencing gibi mobil özelliklerden yoksun
  • Ayrıca PiP, akıllı uygulama pankartları, açılış ekranı widget'ları ve 3D dokunuş gibi Android veya iOS'un özelliklerine destek eksikliği

Aşağıdaki videoda PWA'lara kısa bir genel bakış yapıyorum.

Hibrit Uygulamalar

Bu seviyede, Mobil Uygulama dünyasına dalmaya başlıyoruz. En uzak seviyeden başlayacağız: Hybrid Apps.

Hibrit terimi aynı zamanda tüm çapraz platform çözümlerine de uygulanır. Ancak, burada, WebViews adı verilen mobil bileşenlerin içinde çalışan Uygulamalar ile kısıtlıyorum.

Hibrit Uygulamalar katmanı. Tarayıcı çizgisinin altında, ancak WebView'lerin üstünde

İkinci videodaki demolarda, WebView’i Hello World örneği olarak ekleme amacım, her bir platform için gerçek bir tarayıcı gibi çalışabilen yerel bir bileşen olduğunu açıkça ortaya koymaktı.

Cordova / PhoneGap

Cordova / PhoneGap gibi çözümler, Web ve Mobil Uygulamalar arasındaki boşluğu kapattı. Geliştiricinin HTML, JavaScript ve CSS kodlarını (ayrıca resimler veya videolar gibi ekstra varlıklar) paketlemek için araçlar sağlar ve bunları Mobil Uygulamalara (evet, gerçek Android veya iOS uygulamaları) dönüştürür. Bu uygulamalar, yalnızca ana web kodunu yorumlamak ve çalıştırmak için, yalnızca uygulamanın ana klasöründeki (normalde “www” olarak adlandırılan) “index.html” dosyasıyla başlayan Web Görünümlerine sahiptir. Ayrıca JavaScript kodunu, kısmen JavaScript'te ve kısmen de bir anadilde uygulanan eklentiler aracılığıyla yerel API'lere köprüler.

Öyleyse işleri daha netleştirelim. Hibrit Uygulamalar yerel API'lere (Web API'leri yerine) erişebilir, ancak WebView tarafından eklenirler. Cordova'ya sahip bir düğme, mobil yerel düğme yerine WebView tarafından oluşturulan bir HTML düğmesi olmalıdır.

Bu, şirketlerin Web Uygulamalarını, uygulama mağazaları tarafından sevk edilmek üzere Mobil Uygulamalara aktarmalarını sağlayan sihirli bir katmandır. Yani burada herhangi bir web çerçevesine izin verilir.

İyonik

Ionic gibi yapılar Cordova'yı kendi çözümlerine sararlar. Ionic ile, Cordova’nın komut satırı arayüzünü (CLI) kullanmanıza gerek yoktur, çünkü tüm komutları İyonik CLI tarafından alınır.

Son zamanlarda, İyonik ekip tüm Hybrid Apps yığınının dizginlerini almaya karar verdi. Böylece Cordova için Capacitor adında önerilen bir yedek başlattılar. Kondansatör, Cordova eklentileri için desteğe sahiptir ve İyonik olmayan bir proje tarafından da kullanılabilir.

Serinin beşinci videosunda Cordova Hello World örneğinden geçerken beni izleyebilirsin:

Hybrid Apps avantajları

  • Bunlar aslında resmi uygulama mağazalarına gönderilebilen web uygulamalarıdır.
  • Herhangi bir JavaScript çerçevesi / kütüphanesi ile birlikte kullanılabilir
  • Kod platformlar arasında hala yüksek oranda paylaşılabilir
  • Yerel özelliklere erişim (örneğin, kamera, ivmeölçer, kişi listesi)

Hibrit Apps dezavantajları

  • Web görünümleri her şeyi ekranda göstermekten sorumlu olduğundan performans sorunları ve bellek tüketimi ile mücadele edin
  • Tüm yerel UI bileşenlerini tek bir web görünümünün üstüne taklit etmek zorundasınız
  • Kabul Edilmesi ve App Store'da yayınlanması zor
  • Bu ortamlar için yerel özelliklerin mevcut olması genellikle daha uzun sürer

Yerli Web

Web Yerlisi, nispeten yeni ve genellikle yanlış anlaşılan bir seviyedir. Web Uygulamalarının yerel bileşenlerle buluştuğu yer. Appcelerator (Axway) Titanium uzun süredir bulunsa da, bunu tamamen ayrı bir mobil uygulamalar kategorisi haline getirmeyi haklı kılan bazı nispeten yeni rakipler var.

Web Yerel Uygulamalarının doğrudan diğer yerel bileşenlerle konuştukları için WebView'a ihtiyacı yoktur

Yukarıda gördüğünüz gibi, uygulamanızı oluşturmak ve çalıştırmak için web görünümü yoktur. Peki, JavaScript'iniz nasıl yürütülür? Derlendi mi? Peki, eğer aktarımı (bir dilden diğerine derleme - örneğin, TypeScript - JavaScript), donatılacak, küçükleme, yönetme ve karışıklık gibi bir derleme olarak düşünürseniz, evet JavaScript derlenir.

Ancak sorun şu ki, JavaScript'inizi Android veya iOS işletim sistemleri tarafından doğrudan anlaşılan bir şey yapmaz. Ve teoride, HTML mizanpaj motorunun kabarması olmadan sadece bir JavaScript motoru olarak kullanılan hiçbir yerel bileşen yoktur.

Strateji, kodları ile birlikte JavaScript motorlarını (normalde Android için V8 ve iOS için JavaScriptCore) göndermektir. Küçük ayak izleri olmasına ve çok hızlı olmalarına rağmen, uygulamanızın sağlaması gereken harici bir şeydir.

Öte yandan, bu yaklaşım daha iyi bir UI performansına sahip olma eğilimindedir, çünkü tüm bileşenler Native Apps tarafından kullanılanlarla aynıdır (veya örneğin React Native için aynı şeyi temel alır).

Web Yerel Uygulamaları avantajları

  • Her iki platforma tek bir kod tabanıyla ulaşın
  • Yerel uygulamalarla kabaca aynı performans, aynı zamanda yerel kullanıcı arayüzü bileşenleriyle de ilgileniyor
  • Tweaks gereklidir, ancak kod web geliştirme ile hala paylaşılabilir

Web Yerel Uygulamaları dezavantajları

  • Tek bir kod tabanı ile bile, geliştirici yerel bileşenlerin farkında olmalı
  • Web geliştiricileri için, özellikle mizanpaj söz konusu olduğunda, Hibrit / Web Uygulamalarından daha güçlü bir öğrenme eğrisi

Yerli tepki

Serinin 6. bölümünde React Native'de hızlı bir Merhaba Dünyası yapıyorum. Bu, Android Studio'nun Düzen Denetçisi'nde emülatörde hangi bileşenlerin oluşturulduğunu gösterir. Önceki örneklerle karşılaştırıyorum, hiçbir WebView olmamasını sağlayarak.

Nativescript

Son iki yılda özellikle ilgilendiğim bir başka şaşırtıcı çerçeve (Udemy hakkında - Portekizce hakkında bir kursum var), Nativescript. Bu, React Native ile benzerdir ancak React dünyasına bağlı değildir (resmi olmayan bir entegrasyon vardır, yine de Nativescript-Preact).

Nativescript ile vanilya JavaScript, TypeScript, Angular ve daha yakın zamanda Vue kullanarak geliştirebilirsiniz. Elbette başka çerçeveleri de kullanabilirsiniz, ancak bunlar resmi olarak desteklenenlerdir. Bu arada, oldukça iyi belgelenmiştir.

Nativescript, Nativescript Sidekick ve Nativescript Playground gibi araçların yanı sıra, topluluk tarafından sağlanabilecek şablonlara dayalı proje yapılarına sahiptir. Bu, bir Mac kullanarak geliştirmediğiniz zamanlarda bile bulut ve iPhone aygıtlarındaki simülatörleri başlatma, dağıtma, test etme ve çalıştırma yeteneği veren, proje oluşturma konusunda size yardımcı olacaktır.

Serinin yedinci bölümünde, Sidekick kullanarak CLI'dan başlatılan başka bir projeyle ve öğrenme amacıyla oluşturduğum bir WhatsApp klon şablonunu kullanarak bir Merhaba Dünya yapıyorum.

Uygulamanız bir Android emülatöründe çalışırken Düzen Denetçisine bir göz atmak önemlidir. Nativescript ile, yerel bileşenleri (yine, WebView yok) ve TextView gibi yaygın Android sınıflarının örneklerini gösterir. Bu, yerel bileşenleri sarmak için kendi sınıflarına sahip olan React Native'den farklıdır.

Muhtemelen Nativescript, iOS ve Android'de yeni bir özellik olduğunda ve bunu bir Nativescript projesinde ne zaman kullanabileceğiniz arasında hiçbir gecikme olmadığını iddia etmesinin nedeni budur. Örneğin, bloglarına, aynı gün iOS 11’in yeni ARKit API’sı ile resmen serbest bırakıldığı bir AR projesi yayınladılar.

weex

Bu kategoride bahsetmeye değer başka bir çerçeve Weex. Alibaba tarafından geliştirilen bir proje ve şu anda Apache Sofware Foundation'da (ASF) kuluçkaya yatırılıyor. Yerli bileşenleri çağırmak için