Hello everyone! First of all, I'd like to thank an...

# compose

[Rosen Dimov]

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]

The performance with the scroller inside a constraint layout could be from this https://issuetracker.google.com/issues/163100572

[caelum19]

try setting all of the constraints to fixed values

[Rosen Dimov]

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.

[Rosen Dimov]

Ah I see, you mean to use Dimension.value and Dimension.fillToConstraints only. And no refs and linkTo anywhere?

[caelum19]

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

[Rosen Dimov]

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! :)

[Mark Murphy]

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.

[Rosen Dimov]

@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]

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 😄

[Rosen Dimov]

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]

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

[romainguy]

I definitely don't miss it :)

[romainguy]

Also we nest function calls not objects. And fundamentally it's no different than with a markup language

[caelum19]

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]

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.

[romainguy]

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).

[Rosen Dimov]

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!

[romainguy]

Is it slow just with ConstraintLayout or with Row/Column as well?

[romainguy]

Either way it shouldn’t be slow, sounds like a bug 🙂

[Halil Ozercan]

@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.

[Rosen Dimov]

@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.

[romainguy]

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

[Rosen Dimov]

Either way, I added links to both versions of the composable in the main post

[romainguy]

So both versions are slow?

[Rosen Dimov]

Yep, first I went with ConstraintLayout, then rewrote it to Rows/Column, but no change at all

[Rosen Dimov]

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.

[Rosen Dimov]

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). 😉