Android uygulamasını web sayfasına dönüştürme süreci

• Seyahat programı, konaklama bilgileri ve PDF’leri gösteren Travelbound, fiilen web’den alınan içeriği gösterirken izleme ve seyahat reklamlarını da içerdiği için, aynı bilgileri sunan bir web sayfasıyla değiştirilmiş
• Android sanal cihazı root edilip HTTP Toolkit ile trafik yakalanarak, kullanıcı adı ile parolayı URL’de birleştiren bir API’nin uygulamadaki tüm içeriği JSON olarak döndürdüğü doğrulanmış
• Ruby betiği ve Cron ile en güncel JSON düzenli olarak alınıp HTML üretilmiş; reklam verileri hariç tutularak yalnızca program ve PDF gibi gerekli dosyalar sunulmuş
• Web sürümü kopyalama·yazdırma·kaydetme·yer imleme·arama imkânı veriyor, daha fazla cihazda çalışıyor ve özgün uygulamadaki izleme kodları ile reklamları da kaldırıyor
• Özgün uygulama 43MB’tan içerik indirildikten sonra 124MB’a kadar büyürken, web sayfası 0.05MB ve isteğe bağlı görseller de yalnızca 35MB olduğundan, HTML ve HTTP ile sunulan belge odaklı içerikler için web daha uygun

---

Web sayfası olarak gayet yeterli olan Travelbound

• Çocuğun gideceği sahne sanatları okulunun Disneyland gezisinin programını, ulaşımını ve konaklama bilgilerini görmek için Travelbound uygulamasını kurmak gerekiyordu
• Uygulamanın temel içeriği web üzerinden sunulan metin·görsel·PDF bağlantılarıydı
• Web sayfasından ayrılan başlıca iki özellik kullanıcı aleyhineydi
  • Google Account ile bağlantılı izleme verilerini geliştiriciye gönderiyordu
  • Aynı seyahat şirketinin yönettiği diğer tur ürünlerini inspirations adı altında reklam olarak gösteriyordu
• Bir web sayfasında içerik kopyalanabilir·yazdırılabilir·kaydedilebilir·yer imlerine eklenebilir·aranabilir ve neredeyse her cihazda kullanılabilir, ayrıca potansiyel olarak erişilebilirlik de daha yüksek olabilir

Android uygulama trafiğini yakalama

• Android Studio’daki Virtual Device Manager ile yeni bir sanal cihaz oluşturulup adb shell komutunun çalıştığı doğrulanmış
• Android 33 sanal cihazı rootAVD kullanılarak root edilmiş

  ./rootAVD.sh system-images/android-33/google_apis_playstore/x86_64/ramdisk.img  
  

• Root işlemi, Certificate Pinning kullanan uygulamanın ortadaki adam proxy’sinin kendi imzalı TLS sertifikasına güvenmesini sağlamak için gerekliymiş
  • Root olmadan Travelbound gibi uygulamalar sertifikayı geçersiz sayıp iletişimi reddediyordu
• Soğuk başlatmanın ardından Magisk çalıştırılmış ve izin isteyen uygulamalara su erişimini otomatik verme ayarı yapılmış
  • Otomatik izin verilmezse HTTP Toolkit kullanıcı yanıtını beklemeden ayrıcalıksız modda çalışıyordu
• HTTP Toolkit ile Android sanal cihazının trafiği yakalanmış
  • Sahte bir VPN sağlayıcısı kurarak cihaz trafiğini proxy üzerinden yönlendirmiş
  • Android güvenlik kısıtları nedeniyle kurulan kök CA sertifikasının elle eklenmesi gerekmiş
• Travelbound Play Store’dan kurulduktan sonra, gürültüyü azaltmak için yalnızca bu uygulamanın trafiği proxy’den geçirilecek şekilde ayarlanmış

API çağrıları ve veri yapısı

• Uygulama, seyahat grubunun kullanıcı adı ile parolasını birleştirerek şu biçimde bir API URL’si çağırıyordu

  https://travelbound.api.vamoos.com/api/itineraries/…}  
  

• Kullanıcı adı ve parola tüm seyahat grubunun paylaştığı kimlik bilgileriydi
• API’nin döndürdüğü JSON içinde uygulamanın gösterdiği tüm içerik bulunuyordu
  • Seyahat programının her bölümünü içeren bir dizi
  • inspirations reklam dizisi
  • Diğer bölümlerin başvurduğu görseller gibi dosyaları içeren çapraz başvuru dizisi
• Uygulamanın göstereceği HTML kodu da verinin içinde yer aldığından, içeriğin sunum biçimi zaten web sayfasına benziyordu
• S3 görsel URL’lerinin geçerlilik süresi nispeten kısa olduğundan, içerik değişmese bile JSON’un düzenli aralıklarla yeniden alınması gerekiyordu
  • Bir diğer yöntem görselleri yerelde önbelleğe almak; özgün uygulamanın da bunu yaptığı düşünülüyor

JSON’u HTML’ye dönüştürme

• En güncel JSON’u alıp HTML sayfası üretmek üzere bir Ruby betiği yazılmış ve Cron zamanlamasıyla çalışacak şekilde ayarlanmış
• Üretim sürecinde veri şemasındaki overlayRows karşılığı olan inspirations reklamları tamamen hariç tutulmuş
• Web sayfasında yalnızca şu bilgiler gösterilmiş
  1. Seyahat programı öğeleri
  2. Reklamlarda veya programda referans verilmeyen tüm dosyalar
• İkinci liste, PDF indirme bağlantılarını tek yerde toplamanın basit bir yolu olarak kullanılmış
• Üretilen sayfa, mevcut seyahat grubuna verilen parolayla korunmuş
• Özgün JSON, mevcut betiğin henüz tanımadığı şema verileri sonradan ortaya çıkarsa fark edilebilsin diye <details> öğesi içine eklenmiş

Daha küçük ve esnek web sürümü

• Web sayfası özgün uygulama kadar gösterişli değil, ama çok daha küçük ve web’in yerleşik özelliklerini ayrıca geliştirmeden sunuyor
• İçerik kopyalanabiliyor, yazdırılabiliyor, kaydedilebiliyor, yer imlerine eklenebiliyor ve aranabiliyor; ayrıca daha geniş bir cihaz yelpazesinde erişilebiliyor
• İzleme kodları ile reklamlar kaldırılarak özgün uygulamadaki iki gereksiz özellik de ortadan kaldırılmış
• Resmî bir erişilebilirlik denetimi yapılmamış olsa da, özgün uygulamada yardımcı teknolojilerle kullanım açısından basit bir web sürümüne göre daha zor görünen unsurlar varmış

Boyut ve dağıtım yöntemi karşılaştırması

• Özgün Travelbound uygulaması ilk kurulumda 43MB, ek içerik indirildikten sonra ise 124MB’a kadar çıkıyor
• Alternatif web sayfası 0.05MB; tüm görseller isteğe bağlı olarak indirilirse buna 35MB daha ekleniyor
• Seyahat grubuyla her iki yaklaşım da paylaşılmış, böylece kullanıcılar uygulama ile web sayfası arasında istedikleri yöntemi seçebiliyor
• Bazı işler için uygulama uygun olabilir; ancak zaten HTML olarak yazılıp HTTP ile sunulan Travelbound içeriği, uygulama gerektiren bir kullanım örneği değil
• Uygulama mağazası üzerinden dağıtım maliyeti ve geliştirme yükünü artırıyor; bu tür belge odaklı içeriği uygulamayla sınırlamak da, doğrudan web’de yayımlamaya kıyasla hem erişebilen kişi sayısını hem de temel işlevleri azaltıyor

[GN⁺]

Lobste.rs görüşleri

• Özünde bir web sayfasından ibaret olan hizmetlerin uygulama şişkinliğine yol açmasından bıkmıştım; bunu düşünen tek kişinin ben olmamam sevindirici
  Android'de web sayfası kısayolu oluşturma özelliği kullanıcılara pek görünür sunulmadığı için şirketlerin uygulamayı tercih etmesini anlamak mümkün. Ama şifreyi uygulama bağlantısıyla birlikte SMS'le gönderen bir hizmet için en uygun seçenek web uygulamasıdır. Doğrudan şifre sayfasına bağlarsın, iş biter
  /e/OS uygulama mağazasında da Google Maps'in web sürümü gibi öğeleri toplayan bir “web apps” bölümü var. PWA'nın kendisi kullanımı kolay, ancak varsayılan Chrome'un ya da üretici Android'lerinin kısayol oluşturmayı ne kadar aktif biçimde yönlendirdiğini ve ne kadar görünür sunduğunu bilmiyorum
  Mevcut yaklaşımın kullanıcı yararına olmadığı açık; bunu nasıl iyileştirmek gerektiği üzerine düşünmek lazım

• Sıradan kullanıcılar, özellikle de bilgisayara alışık olmayanlar için uygulama ile web sayfası arasındaki fark pratikte sadece masaüstü ya da ana ekran kısayoludur
  Web sayfası kısayolları doğrudan dağıtılabilseydi bu, uygulama geliştirmenin çok ucuz bir yolu olurdu ve muhtemelen uygulamaların çoğu da böyle yapılabilirdi

  • iOS'ta Safari'de bir web sayfasını açtıktan sonra paylaşım düğmesindeki “View More” üzerinden “Add to Home Screen” seçilirse ana ekrana bir simge eklenebilir
    Bu simgeye basınca yeni bir tarayıcı sekmesi değil, normal bir uygulama gibi bağımsız bir pencere açılır. Ben de App Store'da yayımlamadan, aile harcamaları için yaptığım aracı bu yöntemle dağıtıyorum

• Pek çok “uygulama” için aslında sadece bir web sayfası olmak yeterlidir. Önemsiz bir işlevi kullanmak için hiçbir neden yokken önce uygulama kurmak zorunda kalmak çok sinir bozucu
  Yerel cihaza bağlanmak için uygulama kullanmayı anlaşılır buluyorum, ama bazı sistemler uygulamayı merkezi bir sunucu üzerinden yerel cihazla konuşturacak şekilde tasarlanıyor. O zaman uygulama kurmayı gerektiren tek gerekçe bile ortadan kalkıyor
  İlk iPhone, web sayfalarını bir uygulama platformu yapmayı hedeflemişti ama sonuçta bugünkü gibi dağınık bir ekosistem ortaya çıktı