HTML5, yerli ve karma mobil uygulama yaklaşımlarının artıları ve eksileri nelerdir?


25

Bir mobil uygulama geliştirmek istiyorum. Kısa süre önce , üç mobil uygulama türünü karşılaştıran Telerik Forum'da bir makale okudum ve hangisini seçmem gerektiğini bilmiyorum. Farklı mobil tasarım seçeneklerinin artılarını ve eksilerini tanımlayan bir resim

Telerik mobil tasarım şeması

Bu tasarım seçenekleri arasında karar vermek için, şemada listelenen her mimari seçimin artılarını ve eksilerini daha iyi anlamak istiyorum. Her mimari yaklaşımın artıları ve eksileri nelerdir?


5
Bu sorunun bu prototipten kaynaklandığı görülüyor . Asıl soru, yalnızca biri örnek olan 88 cevap aldı. Yazarın orijinal soruya gösterdiği çabayı takdir ediyorum, ancak tarih bu tür sorulara olumlu bakmadı ve bu soruyu buna göre kapatmak için oy kullandım.
Robert Harvey,

1
@just_name Hangisinin daha iyi olduğunu sorarken, her bir mimari yaklaşım için bir artılar ve eksiler listesi istemek için sorunuzu gözden geçirdim. Sonra sorunuzu yeniden açtım. Umarım şimdi daha iyi cevaplar alırsınız.
maple_shaft

İfadelere dayanarak, yaşlanmayan bazı genel prensiplerin (örneğin batarya ömrü, bağlı / bağlantısız vb.) Bir tartışma görmesini bekledim. Bunun yerine yerel olana karşı başka bir HTML5 var.
Den

Sen bulabilirsiniz Bu makaleyi LinkedIn'in karar verme süreci ilginç hakkında.
Brian

Yanıtlar:


23

Bu sorunu göz önünde bulundurarak çok zaman harcayan bir mobil geliştiriciyim.

Neden soruyorsun?

Büyük olasılıkla, uygulama geliştirme maliyetlerini şu şekilde azaltmayı umuyorsunuz:

  • Mevcut HTML5 / Javascript geliştirme becerilerini kullanma
  • Sıfırdan birden fazla uygulama yazmadan birden fazla platformu hedefleme
  • Gelecekte birden fazla kod tabanı tutmak zorunda değilsiniz

Sebepler ayrıca şunları içerebilir:

  • HTML5 / Javascript geliştirme, yerel platform geliştirmeden daha "kolay" olarak algılandı
  • Geliştirici programı kayıt ücretlerinin ödenmemesi
  • Uygulama mağazası içerik kısıtlamalarından kaçınma (kumar vb.)
  • Geliştirme donanımının satın alınmasından kaçınılması (örneğin, iPhone geliştirme için Mac)

Tanımlar

Sözü geçen üç yaklaşımdan her biri ile tam olarak ne demek istediğimizi belirleyelim:

Yerel
Bir cihaza yüklü bir uygulama, genellikle kendi uygulama mağazasından (bazen yan yana yüklenebilir). Bu tartışmanın amaçları doğrultusunda, yerel bir uygulamanın kullanıcı arayüzü genellikle tam ekran web görünümünden ibaret değildir.

Mobil web
Bu aslında herhangi bir web sayfası olabilir, ancak bu tartışma için yerel bir uygulamanın görünümünü ve izlenimini taklit etmeye çalışan tek sayfalık bir web uygulaması düşünelim. Yerel bir uygulama değil, cihazın tarayıcısında çalışıyor.

Hibrit
Hibrit uygulaması instanceofyerel uygulaması.

Çoğu kişi muhtemelen hibrit bir uygulamayı tek sayfalık bir mobil web uygulaması olarak anlar (yine de büyük olasılıkla yerel bir uygulamanın görünümünü taklit eder), ancak yerel hizmetlere erişimi olan yerel bir uygulama olarak paketlenir (à la Phonegap).

Ancak, Phonegap modeli ile daha sonra geleceğim tamamen doğal olan bir spektrum var.

Mobil web

Teknik kısıtlamalar
Öncelikle, yaptığınız işe bağlı olarak kendi başlarına anlaşma yaratabilecek mobil web uygulamalarındaki bazı teknik kısıtlamaları listeleyelim:

  • Yalnızca HTML / tuval kullanıcı arayüzü
  • Bazı cihaz etkinliklerine ve servislerine erişim yok (bunlar yaygın olarak belgelenmiştir)
  • Uygulama mağazalarında listelenemez (keşfedilebilirliği etkiler)
  • Tam ekran olabilir ve iOS'ta ana ekran simgesine sahip olabilir, ancak bu çoğu kullanıcı için alışılmadık ve alışılmadık bir deneyimdir

Yukarıdakilerin hepsiyle yaşayabiliyorsanız, tek sayfalık yerel stil web uygulamalarının zorlukları hakkında daha fazla bilgi için okumaya devam edin. Ancak bu bölüm, FT uygulamasına atıfta bulunmadan tamamlanmış sayılmaz.

Financial Times FT web uygulaması uygulamanın bu tarz ünlü bir örneğidir. İşte İngiltere Guardian gazetesinden bu konuda ilginç bir özellik.

Kesinlikle dikkat çekici bir mühendislik harikası. Şu anda yalnızca yalnızca iOS'ta kullanılabildiğini unutmayın; bu durum , gelişmiş tarayıcılar arası geliştirmenin zorluklarının çözülmesinin gerçekten çok zor olduğunu bulduklarını söylüyor.

Tek sayfalık yerel stil web uygulamaları

Bu bölüm hem mobil web hem de Phonegap tarzı uygulamalar için geçerlidir.

Bir web uygulaması içindeki yerel görünüm ve his genellikle , kullanmanız için bir UI bileşenleri paketi sağlayan Sencha Touch gibi bir çerçeveyle elde edilir .

Bu çerçeveler çok basit UI'ler için iyidir. Ancak esneklikten yoksundurlar. Sencha kullanarak herhangi bir yerel uygulama tasarımını uygulayamazsınız, tasarımınızı çerçevenin taşıyabileceği şeye uyarlamanız gerekir.

Bu çerçevelerin çektiği temel yol, platformun kendi kullanıcı arayüzü karmaşıklıklarını taklit etmeye çalışmaktır. İPhone'daki bir listenin sonuna kaydırdığınızda elde ettiğiniz o küçük güzel sıçrama efekti? Çerçevenizin Javascript'te öykünmesi gerekiyor. Tamamen yeniden oluşturmak imkansız, yavaşlamaya eğilimli olacak ve kullanıcılarınız yerli gibi görünen ama açıkça görünmeyen ve teknik olmayan bir uygulamanın "tekinsiz vadisinde" kalacak. kullanıcı parmaklarını tam olarak neden kullanamayacak.

"HTML5 / Javascript kolaydır" efsanesi

Web tarayıcılarında cihaz parçalanması zordur ve en temel HTML ve CSS'yi aştığınızda işlerin beklediğiniz gibi çalışmadığını fark edersiniz. Kendinizi yerel UI sorunlarını çözmek için, iki kez doğal yolla kaydettiğinizden daha fazla zaman harcayarak bulabilirsiniz. Yerelleşiyorsanız, yerel uygulama web görünümlerinin cihaz tarayıcıları ile aynı olmadığını ve kendi parçalanma sorunları olduğunu unutmayın.

Uygulamanız daha işlevsel bir şekilde karmaşıklaştıkça, Javascript'inizi temiz ve bakımlı tutmak için temel jquery becerilerinden daha fazlasına ihtiyacınız olduğunu göreceksiniz.

Bununla birlikte, bu yaklaşımla oldukça hızlı bir şekilde basit, işlevsel uygulamalar oluşturmak son derece mümkün. Ancak bir uygulama bunu yaparken oldukça açık.

Spektrum boyunca daha ileri

Bu yüzden, Phonegap tarzı uygulamaların baştan sona kesinlikle her şeyi yazmadan sunabileceğinden daha iyi bir UX istiyoruz. Ne yapabiliriz?

UI olmayan kodu paylaş

Birden fazla yerel platformda iş mantığını paylaşmak için kullanılabilecek çeşitli teknikler vardır. Google, Java'yı Objective-C'ye çeviren J2ObjC'yi başlattı . Dikkatli bir şekilde faktoring işlemi yaparak, Android ve iOS'ta bir Java kütüphanesi kullanılabilir.

Calatrava ve Kirin gibi kütüphaneler , Javascript'te (ve dolayısıyla Javascript'te derlenebilecek herhangi bir şeyin) yerel kodlardan manipüle edilmesine izin verir. Feragatname: Kirin'i yaratan Gelecek Platformları için çalışıyorum; iOS'ta Javascript ile GWT ile oluşturulan Javascript ile birlikte kullanmakta büyük başarı elde ettik, Java kodu Android'de doğal olarak çalıştırılıyor.

Web görünümlerini kullanın ... uygunsa

Tam ekran web görünümleri, ekran geçişlerini ve sıçrama efektlerini taklit edebilmek için yapılacak çok iş var. Ancak yerel uygulama kromu içindeki bir web görünümü yerelden ayırt edilemez olabilir.

Yerel uygulamalar ve web görünümlerinin iletişim kurması için standart ve iyi belgelenmiş yöntemler vardır.

Listeler ve tablolar, bu şekilde yapıldığında özellikle iyi çalışabilir, ancak metin girişi, yerel olarak en iyi işlenen şeylerin bir örneğidir (klavye üzerinde tam kontrol için).

Özetle

Sizin için doğru olan yaklaşım uygulamanızın ne kadar karmaşık olduğuna ve hangi düzeyde UI cila uygulamasından memnun kalacağınıza bağlıdır.

Sloganım: Web görünümlerini mümkün olan her yerde kullanın, ancak kullanıcılarınızın söyleyemediğinden emin olun .


2
Mükemmel cevap! İyi ki J2ObjC hakkında konuştun, bunun farkında değildim.
momo

4

İlk önce neler olduğunu bilmek için bu anketi inceleyin !

üç tür arasında karşılaştırma: Mobil Uygulama Geliştirme Seçeneklerinizi Anlama

Yerli ve hyprid arasındaki karşılaştırmalar:

HTML5 ve Yerli

HTML5 vs Yerel Uygulama: Hangisini seçmeli?

Bu gerçekten iyi: HTML5 v yerel uygulamalar: mobil stratejiniz için önemli noktalar

Yorumlar:

  • Onlardan birine gidebilirsiniz neye sahip olduğunuza (becerilere) ve ne alabileceğinize (bak ve hisset, performans, işlevsellik, ...) bağlıdır.
  • Her mobil uygulama geliştiricisi, ilk sürümler ve gelecek olanlar için geliştirdiği uygulama hakkında net bir vizyon / gereksinim duymalıdır! Sadece kullanacağı seçeneğin bir noktada onu sınırlamayacağından emin olmak için.
  • Üç yolla gerçek bir deneyime sahip olmak ve aynı zamanda güncel olmak gibi bir şey yoktur, bu size doğru karar alma duygusunu ve yeteneğini verecektir.

2

Telefon donanımına erişmeniz gerekiyorsa, yerel bir uygulama oluşturmalısınız (HTML5'te cihazın GPS gibi bazı donanım bileşenlerine erişebilirsiniz).

Web geliştirme konusunda daha rahatsanız, yerel bir uygulama yapmanız gerekmiyorsa, buna bağlı kalmalısınız.

Bilmeniz gerekenler kadarıyla farklı ekran boyutlarını (dikey ve yatay yönlendirme dahil) aklınızda tutmanız gerektiğini söyleyebilirim. OS işletim sisteminin çeşitli sürümlerini (bu android için daha fazla olduğunu) aklınızda tutmalısınız. Bunlar mobil cihazlar olduğu için, kullanıcının bir telefonu arayarak telefona cevap verme şansı vardır ve ayrıca bir masaüstünün veya sunucunun bilgi işlem gücüne sahip değildir.


2

Herhangi bir tüketici uygulamasını yazarken, benim için başarısının en önemli özelliği, kullanıcının kabulü ve uygulamanın algılanması. Bu yüzden, yerel uygulamaların lehine yaslanmanın dört nedeni vardır, WORA'nın öğrenmesi, eğitimi ve kaybedilmesi ile ilgili ek masraflara rağmen (herhangi bir yerde çalıştırılan bir kez yaz):

  1. Daha hızlı uygulama başlangıcı
  2. Daha yumuşak kaydırma
  3. Diğer işletim sistemi ve uygulamalarla daha tutarlı bir şekilde uyum sağlayan daha tutarlı uygulama kullanıcı arayüzü
  4. Daha hızlı uygulama kullanıcı arayüzü yanıtı

Her şeyden önce istediğiniz şey, uygulamanızın bir boğaz pazarında başarılı olmasına yardımcı olan mükemmel bir kullanıcı deneyimidir. Tabii ki, özellikle beceri eksikliği, zaman eksikliği ve bütçe gibi istisnalar vardır. Bazen uygulamalar, bu kadar çok şey umursamayan sınırlı sayıda iş kullanıcısına yöneliktir.

Bunlara benzer nedenler, Facebook'un kendi uygulama stratejisini IOS ve android için yerel uygulamalar lehine bölmesi:

Lütfen oku:

Mark Zuckerberg: En Büyük Hatamız HTML5'te Çok Fazla Bahis Yaptı http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on- html5 /

Facebook Neden Mobil Web'i Değiştirdi ve Yeni iOS Uygulamasıyla Yerli Oldu http://readwrite.com/2012/08/23/how-facebook-ditched-the-mobile-web-went-native-with-its-new- ios-app # awesm = ~ o9jDrRefxdgnpS

Bu yardımcı olur umarım.


2

Aşağıda, bu tartışmadaki mevcut tavrım, hibritin başlamak için, uygulamanızı keşfetmek, müşteri geri bildirimlerini hızlıca yinelemek ve özellik setini dengelemek için iyi olduğu yönünde. Daha sonra, uygulamayı geliştirmek için teknik özelliklerine göre uygulamayı yeniden yazmak, deneyimi geliştirmek.

Mobile Web'i dışarıda bıraktım, çünkü tamamen farklı bir amaca hizmet ediyor. App mağazalarında olmak istiyorsanız, Native / Hybrid gitmek için yoludur. Dağıtımı basitleştirmek ve tecrübe ve teknik kabiliyetten ödün vermeye istekli olmak istiyorsanız, Mobil Web'e gidin.

Pro / Eksileri Yerli :

  • Pro: Cihaz deneyiminin geri kalanıyla uyuşuyor , esrarengiz vadi sorunu yok.
  • Pro: Çoğunlukla pürüzsüz ve tutarlı bir UI deneyimi sağlar, gecikme olmaz, takmazlar olmaz.
  • Pro: Birkaç teknik sınırlama var, cihazı tamamen kullanabilirsiniz.
  • Pro: Yerel araçlar, uygulama mağazalarının doğrulanmasıyla uyum sağlar.
  • Pro: Yerel çerçeveler, platform sürümü başına tweaks, ince ayar için daha az zaman harcar.
  • Con: Uzun süre dayanıyor ve bu nedenle inşa etmek daha uzun sürüyor.
  • Con: Bulması zor, pahalı olan polyglot geliştiricileri gerektirir.
  • Con: Her cihaz platformu API'sini (iOS / Android / etc) tanıyın.
  • Con: Dik öğrenme eğrisi.
  • Con: Platform başına farklı araç takımı.

Pro / Eksileri Hibrit :

  • Pro: Birden fazla cihaz platformunu hedef alan tek kod tabanı.
  • Pro: Hızlı geliştirme döngüleri, düzende büyük esneklik, prototip oluşturma ve MVP'ler için mükemmel .
  • Pro: Konforlu öğrenme eğrisi, birçok dokümantasyon, size yardımcı olacak çerçeveler.
  • Pro: Tek geliştirme araç seti. Chrome hata ayıklayıcı araçları mükemmel.
  • Pro: Birden fazla cihaz platformunu hedef alan bir kod tabanı.
  • Pro: Çok sayıda geliştirici var, öğrenmesi kolay.
  • Con: UI'yi her farklı platform için cihaz deneyimiyle tutarlı olması için uyarlamak için uygun UI çerçevesini gerektirir. Kendo UI , Sencha Touch gibi çözümler var .
  • Con: Bellek ve hesaplama kullanımı konusunda çok bilinçli olmanız gerekir, bazı CSS, javascript döngüleri uygulamayı ciddi şekilde yavaşlatabilir. Cihazda hata ayıklamak için çok iyi araçlar yoktur.
  • Con: Henüz olgunlaşmamış, işler birdenbire değişebilir, araçlar daha iyi hale gelir.

2

Kendimi bir mobil geliştirici olmak, en kötü şey çevrimdışı erişim. Kullanıcıları çevrimiçi olmaya zorluyor, bu da pek çok uygulamada çalışması gerekiyor, ancak hepsi değil.

Diğer büyük kötü yön yavaşlıktır. Uzak verilerin ayrıştırılması için gereken süre önemli ölçüde zaman alabilir. Evet, yükleme süresi boyunca verileri önceden getirebilirsiniz, ancak diğer tüm durumlarda yavaşlıktan kaçınamazsınız.

Böyle bir uygulamanın, uygulamayı yerel olanlardan daha pahalı buldum. Onları artık hiçbir müşterime önermiyorum.


1

Hibrit uygulamalarla ilgili büyük sorun, çerçevelerin parçalanmasıdır: ilgilenilen yerli mobil platformlardan (genellikle sadece iki, Android ve iOS) olduğundan çok daha fazlası vardır (İyonik, Xamarin, Yerli Tepki, vb.). Bu çerçeveler rekabet eder, ortaya çıkar, reddeder, bu yüzden karma melez olmak, mevcut ekibinizi yaşam boyu sürdürmeyi planlasanız bile, sizi platformdan platforma atlamaktan kurtarmaz.

Google ve Apple, editörleri, hata ayıklayıcıları, test çerçevelerini, yeniden düzenleme araçlarını ve platformlar için geliştirilecek diğer araçları sağlama ve destekleme konusunda ellerinden geleni yapıyorlar. Bu nedenle, tipik olarak "Ben bir hibrit uygulama geliştirmek, en sevdiğiniz editörle düzenlemek ve bir tarayıcıda açmak çok daha kolay " ifadesini alırdım . Xamarin ve React Native, Swift veya Java / Android ile aynı olan geliştirme platformlarıdır ve "merhaba dünya" daha kısa görünmekle birlikte, nihayetinde düzgün bir şekilde öğrenmek için karşılaştırılabilir zaman ayırmalıdır.

Herhangi bir durumda, yerel bileşenlere duyulan bir ihtiyaç ortaya çıkarsa (örneğin, mevcut üçüncü taraf kütüphanesi entegre edilmeli), iki yerine üç çerçeveye sahip olursunuz: iOS, Android ve hibrit çerçeveniz en üstte, sonuçta daha karmaşık bir yapıya sahip. Bu tür uygulamalarda hata ayıklama, katmanlar arası aramalar arasında adım atma, tüm katmanları günlüğe kaydetme, kodu senkronize tutma özelliği zaman zaman imkansızdır.

Bazıları " uygulamanın tüm platformlar için tamamen aynı şekilde görüneceğini " söylüyor . Gerçekten iyi bir şey mi? Android uygulaması Android uygulaması gibi görünmeli ve iOS uygulaması iOS uygulaması gibi görünmelidir.

Peki ya yeni özellikler? Wearables? Şimdi Android platformu tarafından sunulan anlık uygulamalar? Harici ekranda ek veri gösteriliyor mu? Hibrit uygulamalar artık birçok yerel özelliği destekliyor, ancak gerçekten hepsini destekliyor mu? Herhangi bir zamanda, hemen?

Son olarak, sadece performans ve kullanıcı deneyimi değil, aynı zamanda güvenlik de yerel uygulamanın yanında olabilir. Hibrit çerçeve, kendi hataları, güvenlik hataları da dahil olmak üzere dolaylı bir katman ekler.

Her şeyden önce, seçme olasılığı altında, ya iOS için, diğeri Android için olan iki yerel uygulamaya ya da alternatif olarak, herhangi bir platform için herhangi bir platform için uygulama geliştirmeye zahmet etmeden, web sitesinin mobil versiyonunu tasarlayacağım. .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.