I know you can set the flag and everything, but that creates its own set of problems. Sometimes I have them there in memory and I just want to pass that to the next screen. It depends on your app, but I don’t always want my objects to be serialized. You can try to solve certain aspects of it, but there is so much to be understood that there are always multiple problems. Wouldn’t it be nice if we had something that looked way more like the original, simple lifecycle we first learned? Problems (3:54) I decided that with the new project I was starting at Wealthfront, I wanted something simpler. The lifecycle has been changing over the different versions of Android. In some edge cases, it not only doesn’t behave as you would expect, but also it changes. Then we have fragments, which are just insane. There are all the optional methods too, for edge cases. The guarantee is onPause and onStop, but onDestroy is not guaranteed to be called.Īnd it gets worse. At any given point in the process of destroying a new activity, the activity can be killed by the process being killed. That sounds great, but in practice, there are all kinds of edge cases.įor example, it turns out that onDestroy might not be called in certain cases. It can also be paused, and that means it’s partially visible. Then it’s resumed, and that means it’s visible. First, an activity is created, then started. The lifecycle is a basic tenet of Android development. In this post, I’ll take you on a journey of how my team at Wealthfront went from the old school View, to fragments, to what I call “modern Android.” Lifecycle (0:50) Hi, I’m Fabien, and I’m the Android lead at Wealthfront. How would you like a screen that doesn’t get destroyed on rotation, and a navigation that’s as simple as calling goTo(screen)? That’s what modern Android development should look like. Using fragments is error-prone, and their lifecycle is even worse. Activities get destroyed when you rotate the screen, and they have a complex lifecycle.
0 kommentar(er)
