You ve been told lies about Fragments.

Size: px

Start display at page:

Download "You ve been told lies about Fragments."

Christopher Darrell Walker
6 years ago
Views:

1 You ve been told lies about Fragments.

2 Mateusz Herych Android Tech IG Google Developer Expert on Android GDG Kraków co-organizer Father of / github.com/partition

3 You ve been told lies about Fragments.

4 Custom Views are all you need.

5 Custom Views are all you need?

6 Goals of this talk

7 Agenda - First I will tell you why Fragments are bad

8 Agenda - First I will tell you why Fragments are bad Then that you can do nothing about it

9 Agenda - First I will tell you why Fragments are bad Then that you can do nothing about it Finally will tell you that ACTUALLY you can do something about it

10 Goals of this talk - For those of your who re locked to Fragments: perhaps teach you something new and share experience how to make your life easier.

11 Goals of this talk - For those of your who re locked to Fragments: perhaps teach you something new and share experience how to make your life easier. For those of you starting a new project: give an idea about alternative approaches that may possibly work for you (or not).

12 Fragments, the bad.

13 Lifecycle.

14 Advocating Against Android Fragments Pierre-Yves Ricau, Square

15 Finally getting rid of Android Fragments Sebastian Drygalski, SoftwareMill

17 Is that a problem though?

18 Too much drama about number of callbacks. Real issue = unexpected behavior.

19 Story of an app.

20 USFragment EuropeFragment AsiaFragment

21 USFragment { us : [ <us news go here> ], eu : [ <eu news go here>], asia : [ <asia news go here>] EuropeFragment } AsiaFragment

22 USFragment { us : [ <us news go here> ], eu : [ <eu news go here>], asia : [ <asia news go here>] EuropeFragment } AsiaFragment setusnews() Activity Presenter seteunews() setasianews()

23 USFragment { EuropeFragment us : [ <us news go here> ], eu : [ <eu news go here>], asia : [ <asia news go here>] findfragmentbytag( us ) + cast + setitems() } AsiaFragment setusnews() Activity Presenter seteunews() setasianews()

24 Response is cached in memory once done. USFragment { EuropeFragment us : [ <us news go here> ], eu : [ <eu news go here>], asia : [ <asia news go here>] findfragmentbytag( us ) + cast + setitems() } AsiaFragment setusnews() Activity Presenter seteunews() setasianews()

25 What s the problem?

27 Activity.onCreate() -> presenter.attachview(view)

28 Data is cached -> immediate call to Activity.setData()

29 Activity.setData() -> getfragment().setdata()

31 View is not yet created.

32 View is not yet created. NPE inside of the Fragment.

33 FragmentTransactions are asynchronous.

35 Quiz

36 Fragment.onAttach() Fragment.onCreate() Fragment.onCreateView() Activity.onCreate() Activity.onStart()

37 Activity.onCreate()

38 Activity.onCreate() Fragment.onAttach()

39 Activity.onCreate() Fragment.onAttach() Fragment.onCreate()

40 Activity.onCreate() Fragment.onAttach() Fragment.onCreate() Activity.onStart()

41 Activity.onCreate() Fragment.onAttach() Fragment.onCreate() Activity.onStart() Fragment.onCreateView()

43 commitnow() - added June 2016, Support Library

45 Changes nothing here.

46 However

51 This is pretty fundamentally WAI as things stand today. We don't create the view until we transition to the ACTIVITY_CREATED state, which is after the activity oncreate returns. This way a fragment's oncreateview can rely on its host activity having been fully created when it runs. If you commitnow() in oncreate, you haven't reached ACTIVITY_CREATED yet, so the view doesn't get created.

52 tl;dr - Works As Intended

53 Activity.onCreate() Fragment.onAttach() Fragment.onCreate() NestedFragment.onAttach() NestedFragment.onCreate()

54 Activity.onStart() Fragment.onCreateView() Fragment.onViewCreated() Fragment.onActivityCreated() performactivitycreated() NestedFragment.onCreateView() NestedFragment.onViewCreated() NestedFragment.onActivityCreated()

55 But...

56 Declaring Fragments in XML

57 Declaring Fragments in XML

59 LayoutInflater.Factory

62 Activity.onCreate() Fragment.onAttach() Fragment.onCreate() NestedFragment.onAttach() NestedFragment.onCreate()

63 Activity.onCreate() Fragment.onAttach() Fragment.onCreate() NestedFragment.onAttach() NestedFragment.onCreate()

64 In case your Fragment is inflated via XML, its View is created before setcontentview() returns.

65 Conclusions

66 Conclusions - The earliest Activity s callback in which you can rely on your Fragments views being created is onstart().

67 Conclusions - The earliest Activity s callback in which you can rely on your Fragments views being created is onstart(). The earliest Fragment s callback in which you can rely on your children Fragments views being created is onstart().

68 Conclusions - The earliest Activity s callback in which you can rely on your Fragments views being created is onstart(). The earliest Fragment s callback in which you can rely on your children Fragments views being created is onstart(). Oh, and in case you inflate Fragments via XML then it works completely different.

69 Move Presenter.attachView( ) to onstart()?

70 ViewPager

71 Problem: tracking screens to Google Analytics

72 setuservisiblehint()

74 setuservisiblehint() is unrelated to the regular lifecycle.

75 setuservisiblehint() can be called before or after your View is created.

76 setuservisiblehint() can be called before or after your Fragment is attached.

78 Problem: I have a heavy View, I don t want to destroy when I navigate.

79 Heavy Fragment A Fragment B

80 show() / hide() attach() / detach() add() / remove()

81 show() / hide()

82 Called when the fragment is visible to the user and actively running. This is generally tied to Activity.onResume of the containing Activity's lifecycle. ragment.html#onresume()

83 Called when the fragment is visible to the user and actively running. This is generally tied to Activity.onResume of the containing Activity's lifecycle. ragment.html#onresume()

84 Hidden Fragment is still in running state.

85 onhiddenchanged()

86 Beware: not called on configuration change, so you re left with ishidden().

87 Debugging

89 Lessons learned

90 Lessons learned - Don t use Fragments in case they don t work on their own - i.e. their are being used as Views.

91 Lessons learned - Don t use Fragments in case they don t work on their own - i.e. their are being used as Views. E.g. they don t have their own Presenters, but rather wait for the data being dispatched from Activity / parent Fragment

92 Lessons learned - Don t use Fragments in case they don t work on their own - i.e. their are being used as Views. E.g. they don t have their own Presenters, but rather wait for the data being dispatched from Activity / parent Fragment If you need to talk to your Fragment from your Activity / parent Fragment give it a second thought.

93 Lessons learned - Don t use Fragments in case they don t work on their own - i.e. their are being used as Views. E.g. they don t have their own Presenters, but rather wait for the data being dispatched from Activity / parent Fragment If you need to talk to your Fragment from your Activity / parent Fragment give it a second thought. If any of the above is true, just go for custom views - in such cases they re equally reusable.

94 General rule of thumb - Casting getactivity() to some callback interface + invoking methods is more-or-less safe.

95 General rule of thumb - Casting getactivity() to some callback interface + invoking methods is more-or-less safe. (at least if you know what you re doing)

96 General rule of thumb - Casting getactivity() to some callback interface + invoking methods is more-or-less safe. (at least if you know what you re doing) Same for gettargetfragment() / getparentfragment()

97 General rule of thumb - Casting getactivity() to some callback interface + invoking methods is more-or-less safe. (at least if you know what you re doing) Same for gettargetfragment() / getparentfragment()

98 General rule of thumb - - Casting getactivity() to some callback interface + invoking methods is more-or-less safe. (at least if you know what you re doing) Same for gettargetfragment() / getparentfragment() Delegating calls from Activity / parent Fragment to Fragments stored within theirs FragmentManagers is less safe, as there s less certainty what state they re in.

99 Ok, but do we really need Fragments at all?

100 Fragments, the good.

101 Fragments, the good. - Backstack + animations

102 Fragments, the good. - Backstack + animations Retaining on configuration changes (and I m not talking about retained Fragments here)

103 Fragments, the good. - Backstack + animations Retaining on configuration changes (and I m not talking about retained Fragments here) requestpermissions / startactivityforresult - if started from Fragments, FragmentActivity/FragmentManager delegate them directly to the Fragment that needs them - no need for dispatching

104 Fragments, the good. - Backstack + animations Retaining on configuration changes (and I m not talking about retained Fragments here) requestpermissions / startactivityforresult - if started from Fragments, FragmentActivity/FragmentManager delegate them directly to the Fragment that needs them - no need for dispatching (finally!)

105 startactivityforresult() in Fragments Fragment.startActivityForResult(intent, 0)

106 startactivityforresult() in Fragments Fragment.startActivityForResult(intent, 0) Dispatched to Activity as Activity.startActivityForResult(intent, 65536)

107 startactivityforresult() in Fragments Fragment.startActivityForResult(intent, 0) Dispatched to Activity as Activity.startActivityForResult(intent, 65536) Then Activity.onActivityResult() is called, with requestcode =

108 startactivityforresult() in Fragments Fragment.startActivityForResult(intent, 0) Dispatched to Activity as Activity.startActivityForResult(intent, 65536) Then Activity.onActivityResult() is called, with requestcode = And delegated futher by Activity to a Fragment with requestcode = 0.

109 startactivityforresult() in Fragments Fragment.startActivityForResult(intent, 0) Dispatched to Activity as Activity.startActivityForResult(intent, 65536) Then Activity.onActivityResult() is called, with requestcode = And delegated futher by Activity to a Fragment with requestcode = 0. Half of the bits are used to identify target Fragment, the other half is actual requestcode requested by that Fragment.

110 Fragments, the good. - - Backstack + animations Retaining on configuration changes (and I m not talking about retained Fragments here) requestpermissions / startactivityforresult - if started from Fragments, FragmentActivity/FragmentManager delegate them directly to the Fragment that needs them - no need for dispatching (finally!) They re in supportlib, no need to deal with platform-bugs that will be there forever (as once something gets shipped in SDK, it ll stay there forever).

111 Fragments, the good. - - Backstack + animations Retaining on configuration changes (and I m not talking about retained Fragments here) requestpermissions / startactivityforresult - if started from Fragments, FragmentActivity/FragmentManager delegate them directly to the Fragment that needs them - no need for dispatching (finally!) They re in supportlib, no need to deal with platform-bugs that will be there forever (as once something gets shipped in SDK, it ll stay there forever). In case you get in trouble - there are other people in the same situation.

112 Fragments, the good. - - Backstack + animations Retaining on configuration changes (and I m not talking about retained Fragments here) requestpermissions / startactivityforresult - if started from Fragments, FragmentActivity/FragmentManager delegate them directly to the Fragment that needs them - no need for dispatching (finally!) They re in supportlib, no need to deal with platform-bugs that will be there forever (as once something gets shipped in SDK, it ll stay there forever). In case you get in trouble - there are other people in the same situation. Communication to parent / target - e.g. settargetfragment() is retained for you on configuration changes.

113 Fragments, the good - View-less Fragments - e.g. for the purposes of managing your options menu or Toolbar

114 Your current balance, streamed in real-time by WebSocket Some data, e.g. charts $ 12,500

115

116 Fragments, the good - View-less Fragments - e.g. for the purposes of managing your options menu or Toolbar Nested Fragments are sometimes helpful - imagine Activity with Bottom Bar tabs, where each tab has its own backstack. (vide Instagram)

117 Fragments, the good - View-less Fragments - e.g. for the purposes of managing your options menu or Toolbar Nested Fragments are sometimes helpful - imagine Activity with Bottom Bar tabs, where each tab has its own backstack. (vide Instagram) Better callbacks than just a View - you may not need them, but once you need them you end-up delegating lifecycle methods to your custom views.

118 tl;dr not something you should write on your own.

119 So I started to look for alternatives.

120 Requirements

121 Requirements - Supports backstack (including nested backstacks), together with backstack animations

122 Requirements - Supports backstack (including nested backstacks), together with backstack animations Synchronous transactions

123 Requirements - Supports backstack (including nested backstacks), together with backstack animations Synchronous transactions Retaining states on configuration changes

124 Requirements - Supports backstack (including nested backstacks), together with backstack animations Synchronous transactions Retaining states on configuration changes Some settargetfragment() equalvement would be nice

125 Requirements - Supports backstack (including nested backstacks), together with backstack animations Synchronous transactions Retaining states on configuration changes Some settargetfragment() equalvement would be nice Fragment-like support for requestpermissions() and startactivityforresult()

126 Requirements - Supports backstack (including nested backstacks), together with backstack animations Synchronous transactions Retaining states on configuration changes Some settargetfragment() equalvement would be nice Fragment-like support for requestpermissions() and startactivityforresult Well maintained, reasonably big user-base.

127 Basically all I needed were Fragments, but synchronous.

128 Conductor

129

130 Controllers are your new Fragments

131

132 Controller.java oncreateview() onattach() ondetach() ondestroyview() ondestroy()

133 Controller.java sethasoptionsmenu() oncreateoptionsmenu() getactivity() startactivity() / startactivityforresult() / onactivityresult() requestpermissions() / onrequestpermissionsresult()

134

135 Whole transaction is executed & your Controller s view is created before this call returns.

136

137 Nested transactions are synchronous as well

138

139 D/ControllerRetaining:

140 D/ControllerRetaining: Then, after orientation change: D/ControllerRetaining:

141 Same behavior as for Fragments with setretaininstance(true)

142 Interestingly, Routers state is being kept in a retained Fragment.

143 Oh, irony!

144 You still need to save your controller s custom state in onsaveviewstate(). e.g. Don t Keep Activities

145

146

147

148

149

150

151

152 Target Controller can be in any Router - root or child routers.

153 Wait, what?

154 Conductor, by default, destroys Views once their Controllers get detached.

155 This is executed on a controller that has its View destroyed.

156

157 startactivityforresult

158 Each Controller has its own, unique instanceid (UUID generated during construction)

159

160

161 Goes recursively - looks up child Routers as well

162 ViewPager

163 You may ve noticed: no visibility callback in Controllers whatsoever.

164 Which means: N controllers are in attached state depending on Pager s offscreen page limit.

165 My first reaction: Damn, this is even worse than Fragments then!

166 Not really!

167

168

169 Disadvantages

170 Disadvantages - Controllers must have Views and need to be attached to some container.

171 Disadvantages - Controllers must have Views and need to be attached to some container. Using Fragments may still be necessary (or simply: easier) - e.g. SupportMapFragment.

172 Disadvantages - Controllers must have Views and need to be attached to some container. Using Fragments may still be necessary (or simply: easier) - e.g. SupportMapFragment. Doing Dialogs is bit hacky

173 Disadvantages - Controllers must have Views and need to be attached to some container. Using Fragments may still be necessary (or simply: easier) - e.g. SupportMapFragment. Doing Dialogs is bit hacky User base is still not even comparable to Fragments - it s quite hard to Google a solution if you step into something unexpected. (Though Conductor s author is super-responsive on Github)

174 Conclusions.

175 Conclusions - For majority of apps Fragments can t be exchanged for Custom Views

176 Conclusions - For majority of apps Fragments can t be exchanged for Custom Views I mean, they can, but then you start reinventing the wheel (e.g. backstack, delegation of onactivityresult/onpermissionsresult callbacks)

177 Conclusions - For majority of apps Fragments can t be exchanged for Custom Views I mean, they can, but then you start reinventing the wheel (e.g. backstack, delegation of onactivityresult/onpermissionsresult callbacks) Fragments are okay-ish if you use them carefully and understand how they work

178 Conclusions - For majority of apps Fragments can t be exchanged for Custom Views I mean, they can, but then you start reinventing the wheel (e.g. backstack, delegation of onactivityresult/onpermissionsresult callbacks) Fragments are okay-ish if you use them carefully and understand how they work Lots of issues in Fragments are caused by bugs that will eventually get fixed. Remember that no alternative is bug-free.

179 Conclusions - For majority of apps Fragments can t be exchanged for Custom Views I mean, they can, but then you start reinventing the wheel (e.g. backstack, delegation of onactivityresult/onpermissionsresult callbacks) Fragments are okay-ish if you use them carefully and understand how they work Lots of issues in Fragments are caused by bugs that will eventually get fixed. Remember that no alternative is bug-free. And the most important one...

180 Conclusions - For majority of apps Fragments can t be exchanged for Custom Views I mean, they can, but then you start reinventing the wheel (e.g. backstack, delegation of onactivityresult/onpermissionsresult callbacks) Fragments are okay-ish if you use them carefully and understand how they work Lots of issues in Fragments are caused by bugs that will eventually get fixed. Remember that no alternative is bug-free. And the most important one Don t follow blindly someone telling you that X sucks and you shouldn t use it. :-)

181 Thanks - Q & A

UI Fragment.

UI Fragment. UI Fragment 1 Contents Fragments Overviews Lifecycle of Fragments Creating Fragments Fragment Manager and Transactions Adding Fragment to Activity Fragment-to-Fragment Communication Fragment SubClasses