J2TeaM là gì? Giới thiệu về J2TeaM và J2TeaM Community

Bài viết này sẽ giúp bạn giải đáp một số thắc mắc như "J2TeaM là gì?", "Tại sao gọi là J2TeaM mà không phải J3TeaM hay J4TeaM?", "J2TeaM có bao nhiêu thành viên?", blah...blah...
Read More

Read More

Những extension bảo mật cho Chrome mà mình khuyên dùng

Trong bài viết này, mình sẽ liệt kê ra những extension giúp tăng cường bảo mật cho trình duyệt Chrome mà mình đang sử dụng và khuyên dùng.
Read More

Read More

Cùng đọc và ngẫm với những hình ảnh chứa câu nói dưới đây

Mỗi người trong chúng ta đều có những suy nghĩ, chính kiến của riêng mình. Và những suy nghĩ đúng đắn, được nhiều người cảm nhận tốt ấy thường có sức lan tỏa. Để có được điều đó, hầu hết đều phải qua những trải nghiệm trong cuộc sống đời thường, trong kinh doanh hoặc trong những hoàn cảnh đặc biệt.

Có thể bạn muốn xem thêm: Cảm nhận những dòng chữ ý nghĩa đời thường

Chúng ta cùng chia sẻ và cảm nhận những hình ảnh dưới đây và hãy lưu lại cho riêng mình một câu nói mà bạn cảm thấy đồng cảm nhất với bạn

Cùng đọc và ngẫm với những hình ảnh chứa câu nói dưới đây {P1}

Đừng sống cùng một năm đến 75 lần và gọi đó là cuộc đời

chi tiết

Read More

Tại sao chúng ta lại sử dụng fitsSystemWindow trong Android?

Chào các bạn!

Hôm nay nhân dịp đang làm task về "immersive fullscreen mode" trong công ty, mình xin viết một bài chia sẻ về một thuộc tính khá liên quan. Đó là fitsSystemWindow.

Tại sao chúng ta lại sử dụng fitsSystemWindow?

System windows (system bars) là một phần của màn hình, nơi hệ thống Android vẽ ra những View không-thể-tương-tác (trong trường hợp của StatusBar) hay là những View có-thể-tương-tác-được (như là Toolbar, NavigationBar).

Trong Android Developers Docs ghi rằng:
 - android:fitsSystemWindow là một thuộc tính nội bộ kiểu boolean để điều chỉnh view layout dựa theo System windows (như là StatusBar,..). Nếu nó được set là true, Android sẽ tự động điều chỉnh lại paddding của View đó sao cho nó chừa đủ khoảng trống dành cho các System windows. Tuy nhiên nó chỉ có tác dụng đối với các view không phải là embeded-Activity. (Là các Activity đươc host ngay trong một Activity khác, ví dụ như TabHost/TabActivity. Trong thực tế các embeded-Activity tồn tại ở LocalActivityManager của Activity mẹ, giống như FragmentManager cho phép bạn hiển thị một Activity này trong một Activity khác.). Bởi vì chúng bị giới hạn bởi diện tích được cấp bởi Activity mẹ).

Toolbar bị vẽ dưới StatusBar

Đa phần thời gian, ứng dụng của bạn sẽ không cần phải được vẽ ở dưới StatusBar hay NavigationBar, tuy nhiên nếu bạn muốn: bạn cần phải chắc chắn rằng những thành phần giao diện mà có-thể-tương-tác-được (như Button, EditText,..) không bị "ẩn" bên dưới các System windows. Đó cũng là hành vi (behaviour) mặc định mà thuộc tính android:fitsSystemWindows=“true” cung cấp cho bạn: và như mình đã trích dẫn ở trên, nó set lại padding của View để đảm bảo nội dung không bị che bởi các System windows.

Một số thứ cần lưu ý:

• fitsSystemWindows được áp dụng theo chiều sâu dạng "deep first" - có quan trọng thứ tự: View đầu tiên nhận được insets sẽ thay đổi.
• Insets (viền) luôn quan hệ và tỉ lệ với toàn cửa sổ trên màn hình: insets có thể được áp dụng ngay cả trước quá trình parse và tạo layout được diễn ra. Vậy nên đừng nghĩ rằng hệ thống Android có chút ít thông tin gì về vị trí của View khi dựa vào thuộc tính fitsSystemWindows để thiết lập padding cho View đó.
• Và dĩ nhiên, vì nó không có chút thông tin gì nên mọi padding khác mà bạn set cho View đó đều bị ghi đè (overwritten): bạn hãy chú ý rằng mọi thuộc tính như paddingLeft/padding/paddingBottom đều bị ghi đè và không còn hiệu lực khi bạn áp dụng android:fitsSystemWindow = "true".

Và, trong nhiều trường hợp, như là một trình phát video full screen, bạn cần một View full màn hình, không có thuộc tính, và một ViewGroup mang thuộc tính android:fitsSystemWindow = "true" để chứa View full màn hình mà bạn cần thiết lập insets.

Hoặc có thể bạn muốn RecyclerView của mình scroll xuống và vẽ ẩn bên dưới thanh NavigationBar, đồng thời biến màu nền của NavigationBar thành trong suốt - bằng cách sử dụng thuộc tính android:fitsSystemWindow = "true" kết hợp với android:clipToPadding = "false". Các nội dung bên trong RecyclerView của bạn sẽ nằm bên dưới NavigationBar, tuy nhiên nếu bạn scroll xuống đến cuối cùng thì thấy item cuối của RecyclerView vẫn được thiết lập padding bottom và nằm phía trên NavigationBar (còn tốt hơn là nó bị che khuất và ẩn bên dưới nhiều nhỉ :D)


Tùy biến fitsSystemWindows

Ở phiên bản Android KitKat hoặc thấp hơn, một custom View của bạn có thể override lại hàm fitsSystemWindows(Rect insets) và thay vào đó bất kì phương thức nào bạn muốn, chỉ việc return true; nếu bạn muốn "nuốt" (consume) những viền insets hoặc false nếu bạn muốn cho những View khác một cơ hội "chạm tay vào điều ước" :D

Tuy nhiên, kể từ phiên bản Android Lollipop, Google cung cấp thêm một số APIs mới để cho việc tùy biến tính năng này dễ dàng hơn và phù hợp hơn với các hành vi, tính năng hiện có khác của View. Thay vì như ở trên, bạn sẽ override onApplyWindowInsets() thứ sẽ cho phép View có thể tùy biến giữ lấy bao nhiêu phần viền insets tùy ý, ngoài ra bạn còn có thể gọi hàm dispatchWindowInsets() lên các View con khi cần thiết.

Và tốt hơn cả là bạn sẽ không phải đau đầu hay hack não khi phải subclass những Views của mình để custom các hành vi cho Views như trên ở các phiên bản Android Lollipop hoặc cao hơn. Bạn có thể dùng ViewCompat.setOnApplyWindowInsetsListener(), thứ có thể cho tham chiếu đến onApplyWindowInsets() của View. ViewCompat còn cung cấp các hàm helper để gọi onApplyWindowInsets() và dispatchWindowInsets() mà không cần kiểm tra version.


Các ví dụ về tùy biến fitsSystemWindows

Trong khi các layouts cơ bản (FrameLayout, RelativeLayout, LinearLayout,..) đang sử dụng hành vi mặc định của mình, thì có rất nhiều layouts khác đã tùy biến sẵn những hành vi mà nó thực hiện khi gặp fitsSystemWindows(), nhờ đó có thể đáp ứng được một số trường hợp usecase cụ thể.

Một ví dụ điển hình ở đây là navigation drawer, thứ cần phải phủ ra cả màn hình, và được vẽ dưới một StatusBar có màu nền trong suốt. 

Ở đây DrawerLayout sử dụng thuộc tính fitsSystemWindows() như là một dấu hiệu rằng nó muốn dịch chuyển viền của những View con (như là main content view), nhưng vẫn vẽ StatusBar bình thường với màu nền được định sẵn trong colorPrimaryDark của theme, nhằm tuân theo qui tắc của Material design.

Nếu bạn chú ý một chút có thể thấy rằng trên các thiết bị chạy Android Lollipop trở lên,  DrawerLayout luôn gọi hàm dispatchApplyWindowsInsets() cho từng View con mà nó chứa, qua đó cho phép những View con đó cũng có thể nhận fitsSystemWindows, khác với hành vi mặc định của nó trên các phiển bản trước (là đơn giản "nuốt" những viền insets đó, và những View con của nó không bao giờ có thể chạm tới fitsSystemWindows).

CoordinatorLayout cũng được cải tiến và có thể override cái cách mà nó "xử lý" những viền window insets - cho phép những hành vi được thiết lập ở những View con có thể đánh chặn (intercept) và thay đổi cách thức mà chúng hành động khi gặp window insets - trước khi gọi hàm dispatchApplyWindowInsets() lên mỗi View con. Nó cũng sử dụng thuộc tính fitsSystemWindows như là một biến cờ (flag) để xác định cách thức mà nó sẽ vẽ màu nền của StatusBar.

Tương tự, CollapsingToolbarLayout tìm fitsSystemWindows trong các thuộc tính của nó để quyết định vẽ content scrim - là những gì được vẽ chồng lên khoảng trống của StatusBar và Toolbar khi CollapsingToolbarLayout được scroll dài ra phủ xuống màn hình.

Nếu bạn vẫn hứng xem những trường hợp phổ biến liên quan đến Design Library, hãy thử nhìn qua ứng dụng mẫu cheesesquare sau.


Sử dụng hệ thống Android, đừng chống lại nó!

Một thứ cần phải luôn nhớ trong đầu rằng thuộc tính này không phải được gọi là fitsStatusBar hay fitsNavigationBar. Bất cứ thứ gì cấu thành System Windows, thì kích thước (dimensions) và vị trí của nó có thể thay đổi khi chạy trên các nền tảng, phiên bản khác nhau. Ví dụ rõ ràng nhất, bạn hãy nhìn vào những điểm khác nhau khi chạy ứng dụng trên Android Honeycomb và Ice Cream Sandwich.

Cuối cùng các bạn hãy yên tâm rằng, phần viền insets mà bạn lấy đi từ fitsSystemWindow sẽ đúng với mọi phiên bản platform để chắc chắn rằng những nội dung trong layout của bạn không bị xếp chồng với những thành phần giao diện UI cung cấp bởi hệ thống - hay chắc chắn rằng bạn sẽ tránh đưa ra bất kì giả định nào về tính khả dụng hoặc kích cỡ nếu bạn tùy biến hành vi mặc định của nó.

Chào các bạn! Chúc các bạn học tốt!

#BuildBetterApps

Read More

Tổng hợp nguồn tài nguyên mới dành cho các nhà phát triển web

Năm 2015 là một năm tuyệt vời đối với ngành lập trình web: công nghệ web đã phát triển mạnh mẽ và vượt qua các yếu tố hình thức bên ngoài như việc xây dựng một trang web hay một ứng dụng web. Nhiều ứng dụng trên điện thoại hay máy tính đã được xây dựng bằng HTML, CSS và JavaScript. Điều này có thể thực hiện được bởi tính di động của công nghệ web và các thư viện như React.js, Angular và Node.js.

Trong series lần này, chúng tôi đã sử dụng một số ít các thư viện JavaScript và CSS.
Read More

Read More

Sự khác nhau giữa @id/ và @+id/ trong Android

Chào các bạn!

Sau một thời gian vắng bóng do bận thi và có khá nhiều việc trên công ty thì hôm nay mình sẽ trở lại với một bài viết nho nhỏ :D

Khi lập trình Android, đặc biệt là khi xử lý với các XML layout bạn chắc hẳn phải gặp qua thuộc tính "id" trong các thẻ View hoặc Layout. Khi mới học chúng ta có thể hiểu đơn giản là nó sẽ gán hoặc gọi id của các View hoặc Layout đó. Tuy nhiên đôi khi bạn thấy nó có sự xuất hiện của các cách gọi, gán id khác nhau như:

- android:id="@id/myView"

 - android:id="@android:id/myView"

- android:id="@+id/myView"

Vậy chúng khác nhau ra sao, và được dùng trong các trường hợp như thế nào?

Thứ nhất, các bạn nên biết "android:" là tiền tố để chỉ đến các thuộc tính, layout được định sẵn trong android. Không chỉ riêng "@android:id/" mà còn nhiều thứ khác như "@android:color/", "@android:drawable/", "@android:layout/"... 

Đây là những tài nguyên PHỔ BIẾN mà Android System đã định sẵn cho nhà lập trình để sử dụng vào các project của họ.

Ví dụ:

Bạn còn nhớ khi tạo một ArrayAdapter cho ListView ta có sử dụng tham số  android.R.layout.simple_list_item_1, hay đơn giản hơn khi dùng "@android:color/transparent" để chỉ màu trong suốt, được rất nhiều người sử dụng, nên android đã tạo ra nó, và tất cả những gì lập trình viên cần là gọi ra và sử dụng. 


Đó là Android Resources, còn khi làm việc với những tài nguyên do chính bạn tạo/defined trong project. Bạn sẽ sử dụng "@id/" và "@+id/"

Căn bản thì bạn có thể không cần suy nghĩ gì cả, hãy sử dụng "@+id/" ở tất cả các chỗ bạn muốn.
Tuy nhiên hiểu sao cho đúng thì là một vấn đề khác. Nếu đơn giản là những gì bạn thích, thì bạn có thể bỏ qua những phần bên dưới!

-----------------------------------------------------------

Khi bạn sử dụng "@+id/myView" thì dấu "+" nói với Android System rằng đây là một tài nguyên mới với tên là "myView" cần được tạo và thêm vào kho tài nguyên (resources) chung. (trong file R.java) NẾU NÓ CHƯA TỒN TẠI. Và sau đó trong Java code bạn sẽ gọi lại các entry đó trong R.java ra bằng cách View view = findViewById(R.id.myView). Quá trình tạo file R.java đó sẽ diễn ra lúc app bạn được compile. 

Mặt khác, khi bạn sử dụng "@id/myView", bạn đang liên kết, refer đến một tài nguyên đã được định nghĩa từ trước bằng "@+id/" và đã tồn tại trong R.java.

File R.java mẫu

Ví dụ:
Trong XML Layout:
- Khi bạn sử dụng thuộc tính "android:id=..." nghĩa là bạn đang muốn xác định id cho một View/Layout mới và cần hướng dẫn cho parser/builder tạo một entry mới trong R.java. Khi đó bạn sẽ phải thêm dấu "+" vào như "android:id=@+id/myView",...
- Khi bạn muốn tham chiếu đến id của một View/Layout khác đã được định nghĩa trước như android:layout_below="@id/myTextView", android:layout_toRightOf="@id/myTextView", ... thì chỉ cần sử dụng "@id/", parser sẽ tự động hiểu và link đến entry đó trong R.java.

Vậy có trường hợp ngoại lệ nào không? 

Xin trả lời là có!

XML Layout của Android có một điểm yếu, nó không như Java code, bạn viết 1 hàm bất kì đâu trong file .java, bạn đều gọi được, không phân biệt thứ tự. Ở đây nó sẽ parse từ trên xuống, nên nếu bạn viết như thế này, thì xuất hiện lỗi lúc compile-time, vì nó không tìm thấy R.id.check.


Rõ ràng đoạn xml trên mình đã dùng "@+id/check" nghĩa là phải có check trong R.java rồi chứ. Tại sao Android lại bảo không có? :D

...

Bạn đã có câu trả lời cho mình chưa nào? :D

Vậy trong trường hợp này ta sẽ có hai cách giải quyết.

Thứ nhất, đem thẻ Button với id.start xuống dưới Button với id.check.

Như vậy dù thay đổi thứ tự trong xml layout, nhưng thứ tự thực tế khi parse ra vẫn không thay đổi khi sử dụng RelativeLayout. Còn LinearLayout thì sai bét nhé :D

Mặt khác code như thế này làm cho người lập trình viên đọc cảm thấy confused, khó hiểu, dẫn đến dễ gây ra nhầm lẫn, bug không đáng có.

Vậy lỡ gặp LinearLayout hay để dễ đọc hơn thì ta sẽ làm thế nào?

Đơn giản, ta thấy trong đây "check" xuất hiện nhiều hơn 1 lần. Vậy nhớ lại qui tắc. Lần đầu tiên dùng "@+id/" để thêm vào, rồi từ đó có thể refer đến nó bằng "@id/".

Và mọi thứ sẽ chạy tốt như bình thường, người lập trình cũng dễ đọc hơn.

Dường như mọi thứ tưởng chừng như đang dễ hiểu khi làm việc với XML Layout trong Android, mà mình lại làm cho nó trở nên khó hiểu nhỉ :D

Biết nhiều hơn một tí cũng tốt mà. Còn dùng thì chọn cách nào tùy bạn!

Cảm ơn các bạn đã xem! Chúc các bạn học tốt!

Read More