CIPPO

Trong thời gian tham gia CIPPO, tôi làm việc trên nhiều phần của ứng dụng Android: khu vực điều hướng chính, đăng tin/quảng cáo doanh nghiệp và trang chi tiết, khu vực hội viên/phúc lợi, tính năng coupon và magazine, Google Play Billing cho mua hàng trong ứng dụng, thông báo đẩy, chat trong ứng dụng, bản đồ, và tính năng thông tin thu gom rác, cùng với công việc liên tục ở lớp dữ liệu và cấu hình dependency injection thủ công của ứng dụng.

1. Thách thức kỹ thuật

   Hai điểm nổi bật. Thứ nhất, CIPPO tự xây dựng cơ chế dependency injection thủ công (không dùng Hilt/Dagger/Koin) — một class factory duy nhất khởi tạo 196 ViewModel, và việc mở rộng nó an toàn khi thêm tính năng mới đòi hỏi hiểu và duy trì đúng cách làm đó thay vì đi vòng qua nó. Thứ hai, ứng dụng kết hợp một REST API (Retrofit) với nhiều dịch vụ Firebase (Realtime Database, Firestore, Auth, Storage, Messaging) trên một tập tính năng lớn và liên tục phát triển, việc giữ dữ liệu nhất quán trên backend kết hợp này khi xây dựng tính năng mới là một mối quan tâm thường trực.

   Cách tôi tiếp cận

   Với dependency injection, các tính năng mới được kết nối vào pattern factory thủ công hiện có một cách nhất quán, thay vì đưa thêm một cách tiếp cận DI thứ hai không tương thích vào một ứng dụng đã lớn. Với backend kết hợp, các tính năng được xây dựng để đi qua các lớp trừu tượng nguồn dữ liệu sẵn có của ứng dụng (REST hay Firebase tuỳ tính năng), để phần còn lại của ứng dụng không cần biết tính năng đó dùng backend nào bên dưới.

Dự án này thể hiện việc đảm nhận liên tục, lâu dài một ứng dụng Android thực tế đang hoạt động — làm việc trên điều hướng, thương mại (đăng tin, coupon, billing), giao tiếp (chat, thông báo đẩy), và thông tin công dân, tất cả trong một kiến trúc cũ nhưng vẫn được duy trì tích cực (DI thủ công, RxJava2, backend kết hợp REST+Firebase) trong hơn ba năm.

• Phát triển Android
• Tích hợp bên thứ ba
• Bản đồ & Vị trí
• Bảo trì hệ thống hiện có
• Gỡ lỗi hệ thống thực tế