Here are the three ideas I want to convey: The Fr...
# compose
w
Here are the three ideas I want to convey: The Fragmentation of Compose is Off-Putting Currently, Compose is divided into Jetpack Compose (developed by the Android team) and Compose Multiplatform (developed by the JetBrains team). Even though these two teams have some level of collaboration, this division makes beginners feel that Compose Multiplatform lacks strong support. Ideally, if these two teams from different companies could work together directly, it would be much better. Additionally, tools provided by Jetpack Compose in Android Studio, such as recomposition counts, layout inspector, and animation debugging, are unavailable in Compose Multiplatform, which is frustrating. The preview functionality in CMP is also fragmented; in Android Studio, it’s not even possible to preview common modules. Issues with Preview in Fleet and Shortcomings in CMP Preview While it’s understandable that CMP support in Fleet is still in its early stages, there are some significant issues: 1. It does not support extended @Preview annotations, such as @MultiplePreview; 2. There is a considerable gap between the preview configurations in Fleet and Android Studio; 3. It’s relatively slow. I believe a dedicated discussion and design effort is needed for the preview feature in Fleet. Although it’s understandable that IDEs themselves support Compose previews, it’s surprising that IntelliJ IDEA, Android Studio, and Fleet have completely different levels of support for them. 3. The Importance of Live Edit, Similar to Flutter Live Edit is extremely important! During prototype design, Flutter’s Hot Reload significantly boosts efficiency, saving a lot of time on waiting for builds and app installations when writing code. Teams that focus on details and real device effects will waste a lot of time on these processes. I believe this feature should not be handled by Fleet but by CMP, and its priority should be very high.
❤️ 3
🤔 2
👍 3
z
i don't think anyone's perfectly happy with the current state of the split, and that's something that's being worked on between google and jetbrains, but will definitely take some time to iron out
👍 4
👍🏾 1
e
I've been working with (and in some cases on) CMP for a while now, so here are some of my thoughts/opinions: 1. I've never had the sense that CMP doesn't have strong support. The progress has been great despite the less than ideal situation that the project is in (forking androidx, the impact of the war on Jetbrains when CMP was starting out, etc...). I'm sure that as the processes around the Jetbrains <-> Google collaboration smooth out it'll get even better 2. The preview support is not great, and I'm not a big fan of Fleet, but it is possible (with only a very minor headache) to get CMP previews in common code in Android Studio (there's a thread somewhere here on how to do it; I'll see if I can find it) 3. I usually disable Live Edit because I find that it causes more issues that don't justify what it is trying to do. For me, the previews are usually fine, and when I do need an actual build, I usually run the JVM app which is super fast to iterate on
2
w
@eygraber I think it's because Live Edit is not user-friendly enough. I think the ideal of this feature is very good. Because it is a satisfying feature for everyone on the front end and Flutter.
c
I'm not a big fan of Fleet,
That's funny, because everytime I use fleet. my fans spin up and sound really big. 🧌
😂 2
a
I used to think that Live Edit was the perfect way to implement changes rapidly, but turns out that Previews are miles better in every aspect there is
1
c
ill take this time to solicit +1s for this bug for fleet making fans loud on mac https://youtrack.jetbrains.com/issue/FL-22803/High-CPU-usage-and-loud-fans-on-Apple-Silicon-machines-in-Fleet
a
I had problems with performance as well, I had never heard my m2 pro use its fans until Fleet was indexing some stuff
and my cache reached like 80gb which is insane
🤯 1
😭 1
m
Not saying it's the case here, but in general wouldn't this indicate a piece of software is able to multithread well and use all your system resources efficiently? Assuming there are no problems in the implementation of the indexing and it doesn't do any wasted work, would people prefer it taking 2 times longer but use 2x less CPU?
w
I think time is more important.