And fragments are a pain, you should use screens a...
# announcements
m
And fragments are a pain, you should use screens and views
r
mkodekar: what do you mean by screen?
m
r
so far i know, fragment should be acceptable for complex view

https://www.youtube.com/watch?v=k3IT-IJ0J98

https://www.youtube.com/watch?v=eUG3VWnXFtg&t=1044s

advise me, if i am wrong
🙂
m
Tell me about fragment lifecycle
How many methods
r
i see, much override functions
just take a look the code
the screen itself just a custom view
i also implements this kind
so, did you not use a fragment
m
See there are lesser in views and screens
And then there is less code and savedinstance state to be lost.
r
how you avoid configuration changes?
m
There is onSave and on restore for that
Which handles it
And view does not changes it state when rotated
Or does it.
And there is not configuration changed method for views and screens
r
it will changes, all you view or screen just implemented in activty
did you use kind MVP for this?
m
It won't try it
Yes its mvp
r
i see
thanks for sharing
🙂
it pleasure to see my github
keep in touch brother
m
Yeah sure .
k
@mkodekar why do you say fragments are a pain. I've been using them successfully in fairly large projects without any "pain". IMHO, once you understand them, they are a real pleasure to use. Fragments have a lot of lifecycle events, yes. But you should only care about the ones that you need. Just like activities. I agree there might be some rather good cons. But I fail to see any from your comments
r
Actually I use fragment for all my project, and that really good.
💯 2
m
I don't have any major issues with fragments as well but sometimes building complex ui with fragments becomes a pain, secondly the screen and view architecture certainly is a good alternative for me to do such type of stuffs.
👍 1