We're happy to hear this was helpful for you 🙂 If you'd like additional information about Compose modifiers, feel free to check out the resource linked below ⬇ goo.gle/3JlrE82
Was wondering the same thing, but it probably starts with the root node using all available space depending on what type of layout it is (so if compose view is taking up entire viewport, and the first compose node is unbounded, the constraints are probably bound to the size of the screen).
I like this video because it has nice illustrated visual examples, but everything about it works exactly the opposite compared to what I'd normally expect. Odd. As a lot of people do like this, maybe I'm the one working in reverse.
We have some great resources to help you get started with Compose. Check out our Introduction to Compose Basics from our MAD Skills series here: goo.gle/418kdaF We also have a guide on building your first app with Compose. You can find it here: goo.gle/419n1US
Everyone needs to start somewhere. I thought at first, the API looks similar to a builder pattern and so I thought the chain order does not matter. That's why when I realize something amiss with the modifier function(s) behaviour, I look up the documentation and they wrote: "The order of modifier functions is significant".
The `Modifier` is an interface, and every other method you call on it it's just an extension function. Therefore, no the Modifier interface isn't bloated.
@@TheMikkelet Probably because in 2007-2008 Android had to be rushed to the market in order to compete with iOS, which looking back, was a smart choice because Android is now still around. Otherwise, Android would be just like Windows Phone, with a pretty strong tech foundation, but DEAD :D
@@n-o-i-d Android was around before iOS. iOS was just more popular. Android was conceived in early 2000's and bought by Google in 2005. The only thing that iOS impacted was forcing Android to move from being button based to touch based.
