Mobile Developers React to Jetpack Compose 1.0

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
with jetpack compose we're saying there's going to be more adoption now that it's stable because the risk is lower we're going to be emboldened to be a lot more creative with our ui and most exciting thing is the way that compose will modernize um the way that we build ui the growth and modernization of the ecosystem and and seeing that the way we do things can change and and improve you don't have to rewrite any part of your app to adopt compose you can just start right now with a new screen or you can start right now by converting an old screen so uh jet black composes is essentially a new uh new ui toolkit for android so um for the entire 10-year history of the android platform we've been building our ui with the view system that that comes built into the platform um and compose is essentially a complete rewrite of that all in kotlin with a pretty neat compiler running it under the hood another important thing to note is that unlike the view system which was tied to yearly android os version updates compose is completely separate from that so like with the old system if there's a new api added most developers didn't really get a chance to use it for a few years until there was a a good percentage of adoption of the os version that that came in and with compose you can update the version completely separately without a losing user coverage on the os versions yeah i do really go back to um like when uh when cottonsport was announced in uh in 2017 um like that that was a big surprise actually to a lot of people i'm composed as lots of surprise because it's they've been developing it in the open for the last couple years but it's definitely comparable in terms of it's going to be a major shift in in how we build android apps the api style of compose is is very different so it's built in what's called a declarative style where you can you kind of write what you want your your ui to look like and the system under the hood deals with what are what are the changes um that it has to do to get you there so there's much less kind of manual work that you have to do to kind of make things consistent when you're trying to change state in your ui um it's also it's all uh written in kotlin and kotlin first so you're no longer dealing with like xml that you're dealing with in the past um everything's in code you can kind of uh reason about it a lot more simply you can add little bits of logic where you need to to make changes um it's there's kind of less extra thinking you have to do to make your ui work compared to other parts of your code in terms of um like less thinking and what you have to do to work i think compose is going to be a really good change in the android ecosystem for new new developers i know a lot of like experienced devs are going through that somewhat difficult transition to change their mindset to work with compose because it's kind of different way of thinking when you're building uis but i think at least in my opinion it seems like it's a lot more intuitive for someone who's a new developer coming in because you like russell said don't have to think about uh all of the changes that need to go on under the hood you just kind of describe what your ui looks like for a given state and everything else is handled for you i'm really excited about all the capabilities of modifying like in the old view system if you want to have a button then that button just extends button which extends text view so you have this this deep kind of hierarchy of views but if you want to add an image to that button then you have to extend material button which extends image view so is it an image is it a button yeah you don't know um because it's it's sort of this this weird kind of inheritance way of looking at things but with compose you can just put arbitrary content in a button or whatever so you don't have to worry about whether it's it's an image or if it's a button or it's material you just put what you want inside that button you can also do things that you couldn't really do before so like drop down menus could only accept text in the android view system i believe it was called a spinner but um but but with compose you can have arbitrary items in there so you could have actually first item set up just text and have a text view there you could have a nested drop down where each item is also a composable drop down menu so it opens up these new possibilities that you that you really couldn't do very easily in the android view system and it also has a rich animation api too so if you're not spending you know all your time learning design and learning the android animation apis just a couple lines you can animate uh say an image just fading and or filling in or something bouncing around really easily without having to pull down um all sorts of resources so i think that's super exciting um yeah that's why i'm excited about it definitely works well when you have um when you have an architecture that's kind of focused on being reactive so with if you're doing mvvm or mdi if you have something that you can like get away or you want to layer if your ui can kind of observe that and subscribe to updates um compose is kind of built to work that way yeah it's it's really interesting because uh compose uses uh this thing called state and that's just this this class and um and so composable functions can take state as a parameter um as composable functions and it'll just automatically update when that state is updated but it can also um take any just sort of normal parameters that are derived by states so if there is a um if you get those i say like a boolean that you get by a state delicate then anytime it's updated it will also update and transforming from your normal world of flow and state flow you can easily just turn those into state by just say you know collect a state or if live data observe a state and boom you're you're in composed land really really easy so none of your architecture really needs to change it's going to be interesting to see kind of as as more and more people start to adopt it um like how we how we learn to kind of build our mental model of what state is and how it changes and and what the different patterns you have to use with it are um it's it's kind of like the big uh big new concept that we're that we're working with now more and more people adopting it is what i what i'm getting most excited about because like we saw when kotlin was announced as the way to build android apps now with compose being stable there is going to be much more adoption more people talking about it more businesses wanting to put that into production um so that's that's where i see the excitement from a non-technical perspective so one of the things that the compost team kind of built in i think in a pretty good way um is um it's very easy to kind of move between compose and the existing view system so there's lots of opportunities if if you're a large company with a big existing app um you can kind of migrate incrementally and that's another spot where i kind of draw the analogy to uh to when talking was introduced as a language um where one of the really big selling points was that you don't uh you don't need to kind of it's not an all-or-nothing thing um you can you can kind of go class by class or bit by bit um adding it um without needing to throw away what you already have and that's super important for for getting adoption um when you have these big teams that have these big existing apps so they don't want to throw it all away i remember um pete doyle from amazon he posted on twitter a while back about launching an amazon care screen i believe that's in the alexa app or maybe it's in its own particular app but just launching one screen in compose so if you want to get your feet wet that's a good way to do it also he hit another time it said that they brought in someone new you didn't actually have any mobile dev experience and so they pushed their first screen with compose so that'll it'll tell you just like how intuitive uh it is and and also the confidence that people had even before this did go stable so it's pretty exciting i think the current advice coming from google mostly is the best way to start adoption is uh by doing new screens and compose just kind of get your feet wet maybe like a side screen or something like that that doesn't get too much traffic just so you can get a feel for the framework without majorly affecting users in a lot of ways it's similar to recommendations on adopting kotlin in your project where the interop is free complete and there's not really much you have to do to tie your old views to new compose code so even if you have some custom view classes in your existing app it's not too challenging to integrate those into a new compose screen without having to rewrite everything so just like with kotlin you don't have to rewrite any part of your app to adopt compose you can just start right now with a new screen or you can start right now by converting an old screen to compose without really affecting the rest of your app that's really interesting uh because four years ago we did have lots of clients who were migrating from java to kotlin and they would give us numbers if we're 20 kotlin or 80 kotlin what their ambitions were and i imagine that's going to be happening with compose2 and when they were adopting colin there were reasons to not just because it's the new i thing it's going to be about just like making it easier to reason about how your screen works how it how it changes when the user is interacting with it and it's just like making it simpler to write all of that code like i think things are going to find it's it's a better way to to build their ui and so they're they're going to want to start using it good point of compose is how much easier and like faster it seems to be to build ui so especially for like larger companies when the end goal isn't going to be any different you're probably going to be handed a link to a figma or something like that from your designer they don't care what framework you're using at all they just want it to look exactly like they told you it should look but when you start trying those things to compose and realizing that getting these streams thrown together in a matter of hours or days instead of weeks or more you're really gonna start seeing the benefits of making the switch i think if you're a designer too and you want things to be just so it's really nice you know to be able to have that if you say you make a card um view you know like you'd have in normal android uh material design and say you want just a little cut off of a corner of the bottom right corner of the card you know you don't have to do any special like vector drawable or some like you know magic to make that happen you can just add a modifier on that corner and boom your design is done so when you want to make a really really pretty and very particular types of ui without spending all day on it compose is going to be a really great tool yeah i think maybe an interesting way way to talk about what radio is describing is there's been a chance for for kind of the android team to like because they're kind of doing a whole um rewrite of view system they're able to um kind of walk back some of the decision some of the api decisions that made things harder to do historically um and and they're able to kind of like take all the lessons that they've learned over the last 10 years um and and apply it to to the design of this new api um that ends up being easier to use um so it's it's like faster to build with and you can do more things i i think when you're a large enterprise there's there's always just this like extra bit of confidence that comes with with something being called stable um like what what i mean secondly is generally that um it's not gonna kind of change underneath you in a breaking way um so you can trust that like if you start if you introduce some compose code into a code base um it's going to remain compatible as the framework evolves often even when things aren't perfectly stable um it's possible to to deal with that like like when an update happens you have to make some changes in your app and um a smaller team is usually more comfortable with that than a larger team um with the risk of like is that going to slow us down knowing that uh yeah that you have those ability guarantees knowing that um that it's kind of reached this milestone where it has that level of support is a good kind of confidence booster to get people to be ready to adopt it you need to use um kotlin 1.5.10 right now for the time being to use uh compose so you can't go on to 1.520 or the 1.530 uh preview um but yeah 1.5.10 is super modern and with the release of composed to stable it also means that you can have the full composed tooling in android studio from the stable channel so you don't have to be maintaining you know a canary version of android studio and then a stable one you can just go full on a stable from now on which is going to be really really nice for reliability and making sure everyone has access to the same tools yeah that's a really good point that we haven't gone into much is this like compose is not just like the code that you're writing but there's also a lot of nice stuff in the ide around it like i've i've never really been a big fan of kind of like the um ide preview kind of like graphical ui builder kind of stuff but compose has like compose has a really nice preview engine it makes that kind of cycle of of make a change and kind of see what it looks like uh go a lot quicker which is nice it's pretty incredible um on the right hand panel you can just see things uh previewing as you update them as you put the app preview there and you can see them in dark mode or light mode you can have different different screens sizes um you can do foldables uh you can add a system overlay too to see what it actually looks like like on a phone uh so yeah it's very powerful especially especially the live literals tool too i mean what really makes compose shine part of what makes it shine is the tooling too also you know added the capability of doing layout inspector for composable ui as well which is really helpful yeah i think uh moving all of the composed tooling into the main release branch of android studio is really going to help with adoption because that was probably one of the things holding some teams back where if you wanted to decompose not only did the person working on it have to install android studio canary and set it up with all their settings and i'm sure you know most people have their like vast array of changes that they've made that they've forgotten about uh but also anyone who wanted to run the app after that would also need to do that so it would kind of force your entire team to transition to a somewhat unstable version of their ide which uh i'm sure a lot of larger teams are reluctant to do because when it's two people it's a lot easier than when it's tens or dozens of people who have to make that change so now that all of the tooling that is needed to effectively uh build compose and develop it is in the main branch i think that'll really speed up adoption yeah so um justin actually dredged up uh an old article from a reddit trend where people were building like the most abhorrent difficult to use volume slider uis that they could and throughout the recommendations that someone could try implementing some of those and compose i kind of use that to really dive deep into understanding the framework i had done a little bit of composed stuff before but nothing beyond like the basic list views and things like that and overall i mean it was a super enjoyable and like simple experience like there's a lot of things that i saw in some of those examples that don't feel confident that i'd be able to do for at least very quickly without taking a few days to learn something in the traditional view system whereas it composed not only is it a brand new thing that i haven't done before but on top of learning the framework itself i learned the tools and skills i needed to implement these things that are a bit more complicated all in the course of a couple days which really shows how much more straightforward and efficient the process of developing opposed uis is i'm really happy you did that i i wanted people i want people to have fun with what we're making and with compose you definitely can have fun it was just an accident that somewhere in my twitter feed one of these bad volume controls showed up and i was just like hey let's do this and compose and thanks michael for jumping on that it was a great time i really enjoyed it i kind of like ran away with it a couple days and just like oh what if i did this this is even worse and really ended up with some horrendous uis that i mean that the code that wrote them is clean and you know i think uh an intentionally bad ui is as difficult to write as a really good ui yeah i really like it too as um and it's sort of what you're saying that it's about how it's much easier to do that sort of thing in compose than in the traditional ui framework but it's um it's it's a really neat example because it's like it's um user interaction based and it's like sort of animation-y um it's all these things that like we often avoid in our our first pass at things in the traditional system because it's just kind of like a bunch of extra overhead and now it's gotten a lot easier to do which is really cool i started playing around with it just like doing some image transformations uh and just kind of having having fun with that because we have accompanist which is which is great uh what allows you use coil and compose uh images um but what i really liked was um just making like a simple dnd spell app with just it's just like a normal phone app or whatever but you have a list of these things and instead of doing master detail which you usually do for android i was thinking what if i just make it expandable so you click on it and then it'll just show your entire like all the details of it you can collapse it again um and then you don't have to have that jarring kind of flash from one to the other and that was really that was really cool because the animation apis let you let that just happen just effortlessly so yeah i really like that and i think i think it's going to change how i think about after detail and navigation and animations so one of the things that we always kind of say is one of the big benefits of kmm is the modularity of it um so like um compared to two other uh ways of doing cross-platform mobile kotlin doesn't make it any more difficult to drop down into native and use any kind of new existing native tools so so it's it's a neat example of of of seeing like there's there's this like brand new thing that's going to transform the android ecosystem and we can kind of adopt it right away um without needing to change anything else about the way that we're uh doing our um kmm setup yeah that optionality and modularity risks risks are bad but taking risks are not always bad you need to be deliberate and make the right choices around those risks to move forward in anything that you're doing so with jetpack compose we're saying there's gonna be more adoption now that it's stable because the risk is lower with kmm you can uh take parts of your app and try out km and it used to be more experimental than it is now so the risks continue to be lower and the nature of it is lower just like with jetpack compose there's optionality just try it on one screen the risk is lower so you can make those decisions you're not going to break your company and your product by trying these things out now and i think with jetpack compose being version one we've we've seen jetpack compose on web and on desktop already utilizing the fact that kotlin is a multi-platform language and with the stability around jetpack but it just opens up more doors for people to try it out on different platforms i really um i'm just really impressed with the the new compiler um that's that's what really makes kmm and compose possible is um is this new ir back-end so the intermediate representation of your code it will you know the compiler is going to parse it and then it's going to put it into it this abstract syntax tree and and from there that that is where the compose compiler now is going to go in there and rewrite those functions with these uh with a couple extra parameters in them and then it'll it'll make you know the state management and drawing on the screen possible now when composers first being developed this wasn't there and so they had to do some really difficult things to rewrite uh the byte code but now you know compose functions um you know it looks like an annotation processor but it doesn't generate code or rewrites it what's what's really cool um is is that you know you don't have to you don't have to be really deep in the weeds if you want to write a compiler plug-in just like that you can plug into the i mean the ir compiler plugins are not easy they're not easy by any stretch of the imagination but they're also not as hard as it used to be either that's kind of like what what made kotlin multi-platform possible it used to be that your kotlin would compile directly to jvm and they would compiler directly to native and that would take a longer time but now it just once it gets into the intermediate representation now we can deploy it to jvm and deploy it to js and compile that to native as well for ios and other platforms so i'm just really excited about what the development of this ir and the fi are coming up is going to make possible it's going to make like a huge dent in meta programming i think it's going to be a really cool time yeah i just want to make one small corruption which is native actually was always building ir like that was where they were first uh first prototyping it um but yeah only only in the most recent version does uh does the jvm use it by default and yeah i guess it's gonna still be a long road getting there but there's definitely some really neat uh multi-platform use cases that will that will start to open up more and more as as composed for desktop and host for web and compose for whatever else starts to develop it goes back to our parallels with kotlin as a language people were using kotlin in production before google said this is now the official language on android and that was also important to people as they're watching should we adopt this now if not many people were using it in production already and it became 1.0 there'd still be a lot of risk around it um like okay this means it's probably not going away this means it's probably we're not going to need to rework a lot of stuff since it's stable but if nobody's really using it you don't have that confidence but because people were already using it they're already using jetpack compose in production 1.0 is icing on the cake it's showing that it's it's recommitting to compose as the way forward for android
Info
Channel: Touchlab
Views: 742
Rating: 5 out of 5
Keywords: android, development, design, mobile, web
Id: CA6KYa0MvPo
Channel Id: undefined
Length: 25min 14sec (1514 seconds)
Published: Wed Aug 04 2021
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.