กระบวนการลองเปลี่ยนแอป Android ให้เป็นเว็บเพจ

 (danq.me)
3 คะแนน โดย GN⁺ 11 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Travelbound ซึ่งแสดงกำหนดการเดินทาง ข้อมูลที่พัก และ PDF แท้จริงแล้วแสดงคอนเทนต์ที่ได้รับจากเว็บ แต่กลับใส่ทั้งการติดตามและโฆษณาท่องเที่ยวมาด้วย จึงลองแทนที่ด้วยเว็บเพจที่ให้ข้อมูลเดียวกัน
  • รูทอุปกรณ์เสมือน Android แล้วใช้ HTTP Toolkit ดักทราฟฟิก จนพบว่า API ที่นำชื่อผู้ใช้และรหัสผ่านมาต่อเข้ากับ URL ส่งคืนคอนเทนต์ทั้งหมดของแอปเป็น JSON
  • ใช้ สคริปต์ Ruby และ Cron ดึง JSON ล่าสุดเป็นระยะเพื่อสร้าง HTML และตัดข้อมูลโฆษณาออก เหลือเฉพาะไฟล์ที่จำเป็น เช่น กำหนดการและ PDF
  • เวอร์ชันเว็บสามารถ คัดลอก·พิมพ์·บันทึก·บุ๊กมาร์ก·ค้นหา ได้ ทำงานบนอุปกรณ์ได้หลากหลายกว่า และยังเอาโค้ดติดตามกับโฆษณาของแอปต้นฉบับออกด้วย
  • แอปต้นฉบับมีขนาด 43MB และขยายเป็น 124MB หลังดาวน์โหลดคอนเทนต์ แต่เว็บเพจมีขนาด 0.05MB และแม้รวมรูปภาพแบบเลือกดาวน์โหลดก็เพียง 35MB จึงเหมาะกว่าเมื่อเป็น คอนเทนต์เชิงเอกสารที่ส่งผ่าน HTML และ HTTP

Travelbound ที่จริงใช้เว็บเพจก็เพียงพอแล้ว

  • เพื่อดูตารางเดินทางไป Disneyland การเดินทาง และข้อมูลที่พักของโรงเรียนศิลปะการแสดงที่ลูกจะไป จำเป็นต้องติดตั้ง แอป Travelbound
  • คอนเทนต์หลักของแอปคือ ข้อความ·รูปภาพ·ลิงก์ PDF ที่ส่งผ่านเว็บ
  • ฟังก์ชันที่ต่างจากเว็บเพจมีอยู่สองอย่างที่เป็นผลเสียต่อผู้ใช้
    • ส่งข้อมูลติดตามที่เชื่อมกับ Google Account ไปให้นักพัฒนา
    • โฆษณาแพ็กเกจท่องเที่ยวอื่นของบริษัทท่องเที่ยวเดียวกันในชื่อ inspirations
  • ถ้าเป็นเว็บเพจ จะสามารถ คัดลอก·พิมพ์·บันทึก·บุ๊กมาร์ก·ค้นหา คอนเทนต์ได้ ใช้งานได้บนแทบทุกอุปกรณ์ และอาจเพิ่มการเข้าถึงได้ด้วย

การดักทราฟฟิกของแอป Android

  • สร้างอุปกรณ์เสมือนใหม่ใน Virtual Device Manager ของ Android Studio และตรวจสอบว่า adb shell ทำงานได้
  • ใช้ rootAVD เพื่อรูทอุปกรณ์เสมือน Android 33 
    ./rootAVD.sh system-images/android-33/google_apis_playstore/x86_64/ramdisk.img
  • การรูทจำเป็นเพื่อทำให้แอปที่ใช้ Certificate Pinning เชื่อถือใบรับรอง TLS แบบ self-signed ของพร็อกซีแบบคนกลาง
    • หากไม่รูท แอปอย่าง Travelbound จะมองว่าใบรับรองไม่ถูกต้องและปฏิเสธการสื่อสาร
  • หลัง cold boot ให้รัน Magisk และตั้งค่าให้อนุญาตการเข้าถึง su โดยอัตโนมัติสำหรับแอปที่ร้องขอ
    • หากไม่อนุญาตอัตโนมัติ HTTP Toolkit จะทำงานในโหมดไม่มีสิทธิ์พิเศษโดยไม่รอคำตอบจากผู้ใช้
  • ใช้ HTTP Toolkit ดักทราฟฟิกของอุปกรณ์เสมือน Android
    • ติดตั้งผู้ให้บริการ VPN ปลอมเพื่อส่งทราฟฟิกของอุปกรณ์ไปยังพร็อกซี
    • เนื่องจากข้อจำกัดด้านความปลอดภัยของ Android จำเป็นต้องเพิ่มใบรับรอง root CA ที่ติดตั้งไว้ด้วยตนเอง
  • หลังติดตั้ง Travelbound จาก Play Store แล้ว ตั้งค่าให้พร็อกซีเฉพาะทราฟฟิกของแอปนั้นเพื่อลดสัญญาณรบกวน

การเรียก API และโครงสร้างข้อมูล

  • แอปนำชื่อผู้ใช้และรหัสผ่านของกลุ่มเดินทางมาต่อกัน แล้วเรียก API URL ในรูปแบบต่อไปนี้ 
    https://travelbound.api.vamoos.com/api/itineraries/…}
  • ชื่อผู้ใช้และรหัสผ่านเป็นข้อมูลรับรองที่ใช้ร่วมกันทั้งกลุ่มเดินทาง
  • JSON ที่ตอบกลับจาก API มีคอนเทนต์ทั้งหมดที่แอปแสดงอยู่
    • อาร์เรย์ที่เก็บแต่ละช่วงของกำหนดการเดินทาง
    • อาร์เรย์โฆษณา inspirations
    • อาร์เรย์อ้างอิงข้ามที่เก็บไฟล์ เช่น รูปภาพที่ส่วนอื่นอ้างถึง
  • ในข้อมูลยังมีแม้กระทั่งโค้ด HTML ที่แอปจะแสดง จึงมีวิธีส่งคอนเทนต์คล้ายเว็บเพจอยู่แล้ว
  • URL รูปภาพบน S3 มีเวลาหมดอายุค่อนข้างสั้น จึงต้องดึง JSON ใหม่เป็นระยะ แม้คอนเทนต์จะไม่เปลี่ยนก็ตาม
    • อีกวิธีคือแคชรูปภาพไว้ในเครื่อง ซึ่งแอปต้นฉบับดูเหมือนจะใช้วิธีนี้

แปลง JSON เป็น HTML

  • เขียน สคริปต์ Ruby และตั้งค่าให้ดึง JSON ล่าสุดตามตาราง Cron เพื่อสร้างหน้า HTML
  • ในขั้นตอนสร้าง ตัดโฆษณา inspirations ซึ่งสอดคล้องกับ overlayRows ในสคีมาข้อมูลออกทั้งหมด
  • เว็บเพจแสดงเฉพาะข้อมูลต่อไปนี้
    1. รายการกำหนดการเดินทาง
    2. ไฟล์ทั้งหมดที่ไม่ได้ถูกอ้างอิงจากโฆษณาหรือกำหนดการ
  • ใช้รายการที่สองเป็นวิธีง่าย ๆ ในการรวมลิงก์ดาวน์โหลด PDF ไว้ที่เดียว
  • หน้าที่สร้างขึ้นถูกป้องกันด้วยรหัสผ่านเดียวกับที่ให้ไว้กับกลุ่มเดินทางเดิม
  • ใส่ JSON ต้นฉบับไว้ในองค์ประกอบ <details> เพื่อให้ตรวจสอบได้ภายหลังว่ามีข้อมูลสคีมาที่สคริปต์เดิมยังไม่รู้จักปรากฏขึ้นหรือไม่

เวอร์ชันเว็บที่เล็กและยืดหยุ่นกว่า

  • เว็บเพจอาจไม่สวยหวือหวาเท่าแอปต้นฉบับ แต่ มีขนาดเล็กกว่ามาก และให้ฟังก์ชันพื้นฐานของเว็บโดยไม่ต้องพัฒนาเพิ่ม
  • สามารถคัดลอก·พิมพ์·บันทึก·บุ๊กมาร์ก·ค้นหาคอนเทนต์ได้ และเข้าถึงได้จากอุปกรณ์ที่หลากหลายกว่า
  • ลบโค้ดติดตามและโฆษณาออก จึงตัดฟังก์ชันไม่จำเป็นสองอย่างที่มีในแอปต้นฉบับไปด้วย
  • แม้ยังไม่ได้ตรวจสอบการเข้าถึงอย่างเป็นทางการ แต่ในแอปต้นฉบับมีองค์ประกอบที่ดูเหมือนใช้งานด้วยเทคโนโลยีช่วยเหลือได้ยากกว่าเวอร์ชันเว็บแบบเรียบง่าย

เปรียบเทียบขนาดและวิธีเผยแพร่

  • แอป Travelbound ต้นฉบับมีขนาดเริ่มต้น 43MB และหลังดาวน์โหลดคอนเทนต์เพิ่มเติมจะขยายถึง 124MB
  • เว็บเพจทดแทนมีขนาด 0.05MB และหากเลือกดาวน์โหลดรูปภาพทั้งหมดจะเพิ่มอีก 35MB
  • แชร์ทั้งสองวิธีให้กับกลุ่มเดินทาง เพื่อให้ผู้ใช้เลือกได้ว่าจะใช้แอปหรือเว็บเพจ
  • บางงานเหมาะกับแอป แต่คอนเทนต์ของ Travelbound ซึ่งเขียนเป็น HTML อยู่แล้วและส่งผ่าน HTTP ไม่ใช่กรณีที่จำเป็นต้องมีแอป
  • การเผยแพร่ผ่านแอปสโตร์เพิ่มทั้งต้นทุนและภาระการพัฒนา และเมื่อจำกัดคอนเทนต์เชิงเอกสารแบบนี้ไว้ในแอป ก็ทำให้จำนวนผู้ที่ใช้งานได้และฟังก์ชันพื้นฐานลดลงเมื่อเทียบกับการเผยแพร่บนเว็บโดยตรง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 11 시간 전
ความคิดเห็นจาก Lobste.rs

  • เบื่อที่บริการซึ่งโดยเนื้อแท้แล้วเป็นแค่เว็บเพจ กลับนำไปสู่ แอปที่บวมเกินจำเป็น ดีใจที่ไม่ได้คิดแบบนี้อยู่คนเดียว
    บน Android การสร้างทางลัดไปยังเว็บเพจไม่ได้ถูกทำให้ผู้ใช้เห็นชัดนัก จึงพอเข้าใจได้ว่าทำไมบริษัทถึงชอบแอปมากกว่า แต่ถ้าเป็นบริการที่ส่งรหัสผ่านพร้อมลิงก์แอปมาทางข้อความ เว็บแอป น่าจะเหมาะที่สุด แค่ลิงก์ตรงไปยังหน้ารหัสผ่านก็จบแล้ว
    ในแอปสโตร์ของ /e/OS ยังมีส่วน “web apps” ที่รวมรายการอย่าง Google Maps เวอร์ชันเว็บไว้ด้วย PWA เองใช้งานง่าย แต่ไม่แน่ใจว่า Chrome พื้นฐานหรือ Android ของผู้ผลิตต่าง ๆ แนะนำและทำให้การสร้างทางลัดเห็นเด่นชัดแค่ไหน
    วิธีในปัจจุบันชัดเจนว่าไม่ได้ทำเพื่อผู้ใช้ และจำเป็นต้องคิดว่าจะปรับปรุงอย่างไร

  • สำหรับผู้ใช้ทั่วไป โดยเฉพาะคนที่ไม่คุ้นกับคอมพิวเตอร์ ความแตกต่างระหว่างแอปกับเว็บเพจ แทบจะมีแค่ ทางลัดบนเดสก์ท็อปหรือหน้าจอหลัก เท่านั้น
    ถ้าสามารถแจกจ่ายทางลัดเว็บเพจได้โดยตรง ก็คงเป็นวิธีพัฒนาแอปที่ถูกมาก และแอปส่วนใหญ่ก็อาจถูกสร้างขึ้นแบบนั้นได้

    • ใน Safari บน iOS หลังเปิดเว็บเพจแล้ว กดปุ่มแชร์ ผ่าน “View More” แล้วเลือก “Add to Home Screen” ก็จะเพิ่มไอคอนลงในหน้าจอหลักได้
      เมื่อกดไอคอนนี้ จะไม่ได้เปิดแท็บเบราว์เซอร์ใหม่ แต่จะเปิดเป็น หน้าต่างแยกอิสระ เหมือนแอปทั่วไป ผมแจกจ่ายเครื่องมือจัดการค่าใช้จ่ายครอบครัวที่ทำเองด้วยวิธีนี้ โดยไม่ต้องเผยแพร่บน App Store

  • “แอป” จำนวนมาก แค่เป็น เว็บเพจ ก็เพียงพอแล้ว น่าหงุดหงิดมากที่มีหลายสถานการณ์ซึ่งต้องติดตั้งแอปก่อน เพียงเพื่อใช้ฟังก์ชันเล็กน้อยโดยไม่มีเหตุผลชัดเจน
    การใช้แอปเพื่อเชื่อมต่อกับอุปกรณ์ในเครื่องยังพอเข้าใจได้ แต่ก็มีระบบที่ทำให้แอปสื่อสารกับอุปกรณ์ในเครื่องโดยต้องผ่านเซิร์ฟเวอร์กลางอยู่ดี แบบนั้นแม้แต่เหตุผลเดียวที่จำเป็นต้องติดตั้งแอปก็หายไป
    iPhone ในยุคแรกพยายามใช้เว็บเพจเป็น แพลตฟอร์มแอป แต่สุดท้ายก็กลายเป็นระบบนิเวศรก ๆ แบบที่เห็นกันในตอนนี้