Hỗ trợ đa màn hình trong lập trình Android.

Tham khảo:

https://developer.android.com/guide/practices/screens_support.html

http://www.survivingwithandroid.com/2012/07/how-to-support-multiple-screen-in.html

http://www.techotopia.com/index.php/Handling_Different_Android_Devices_and_Displays

https://www.quora.com/Is-there-any-good-tutorial-on-how-to-support-multiple-screen-layouts-for-Android-Development

Tìm hiểu về thư viện network Retrofit (Phần 1)

Retrofit là một network library mới nổi của Square ( khoảng vài năm…) và thường được so sánh với thư viện Volley của Google.
Retrofit là gì ?
A type-safe REST client for Android and Java.
Ko biết diễn giải ra tiếng việt như thế nào, nhưng cứ hiểu nó tương đương với Volley là được rồi. (Mặc dù đi sâu vào so sánh thì hai thư viện này có những mục đích và chức năng khác nhau. Tuy nhiên chưa cần quan tâm đến bây giờ)
Retrofit đã ra đến phiên bản > 2. và khá ổn định. Trước đó có một phiên bản ổn định và được biết tới nhiều là 1.9. Chúng ta sẽ nghiên cứu >2.0 thôi vì còn học cái cũ làm gì.
Để sử dụng Retrofit, ta khai báo trong gradle.

Ở các phiên bản trước, khi khai báo thì retrofit & OkHttp được khai báo như hai module riêng rẽ, tuy nhiên đến 2.0 trở đi thì mặc định retrofit dùng OkHttp làm tầng network (Network Layer) và xây dựng trên nó rồi.
Vì vậy khai báo chung là như một.
(Retrofit chỉ dùng OkHttp để làm tầng network, còn Volley thì linh động hơn, có thể dùng được OkHttp, Appache, v.vv.)
Ngoài ra đi kèm retrofit cung cấp cả gson converter như là một Convert Factory của nỏ.
(Gson là định dạng phổ biến hiện nay nên khai báo thế. Nếu muốn dùng XML thì cũng có thể khai báo XML converter)
Phần khai báo thư viện đã xong. Tiếp theo dùng Retrofit như thế nào.
Ta sẽ tìm hiểu một khái niệm cơ bản & cốt lõi đó là Service Generator. Mục đích của thằng này là để tạo ra một Adapter REST cơ bản cho class/interface của chúng ta.
Code như sau:
Phân tích đoạn code: chúng ta sẽ khai báo base Url của api.
Sau đó tạo ra một OkHttp client.
Sau đó tạo ra một Builder của retrofit sử dụng base url và network layer là Okhttp vừa khởi tạo.
Sau đó sử dụng builder để tạo ra service cho lớp/interface cần tạo.
“Lớp/interface cần tạo” được nhắc đến ở đây là gì ?
Các interface này là những khai báo về method call api. Trong file này chúng ta sẽ khai báo các api với thông tin như: phương thức call api (GET, POST), tham số truyền vào, kiểu truyền vào, giá trị trả về.
(Contributor là một class dữ liệu )
Khi sử dụng, chúng ta sẽ dùng như sau:
Trong đoạn code trên có thể thấy được vai trò của Service Generator. Interface GitHubClient lúc đầu chỉ là một class khai báo các phương thức. Nhờ có Service Generato mà nó mới trở thành một Http client.
Tạm thời tìm hiểu qua về cách sử dụng Retrofit là như vậy. Ở những bài tiếp theo của serrie retrofit sẽ trình bày các vấn đề sau:
– Cách  truyền tham số vào một API Retrofit.
– Call api Retrofit đồng bộ & bắt đồng bộ.
– So sánh Volley & Retrofit.

Pokemon – Một thời tuổi thơ.

Pokemon đã trở thành một phần tuổi thơ tôi. Chính vì vậy, khi pokemon xuất hiện trên game, tôi đã trở thành một fan, khá là cuồng nhiệt của game.

Những ngày đầu game mới ra lúc đi ăn trưa mắt mũi lúc nào cũng cắm cúi vào nhìn xem có con pokemon nào xuất hiện không, rồi đi vòng vòng qua các điểm pokestop để lấy bóng nữa chứ. Rồi xuất hiện trên màn hình những bulbasaour, quirtle, pikachu, chamande càng làm tôi cảm thấy thú vị.

Hồi xưa, hồi còn cấp 2, tôi và thằng bạn thân, thằng Hùng cùng với thằng em nó có một bộ sưu tập các con giống Pokemon, rồi chúng nó sáng tạo ra trò chơi như chơi cờ ấy, nhìn chung rất là vui. Tôi còn tiết kiệm tiền để đi mua những con giống nữa chứ. Bây giờ chẳng biết ở đâu bán, nếu mà có khéo bán bộn tiền ấy chứ.

Bây giờ vẫn thế, vẫn có những người bạn có cùng đam mê. Ví dụ như thằng em cùng công ty. Đến trưa lúc đi ăn hai anh em vịn vào vai một ông đi cùng để tránh tai nạn các kiểu. Rồi ăn xong hai anh em đi một vòng quanh công ty để lấy bóng.

Rồi ông anh ở cùng công ty cũ, lúc game mới ra, hai anh em cùng nhau ra công viên đi lòng vòng để bắt pokemon, rồi cuối tuần cùng nhau lên hồ Hoàn Kiếm ngồi bắt pokemon. Vui vl.

Mà cái game này cũng mang con người đến với nhau phết. Lúc ở Hoàn Kiếm, rất đông các a e pokemon ngồi ở cùng một chỗ, rồi thỉnh thoảng lại có thằng hô lên: psyduck ,squirtle … (tôi.) Thế rồi cứ dần dà bắt chuyện chia sẻ kinh nghiệm, bàn chuyện tếu, đến là vui.

Có bữa chở bạn gái đi thi, t quay về điểm pokestop thả thính quen thuộc bắt pokemon thì làm quen với một ông anh bỏ làm đi bắt pokemon, cả một ông anh cho cả con gái đi cùng (bố ơi mình đi đâu thế ? :D)

Ôi, tuổi thơ tôi.

Đây là hình ảnh của allen đứng bên cạnh những chú pokemon yêu thích.

Allen with Rồng điên. Kích thước có vẻ hơi bé nên dù có điên cũng ko đáng sợ mấy.

 

Allen with nòng nọc tiến hóa. Con này to vãi.

 

Allen chuẩn bị cưỡi Chó lửa

Nguyên tắc lập trình SOLID

solid-object-oriented-design

  • Single Responsibility principle: một class chỉ giữ một trách nhiệm duy nhất. Chỉ có thể thay đổi class vì một lí do duy nhất. Nếu bạn ko thể diễn đạt trong một câu, trách nhiệm của class là gì ? 95% là bạn thiết kế tồi.
  • Open/Close principle: có thể thoải mái mở rộng một module, nhưng hạn chế sửa đổi trong module đó.
  • Liskov Substitution principle: trong một CT, các object của class con có thể thay thế class cha mà không làm thay đổi tính đúng đắn của chương trình. Điều này có nghĩa là gì: là class con phải bao hàm đầy đủ tất cả các tính chất của class cha. Lấy ví dụ như một thiết kế: Class VitBau, Vitxiem extend từ class Vit, class VitChayPin cũng có các tính chất như bơi, kêu quác quác, tuy nhiên nó có một tính chất mà ko đáp ứng được với class cha: đó là phải ăn mới sống được. Nghĩa là khi thiết kế object ta cần quan tâm đến tính chất cần sử dụng của class.
  • Interface Segregation Principle: Thay vì dùng một interface lớn thì tách thành nhiều interface nhỏ, với mục đích cụ thể. (Nếu nguyên tắc đầu tiên được áp dụng tốt, nguyên tắc này cũng sẽ tốt theo)
  • Dependency inversion principle: các module cấp cao ko nên phụ thuộc vào module cấp thấp, cả hai nên phụ thuộc vào abtraction / interface. Interface ko nên phụ thuộc vào chi tiết, mà ngược lại chi tiết nên phụ thuộc vào interface.

SOLID please !

Giảm kích thước của apk file

Áp dụng những cách sau, bạn có thể giảm kích thước file apk một cách đáng kể.

  1. Config Gradle
1
2
3
4
5
6
7
8
9
10
buildTypes {
        release {
            shrinkResources true  // get rid of unused resource
            minifyEnabled true  // enlable Proguard, remove unused code
            proguardFiles getDefaultProguardFile(‘proguard-android-optimize.txt’),’proguard-project.txt’
            signingConfig signingConfigs.config
        }
    }
– Sử dụng các định dạng ảnh khác thay vì PNG. Ví dụ JPEG hoặc Vector Drawable khi có thể. (source)
– Xem xét việc sử dụng các thư viện. Không nên dùng một thư viện quá lớn chỉ để đáp ứng một nhu cầu nhỏ
– Chia nhỏ APK (source)

Một số cách để áp dụng Crashlytics (Fabric) hiệu quả

Crashlytics / Fabric là công cụ rất mạnh mẽ để quản lý crash. Sau đây là một số cách để tận dụng hiệu quả thêm cho công cụ này.
Tip #1. Kiểm tra xem code lỗi ở version nào.
Đây là cách để thêm vào log của crashlytics phiên bản git & ngày build để có thể xem lại code khi bug xảy ra.
Image3
Sau đó khi setup AL ở Application.
Image4
Sau này, khi kiểm tra lỗi bạn có thể xem ở trên trang quản lý fabric
Image5
Tip #2: log lại những sự kiện ko phải là chí mạng (ko crash)
Khi lập trình, bạn nên log lại những tình huống mà app đi vào trạng thái ko mong đợi, ngay kể cả khi nó ko gây crash.
Đó có thể là lỗi do network data trả về ko như mong đợi, có thể là hiểu nhầm requirements hoặc do logic code có vấn đề.
Khi đó bạn có thể ném ra exceptions để có thể fail faster.
Tuy nhiên, như thế app release bị crash thì ko tốt.  Đoạn code sau sẽ giải quyết được vấn đề:
Image6
Tip# 3: để lại breadcum. Hiểu như là để lại dấu vết trên đường đi.
Để tránh các trường hợp gặp lỗi mà ko biết tái hiện như thế nào, ta sẽ dùng cách để lại breadcum để có thể thêm một chút ít thông tin phòng khi gặp lỗi, sử dụng làm Crashlytics.log (String mes)
Image7
Một lập trình viên “hay” ko chỉ nhìn thấy code chạy được là xong. Một code “hay” phải tính trc nhiều bước, đề phòng các trường hợp xảy ra.
Và phải chấp nhận một điều rằng: code mình còn tồn tại bug, vì vậy phải có cách để khi các bug xảy ra thì còn cách ứng phó.
Cảm ơn tới Fabric / Crashlytics.
//Todo: tìm hiểu một công cụ khác để tích hợp với CL: Timber

Hiểu về Android State List

StateListDrawable – xml – represent for a view in different state
Element :
<selector>
     <item></item>
     <item></item>
</selector>
Example:
<?xml version=”1.0″ encoding=”utf-8″?><selector xmlns:android=”http://schemas.android.com/apk/res/android”&gt;
<item android:drawable=”@drawable/pressed”
android:state_pressed=”true” />
<item android:drawable=”@drawable/focused”
android:state_focused=”true” />
<item android:drawable=”@drawable/normal” /></selector>
With resource:
Image
Image2
State Understand:
– state_pressed: true nếu đối được được nhấn vào (touch/click), false khi ở trạng thái bình thường, ko bấm
– state_focused: true khi đối tượng đc tập trung. Ví dụ như khi đối tượng đc di chuyển đến bằng bàn phím <- -> …
– state_selected: true khi đối tượng ở trạng thái selected, false khi ko đc select
– state_checkable: true khi object ở trạng thái checkalbe, false khi ngược lại
– state_checked: các trạng thái đã check & chưa check
– state_enabled: các trạng thái enabled/disabled  (có khả năng nhận được các sự kiện touch/click)
– state_window_focused: khi mà window ở trạng thái có focus, một ví dụ của việc ko có focus là: khi có cái dialog nó hiển thị lên trên bề mặt.
– state_hovered: