Quá trình thử biến một ứng dụng Android thành trang web

 (danq.me)
3 điểm bởi GN⁺ 11 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Travelbound, ứng dụng hiển thị lịch trình du lịch, thông tin lưu trú và PDF, về thực chất chỉ đang hiển thị nội dung nhận từ web nhưng lại kèm cả theo dõi và quảng cáo du lịch, nên tác giả đã thử thay thế bằng một trang web cung cấp cùng thông tin
  • Root một thiết bị Android ảo và dùng HTTP Toolkit để chặn lưu lượng, qua đó xác nhận rằng API ghép tên người dùng và mật khẩu vào URL trả về toàn bộ nội dung của ứng dụng dưới dạng JSON
  • Dùng script Ruby và Cron để định kỳ lấy JSON mới nhất và tạo HTML, chỉ hiển thị các tệp cần thiết như lịch trình và PDF, đồng thời loại bỏ dữ liệu quảng cáo
  • Phiên bản web có thể sao chép, in, lưu, đánh dấu trang và tìm kiếm, chạy trên nhiều loại thiết bị hơn, đồng thời loại bỏ cả mã theo dõi và quảng cáo của ứng dụng gốc
  • Ứng dụng gốc tăng từ 43MB lên 124MB sau khi tải nội dung, trong khi trang web chỉ 0,05MB và phần ảnh tùy chọn cũng chỉ 35MB, cho thấy web phù hợp hơn với nội dung dạng tài liệu được truyền bằng HTML và HTTP

Travelbound vốn chỉ cần một trang web là đủ

  • Để xem lịch trình chuyến đi Disneyland, phương tiện di chuyển và thông tin lưu trú của trường nghệ thuật biểu diễn mà con tác giả sẽ tham gia, cần cài ứng dụng Travelbound
  • Nội dung cốt lõi của ứng dụng là văn bản, hình ảnh và liên kết PDF được truyền qua web
  • Những chức năng khác với một trang web chỉ có hai điểm bất lợi cho người dùng
    • Gửi dữ liệu theo dõi liên kết với Google Account về cho nhà phát triển
    • Quảng cáo các sản phẩm du lịch khác do cùng công ty du lịch vận hành dưới tên inspirations
  • Nếu là trang web, người dùng có thể sao chép, in, lưu, đánh dấu trang và tìm kiếm nội dung, sử dụng trên gần như mọi thiết bị và có thể cải thiện khả năng tiếp cận

Chặn lưu lượng của ứng dụng Android

  • Tạo một thiết bị ảo mới trong Virtual Device Manager của Android Studio và xác nhận adb shell hoạt động
  • Dùng rootAVD để root thiết bị ảo Android 33 
    ./rootAVD.sh system-images/android-33/google_apis_playstore/x86_64/ramdisk.img
  • Việc root là cần thiết để khiến các ứng dụng dùng Certificate Pinning tin cậy chứng chỉ TLS tự ký của proxy trung gian
    • Nếu không root, các ứng dụng như Travelbound sẽ đánh giá chứng chỉ là không hợp lệ và từ chối giao tiếp
  • Sau khi cold boot, chạy Magisk và thiết lập tự động cho phép quyền truy cập su đối với ứng dụng yêu cầu
    • Nếu không tự động cho phép, HTTP Toolkit sẽ chạy ở chế độ không đặc quyền mà không chờ phản hồi từ người dùng
  • Dùng HTTP Toolkit để chặn lưu lượng của thiết bị Android ảo
    • Cài một nhà cung cấp VPN giả để chuyển lưu lượng thiết bị qua proxy
    • Do các ràng buộc bảo mật của Android, chứng chỉ root CA đã cài phải được thêm thủ công
  • Sau khi cài Travelbound từ Play Store, cấu hình để chỉ proxy lưu lượng của ứng dụng đó nhằm giảm nhiễu

Lệnh gọi API và cấu trúc dữ liệu

  • Ứng dụng gọi URL API theo định dạng sau bằng cách nối tên người dùng và mật khẩu của nhóm du lịch 
    https://travelbound.api.vamoos.com/api/itineraries/…}
  • Tên người dùng và mật khẩu là thông tin đăng nhập dùng chung cho toàn bộ nhóm du lịch
  • JSON phản hồi từ API chứa toàn bộ nội dung mà ứng dụng hiển thị
    • Mảng chứa từng chặng trong lịch trình du lịch
    • Mảng quảng cáo inspirations
    • Mảng tham chiếu chéo chứa các tệp như hình ảnh được tham chiếu từ những phần khác
  • Dữ liệu còn bao gồm cả mã HTML mà ứng dụng sẽ hiển thị, nên bản thân cách truyền nội dung tương tự một trang web
  • URL ảnh trên S3 có thời hạn hết hạn khá ngắn, vì vậy cần định kỳ lấy lại JSON ngay cả khi nội dung không thay đổi
    • Cách khác là cache ảnh cục bộ, và ứng dụng gốc có vẻ dùng cách này

Chuyển JSON thành HTML

  • Viết script Ruby và cấu hình để lấy JSON mới nhất theo lịch Cron rồi tạo trang HTML
  • Trong quá trình tạo, loại bỏ hoàn toàn quảng cáo inspirations tương ứng với overlayRows trong schema dữ liệu
  • Trang web chỉ hiển thị các thông tin sau
    1. Các mục lịch trình du lịch
    2. Tất cả tệp không được tham chiếu từ quảng cáo hoặc lịch trình
  • Danh sách thứ hai được dùng như một cách đơn giản để gom các liên kết tải PDF về một chỗ
  • Trang được tạo được bảo vệ bằng cùng mật khẩu đã cung cấp cho nhóm du lịch hiện có
  • Đưa JSON gốc vào phần tử <details> để có thể kiểm tra liệu sau này có xuất hiện dữ liệu schema mà script hiện tại chưa nhận biết hay không

Phiên bản web nhỏ hơn và linh hoạt hơn

  • Trang web không hào nhoáng như ứng dụng gốc nhưng nhỏ hơn rất nhiều, đồng thời cung cấp các chức năng mặc định của web mà không cần triển khai riêng
  • Có thể sao chép, in, lưu, đánh dấu trang và tìm kiếm nội dung, đồng thời truy cập được từ nhiều thiết bị hơn
  • Loại bỏ mã theo dõi và quảng cáo, nhờ đó cũng bỏ đi hai chức năng không cần thiết có trong ứng dụng gốc
  • Dù chưa kiểm toán chính thức về khả năng tiếp cận, ứng dụng gốc có những yếu tố trông có vẻ khó dùng với công nghệ hỗ trợ hơn so với phiên bản web đơn giản

So sánh dung lượng và cách phân phối

  • Ứng dụng Travelbound gốc ban đầu là 43MB và tăng lên 124MB sau khi tải thêm nội dung
  • Trang web thay thế là 0,05MB, và nếu tùy chọn tải toàn bộ hình ảnh thì thêm 35MB
  • Chia sẻ cả hai cách tiếp cận với nhóm du lịch để người dùng có thể chọn giữa ứng dụng và trang web
  • Một số tác vụ phù hợp với ứng dụng, nhưng nội dung Travelbound vốn đã được viết bằng HTML và truyền qua HTTP thì không phải là trường hợp cần ứng dụng
  • Phân phối qua app store làm tăng chi phí và gánh nặng phát triển; việc giới hạn loại nội dung dạng tài liệu này trong ứng dụng sẽ làm giảm số người có thể sử dụng và các chức năng cơ bản so với khi đăng trực tiếp lên web

Bài viết liên quan

1 bình luận

 
GN⁺ 11 giờ trước
Ý kiến trên Lobste.rs

  • Tôi đã quá chán việc những dịch vụ về bản chất chỉ là trang web lại dẫn đến sự phình to của ứng dụng, nên cũng mừng vì không chỉ mình tôi thấy vậy
    Trên Android, việc tạo lối tắt tới trang web không quá dễ thấy với người dùng, nên việc doanh nghiệp chuộng ứng dụng cũng là điều có thể hiểu được. Tuy vậy, với những dịch vụ gửi mật khẩu qua tin nhắn kèm liên kết ứng dụng thì ứng dụng web mới là phù hợp nhất. Chỉ cần liên kết thẳng tới trang mật khẩu là xong
    Cửa hàng ứng dụng của /e/OS cũng có mục “web apps” tập hợp các mục như phiên bản web của Google Maps. Bản thân PWA thì dễ dùng, nhưng tôi không rõ Chrome mặc định hay Android của các hãng có hướng dẫn tạo lối tắt tích cực và hiển thị nổi bật đến mức nào
    Rõ ràng cách làm hiện tại không phải vì người dùng, và cần suy nghĩ về cách cải thiện điều này

  • Với người dùng thông thường, đặc biệt là những người không quen máy tính, khác biệt giữa ứng dụng và trang web thực chất chỉ là lối tắt trên desktop hoặc màn hình chính
    Nếu có thể phân phối ngay lối tắt tới trang web thì đó sẽ là một cách làm ứng dụng với chi phí rất thấp, và có lẽ phần lớn ứng dụng đã có thể được tạo ra theo cách đó

    • Trong Safari trên iOS, sau khi mở một trang web, bạn có thể nhấn nút chia sẻ, vào “View More”, rồi chọn “Add to Home Screen” để thêm biểu tượng lên màn hình chính
      Khi nhấn vào biểu tượng này, nó sẽ mở trong một cửa sổ độc lập như ứng dụng bình thường chứ không phải một tab trình duyệt mới. Tôi đã phân phối công cụ quản lý chi tiêu gia đình do mình tự làm theo cách này mà không cần đăng lên App Store

  • Rất nhiều “ứng dụng” thực ra chỉ cần là trang web là đủ. Thật bức bối khi quá thường xuyên phải cài ứng dụng trước chỉ để dùng một chức năng nhỏ nhặt mà chẳng có lý do rõ ràng
    Dùng ứng dụng để kết nối với thiết bị cục bộ thì còn có thể chấp nhận được, nhưng cũng có những hệ thống mà ứng dụng lại giao tiếp với thiết bị cục bộ thông qua máy chủ trung tâm. Khi đó, ngay cả lý do duy nhất để phải cài ứng dụng cũng biến mất
    iPhone đời đầu từng định biến trang web thành một nền tảng ứng dụng, nhưng rốt cuộc lại trở thành một hệ sinh thái lộn xộn như hiện nay