Do qui ước của Apple nhé. Apple cũng có thể để mặc định là không capture, trong trường hợp đó thì mình phải check là nil hay không để app không bị crash. Còn nếu để mặc định là capture thì có thể gây ra retain cycle (leak) nếu developer không làm đúng cách. So sánh giữa việc leak và crash thì chắc leak vẫn tốt hơn nên Apple mới để mặc định là capture. Còn function không capture thì function đó phải thuộc class mà nó đang dùng self, và trong trường hợp đó thì truy xuất đến function đó thì phải truy xuất đến object của class đó trước, nếu object nil thì crash, còn nếu không nil thì capture không có ý nghĩa. Capture là để đảm bảo object tồn tại đến thời điểm code đươc thực thi mà. Còn closure thì nó không thuộc một class nào hết.
Cho e hỏi ngu phát:
"No No. Về bản chất Closure không khác gì Function. Closure chỉ là một bản viết tắt của Function":
vậy tại sao trong closure khi có sử dụng self or các biến bên ngoài phải capture lại . Nếu không thì sảy ra retain cycle. Còn func thì không cần phải capture j hết ạ .
vì e không hiểu nên hỏi ngu... ad nhẹ tay thôi nhé:V
con số 20k records và 100k+ bạn lấy ở đâu vậy? Hơn nữa Subquery và JOIN là khác nhau nên việc so sánh còn tùy thuộc vào bài toán cụ thể, với mỗi bài toán sẽ có cách chọn khác nhau. Theo mình việc so sánh như này chỉ đúng với không gian dữ liệu và yêu cầu bài toán nhằm demo của bạn. Chứ nó không hoàn toàn đúng.
e cám ơn anh nhiều ạ. Anh cho e hỏi , câu này : THEO A TRONG TRƯỜNG HỢP FORM KHÔNG THAY ĐỔI THÌ K NÊN DÙNG STATE
ý anh có phải là với Form chỉ có chức năng cho người dùng nhập để gửi thông tin đi ( form 1 chiều ) => thì loại này gọi là FORM KHÔNG THAY ĐỔI .
Còn một loại Form mà ta có thể chỉnh sửa thông tin của một user nào đó (thường thấy trong mấy trang quản trị) => thì gọi là FORM CÓ THAY ĐỔI phải không anh ?
Anh có thể cho e một vài suggest về những trường hợp như nào thì dùng state và khi nào thì không nên dùng không ạ .
PS: Cách viết code của anh đọc rõ ràng và dễ hiểu lắm.
:: [ Ước gì mấy anh trong Công ty e cũng có phong cách viết như vậy thì tốt quá : ))
Bài viết đơn giản quá. Cần nhất là giải thích cụ thể dùng thao tác gì thì ứng dụng vào tác vụ nền, thao tác gì thì trở lại,... VD ấn nút HOME, đang dùng app có đt gọi đến...?
Ngoài ra, cái life cycle này trở thành 1 mớ bòng bong khi nó kết hợp cùng life cycle của Fragment. Nếu có thể bạn hãy làm 1 bài thật chi tiết về cái này.
Ta có table Employee(id,name,dept)
Và có 2 bài toán như sau:
Bài tập 1:
* 30 nhân viên trên 1 page
* có 50 phòng ban, mỗi nhân viên thuộc 1 phòng ban
Bài tập 2:
* 30 nhân viên trên 1 page
* 5000 phòng ban, mỗi nhân viên thuộc 1 phòng ban
Và ta có câu query như sau:
Select * from Employee Where dept="IT"
Đọc xong không hiểu yêu cầu của bài toán là gì? Insert vào Employee 30 nhân viên hay query thông tin nhân viên hay là gì?
// Câu SQL 1 - dùng sub query, bình thường sẽ viết như sau:
Select *
from A
where col_a1 not in (Select col_a1 from B)
// Câu SQL 2: Sử dụng join
Select A.*
from A
left join B on B.col_a1=A.col_a1
where B.col_a1 is not null
Có vẻ như câu SQL 2 đang không đúng yêu cầu. where B.col_a1 is not null -> where B.col_a1 is null mới phải.
Bài viết cần đầu tư thêm thời gian để có cấu trúc tốt hơn và phân tích kỹ hơn. VD như đặt vấn đề là cái gì nhanh hơn cái gì thì nên phân tích cả 2 chiều và tại sao lại như vậy, nếu có thử nghiệm rồi chụp evidence để mang tính thuyết phục cao hơn thì càng tốt. Chứ như hiện tại thì cảm giác hơi cưỡi ngựa xem hoa rồi kết luận luôn.
THẢO LUẬN
cho em hỏi lỗi này sửa sao vậy ạ, em cám ơn
Do qui ước của Apple nhé. Apple cũng có thể để mặc định là không capture, trong trường hợp đó thì mình phải check là nil hay không để app không bị crash. Còn nếu để mặc định là capture thì có thể gây ra retain cycle (leak) nếu developer không làm đúng cách. So sánh giữa việc leak và crash thì chắc leak vẫn tốt hơn nên Apple mới để mặc định là capture. Còn function không capture thì function đó phải thuộc class mà nó đang dùng self, và trong trường hợp đó thì truy xuất đến function đó thì phải truy xuất đến object của class đó trước, nếu object nil thì crash, còn nếu không nil thì capture không có ý nghĩa. Capture là để đảm bảo object tồn tại đến thời điểm code đươc thực thi mà. Còn closure thì nó không thuộc một class nào hết.
Cho e hỏi ngu phát: "No No. Về bản chất Closure không khác gì Function. Closure chỉ là một bản viết tắt của Function": vậy tại sao trong closure khi có sử dụng self or các biến bên ngoài phải capture lại . Nếu không thì sảy ra retain cycle. Còn func thì không cần phải capture j hết ạ . vì e không hiểu nên hỏi ngu... ad nhẹ tay thôi nhé:V
tks @vankhoadesign )
bài viết hữu ích, tks bạn nhiều
Mình có save bài viết phần 3 vào Drafts vài ngày để cập nhật thêm một số mục, bây giờ thì bài viết đã public rồi bạn nhé !
Mình có save bài viết phần 3 vào Drafts vài ngày để cập nhật thêm một số mục, bây giờ thì bài viết đã public rồi bạn nhé !
con số 20k records và 100k+ bạn lấy ở đâu vậy? Hơn nữa Subquery và JOIN là khác nhau nên việc so sánh còn tùy thuộc vào bài toán cụ thể, với mỗi bài toán sẽ có cách chọn khác nhau. Theo mình việc so sánh như này chỉ đúng với không gian dữ liệu và yêu cầu bài toán nhằm demo của bạn. Chứ nó không hoàn toàn đúng.
nội dung hay và dễ hiểu, like!
Thanks Dao.
e cám ơn anh nhiều ạ. Anh cho e hỏi , câu này :
THEO A TRONG TRƯỜNG HỢP FORM KHÔNG THAY ĐỔI THÌ K NÊN DÙNG STATE
ý anh có phải là với
Form
chỉ có chức năng cho người dùng nhập để gửi thông tin đi ( form 1 chiều ) => thì loại này gọi làFORM KHÔNG THAY ĐỔI
. Còn một loạiForm
mà ta có thể chỉnh sửa thông tin của một user nào đó (thường thấy trong mấy trang quản trị) => thì gọi làFORM CÓ THAY ĐỔI
phải không anh ?Anh có thể cho e một vài
suggest
về những trường hợp như nào thì dùngstate
và khi nào thì không nên dùng không ạ .PS: Cách viết code của anh đọc rõ ràng và dễ hiểu lắm. :: [ Ước gì mấy anh trong Công ty e cũng có phong cách viết như vậy thì tốt quá : ))
Đọc mắc cười thiệt
Thank tác giả. Thấy Facebook với Chatwork dùng cái này từ lâu mà giờ mới biết là Chrome Custom Tab.
Bài viết đơn giản quá. Cần nhất là giải thích cụ thể dùng thao tác gì thì ứng dụng vào tác vụ nền, thao tác gì thì trở lại,... VD ấn nút HOME, đang dùng app có đt gọi đến...? Ngoài ra, cái life cycle này trở thành 1 mớ bòng bong khi nó kết hợp cùng life cycle của Fragment. Nếu có thể bạn hãy làm 1 bài thật chi tiết về cái này.
kiến thức ko mới nhưung rất trực quan
Góp ý chút về bài viết này:
Đọc xong không hiểu yêu cầu của bài toán là gì? Insert vào Employee 30 nhân viên hay query thông tin nhân viên hay là gì?
Có vẻ như câu SQL 2 đang không đúng yêu cầu. where B.col_a1 is not null -> where B.col_a1 is null mới phải.
bài viết hứu ích, cảm ơn tác giả
@luffybkchypro cái Key Authorization của bạn đang bị sai rồi kià , Bearer đằng sau làm gì có dấu . (chấm) bạn ơi