Hello Android devs :space_invader:, we need YOUR i...
# compose
s
Hello Android devs 👾, we need YOUR input. Help us out and hopefully, we can help you out in return! 😊 What are the key things preventing you, your teams and your apps from migrating to Jetpack Compose?🤔
🙏 2
🎉 3
p
In this channel probably everybody is working towards the migration direction but I would talk about a point we discussed in my current company before starting the migration. Developer x comes with this opinion: we have around 30 modules using a decent architecture based on activities/fragments that allow for a decent speed to add new features. It took us probably 7-8 years to mature that architecture + salaries paid. Not a perfect solution but solves most/all the business needs and not a steep learning curve for new maintainers. Why bringing more dependencies, that grow the App size, that might introduce new types of bugs, to a system that already works. For new green fields modules good but existing massive brutal code doesn't sound helpy. Many of the modules have really tied business logic+ ui and is very hard to break that binding.
And that is where we are at, new modules are compose because we think it is faster to develop/maintain and it is where the new ui research is focused. Globe wise in every ui oriented framework. But the old modules will remain with the classic View system, sorry 😔
a
For us, it's not necessarily anything technical, but more so red tape/corporate bureaucracy. We get mixed signals/ins to port the app over to Compose and SwiftUI from react native, however, product leadership doesn't want to spend time on something that is a "waste of time"
It comes from folks who are less technically literate and do not understand the benefits of a native app, whereas devs on the mobile team plus the product side of our team do understand it, have business cases for it, but the only time any of us (2 folks out of the rest of the team) have to work on it is after hours
For context, we work on a pretty popular multi family solution for smart home used in apartments, and a big aspect of the app is bluetooth communications to various lock integrations. Very easy to do in native code, but react native holds us back in some very interesting ways. Product leadership up the chain doesn't understand this/doesn't care and wants to keep going with what we have since it "works"
My goal since joining 2 years ago has been to keep modernizing what we have, and moving to native would be the next step in that
m
I may be wrong, but something I realized working with Android (and transitioning from the web) is that the community is not as big as the web application community is. I believe this impacts a lot into transitioning into new technologies. Taking as a comparison, a new JS framework is born today and we will have hundreds of videos explaining the future of JS tomorrow. In Android, however, the effect seems slower, not only because we are in the "no browser" land (so everything tends to be harder to build than in the web), but we maybe also lack that community excitement volume, like when people dropped jquery for the one who must not be named. Also, sometimes I feel like jetpack compose needs to pop up from previous frameworks, like the way JS does: here's something "impossible" in older versions that is only achievable in compose. I can make a naive guess where we could have space for that: today, many things is about media, either by image, sound or video manipulation. Also, beautiful effects, like backdrop-filter. Maybe we need to see more of those things related to a universe where only in jetpack compose is possible, like: "who are the ones willing to implement this robust camera sound effect editor when we have out of the box in compose?". But that's just my bias and completely junior perspective from someone who had joined android last year.
k
@mgrazianodecastro I’m so curious what this is referring to…
“…when people dropped jquery for the one who must not be named.”
m
I'm scared of saying, the evil is out there
l
For us, it's the lack of out of the box support for TV. We work on apps that are for both mobile and TV so we want to have components we can share in both places (since the only difference is size), but migrating to compose for TV apps is a pain right now. Navigation with DPAD feels weird and we lack needed functionalities like being able to long press. The new compose for TV library seemed pretty promising, but the fact that the TVLazyLists are completely separated from the normal lazy lists is concerning and also makes it harder for us to have shared components.
c
We use bottom sheets... a LOT. no dialogs or anything. and yeah. bottom sheets are just still rough around the edges. m3 sheets are still veryyy rough. like 15% of our app is bottom sheets and just gets complaints constantly. sad panda
and proper screenshot testing
lots of devs complain about perf too, but i dont really have much issues with perf personally. but i guess having faster perf during debug builds would be nice
s
Thank you all lots and lots 🌻
Heyaa 🌻 , I tried to group all of the generous feedback you sent and provide some helpful materials in return 🙂 so sharing it here as well, in case you find something interesting 🤙 thanks again https://twitter.com/anomisSi/status/1642944221442195495