What's New in Jetpack Compose (Android Dev Summit '19)

[Music] good morning and welcome to what's new in jetpack Campos I don't know why it's called that because this is not really where the talk is about it's more what is jetpack Campos anyway I'm alone I agree I manage the entreated team at Google I'm Kara Valeri and a technical took it and I'm Adam now and I'm also a tenant okay and the toolkit now is also detect impose my clicker any debt all right so what is the packing towards the real title so according to developer.

android.

com jetpack composition modern toolkit for building a native Android device and it simplifies the next story to a development blah blah so in carefully so instead of trying to tell you what it is I think it's more useful if we try to tell you what kind of problems were trying to solve what kind of goals were trying to achieve would jetpack compose we did some of that energy it's me again same shirt same pants different what yes so Adam and Jim were with me on stage and did most of the talking so we explained some of the reasoning and I wanted to go over other points the first one for us is to simplify the development and we all got used to the complexity of Android development and the complexity can mean many different things you know some of IP is audio awkward to use you have to manipulate different files different languages so I want to show you an actual example so that's something that Jim works on the compost compiler and runtimes came up with to try to convince a bunch of people internally that compost is a good thing so the idea is to build a simple app where you have a list of names and you just want to type something at the top and it's gonna filter the list so how would you do that with the existing UI toolkit you start with a simple XML file you know you're all used to that to recyclerview ready text in the layout all that good stuff then you need another XML file for each list item in the list so we already have couple files in XML then you need your filtered list view that's just going to do the find you by define GD text set up the listeners find the recycler view set up the adapter I'm not even showing the activity here finally you need the adapter itself so actually it's funny because when I put that on the side I'm like wait is that the best way we have to journalist so I googled it and turns out because I did write some of the filtering API for adapter so I thought it was a better way turns out there's not really and there's a lot of blog post articles and even Stack Overflow questions on how to do this I'm proud to announce that this is one of the simpler ways and then you can use rx Java or you know fancy frameworks to make this happen anyway that's all I've code it's annoying it is not simple so this is the entire compose version all the code you need easier on-screen much easier it's going to be a lot easier to find bugs and more importantly when you read the code it's pretty abuse with the intent of the code is like you know whoever wrote that could what they wanted to do so you you say I want to ask order I want a column of text fields sorry I want to call them with the text field at the top and for each row I want to imagine a piece of text and as soon as you change the content the content of the list to contact list everything updates as you would expect another thing we want to do is fix what's broken so that's our API regrets we talked about this at Google i/o and invite you to watch the talk if you want to know more we had a few funny anecdotes one of the good ones of course is vue de java that now clocks at around 30, 000 lines of code sure there's a lot of comments in there but still a down from some point yeah but still it's a lot so the plan for us is you know also we have a lot of baggage in history so there are things that we just cannot fix we know there are columns but we just can't fix them we could introduce new bugs or apps maybe relying on the current behavior so we're kind of stuck we can't really do much more with the existing UI chocolate we want to start seeing this is something we did originally and I think Adam recently you said on the cutting length slack channel that you really really want at high to disappear so if you ever looked at the source code of the Android platform we have this magical annotation called ID hide which turns public API into very private api's and super useful to us it was a way to work around some of the limitations of the java programming language but it led over the years it led to two to two an issue for us for instance let's say you want to do something with textview that takes two dozen two out of the box you have your sensor is like write your own text view while you start pulling that thread and then you're grabbing like the entire text package and you run into priority PS all over the place and you do anything about it so that's an issue for us and it's an issue for us so what we want to do with Campos is we don't want to rely on private DPS anymore we can I have to at the low level to interact with the platform but all of our widgets are built entirely using public ApS that are available to you and I'm going to show you actually an example of that and the good news is is that it's kind of forming a forcing function for us to open more things in the platform itself along the way and we have to think a little harder but what we would reopen Metsu and animations oh my I had a pretty hard emoji on the slide it's gone anyway all right cards anyway so we want you know now we're in the metal design world the existing UI talk it was built before metal design with the thing so the good news now now we can Technogel design into account this is what a client her team do in London and we also are building animations you know in strong collaboration with the rest of the of the composed way toolkit so we expect it's going to be easier and more powerful than it was in the previous in the existing one a two sprues composed same thing when we build the initial UI toolkit the existing one there was not that much interaction with the toasting because the toasting was very small so one of the tools games came after the fact so you know the visual editor the motion out that you saw in the keynote and we want to change that and you just saw that you know we're building things like live previews are composable right now as we're building compose itself Kathleen we adopted Kathleen we announced that we want to go cut in first so that would be one thing for us to tell you to go cut in first and we thought that maybe it was a good idea to do what we say that you should do so compose is written in cutting and cutting actually unlocks a lot of the things that we do in compose the web we design the API is possible thanks to cutting where we rely heavily on lambdas for instance and we plan on using fun features like aubergines adam is chomping at the bits to encode all of our compost and finally compatibility is something that we deeply care about we we are not asking you to rewrite your entire app if you want to adapt compose you know once it's ready for production we don't expect you to just delete all the code like we did for instant run and to start from scratch we want you to write you know your next activity or in Ex fragmented but you reuse some of your custom views and chances are that some of the the exist interviews we won't even rewrite ourselves so things like surface view or web view I don't think if any of you wants wants to write a new web you like please come help us but we're not gonna do that so we're gonna use the existing web all right and finally this is what with the technical stack of clippos looks like so on one hand on one side we have the the build time stack so that's on the host what's wrong is on your machine so we use a slightly modified code version of the curtain compiler so we work closely with JetBrains we just added a couple of compiler extensions in collaboration with them and we use those extensions to enable our compost compiler plugins so it's funny because last week people saw that we had the artifacts on maven for compose and people started using them in the like I'll grade each works were like no it doesn't work in the compiler that we haven't released yet like you know it works the reason it seems to work is because the syntax is just kirtland's with just invoking functions it was just not very reactive at all which is kind of a bummer anyway and so we also have Android CO and then on the runtime side so compose at the bottom is a runtime that just deals with trees it knows how to produce trees it doesn't know anything about UI toolkit so we could really use it to do other things than UI then we have the UI core the UI foundations and finally on top all all the widgets so that's pretty much it and now Claire will tell you more about how compose actually works when you write good thank you so you want to walk it through sorry I want to walk you through some of the things that you need to understand to really be able to play with composure some of the basic concepts the first one is composable functions I know Ramana has kind of thrown this term out a few times and composable function is just a function it's function that takes some input and just decides what you are to show based on that input so in a way it transforms your application data into your UI hierarchy creating an composable function is very very easy so for example we have a screen income first of all and it takes a name as a string and it just decides to emit a text element that uses that string text is one of the components that we will provide for you it is the equivalent of a text view so it shows the text on the screen the interesting thing here is because we have the run time and the compiler behind us whenever you change that input to say the name you're gonna pass through changes well then we take care of figuring out what change Rhian voke the function figure out what we need to change in the UI hierarchy for use so at any point you are just describing what you want to see and will take care of the rest say for example we want to build a news story we can actually emit several composable x' within a composable function so we can emit say a title subtitle and a date and we're just gonna build our news story this is absolutely fine but you will find you kind of need to have an opinion on how you want your UI to show cuz if you just do this you will end up with something like this which is not really what you wanted so this is where concert number two layouts come in and we are building out a bunch of layouts for you out of the box to make sure that you can place things on screen as much as you want and so for example we can wrap those three texts in a column and column is the equivalent of a vertical linear layout so we'll just place everything one on top of the other so then suddenly this looks more like what we were expecting right so we have our title subtitle and date still Android developers are used to being able to customize a lot of things you'll be like ah you know this is nice but my text is really stuck to the side of the screen so we can go a bit further add some spacing and what that will do is just create the spacing around it that we need to make it look a bit better so until now we've built this entire UI just with like one function right going a bit further like column doesn't just take text I know I use three texts as an example but we can throw anything in there so for example we can just display an image by using a image composable and then build up our UI in this way oh yes sorry we're providing them in two layers out of the box there you go um we have row which will place things horizontally we have column which will place things vertically those are easy to understand we have more events things for example we've introduced flicks which is I believe is new to Android and we're building a bunch more there's a bunch more in there that you can go and play with and we are working on constraint layout but it's just not there yet um so look forward to that coming and then well we've built the layout but really what you want is for us to build components for you right so compose comes with a bunch of built-in components that you make it really easy for you to get kick-started first of all we've partnered very heavily with the material team because we want to make sure material is out of the box just there for you so we've started creating the material components they're not all there yet but the team has already been hard at work to be able to create those beautiful UIs and we already have things like buttons checkboxes and I think more complex things at bars drawers some of these pieces are in there in flux we'll get there but you already have the basic pieces to build something like a sample app so saying we want to buy we want to build this material card building up on the example we had before with the image in the three techs well we'll take the kid we've had before I haven't changed anything we wrap it in a card and we can give a card or a shape because there's a material thing that you can choose what your corner should look like so for example I want rounded corners on my card we can style the text to look prettier than it was before with the three same styles you'll see here you're reaching into a themed textile this looks a bit weird let's take a step back to the material spec so in the material spec there's a definition of all the typographies that you could define in your app so how you define all the styling of your entire app there's a preset amount of textiles that you can use just like they have a color system in a shape system we've built this out of the box for you so if you buy into the material system we have a material theme composable that allows you to configure all of the colors all of the typography all of the shapes you need for your app and then when you put this in your hierarchy any other material component you're using will know how to read all these values by default so you don't have to to stop them similarly you can reach into these values and that's what I'm doing in this example so I'm sitting out of these three texts I'm reaching into the style and saying I want h6 subtitle 1 and body 1 it's a very easy way to style if you've set up all your stunning for your app correctly and finally to finish the app I can add a row with a couple of buttons again we've provided the material implementations of buttons so material defines three different kinds of buttons there's contained outline and text buttons and you will find that we keep the same terminology to make it easy to find things and so we have contained buttons outline buttons and text buttons available so all of the material components we provide we've built purely on the public API from layers below us um so compose UI core provides some foundation for us and we built everything layered up on top of that so we tried to not cheat with any private API is this means that material should be a showcase of how you can build components we're hoping there samples right like they're very useful components or at the same time it should be code that you can go in and read and see how we've done it and take those examples for yourself we've also tried to break everything down into multiple layers because you can break everything into more and more functions to make sure there's as many reusable bits in there as possible for everyone and as part of that we've created this foundation level in the middle the main idea there is there's a lot of material that is not necessarily a design specific there'll be a bunch of gestures accessibility that we've implemented to do a button so we can put the actual button in material but then we can put the internals of the button in foundation so all the gestures accessibility other things that we've built that are not UI so that you don't have to start from scratch you can already start from that layer and just build your UI on top and then no matter how many components we give you there's always going to be custom views that you want to do and there's always going to be that designer that asks for a very strange thing that we had never anticipated so the bet so in in the existing toolkit you have to extend view you have to take care of a bunch of things it's a lot of work to create a custom view and compose is extremely simple you just have to create a function and there's some building blocks that you can do to help you build up that custom view the two basic ones are draw and layouts so draw will give you a handle into doing any kind of custom code that you want say for example we want to do a check box and a check box is just a square with rounded corners and a check mark right let me walk you through the code to do this because it's quite simple to draw the box we open a draw tag we get access to a canvas and the sizes we've been measured to so we can easily calculate how much do we want our square to be apply the rounded corners and then there's draw the square same for the check box sorry for the check mark will open a draw we have access to the canvas and the size we can calculate the three points that make a check mark and then just draw those on the screen it's a surprisingly simple the next part is layout of course we will try to provide as many layouts as we can out of the box there will be some always something that you want to do that is extremely custom well you can reach down into the layout component I've just showed here an example the most simple example I can find is a stack or a frame layout right like stacking things one on top of the other so you will create a function that takes a bunch of children that it needs to place we open a layout tag we can action access to these children there are measurable pieces and all the constraints we have and then we just have to go through two easy steps we measure each of the children to make sure we know what size they want to be and then we decide what size we want to be so for example in a stack I'll probably want the maximum of the children to make sure they all fit and then I'll place them each at the zero zero coordinate because that's what a stack would do so then we'll end up with an effect that is something like this all right so what we have today like I mentioned in the keynote we just released our Developer Preview it's called zero point one point O – dev o – so if not fair enough it is not quite ready for production but I want to show you some code and a demo so you can switch to the demo machine feels alright so one of the simple apps we have is called jet news you can see it on the right in the emulator so it gives you a good idea of the kind of things you can already build today we have no horizontal scrolling please vertical scrolling list the tech stack is already pretty advanced we can do a lot of like you know complex text layout and styling so this is a very interesting to to look at it's all real a pack is not connected to a database or web service you know keep the samples simple but it's a very good example how to create your own widgets and reuse the existing widgets so what I wanted to show you is what you see here so yesterday I built this little to-do list app so every deal fab icon in the bottom right and when you click on it I just want to add list items and each list item will have a your bookmark icon that I want to be able to toggle so the way it works you hear my demo is a simple data class in Kirkland is the text big enough by the way on the screen for everyone all right assume it's yes so we have a data class it's immutable everything's a vowel and you can see that sorry an item can be a favorite and just as a description in an ID then the actual model for the app is just this empty list of to-do items and it's gonna be an immutable list and I wrapped it into this object that's probably not how you would do it in a real application an object like this was a global object but I use this at model annotation and added model basically turns the subject into an observable observable object so whenever I change the items property the UI what we can post automatically and Adam will tell you more about this and if you want to know even more details Leyland as I talk tomorrow explains how it works internally the compiler this is the main part of the application so very similar to what we saw this earlier in the keynote have a vertical scorer I have a column I just iterate over all the items and then for each item I create a row you can ignore the do layout parameters but at this book my bookmark icon so this is a computable I created and one of the things I really like about composing that there was one of the things we really wanted to do we wanted to make it easy to create your own widgets like very often in Android applications we end up with very large XML files because it's very cumbersome to create all those XML files doing the fun job ID you know doing the includes and the merge and all that stuff and here all you have to do is like when I first wrote this application I wrote everything into these items composable and then when I saw that at this bookmark icon composable I just selected it extracted a method using a refactor in IntelliJ and I just added my add composable annotation and that's all you need to do to create a new new component you know you don't have to extend from view of your group in overwrite methods and then I just have a small spacer and finally the piece of text that that describes the item so the bookmark icon is here and here you can see another interesting oops I'm revealing what I'm going to type that's med sheet in case I forget what to do so my bookmark icon is pretty simple it takes one of those to-do items it's right by a clickable so that's how you create a click listener really and inside all I do is I have this branch and I say if this item is a favorite then I want to show the image that corresponds to the favorite state and if it's not a favorite I want to use the other image so it shows you that you know it's not just about using for loops constants for each you can use like any kind of control flow you want and makes the code extremely easy to read and you could do this this piece of code in different ways anyway so I have two callbacks in the app I have this total favorite when we're going to click the bookmark icon and I also have one when we click the fab so I'm gonna try to write them so when we add it to when we add an item I'm gonna take the list of items and I'm gonna add a new item that I currently have in my clipboard so we just give it like a default string in an ID so shall we run that and you can note that so I did write like this no listener I don't call really out request layout when validates and when I click the button anyway time appears in the list and that's all you have to do and that thanks to this ad model right here because we observe that the items are changing but now I want to be able to toggle those your bookmarks like when I click right now nothing happens so the way I'm doing it is because it's an immutable list let's see if I remember so I'm gonna do a map which also fancy I'm gonna do functional programming let's see so if it's it that ID equals item we clicked ID never return a copy and I will do favorites equals not to do that favorites I'm just struggling the boolean otherwise I just leave the item and modified alright that should work we launched the app so add a few items and now when I click it toggles the icon yay and that's why always be prepared right I will make it work oh yeah use the wrong item alright add items bookmark yes all right now it works so again like the point here is to show you like how easy it is to manipulate your data and and to you know build that logic and make it interact with the UI and more importantly like you can keep like both kind of separated or more separate than you could before but Adam will tell you a lot more about that can you go back to the sides peace thank you alright so this is the part of the talk where we talk a little bit more about kind of our design thinking behind compose and kind of what's on our mind so in addition to the team's ongoing work with compose we've also been spending a lot of time talking with the community and some of you who's probably been part of that conversation as well as running some more formal user studies and so here are some of the things that are really sort of top of mind for us that we're excited about or that we think is really kind of important is you take it for a test drive so be careful that some of this isn't implemented yet this is just kind of how we're thinking about some of these open questions so please join us in kind of participating in some of the design process so the first thing that really kind of hits you as soon as you start working with composes the data flow and while some of the tools available for managing that data flow came into compose very early or they existed before composed in in the case of just some of the standard functional and reactive systems that you might be used to the bass best practices in teaching materials around all of this is still kind of a work in progress like we really are building something new here so the Android architecture components libraries have been really successful so far and that set the stage nicely and establish patterns that we've continued with and composed itself so let's go ahead and distill down some of those ideas and kind of see where they lead us there we go so we showed this diagram at Google i/o during our talk on compose there data flow is really kind of the first thing that you encounter like I said the shape of the API more or less enforces this top-down one-way data flow approach is just functions calling functions and most people like this so far so it's always good to have a single source of truth in your UI and it's kind of frustrating when your views have a different idea about the state of your app than your application model does which is definitely the case when you're working with views and the average Android app so what do we mean when we talk about single source of truth and UI well it's about avoiding conflicts or making sure that you're not showing inconsistent data but it's also kind of about who has write permissions to that state so with composed you prevent inconsistencies by having the owner of a piece of state past that state to the other composable functions that need it so the parameters that we call our composable functions with they have to come from somewhere and the source of that data is kind of our source of truth by definition and the interface that we use to pass those parameters really kind of determines what the composable functions can do with it just like with any other function so you see access control layering like this in Kotlin frequently in the standard library you've got the list interface here which only defines the read methods but the methods to actually change that state or to find a mutable list so even if I have a mutable list if I pass it to a function like the aptly-named do stuff over here as the read-only list interface I can be reasonably sure that do stuff isn't gonna change my data out from underneath so from a certain point of view source of truth has to do with who have access to a mutable reference to that source of truth and what kind of mutations a caller can perform with that reference if you can change the source of truth or if you can change the truth in any way that you want are you yourself a source of it kind of so we use event handler lambda as kind of liberally throughout compose because it's kind of a more restricted way to express a very specific mutation that you can make to state without actually giving away the keys in the process so here's kind of what I mean by that we can show this just by using views with some of the api's that you're used to so here i've just added a click listener of the view and inside that listener i'm using the fact that i have access to this my list variable from the example before and that's our mutable list so that's in my lexical scope so i can capture it as part of a listener block and just use it directly I haven't actually leaked a mutable reference outside of this code snippet like the block where this appears is the only place where mutable list is is accessible from anything I haven't permitted mutation in any sort of uncontrolled ways by giving out a reference to it so all my view can do is just tell me that a click happened and I've defined how this higher-level will respond to those clicks given this layers access level so this is a really simple example and we're just kind of using lists and we definitely did so in the demo as well is sort of a hand wave for hey this is the rest of the app model I mean clearly you'll be doing something a little bit more sophisticated than direct mutations on lists so you know bear with us a little bit so a more real example might do something kind of like this so in this sort of sample view binding method I'm setting a click listener and make some requests to my app based on the parameters that I was passed to when the bind happened so just like before with the mutable list I didn't teach buttons how to add and remove bookmarks I defined what a bound button should do when the button raises a click event and I used the context that was available to me when I bound it that's just the lexical scope to form that definition so this is all pretty standard stuff so what's actually new here I mean this this isn't isn't unique to compose here but it's kind of the framing for what comes next which is that compose code is really really dense like we think that this is pretty great that you can remove so much boilerplate but the trade-off for that is that sometimes the distinctions of what you're really doing become kind of subtle when it's compressed into such a small space so let's look at the same pattern that we just saw using compose in this case it's not actually that much smaller it doesn't look that much different we're declaring the actual button is an implementation detail along with its properties so what it's text is and what will happen when it's same thing but the syntax here is kind of interesting it we said before that state flows down and events flow up but we're passing both text and the onclick handler to button in the same way they're both parameters so in a way event handlers are just another kind of state that flows down its state the bookmark button created and that it owns so as far as button is concerned it's just this opaque token that can be invoked so when it is clicked we make a request of this bookmarker objects that's not yet defined here to please add or remove the associated bookmark in response so the book marker might be backed by a local database API calls to some back-end really whatever I can fake it or test it outside the context of my UI but I've defined how the UI itself interacts with the book marker in one place here along with the structure of the UI that it's that's uh being manipulated so book marker can be written to expose whatever operations that are appropriate to its clients like this one so the single source of truth here is preserved so that's a single snapshot of that truth but the real power of a declarative UI framework like compose is that it can keep up with changes over time so it'd be really nice if my code was always this straightforward even when time is involved and when changes over time is involved so we saw a little bit of that in the demo so far so if you want to update the UI in response to changes well you need your data to be observable and composers ready for that we saw in the demo that when you annotate a class with that model that compose will know when its properties change but why did we add something new here the Android ecosystem has a lot of existing observable constructs so what what games do we get from this the justify adding something new well we think that the answer lies somewhere between the ease of understanding of the kind of code that we can write this way and also just kind of the ergonomics of actually using it in practice so let's talk about live data for a moment because it really has some neat properties for building you I fundamentally live data is a single value holder it'll tell you when it's updated so for our purposes in a UI only the latest value matters live data will conflate its values and only keeps the latest one there's no such thing as missing an event you don't actually have an event stream there's only the latest state and that model behaves much in the same way in this regard maybe there we go so let's take another look in an example kind of like the bookmarks code from before if you've worked with Android architecture components view model and live data you've probably seen something like this before the view model sort of becomes this hub for a bunch of different observable data along with some operations to request some changes to that data so we can reflect the same sort of structure with that model but you can see something kind of different here so the has bookmark method that we used in the example before it isn't returning a mapped live data that has to be individually observed it's just accessing internal object State the list of bookmarks itself isn't even public app model has turned any normal reads of objects properties that happen within a special scope into observable subscriptions even if that read happens layers down the call stack if I called has bookmarks through some other helper function that I extracted in a refactoring or something like that even in a completely different class this would still work we don't have to turn it into a stream or live data mapping as each step of the way so if we take a look back at our bookmark button from before we see that our UI can be expressed in terms of these snapshots of state and time and compose can help manage the complexity of wiring these subscriptions together for us even if the actual app model objects might be several layers away across the call stack or across an object reference Jane so compose will automatically insert these observable scopes for us and composable functions we don't even have to think about it so let's go ahead and recap on that so we need observable data compose will add app model classes as a new tool that we have available but the cool thing about it is that it allows for this sort of cross-cutting observability so we can write less plumbing and subscription management code in our apps but the thing is is that all these other observable and reactive systems are great you don't have to leave them behind if they're a natural fit for what you're doing especially if it makes sense in in other layers of your application so if it makes more sense for the bookmarker at this particular layer that I've defined it to return a live data or flow or something from has bookmark then we can still support automatic automated but explicit subscription management by using an effect function kind of like this there we go so that's kind of a tour of the background behind some of that so really what's left for us around data flow is kind of documenting recommendations for the question that's kind of left that you're probably all asking yourself which is which of these tools should I use win so kind of establishing some of these guidelines and best practices or they're still kind of a work in progress here so more things that are work in progress I hear a lot of questions about how to work with resources and compose and kind of what we plan to do there so let's talk a little bit about that too again this is current thinking subject to change but this is kind of where our heads are at at the moment so when it comes to using resources and UI toolkit we can't think that we've learned a few things along the way and this is kind of a big one so really we need to avoid too many overloads some of you might recognize where these are from we have a lot of ways to set an image it's a convenience it's very convenient but the thing is is that this makes the view in question huge in terms of its own implementation but even worse it means anything that tries to wrap or reuse one of these in a composable fashion has to reflect the whole capabilities of the API surface we don't want this so it's annoying for us to maintain and it's even more annoying for anyone who wants to build something on top now there are a lot of reasons why you might want to offer overloads for your own composable functions and we would really be doing you a disservice by asking you to multiply that by the number of overloads that you might need to cover for this form of completeness because some underlying piece that you're relying on offered all of these different ways of doing a single thing so that's something that we'd kind of like to avoid so we've also seen a lot of other libraries appear to fill the gaps in between what Android views offer and what you need in your apps so image loading libraries are a really great example of this there's a bunch of great ones out there and they apply different loading and caching policies for images tie-in to life cycle so on and so forth but really this is because a lot of resources are dynamic they might come from the web they might come from a disk cache or plenty of other places and tying into the appropriate life cycle events as signals it's really not always fun there's no there's a lot to get right by focusing so much on static resources in what we offered we kind of created this privileged type of data it created a blind spot for us when we were looking at the system kind of from the inside and it should be much more straightforward to write these dynamic resource policy layers and static resources should have to play by the same rules so using the same public API surfaces to operate so co-routines are awesome Rahman mentioned like sometimes I won't shut up you've never shut up a bank the only one there are more so we still have a few issues to work out with the experimental compiler around generating suspending code so we haven't done a whole lot here yet but our intention is to standardize on co-routines as our async primitive for working with resource loading whether that's static or dynamic so androids our class is also pretty convenient having a bunch of symbols that will autocomplete for the resources and your app is pretty nice we'd like to keep that sort of convenience but really all of them being int is not so convenient and I'll run into that yesterday while building that demo I would get a crash because the IDE the PNG felled in an XML file with the same name so the runtime would dig the XML file and try to load it as a bitmap in yeah it took us five minutes to figure it out and you know we wrote the goddamn thing like all right I think that we might be able to squeeze one more into this list if someone will get out of the way there okay so layering is a pretty great idea too because once we start talking about type safety and resources and avoiding overloads the natural question comes up why should any of this be specific to compose we're really kind of looking at how working with apk resources might be made better whether you're using compose or not and while we're talking about things that are great whether you're using compose or not let's go ahead and talk a little bit about the view compatibility so we like Kotlin itself so much because you can adopt it in an existing project at your own pace incrementally just a little bit at a time one class at a time one test at a time etc so we're designing compose to be used in the same way so if you have an Android app today you probably have a lot of views at layouts maybe even fragments that you've extensively tested so they work even once compose graduates to a stable release rewriting your existing and working code up front probably doesn't sound so great so you don't have to so let's take a look at a couple of things that we have in mind here and how this might look once we spend a little bit more time here so the first step in Interop for us is being able to use just a little bit of compose inside an existing app the API for this is about as simple as it gets it's just one annotation and this may look familiar if you saw a talk from i/o earlier that you'll be able to annotate a composable function it'll ask the compose compiler to generate a view subclass for you this will host an instance of that composable function with appropriate setters so on and so forth that you can use to feed it data in the same way that you would by its parameters so this will let you use compose alongside your existing view based UI so this still isn't implemented yet but we're pretty confident that this is the way to go and that's kind of the way that things always go right it's like the things that you're most sure about are the things that you do last so if someone that started working on this it's just not finished right so the next step is a little bit less certain and this is something that we're gonna be doing some prototyping on you can follow along with us in AOSP as we kind of play with some different ideas so even if you dive into compose head first you'll probably still need to use views within that UI at some point maybe you're integrating a third-party SDK that doesn't offer compose integration yet you still want to be able to use it so one idea that we've had is to leverage the new view binding feature that you might have seen in recent Android studio builds so if you're not familiar with it if you have xml file that looks something like this if you binding will generate some code that lets you consume it like this so you get a type safe object generated for you that you can use to bind values and listeners to it in code so you can imagine that turning into something maybe like this when you use it from compose well this might be nice for giving life to some layouts that you've already set up and imply some additional work if you just want to use one custom view another idea is that we could use the composition system itself to directly manage a view hierarchy the compose compiler in composition runtime were originally designed to manipulate the view tree directly so here rather than reusing layouts you could use any existing view subclass as if it were native to compose UI but a limitation that this has is that it might make things look a little bit too similar there's really a lot of mismatches at the boundaries and some things like most notably edit text it comes along with a lot of gotchas when you're trying to use it in this sort of reactive style where the single source of truth lives outside of that view so the existing view implementations still fundamentally want to own their state and layout contracts work differently so on and so forth so we're trying to figure out like what what the right balance is with some of these things so this like some of the other design spaces that we just talked about are gonna be occupying a good bit of our time over the coming weeks so we want to be sure that interrupts with your existing code is as straightforward as we can make it while not leading you down a path that ends up creating additional work if your constraints change so we'll keep you updated as development continues but hopefully by now you're asking another question so you've heard what we can do you've heard what we're trying to get to do but how do you play with it well today we've published a brand new website and so Dida Andrew comm slash jetpack compose we've updated the content in the jetpack compose website including for example how to file bugs so please go check that out it's part of that content we've published a tutorial and this tutorial will guide you through the basic principles of compose kind of similar to what we've done today but much more in detail so please go check that out you can read through it and it will make sense or you could go and download the new Android studio build that supports jetpack compose it should be up soon I think you also get a new template you have a tempo for a composer activity and that will set up all your dependencies and everything so you don't need to go read random blog posts it will tell you how to set it up you can try the new preview that we showcased at the keynote you'll be able to preview what you're building with compose you'll be able to see the sample so we published jet news as our sample i showcase everything that is there now and how you can use it to build this news article app and then other things you can try while you're here at the dev summit there's two code labs options happening the code lab is also available online and if you're streaming and we have two talks that you should go check out what's new in Android studio or Turin J we'll walk through the tools that we're building for compose as part of that and tomorrow we have a talk from Leland who's in our compiler and runtime team and will explain a lot more on how the the insides of compose work and kind of demystify the compiler and what we're doing behind the scenes thank you very much thanks [Applause] [Music] you.