Dùng ma trận lập kế hoạch để xác định phạm vi camera, GPS, sinh trắc và lưu trữ ngoại tuyến trong ứng dụng no-code — kèm UX, quyền và tiêu chí kiểm thử rõ ràng.
Camera, GPS, sinh trắc học và chế độ ngoại tuyến nghe thì như những bổ sung đơn giản. Thực tế, chúng chạm tới phần cứng thiết bị, quy tắc quyền riêng tư và một danh sách dài các trường hợp rìa. Đó là lý do tại sao các khả năng gốc trên di động trong ứng dụng no-code thường gây ra trì hoãn vào phút cuối.
Hầu hết sự trì hoãn bắt đầu từ phạm vi không rõ ràng. Một nhà thiết kế phác thảo luồng mượt mà, rồi QA thử nghiệm hành vi thực tế: tín hiệu yếu, ánh sáng kém, người dùng từ chối quyền, hoặc điện thoại tắt app khi chạy nền. Mỗi bất ngờ tạo ra công việc sửa đổi trên UX, logic nghiệp vụ và test case, đúng vào lúc quy trình đánh giá phát hành đã nghiêm ngặt.
Phần khó không phải là đường tốt. Phần khó là đồng ý về hành vi tối thiểu chấp nhận được trước khi bạn xây dựng:
Một ma trận lập kế hoạch đơn giản buộc phải đưa ra các quyết định này sớm. Nó làm cho các đánh đổi hiển nhiên (tốc độ vs quyền riêng tư, tiện lợi vs bảo mật), biến các trường hợp rìa thành yêu cầu, và biến ý tưởng mơ hồ thành các phát biểu có thể kiểm thử.
Ví dụ: một app kỹ thuật hiện trường có thể “cần GPS”, nhưng câu hỏi thực sự là nó cần theo dõi liên tục hay chỉ cần đóng dấu vị trí khi hoàn thành công việc. Một lựa chọn thay đổi quyền, tác động pin và những gì người phê duyệt sẽ mong đợi.
Ma trận lập kế hoạch tính năng là một bảng một trang giúp bạn đồng ý về phạm vi trước khi ai đó bắt tay xây dựng. Với tính năng di động, nó giữ cho các nhóm thống nhất về mục đích tính năng, những gì người dùng thấy và những gì người phê duyệt sẽ kiểm tra.
Hãy để các hàng là các khả năng bạn có thể thêm, như camera, GPS, sinh trắc và lưu trữ ngoại tuyến. Rồi thêm các cột buộc các quyết định rõ ràng. Bạn không viết spec đầy đủ lúc này. Bạn chỉ đảm bảo cùng một câu hỏi được trả lời cho mọi tính năng: mục tiêu người dùng, luồng UX, quyền sẽ yêu cầu, dữ liệu thu thập hoặc lưu, các trường hợp rìa và ghi chú kiểm thử ngắn.
Quyền sở hữu quan trọng. Chọn một người duy trì ma trận (thường là product owner hoặc lead designer), và xem lại theo nhịp đều đặn: hàng tuần, hoặc trước mỗi lần đánh giá phát hành. Ma trận chỉ hữu ích nếu nó được cập nhật khi phạm vi thay đổi.
Một quy tắc ngăn hầu hết bất ngờ phút cuối: mỗi tính năng cần một đường dự phòng. App nên vẫn hoạt động theo cách giới hạn nhưng trung thực khi người dùng nói không, thiết bị thiếu phần cứng, hoặc hệ điều hành chặn yêu cầu. Ví dụ: nhập thủ công khi không có camera, chọn địa chỉ khi không có GPS, PIN/mật khẩu khi sinh trắc thất bại, và thông báo “cần kết nối” (cộng với nháp khi có thể) khi công việc ngoại tuyến không được hỗ trợ.
Nếu bạn đang xây dựng với một nền tảng như AppMaster, ma trận cũng giúp bạn ánh xạ phạm vi tới màn hình, logic và mô hình dữ liệu trước khi bắt đầu nối các thành phần.
Xem ma trận như một lời hứa bạn có thể kiểm thử sau này, không phải danh sách mong muốn. Với mỗi khả năng, viết một “nhiệm vụ” rõ ràng từ góc nhìn người dùng. Ví dụ: “Kỹ thuật viên hiện trường chụp ảnh công tơ và đính kèm vào chuyến thăm hôm nay, ngay cả khi tín hiệu yếu.” Điều này giữ tính năng gắn với công việc thực tế.
Tiếp theo, ép tính năng vào một đường tốt ngắn. Nếu bạn không thể mô tả luồng trong vài màn hình, phạm vi chưa sẵn sàng. Bạn không cần hoàn thiện thiết kế, chỉ cần thứ tự hành động và những gì người dùng thấy.
Rồi ánh xạ quyền theo khoảnh khắc. Tránh hỏi ngay khi mở app “vì sau này sẽ cần”. Quyết định chính xác màn hình và hành động kích hoạt yêu cầu, cùng một câu bạn sẽ hiển thị trước lời nhắc hệ thống.
Với mỗi hàng trong ma trận, ghi lại:
Kết thúc bằng tiêu chí chấp nhận khớp với test thực tế, không phải ý kiến. Ví dụ: “Nếu quyền camera bị từ chối, người dùng vẫn có thể gửi biểu mẫu không có ảnh và thấy các bước rõ để bật quyền sau.” Hoặc: “Nếu xác thực sinh trắc thất bại ba lần, app sẽ cung cấp PIN/mật khẩu mà không khóa tài khoản.”
Nếu bạn xây trong AppMaster, khóa các quyết định này trước khi kết nối màn hình và logic nghiệp vụ sẽ giảm công việc sửa đổi bởi vì ma trận đã bao phủ UX, quyền và các trường hợp rìa thường xuất hiện muộn.
Tính năng camera trông đơn giản cho đến khi bạn định nghĩa “hoàn tất” nghĩa là gì. Chọn một hành động người dùng chính và thiết kế xoay quanh nó: quét ID, chụp ảnh công trường, hay chọn ảnh từ thư viện. Mỗi lựa chọn thay đổi màn hình, quyền và phạm vi kiểm thử.
Quyết định bao nhiêu quyền kiểm soát người dùng có sau khi chụp. “Chỉ ảnh” dễ phóng nhanh nhất. Khi bạn thêm cắt, xoay, nhiều ảnh hay chú thích, bạn thêm trạng thái: chụp lại, hủy, lưu nháp, và tương thích trên nhiều kích thước màn hình. Nếu cần chỉnh sửa, đặt mức tối thiểu (ví dụ chỉ cho chụp lại và cắt cơ bản) và bỏ qua những thứ khác.
Lưu trữ là một phần của phạm vi, không phải chi tiết triển khai. Nếu ảnh là bằng chứng (bằng chứng giao hàng), tải lên ngay khi có thể và hiển thị tiến trình. Nếu ảnh hỗ trợ bước sau (điền biểu mẫu rồi gửi), lưu tạm trên thiết bị và tải lên khi gửi. Định nghĩa chuyện gì xảy ra nếu tải lên thất bại: xếp hàng chờ gửi lại, hay chặn người dùng đến khi tải lên thành công.
Lên kế hoạch các đường thất bại thường tạo ticket: ánh sáng yếu hoặc ảnh mờ (mẹo + chụp lại), quyền bị từ chối (dự phòng như tải từ thư viện và đường thử lại rõ ràng), hủy giữa lúc chụp (vứt hay lưu nháp), ảnh lớn trên mạng chậm (nén hoặc giới hạn độ phân giải), và chụp bị gián đoạn (chuyển cuộc gọi/app) với phục hồi mượt mà.
Viết ghi chú quyền riêng tư bằng ngôn ngữ đơn giản: bạn chụp gì, có giữ metadata vị trí không, ảnh lưu ở đâu (thiết bị hay cloud), và bạn giữ bao lâu.
GPS trở nên rắc rối khi “sử dụng vị trí” là yêu cầu duy nhất. Bắt đầu với một mục tiêu đơn: kiểm tra một lần (tôi đang ở đâu ngay bây giờ), theo dõi nền (cập nhật khi app đóng), hoặc ghi lộ trình (dấu vết các điểm theo thời gian). Mỗi mục tiêu thay đổi quyền, tiêu hao pin và những gì người phê duyệt mong đợi bạn giải thích.
Mô tả độ chính xác và tần suất cập nhật bằng từ ngữ dễ hiểu. “Ghim công việc trong phạm vi 50 mét” và “cập nhật mỗi 2 phút khi chuyến thăm đang hoạt động” dễ phê duyệt hơn “độ chính xác cao, cập nhật thường xuyên.” Quyết định chuyện gì xảy ra nếu app không lấy được vị trí: chờ, thử lại, hay cho phép người dùng tiếp tục không có vị trí.
Thời điểm yêu cầu quyền quan trọng như tính năng. Hỏi khi mở app thường dẫn đến bị từ chối vì người dùng chưa thấy lợi ích. Hỏi ngay trước hành động (“Thêm vị trí hiện tại vào báo cáo này”) thường hiệu quả hơn. Theo dõi nền khác biệt: chỉ yêu cầu sau khi người dùng bật tính năng rõ ràng cần nó.
Lên kế hoạch các trường hợp rìa: GPS tắt hoặc chế độ máy bay, tín hiệu yếu/hoạt động trong nhà, quyền bị từ chối, vị trí lưu cuối cùng lỗi thời, và bộ tiết kiệm pin hạn chế cập nhật nền.
Giảm lo lắng bằng cách hiển thị khi nào vị trí được sử dụng. Một dòng trạng thái nhỏ như “Vị trí đã được lưu cho chuyến thăm này” hoặc một huy hiệu khi đang theo dõi tạo niềm tin.
Ví dụ: nếu đội dịch vụ hiện trường chỉ cần vị trí check-in khi kỹ thuật viên bắt đầu công việc, hãy định scope là “chụp một lần khi chạm,” lưu cùng lệnh công việc và hiển thị thông báo rõ nếu GPS tắt. Tránh ghi lộ trình trừ khi thực sự cần.
Sinh trắc có thể làm app cảm thấy nhanh và an toàn, nhưng cũng tạo ra cách người dùng bị kẹt. Lập kế hoạch nó như một tính năng an toàn, không chỉ một nút tiện lợi.
Bắt đầu bằng việc quyết định sinh trắc bảo vệ gì. Với hầu hết nhóm, nó hoạt động tốt nhất như bước re-auth nhanh (mở app sau một thời gian timeout) hoặc để xác nhận hành động nhạy cảm như duyệt thanh toán, xuất dữ liệu hoặc thay đổi thông tin ngân hàng. Dùng sinh trắc làm phương thức đăng nhập duy nhất thường dẫn đến bị khóa và ticket hỗ trợ.
Chọn phương án dự phòng phù hợp với mức rủi ro và người dùng. Các tùy chọn phổ biến gồm mật khẩu/mã PIN cho tài khoản thường, mã một lần (SMS/email) cho khôi phục mạnh hơn, magic links cho ít mật khẩu hơn (kèm kiểm soát tài khoản), hoặc khôi phục qua admin cho ứng dụng doanh nghiệp dạng cao.
Làm cho việc đăng ký trở thành tuỳ chọn. Đề nghị sau khi đăng nhập thành công, giải thích lợi ích trong một câu, và cho phép tắt sau này.
Thiết kế cho giới hạn và lỗi thiết bị: không có phần cứng sinh trắc, chưa cài đặt sinh trắc, cảm biến lỗi (ngón tay ướt/không nhận mặt), và OS khóa sau nhiều lần thất bại.
Dùng ngôn ngữ rõ ràng để giảm lo lắng. Nói bạn lưu gì và không lưu gì: bạn không lưu vân tay hay dữ liệu khuôn mặt, bạn chỉ yêu cầu điện thoại xác nhận người dùng.
Tính năng ngoại tuyến thất bại thường vì các nhóm cố “làm mọi thứ ngoại tuyến” mà không định nghĩa “làm việc” là gì. Bắt đầu với mục tiêu ngoại tuyến nhỏ nhất nhưng vẫn hữu ích: chỉ đọc, lưu nháp, hoặc quy trình hoàn chỉnh.
Hình dung người dùng không có tín hiệu trong 30 phút. Họ cần làm gì để hoàn thành nhiệm vụ mà không mất dữ liệu? Một kỹ thuật viên có thể cần danh sách công việc hôm nay (chỉ đọc), khả năng thêm ghi chú và ảnh (lưu nháp), và cách gửi bảng kiểm hoàn thành sau (quy trình một phần).
Chọn chính xác dữ liệu nào sống trên thiết bị và nó giữ trong bao lâu. Cache mọi thứ làm tăng sử dụng lưu trữ và rủi ro quyền riêng tư. Giữ dữ liệu gắn với các màn hình người dùng thực sự cần.
Định trước hành vi đồng bộ trước khi xây màn hình: khi nào đồng bộ (khi mở, khi có Wi‑Fi, khi nhấn thủ công), cách thử lại và chuyện gì xảy ra khi cùng bản ghi thay đổi trên server và trên điện thoại. Nếu bạn không muốn xử lý xung đột phức tạp, tránh chỉnh sửa bản ghi chia sẻ ngoại tuyến. Ưu tiên hành động xếp hàng mà server có thể áp dụng theo thứ tự.
Làm cho ngoại tuyến dễ thấy. Người dùng cần tín hiệu như banner “Ngoại tuyến”, thời gian “Đồng bộ lần cuối”, và số lượng hàng chờ. Lên kế hoạch các trạng thái UI riêng cho chúng (online, offline, syncing, error) để QA có thể kiểm tra đáng tin cậy.
Cuối cùng, viết câu chuyện khôi phục. Nếu người dùng cài lại app, hết dung lượng lưu trữ, hoặc đăng xuất khi hàng đợi đang chờ, app nên giải thích chuyện gì xảy ra tiếp theo và cách tiếp tục an toàn.
Quyền trở thành vấn đề khi chúng có vẻ ngẫu nhiên. Kết nối mỗi quyền với một khoảnh khắc hiển thị rõ ràng cho người dùng. Nếu điều đầu tiên app bạn làm là hỏi Camera, Location và Notifications, nhiều người sẽ chọn "Don't Allow" và khó phục hồi.
Làm cho yêu cầu quyền là một phần của luồng. Hỏi quyền camera chỉ sau khi người dùng chạm “Quét mã” và hiển thị một câu ngắn giải thích lý do: "Chúng tôi dùng camera để quét mã để bạn không phải gõ." Dùng ngôn ngữ đơn giản và cụ thể.
Cũng thiết kế đường vẫn hoạt động khi không có quyền. Một kỹ thuật viên có thể từ chối GPS trên thiết bị dùng chung. Cho họ chế độ nhập tay, danh sách giới hạn, hoặc lựa chọn “nhắc lại sau”.
Giữ các quyết định này trong phạm vi để QA và đánh giá phát hành nhanh hơn:
Bao gồm một bảng chú ý nền tảng nhỏ để không ai nghĩ iOS và Android giống nhau:
| Capability | iOS notes | Android notes |
|---|---|---|
| Camera | Thêm lý do rõ ràng | Xử lý quyền + khả năng “Không hỏi lại” |
| GPS | Ưu tiên “chỉ khi sử dụng” nếu có thể | Theo dõi nền cần xem xét thêm |
| Biometrics | Luôn có dự phòng passcode | Cho phép dự phòng credential của thiết bị |
| Offline storage | Xác định gì được cache và trong bao lâu | Lên kế hoạch dọn dẹp khi lưu trữ thấp |
Nếu bạn xây trong AppMaster, coi quyền là phần thiết kế UX chứ không phải một công tắc. Soạn sẵn các màn hình khi quyền bị từ chối. Đó là nguồn gốc của ticket hỗ trợ.
Hầu hết trì hoãn xảy ra khi tính năng chạy trên điện thoại của bạn, nhưng vỡ trong điều kiện thực: tín hiệu yếu, người dùng mệt mỏi, hoặc người kiểm duyệt quyền riêng tư hỏi “Tại sao bạn cần điều này?” Sửa nhanh nhất thường không phải xây thêm. Mà là định nghĩa các quyết định còn thiếu.
Một chướng ngại phổ biến là yêu cầu quyền ngay khi app mở. Người phê duyệt muốn lý do gắn với một hành động. Nếu người dùng chưa chạm “Quét mã”, lời nhắc camera sẽ khiến họ nghi ngờ. Vị trí cũng tương tự: nếu mục tiêu chỉ là tìm địa chỉ dịch vụ, nhập thủ công hoặc tra cứu một lần có thể đủ.
QA cũng hay bị kẹt ở các luồng chưa hoàn thiện. Tính năng camera thường ra mắt thiếu chụp lại, đường hủy rõ ràng, hoặc thử lại tải lên khi kết nối rớt. Ngoại tuyến là cái bẫy khác: đó không phải công tắc. Nó là tập hợp trạng thái (cái gì hoạt động, cái gì xếp hàng, đồng bộ làm gì, và xung đột xử lý thế nào).
Các khoảng trống phạm vi thường thêm ngày làm việc:
Trước khi hứa camera, GPS, sinh trắc hay ngoại tuyến, chạy một kiểm tra hợp lý. Nó ngăn các bất ngờ như quyền bị từ chối, phương án dự phòng không rõ và các test case QA không ai lên kế hoạch.
Viết mục tiêu người dùng trong một câu cho mỗi tính năng. Nếu bạn không thể nói ai cần nó và vì sao, nó chưa sẵn sàng cho sprint.
Rồi ánh xạ đường tốt và đường dự phòng. Ví dụ: tài xế quét mã (đường tốt). Nếu quyền camera bị từ chối, họ có thể gõ mã thủ công hoặc chọn từ danh sách công việc gần đây (dự phòng). Dự phòng là một phần của tính năng, không phải bổ sung.
Dùng checklist này để cam kết phạm vi:
Một app nhỏ cho kỹ thuật viên hiện trường cho thấy ma trận hoạt động. Mục tiêu rõ ràng: kỹ thuật viên mở công việc, kiểm tra, thêm ảnh và ghi chú, rồi gửi báo cáo cuối. Nhóm văn phòng xem và lên lịch theo dõi.
Đây là một ví dụ ma trận v1 giữ phạm vi rõ ràng và tránh bất ngờ quyền:
| Capability | What we ship in v1 | Permission moment | UX decisions that prevent rework |
|---|---|---|---|
| Camera | Take 1+ photos per job, with retake. Compress before upload. Upload only on Wi-Fi by default (with an override). | Ask only when the user taps "Add photo". | Show a preview, "Retake" and "Use photo". Explain upload rules near the Save button. |
| GPS | Attach one location to a job when the tech taps "Set location". No background tracking. | Ask only when the user taps "Set location". | Provide "Use current location" and "Enter address instead". Store accuracy (for review) but don’t block submission. |
| Biometrics | Re-authenticate with Face ID/Touch ID (or Android equivalent) right before "Submit final report". | No extra OS permission prompt, but user must enable biometrics in the app settings. | Always offer a fallback (PIN/password). If biometrics fails, don’t lock the user out of the job. |
| Offline storage | Save drafts (notes + checklist state) and photos locally. Sync when online. | No permission prompt in most cases. | Show an "Offline" badge and a clear "Syncing..." status. Prevent duplicate submissions. |
Trước khi xây, đồng ý vài kiểm tra pass/fail cho review và QA:
Trong AppMaster, ma trận này ánh xạ trực tiếp tới màn hình (chi tiết công việc, chụp ảnh, luồng gửi), quy tắc nghiệp vụ (khi hỏi, khi đồng bộ) và trường dữ liệu (trạng thái nháp, vị trí, metadata ảnh).
Khi ma trận đã được điền, chuyển mỗi ô thành thứ mà đội có thể xây và kiểm thử. Biến nó thành user story với tiêu chí chấp nhận, để không ai tranh cãi sau này về “ngoại tuyến” hay “GPS” nghĩa là gì.
Viết các story xoay quanh kết quả, không phải cảm biến. Ví dụ: "Là một kỹ thuật viên, tôi có thể đính kèm tối đa 3 ảnh vào công việc, và nếu tôi từ chối truy cập camera tôi vẫn có thể tải lên từ thư viện." Rồi thêm tiêu chí cho quyền, trạng thái lỗi và đường dự phòng.
Giữ kế hoạch xây nhỏ có mục đích. Chọn một lát tính năng mỏng (một màn hình, một luồng, một khả năng), thử trên thiết bị thực, rồi mở rộng dựa trên những gì học được. Phát hành camera + ngoại tuyến + GPS cùng lúc sẽ nhân lên rủi ro QA và phê duyệt.
Nếu bạn quyết định triển khai bằng AppMaster, cùng ma trận có thể đồng thời là checklist xây dựng: quyết định mô hình dữ liệu trong Data Designer, logic xử lý ngoại lệ trong Business Process Editor, và các trạng thái UI rõ ràng trong mobile UI builder. Điều này giữ phạm vi, UX và kiểm thử đồng bộ khi yêu cầu thay đổi.
What is a feature planning matrix, and why use it for mobile features?Ma trận lập kế hoạch tính năng là một bảng một trang buộc phải đưa ra các quyết định rõ ràng trước khi xây dựng. Nó biến “thêm GPS” hay “hỗ trợ ngoại tuyến” thành phạm vi có thể kiểm thử bằng cách nắm bắt mục tiêu người dùng, luồng hoạt động, thời điểm yêu cầu quyền, các đường thất bại và kiểm tra QA cơ bản.
What’s the fastest way to fill out the matrix without writing a full spec?Bắt đầu với một câu mô tả công việc của người dùng, rồi viết luồng hành trình đơn giản nhất để hoàn thành công việc đó. Thêm chính xác khi nào bạn sẽ yêu cầu quyền, chuyện gì xảy ra khi từ chối, dữ liệu nào lưu trên thiết bị, và 3–5 trường hợp lỗi mà QA có thể tái tạo nhanh.
When should my app request camera or location permission?Hỏi ngay trước hành động rõ ràng cần tới nó, ví dụ khi người dùng chạm “Thêm ảnh” hoặc “Đặt vị trí”. Kết hợp một câu giải thích trong app để lời nhắc hệ thống không có vẻ ngẫu nhiên, và luôn có đường thay thế nếu người dùng từ chối.
What counts as a “fallback path” that reviewers and QA will accept?Một fallback tốt vẫn cho phép người dùng hoàn tất nhiệm vụ, dù ít tiện hơn. Ví dụ: nhập tay thay vì quét, chọn địa chỉ thay vì GPS, hoặc dùng PIN/mật khẩu thay cho sinh trắc, kèm hướng dẫn rõ để thử lại sau.
What camera decisions usually cause last-minute rework?Quyết định rõ “hoàn tất” nghĩa là gì: chụp ảnh mới, chọn từ thư viện hay quét tài liệu; đừng trộn nhiều mục tiêu trong phiên bản đầu. Định nghĩa lại hành vi retake/cancel, thời điểm tải lên (ngay lập tức hay khi gửi), và xử lý khi tải lên thất bại để người dùng không mất dữ liệu.
How do I avoid over-scoping GPS and getting stuck in reviews?Cụ thể liệu bạn cần đánh dấu vị trí một lần, theo dõi nền hay ghi lại lộ trình. Hầu hết ứng dụng doanh nghiệp chỉ cần “chụp một lần khi chạm”, giảm gánh nặng quyền, tiêu hao pin và các câu hỏi phê duyệt.
What’s the safest way to add Face ID/Touch ID without locking users out?Xem sinh trắc học như lớp tiện lợi, không phải là cách duy nhất để vào. Làm cho nó tùy chọn sau khi đăng nhập, dùng cho re-auth nhanh hoặc hành động nhạy cảm, và luôn có phương án dự phòng như mật khẩu hoặc PIN để người dùng không bị khóa.
How do we scope offline mode so it’s useful but not a huge project?Chọn mục tiêu ngoại tuyến tối thiểu như xem chỉ đọc hoặc lưu nháp, rồi xác định dữ liệu nào lưu cục bộ và trong bao lâu. Quyết định khi nào đồng bộ chạy, cách thử lại và cách tránh gửi trùng khi mạng trở lại.
What should acceptance criteria look like for these native capabilities?Viết tiêu chí chấp nhận quanh hành vi có thể quan sát được, không phải ý định. Bao gồm ít nhất một kiểm tra pass/fail cho quyền bị từ chối, phần cứng thiếu, kết nối kém và khôi phục sau khi khởi động lại app, để QA có thể xác minh cùng một quy tắc mỗi lần.
How does AppMaster help implement this matrix without creating tech debt?Dùng ma trận để ánh xạ mỗi khả năng tới màn hình, trường dữ liệu và logic xử lý ngoại lệ trước khi nối bất cứ thứ gì. Trong AppMaster, điều này thường có nghĩa là định nghĩa dữ liệu trong Data Designer, xử lý luồng quyền và lỗi trong Business Process Editor, và xây dựng các trạng thái UI rõ ràng trong mobile UI builder để thay đổi phạm vi không tạo ra các bản vá lộn xộn.
21 thg 1, 2026
8 phút
20 thg 1, 20268 phút
20 thg 1, 20268 phútThử nghiệm với AppMaster với gói miễn phí.
Khi bạn sẵn sàng, bạn có thể chọn đăng ký phù hợp.
