Tại sao bạn nên biết những lỗi thường gặp khi lập trình android để tránh nó kịp thời? Rất nhiều chuyên gia ở các lĩnh vực khác nhau (kể cả chuyên gia phát triển Android) đều cho rằng:
Những bài đăng của mình từ trước tới nay thường nói về cách phát triển một ứng dụng, một task vụ cụ thể nào đó trên Android.
Tuy nhiên, mình vẫn cảm thấy có gì đó thiếu sót khi không nhắc đến những sai lầm mà rất nhiều các bạn developer mắc phải.
Nội dung chính của bài viết
5 lỗi thường gặp khi lập trình Android nên tráng
Bài viết này mình sẽ liệt kê 5 lỗi thường gặp nhất mà mình nghĩ các bạn Android developer nên tránh.
#1. Không sử dụng strings.xml
Điều này sẽ làm giảm trải nghiệm quốc tế hóa của ứng dụng. Vì bạn sẽ phải tự thiết kế phiên bản hiển thị chính xác của message dựa trên ngôn ngữ của người dùng.
Nếu như các String được đặt trong file strings.xml, chúng có thể dễ dàng được dịch và tích hợp vào ứng dụng.
Điều tuyệt vời là Android sẽ căn cứ vào thiết lập ngôn ngữ hệ thống để tự động chuyển sang file string.xml đúng với ngôn ngữ đó.
Những lý do biện minh cho việc bạn không dùng string-resources?
Dưới đây là một số lý do mà các bạn phát triển Android đưa ra để “viện cớ” không dùng string-resources:
Lý do 1: “Tôi chỉ dùng nó mỗi ở đây thôi”
Bây giờ thì bạn nghĩ thế, nhưng ai biết trước đươc tương lai. Sau này, bạn cần phải sử dụng lại String đó ở một nơi khác thì sao? Bạn có có chắc chắn là chỉ sử dụng ở mỗi đó thôi không?
Vì vậy, bạn nên đầu tư thêm một phút để sau này có thể dễ dàng tái sử dụng.
Lý do 2: String phức tạp và cần cập nhật liên tục
Đừng lo! Android đã hỗ trợ sẵn cho bạn có thể làm được điều đó trong String.xml file. Bạn hoàn toàn có thể cập nhật String thông qua các tham số truyền vào String. Ví dụ:
<string name="timeFormat">%1$d minutes ago</string>
Tham khảo tài liệu official của chính chủ Google tại đây.
Lý do 3: “Ứng dụng của tôi chỉ hỗ trợ một ngôn ngữ”
Thông thường, với các nhà phát triển độc lập (nhà phát triển phần mềm không phải là công ty) thường chỉ có kế hoạch cho một thị trường nào đó hoặc một ngôn ngữ nào đó, để giảm chi phí.
Nhưng hãy nghĩ lớn một chút, với thị trường rộng lớn ngoài kia. Khi ứng dụng phát triển, việc chuyển ứng dụng sang hỗ trợ thị trường mới sẽ đỡ tốn kém hơn rất nhiều nếu bạn sử dụng String.xml.
#2. Không sử dụng data-binding
Bạn có hay sử dụng hàm findViewById để tạo reference đến các View không?
Ngoài ra, trong trường hợp chúng ta cũng cần giữ view-id để đảm bảo chúng ta đang sử dụng đúng view-id nào trong findViewById.
Tất nhiên, việc này thì Android Studio có thể hỗ trợ bạn tự động, nhưng chỉ những view-id nào có sẵn trong cùng layout-tree thì mới được tìm thấy bằng findViewById. Những thứ không tồn tại sẽ trả về null (có thể gây ra một NullPointerException).
Google đã có giải pháp để tích hợp data-binding vào bất kỳ ứng dụng (mới hoặc dự án cũ) và loại bỏ tất cả view-reference mà bạn đã viết trước đó.
Một vài lợi ích của việc sử dụng data-binding :
- Chỉ references đến những view có sẵn (điều này sẽ giúp bạn tránh được lỗi NullPointerException khi cố reference đến một view không tồn tại).
- Có hiệu năng tốt hơn so với việc sử dụng
findViewById. Bởi data-binding sẽ duyệt toàn bộ layout-tree một lần thay vì luôn duyệt layout-tree khi hàmfindViewByIdđược gọi. - Namespace của bạn (hay nói cách khác là các Class/Function) vẫn “clean”, và bạn không phải giữ reference đến tất cả các views.
Ngoài ra, bạn sẽ có thêm một số tính năng hay ho trong data-binding không chỉ có mỗi loại bỏ findViewById. Như ở bài viết này tác giả George Mount đã viết một Adapter cho tất cả các RecyclerView – quá kinh! 👾
💦 Bạn nên đọc thêm về Data Binding tại đây: Hướng dẫn sử dụng Data Binding trong Android
#3. Không ẩn API keys khi sử dụng Git
Đây là lỗi khá phổ biến và chủ yếu là do các bạn developer còn ít kinh nghiệm chưa chú ý.
Với dự án được quản lý bằng SVN hay Git, khi bạn đã từng commit một version lên server thì nó sẽ tồn tại trên đó mãi.
Người ta có thể tra lại lịch sử commit và mò ra API key đó, kể cả bạn đã xóa cái API key trong một commit sau đó.
Bạn có thể xem bài viết này để tìm hiểu cách ẩn API key khỏi repository trong khi vẫn sử dụng chúng trong quá trình build test ứng dụng mà chúng vẫn available trong source code của bạn.
🔥 Có ích cho bạn: Những kinh nghiệm viết code dễ đọc và dễ bảo trì
#4. Không xử lý hết các trạng thái vòng đời của Activity
Tất cả các cấu hình (configuration) hay logic của Activty hiện tại sẽ bị mất khi Activity bị destroyed hay re-created.
Để đảm bảo rằng quá trình transition liền mạch, chúng ta cần lưu trữ trạng thái của ứng dụng trước khi thay đổi configuration.
Sau đó, chúng ta có thể tái tạo lại trạng thái của ứng dụng thông qua các hàm onSaveInstanceState/ onRestoreInstanceState.
Đừng để ứng dụng crash hay restart lại chỉ vì người dùng xoay ngang màn hình điện thoại nhé 😛
#5. Không tìm hiểu các phím tắt trong Android Studio
Điều này có thể không phản ánh chất lượng đoạn mã bạn viết. Nhưng nó ảnh hưởng đến tổng quan công việc của bạn.
Android Studio được xây dựng dựa trên IntelliJ Idea (một IDE nổi tiếng về tính thân thiện với bàn phím). Điều này có nghĩa rằng, năng suất của developer có thể tăng lên bằng cách rất đơn giản. Đó là đầu tư một chút thời gian vào việc học các phím tắt.
Dưới đây là một số tài nguyên giúp bạn học/thực hành các phím tắt trên Android Studio:
- KeyPromoter: Đây là một plugin có sẵn trong Android Studio. Nó sẽ hiển thị một hộp thoại hiển thị các lệnh phím tắt cho hành động bạn vừa thực hiện.
Hãy tin mình đi, điều này sẽ làm bạn khó chịu và bạn buộc phải học những lối tắt đó. Bạn có thể tìm và tải xuống trong Android Studio settings.
- Cheat-sheet : Các bạn có thể download về và in ra cho dễ tra cứu. Đây là bản tổng hợp tất cả các phím tắt của Android Studio cho cả 2 nền tảng Window, MacOS.
- Hướng dẫn chính thức từ Jetbrains – Đây là hướng dẫn chính thức được cung cấp bởi Jetbrains giúp làm chủ các phím tắt.
#Tạm kết
Đây là 5 lỗi thường gặp khi lập trình Android mà bạn nên hạn chế mắc phải. Đừng để những sai lầm làm hỏng cả dự án.
Nếu bạn có bất kỳ đề xuất hoặc bất kỳ chủ đề nào khác, hãy comment bên dưới nhé. Đừng ngại 🔥
Bình luận. Cùng nhau thảo luận nhé!