r

    Rosen Dimov

    2 years ago
    Hello everyone! First of all, I'd like to thank and salute you for your efforts in modernizing the Android SDK! It really looks way better with compose. I'm a web developer using React in my daily routines and I'm currently learning mobile development, right now playing with the Android SDK. So applying programming styles from React in Android really appeals to me. I have a few questions for you, guys: 1 - What is the state of compose in terms of performance (more specifically list-displaying composables)? I tried using
    LazyColumnFor
    , because I wanted to migrate an adapter which has two view types (both written in constraint layout). I migrated the XML definition of the CL to the equivalent
    ConstraintLayout
    composable, using
    createRefs
    for describing constraints, and
    start.linkTo
    ,
    top.linkTo
    , etc. (part of 0.1.0-dev16 version). Scrolling was very slow, compared to the adapter approach where things are smooth. Here's a gist of the composable. Here's some relevant code:The activity which sets the root composable (the list) - grabs first a bunch of data from a Firestore and calls
    setContent
    The list, based on LazyColumnFor The repeating item - with ConstraintLayout, and with Row and Column RoundedImage composable - a simple card view with circle shape The customized button 2 - Have you considered taking an approach similar to JSX in React, something like files with both Kotlin code and some sort of markup for definition of the view itself. Seems like the main drawback of the composables is the nesting of objects that happens in code, and to me at least, it seems more natural to express certain hierarchy of components through a markup language (don't get me wrong, moving to composables in their current state is already a big step, just my thoughts as React dev 😉 ) 3 - For beginners like me, is it worth diving deep into things like activities, fragments, navigation in its stable state, lifecycles of fragments/activities, different kind of layouts, etc.? I'll probably not be working on professional Android projects (if I decide to take up mobile dev in my work) by the time stable version of compose is released (in the beginning of 2021, from what I know). Thanks and have a great day! 🙂
    caelum19

    caelum19

    2 years ago
    The performance with the scroller inside a constraint layout could be from this https://issuetracker.google.com/issues/163100572
    try setting all of the constraints to fixed values
    r

    Rosen Dimov

    2 years ago
    Sorry, a little unfamiliar with the terminology, what do you mean by "fixed values"? I also added a link to a gist with how it looks like in the post.
    Ah I see, you mean to use
    Dimension.value
    and
    Dimension.fillToConstraints
    only. And no refs and
    linkTo
    anywhere?
    caelum19

    caelum19

    2 years ago
    hey, yeah Dimension.value, sorry I wasn't clear 😄. I think fillToConstraints still had performance issues for me. I think it may only be important for the dimension that the list scrolls in, so start.linkTo(start) may be okay if it scrolls vertically
    r

    Rosen Dimov

    2 years ago
    Okay, I'll try with horizontal constraints only and probably hardcode the height or something to see what happens. I'll get back to you about this, thanks a lot! 😃
    m

    Mark Murphy

    2 years ago
    For beginners like me, is it worth diving
    deep into things like activities, fragments, navigation in its stable state, lifecycles of fragments/activities, different kind of layouts, etc.? Activities and their lifecycles still matter. Navigation will still matter, though using the Kotlin DSL, and its support for Compose has not yet shipped. The classic
    View
    system ("different kind of layouts") may still matter to an extent, simply because not everything will be Compose-ready soon (think
    WebView
    ,
    MapView
    , ExoPlayer, etc.). So, ideally, you have at least rudimentary understanding of how views work, even if you skip the details of things like
    LinearLayout
    . Fragments can be used with Compose, though I think that will be more for people migrating from the classic
    View
    system to Compose.
    r

    Rosen Dimov

    2 years ago
    @Mark Murphy thank you for the explanation, I already learned the basics of the things I mentioned, it might be just enough for the future, we'll see.@caelum19 I wasn't able to arrange the constraint layout without vertical constraints, so I went using Row and Column composables. Here's another gist. Still scrolling is quite slow. 😕 Just for the record, that
    WallpostButton
    composable is a simple button with an image and configurable text. Seems like performance is yet being tuned maybe?
    caelum19

    caelum19

    2 years ago
    Hmm try simplifying until the lag is gone - does it still lag when you have empty coloured boxes instead of WallpostButtons? how about coloured boxes with text in them? Also, is this WallpostView what is inside of a LazyColumn? Is that LazyColumn constrained? that was what I originally meant should have fixed values. Sorry I wasn't clear again 😄
    r

    Rosen Dimov

    2 years ago
    Thanks again for replying @caelum19. I added the code for the activity that sets up the composable hierarchy, the list with
    LazyColumnFor
    and the customized image and button as gists in my main post. I tried using a
    Box
    , with a single column and text in it - yes, there's a significant difference now, but still the first few scrolls are laggy and scrolling speed is slower (yet smooth) than with adapter. And I forgot to mention - I'm testing on Nexus 5X.
    Adam Powell

    Adam Powell

    2 years ago
    Re. The jsx question, yes, we originally started there and moved to the current function call syntax. A couple members of the team still miss it deeply 🙂 It's not something we're looking to go back to
    r

    romainguy

    2 years ago
    I definitely don't miss it 😃
    Also we nest function calls not objects. And fundamentally it's no different than with a markup language
    caelum19

    caelum19

    2 years ago
    I really like how we don't need to go to the effort of returning everything up that needs to be drawn. I think it is a confusion every react dev faces when they're learning when something inside a for loop or if statement block isn't showing, and it's nice to just use an if statement instead of conditionally setting a variable and returning that
    Halil Ozercan

    Halil Ozercan

    2 years ago
    Please don't go back to using a markup language. Flutter was a breeze to work with even though I hated Dart coming from Kotlin. The reason for that was the predictable syntax of widget trees. I didnt need to learn how to reference variables from code or reserved keywords. Also, I think current composable way is even better than Flutter. Sometimes it takes a little bit more attention to figure out which Composables actually do the drawing but I still prefer it.
    r

    romainguy

    2 years ago
    Those are very much some of the reasons why we dropped the XML syntax. We realized we were effectively trying to recreate existing language features (to be clear @caelum19, you can have the XML syntax and still use if statement). But it became clear after a while that XML tags were effectively function calls (although they did give us some flexibility that we don’t have with functions).
    r

    Rosen Dimov

    2 years ago
    Thank you a lot everyone for the in-depth explanation and reasoning behind the syntax! It's really all subjective if markup is better or not for mobile development (but I can still understand the people in your team preferring JSX 😛 ). The thing I'm mostly concerned though is the performance (in point 1 of my post), can you confirm if I'm doing something wrong or it's just not ready yet? It's just that the classic Adapter is way faster than the new
    LazyColumnFor
    right now. Thanks!
    r

    romainguy

    2 years ago
    Is it slow just with
    ConstraintLayout
    or with
    Row/Column
    as well?
    Either way it shouldn’t be slow, sounds like a bug 🙂
    Halil Ozercan

    Halil Ozercan

    2 years ago
    @Rosen Dimov I was going to ask you if by any chance you were using images in item views but then checked out your code and it seems like there is at least one image view in items. I also had troubles when I introduced thumbnails. Have you tried checking out if your image loading had anything to do with performance? Because scaling down a higher resolution image turned out to be very costly in my case.
    r

    Rosen Dimov

    2 years ago
    @Halil Ozercan I have two images - one png which is small (which is used in the RoundedImage composable) and also one vector image, again small in size. In both cases no resizing should happen. Actually the original XML view with adapter is even more complex, using Glide to download and scale bigger images.@romainguy Should I open an issue in Google Issue Tracker? If so, is it enough to provide the gists I have or additional information is needed? And just to mention, I have a similar sample with Flutter (a few months ago when I just wanted to try it out). I used rows and columns there together with ListView and scrolling was smooth as with Android's adapter.
    r

    romainguy

    2 years ago
    Right but I was asking about your Compose version. Is it always slow? Or only slow with ConstraintLayout?
    r

    Rosen Dimov

    2 years ago
    Either way, I added links to both versions of the composable in the main post
    r

    romainguy

    2 years ago
    So both versions are slow?
    r

    Rosen Dimov

    2 years ago
    Yep, first I went with ConstraintLayout, then rewrote it to Rows/Column, but no change at all
    To avoid lenghty discussions here I posted an issue in the tracker: https://issuetracker.google.com/issues/165028371 Sorry if priority/severity are wrong, but I copied it from the issue that @caelum19 provided in the first comments: https://issuetracker.google.com/issues/163100572 It's just a similar issue to me.
    Sorry all to ping you again in a rather finished discussion, but just for anyone curious to try out a sample project, I added one attached to the issue (with latest dev17 version). 😉