Other thoughts from going through the tutorial, ma...
# compose
c
Other thoughts from going through the tutorial, maybe someone from the team will find my beginner point of view interesting? Starting a thread:
1. Does wrapping "elements" in a layout have some quick fix/action?
2. The tutorial preview shows an actionBar/Toolbar on the web. The new compose activity template doesn't have this when you run on a device. For a second, it made me think I missed a step or something.
3. Imports feel wonky? I'm constantly having to import things that should just know to be imported? i.e. I pasted
Copy code
modifier = Modifier.padding(16.dp)
into
Column()
and I still had to import Modifier AND padding. Weird! Then I went into the column to add
Copy code
Image(image)
and I had to manually alt enter and select the import again. It should just know
4. Might be nit picking... but I'm pretty sure in the current android ui toolkit if you import a drawable you should not put it into the /drawable dir, but instead put it into /drawable-nodpi
5. Going off of the image to download and use in the tutorial... that just gets me thinking, can we use the tools:samples/images[0] technique from XML in compose somehow?
6.
ContentScale.Crop
was the next step. This seems to be a center_crop. One thing that was never supported in xml land was cropping strategies. Like crop_top, or crop_bottom. Is that possible in compose? Sometimes from my designers I get requirements of ("This should be a 16:9 image, cropped, starting from the top") and I always had to use a third party imageView in android xml land.
7.
contentScale = ContentScale.Crop
why is this set on the Image as a param, and it's not a modifier?
8.
Copy code
.clip(shape = RoundedCornerShape(4.dp))
Up to this step. The clip portion was red and wanted me to import. I waited like 10 seconds and it seemed to auto import? Maybe the auto import does work, but it's just suppppper slow? maybe a fluke?
9.
Copy code
.clip(shape = RoundedCornerShape(4.dp))
does not reflect in the editor preview... it does in the emulator. edit: wait maybe it does its just super tiny? I think actually the border around the image just hides the corner radius. Leaving me to maybe recommend to not have the border there? Or maybe make it toggleable?
10. Applying `
Copy code
MaterialTheme {
` to the entire column. Same as #1, it'd be nice to wrap quickly with a list of options
11. Now adding style to my Text. I don't know which one to import? I guess I'll try both?
r
For #4 you should only put something in
-nodpi
if you want to avoid density aware rescaling
c
@romainguy don't you always want to avoid that? Maybe I've been doing the wrong thing with the current ui toolkit, but I know sometimes we'd put images in JUST /drawable and hit OOM
12.
Copy code
maxLines = 2,
overflow = TextOverflow.Ellipsis
Again, new to compose so bear with me. Why aren't these modifiers?
r
You don’t want to avoid that no
c
13. "All done"!!! That was awesome. I feel like I can just start building these things like xml layout. I wish I had a drawer or some kind of component library that let me know what is available to me (similar to the "Pallette" pane in xml land). Overall I feel super confident in a short amount of time. Most of my questions above are nit picks but just giving someone perspective if they want to look into it. Awesome job with the tutorial too because it seemed like every time I had a question or went "Well what about this", the next step in the tutorial did that thing, or answered that question. Great job team/whoever set that up!
r
Also
drawable/
is equivalent to `drawable-mdp/`` which will cause your images to be scaled by a large amout
Use
drawable/
for your XML files, etc.
Other wise use the
-*dpi
variants
For 12, not everything should be a modifier
Modifier are generic ways to modify a component (padding, clipping, etc.)
👍 4
Any intrinsic property (maxLines) belongs to a parameter
c
You don’t want to avoid that no
Oh no. I think I followed an old tutorial from google a while back and they put a full bleed image in drawable-nodpi and I always basically followed that convention.
r
nodpi
is useful but you need to have a good reason to use it 🙂
👍 2
c
@romainguy definitely going on a tangent, but yeah I did a codelab in 2015 that used no-dpi and I just thought that's where full bleed images go: https://web.archive.org/web/20190330173245/https://codelabs.developers.google.com/codelabs/android-deep-linking/index.html?index=..%2F..index#1
git clone <https://github.com/google/search-samples.git>
Maybe this was one of those cases where we needed nodpi? 🤷‍♂️ EDIT: Glad I actually was able to find this and know I wasn't going crazy