Patrick Yin
07/29/2020, 12:03 AM@Preview
, will the @Preview marked method be removed (or changed) when assembling release build?gildor
07/29/2020, 6:43 AMjim
07/29/2020, 10:59 AM@Preview
is the least of your worries.gildor
07/29/2020, 1:54 PMjim
07/29/2020, 9:45 PM@Preview
functions. Having said that, the annotation is flexible, and if you find that moving your `@Preview`s outside of your main modules does in fact get you significant savings, feel free to do that! You can and should structure your app in whichever way works best for you.Patrick Yin
07/29/2020, 9:58 PM-dontobfuscate
-dontoptimize
gildor
07/30/2020, 2:21 AMSo if you really want to remove preview functions on your debug build, you could do thisIt’s still build performance penalty, tree shaking is not free
the size in development isn’t nearly as importantI mostly agree, not very important, difference is minor (packing, installation)
Your compose widgets should generally be in leaf modules because they shouldn’t be depending upon internals of your appIt’s true, and what I said is for leaf module, the best case. But you also have hierarchy of modules, a lot of components are reused, or part of another component in another module, which itself part of another component and so on.
are going to be written and then shouldn’t change super oftenUntil you start working on some changes (or want to play with preview of some core component!) and getting close to full recompilation when you want to change something in those core widgets
but there is probably lower hanging fruit than trying to avoidI would love to hear about all those lower hanging fruits, but we very careful with build and configuration time, now most of time is obviously annotation processing, direct compilation and app packing And unfortunately all those “fruits” will not change one fact, you still pay by build time on amount of code which you have to compilefunctions@Preview
moving your `@Preview`s outside of your main modules does in fact get you significant savingsIt would increase amount of modules, adding modules not only boilerplate itself, but also increase configuration time (which will problem even with gradle configuration cache). I think custom source set, same way as it works for tests or for textFixtures is way to go, it allows you have preview separated from main app code without build penalty
@Preview
But I also a person who responsible for build infrastructure, and spent huge amount of time fighting with build system, AGP, project structure itself to keep the team productive and reduce compilation time. And when we start adopting compose I wouldn’t like to be in a choice between
1. “we will write preview in main code” and ended up in a year or two with significant amount of code which used only for preview rarely, but compiled every time on CI, recompiled often because incremental compilation is not so stable (and without easy way to measure impact of it) and causes more abi changes than it could be
2. Invent own way to move preview away from main source set by creating a custom source set or special system of modules which include only preview, but getting all possible issues with Android Studio preview integration (code preview, live preview, preview on device etc), some build issues and so on, which we have to maintain ourselves
And I really don’t know which option I would chooseKarthick
08/02/2020, 6:14 PM