https://kotlinlang.org logo
Docs
Join the conversationJoin Slack
Channels
100daysofcode
100daysofkotlin
100daysofkotlin-2021
advent-of-code
aem
ai
alexa
algeria
algolialibraries
amsterdam
android
android-architecture
android-databinding
android-studio
androidgithubprojects
androidthings
androidx
androidx-xprocessing
anime
anko
announcements
apollo-kotlin
appintro
arabic
argentina
arkenv
arksemdevteam
armenia
arrow
arrow-contributors
arrow-meta
ass
atlanta
atm17
atrium
austin
australia
austria
awesome-kotlin
ballast
bangladesh
barcelona
bayarea
bazel
beepiz-libraries
belgium
berlin
big-data
books
boston
brazil
brikk
budapest
build
build-tools
bulgaria
bydgoszcz
cambodia
canada
carrat
carrat-dev
carrat-feed
chicago
chile
china
chucker
cincinnati-user-group
cli
clikt
cloudfoundry
cn
cobalt
code-coverage
codeforces
codemash-precompiler
codereview
codingame
codingconventions
coimbatore
collaborations
colombia
colorado
communities
competitive-programming
competitivecoding
compiler
compose
compose-android
compose-desktop
compose-hiring
compose-ios
compose-mp
compose-ui-showcase
compose-wear
compose-web
connect-audit-events
corda
cork
coroutines
couchbase
coursera
croatia
cryptography
cscenter-course-2016
cucumber-bdd
cyprus
czech
dagger
data2viz
databinding
datascience
dckotlin
debugging
decompose
decouple
denmark
deprecated
detekt
detekt-hint
dev-core
dfw
docs-revamped
dokka
domain-driven-design
doodle
dsl
dublin
dutch
eap
eclipse
ecuador
edinburgh
education
effective-kotlin
effectivekotlin
emacs
embedded-kotlin
estatik
event21-community-content
events
exposed
failgood
fb-internal-demo
feed
firebase
flow
fluid-libraries
forkhandles
forum
fosdem
fp-in-kotlin
framework-elide
freenode
french
fritz2
fuchsia
functional
funktionale
gamedev
ge-kotlin
general-advice
georgia
geospatial
german-lang
getting-started
github-workflows-kt
glance
godot-kotlin
google-io
gradle
graphic
graphkool
graphql
graphql-kotlin
graviton-browser
greece
grpc
gsoc
gui
hackathons
hacktoberfest
hamburg
hamkrest
helios
helsinki
hexagon
hibernate
hikari-cp
hire-me
hiring
hongkong
hoplite
http4k
hungary
hyderabad
image-processing
india
indonesia
inkremental
intellij
intellij-plugins
intellij-tricks
internships
introduce-yourself
io
ios
iran
israel
istanbulcoders
italian
jackson-kotlin
jadx
japanese
jasync-sql
java-to-kotlin-refactoring
javadevelopers
javafx
javalin
javascript
jdbi
jhipster-kotlin
jobsworldwide
jpa
jshdq
juul-libraries
jvm-ir-backend-feedback
jxadapter
k2-early-adopters
kaal
kafka
kakao
kalasim
kapt
karachi
karg
karlsruhe
kash_shell
kaskade
kbuild
kdbc
kgen-doc-tools
kgraphql
kinta
klaxon
klock
kloudformation
kmdc
kmm-español
kmongo
knbt
knote
koalaql
koans
kobalt
kobweb
kodein
kodex
kohesive
koin
koin-dev
komapper
kondor-json
kong
kontent
kontributors
korau
korean
korge
korim
korio
korlibs
korte
kotest
kotest-contributors
kotless
kotlick
kotlin-asia
kotlin-beam
kotlin-by-example
kotlin-csv
kotlin-data-storage
kotlin-foundation
kotlin-fuel
kotlin-in-action
kotlin-inject
kotlin-latam
kotlin-logging
kotlin-multiplatform-contest
kotlin-mumbai
kotlin-native
kotlin-pakistan
kotlin-plugin
kotlin-pune
kotlin-roadmap
kotlin-samples
kotlin-sap
kotlin-serbia
kotlin-spark
kotlin-szeged
kotlin-website
kotlinacademy
kotlinbot
kotlinconf
kotlindl
kotlinforbeginners
kotlingforbeginners
kotlinlondon
kotlinmad
kotlinprogrammers
kotlinsu
kotlintest
kotlintest-devs
kotlintlv
kotlinultimatechallenge
kotlinx-datetime
kotlinx-files
kotlinx-html
kotrix
kotson
kovenant
kprompt
kraph
krawler
kroto-plus
ksp
ktcc
ktfmt
ktlint
ktor
ktp
kubed
kug-leads
kug-torino
kvision
kweb
lambdaworld_cadiz
lanark
language-evolution
language-proposals
latvia
leakcanary
leedskotlinusergroup
lets-have-fun
libgdx
libkgd
library-development
linkeddata
lithuania
london
losangeles
lottie
love
lychee
macedonia
machinelearningbawas
madrid
malaysia
mathematics
meetkotlin
memes
meta
metro-detroit
mexico
miami
micronaut
minnesota
minutest
mirror
mockk
moko
moldova
monsterpuzzle
montreal
moonbean
morocco
motionlayout
mpapt
mu
multiplatform
mumbai
munich
mvikotlin
mvrx
myndocs-oauth2-server
naming
navigation-architecture-component
nepal
new-mexico
new-zealand
newname
nigeria
nodejs
norway
npm-publish
nyc
oceania
ohio-kotlin-users
oldenburg
oolong
opensource
orbit-mvi
osgi
otpisani
package-search
pakistan
panamá
pattern-matching
pbandk
pdx
peru
philippines
phoenix
pinoy
pocketgitclient
polish
popkorn
portugal
practical-functional-programming
proguard
prozis-android-backup
pyhsikal
python
python-contributors
quasar
random
re
react
reaktive
realm
realworldkotlin
reductor
reduks
redux
redux-kotlin
refactoring-to-kotlin
reflect
refreshversions
reports
result
rethink
revolver
rhein-main
rocksdb
romania
room
rpi-pico
rsocket
russian
russian_feed
russian-kotlinasfirst
rx
rxjava
san-diego
science
scotland
scrcast
scrimage
script
scripting
seattle
serialization
server
sg-user-group
singapore
skia-wasm-interop-temp
skrape-it
slovak
snake
sofl-user-group
southafrica
spacemacs
spain
spanish
speaking
spek
spin
splitties
spotify-mobius
spring
spring-security
squarelibraries
stackoverflow
stacks
stayhungrystayfoolish
stdlib
stlouis
strife-discord-lib
strikt
students
stuttgart
sudan
swagger-gradle-codegen
swarm
sweden
swing
swiss-user-group
switzerland
talking-kotlin
tallinn
tampa
teamcity
tegal
tempe
tensorflow
terminal
test
testing
testtestest
texas
tgbotapi
thailand
tornadofx
touchlab-tools
training
tricity-kotlin-user-group
trójmiasto
truth
tunisia
turkey
turkiye
twitter-feed
uae
udacityindia
uk
ukrainian
uniflow
unkonf
uruguay
utah
uuid
vancouver
vankotlin
vertx
videos
vienna
vietnam
vim
vkug
vuejs
web-mpp
webassembly
webrtc
wimix_sentry
wwdc
zircon
Powered by Linen
compose
  • a

    Adam Powell

    05/21/2019, 3:39 PM
    avoiding namespace pollution is implicit here since
    @Composable
    functions can only be called from other
    @Composable
    functions - yes, we don't want that pollution either 🙂
    t
    3 replies · 2 participants
  • o

    orangy

    05/21/2019, 7:19 PM
    From the language perspective and idiomatic Kotlin, it would be nice to have a sketch on how could a generic system look like, even if still a plugin. By generic, I mean something that is not bound to this UI system, nor to Android or anything else. Like it was said on
    suspend
    function, let’s imagine for a moment we are doing an “incremental structure updates” plugin to the language, and let’s pretend we can have a (soft) keyword. In the true Kotlin spirit, we should be able to develop libraries and frameworks, and not just UIs. Like if we have
    compose fun Data(name: String)
    , then where the composition context comes from, how do you scope different DSLs belonging to different systems, etc. These are open questions, and they are probably out of scope of this very specific use case, but I find it interesting thinking about it and it would be nice to see what you folks think here.
    ➕ 2
    👍 3
    n
    m
    +1
    10 replies · 4 participants
  • n

    napperley

    05/21/2019, 11:11 PM
    Sounds like Compose is strongly moving in the Functional direction (aka Functional DSLs). Would there be any plans in the compose language proposal on how state is managed? Do think that the compose language proposal should include the ability to initialise the context in a code block without having to pass through function parameters, so a user can use a composable API like this eg:
    // ...
    StoryWidget {
        story = StoryData
        Clickable {
            onClick = onClick
            Padding {
                amount = 8.dp
                Column {
                    Title { txtContent = story.title }
                    Image { src = story.image }
                    Text { txtContent = story.content }
                }
            }
        }
    }
    👎 4
    c
    g
    +6
    45 replies · 9 participants
  • p

    Pedro Gomez

    05/22/2019, 6:38 AM
    @Leland Richardson [G] my comment about testing was in another direction. I simplified it in this channel saying that'd close the door for testing but if you read the post what I mean is that returning the components could simplify the way Android devs test their applications. Even if you don't think snapshot testing could be a good testing strategy, a good design should let the developer choose the scope of the test or the testing strategy we could use for our automated test suite. I'm going to paste here the same message I sent you and the rest of your team sending me private messages and asking for my email to send me detailed explanations about the usage of compose that are not part of the documentation: I wrote the article with the information Google provided during the Google I/O and wrote in the official compose documentation. If you think there is something I didn't express properly or I didn't understand properly that could be because of the lack of information. That's why the post is written using a lot of questions and assumptions. I'm just a random developer, if I understood that, any other developer may have thought the same. An example of the assumptions or inaccurate parts of the post is the inner state of the component. During the Google I/O talk the message was: "we don't want local state in our components, we will use a single source of truth" and nobody explained that the state can be part of the tree as other google employee already told me by DM. You have another example here:
    However, this is not part of the repository right now and we will have to wait until a new release in order to check if the suggested implementation looks like this or not.
    If nobody documents how the library is implemented the only thing I can find is questions around. I'm not judging anybody. I'm really sorry if you or your team feel bad because of my blog post. I didn't mean to hurt you or your team feelings. I already told Adam and the whole team I think you are doing it great with compose and as I said in my blog post:
    The Android team is doing it great. Believe me when I say that this Compose API is way better than the current state of the art of Android development.
    During the Google IO talk the team said "go to the repo and play with compose" and that's what I did. After playing with compose and the available documentation I wrote the post. if compose has an API that is not documented or used in the example provided, I'm afraid I can't review it. If you have examples of things that don't match what I explained in the blog post I'll add a note with the resources you provide me. I hope these resources will be part of the documentation soon.
    🤔 1
    ❤️ 1
    r
    s
    6 replies · 3 participants
  • l

    Leland Richardson [G]

    05/22/2019, 7:24 PM
    Hey friends! I just published a blog “Compose from First Principles” talking about some of the implementation details around compose. Would love to hear your thoughts! http://intelligiblebabble.com/compose-from-first-principles/
    🔝 2
    👍 30
    👏 16
    f
    i
    +3
    24 replies · 6 participants
  • g

    Gil Goldzweig

    05/23/2019, 6:07 AM
    Will the components have the same names as what we currently have? RecylerView LinearLayout EditText etc... If not, what is the plan to help developers have a easier time adjusting to the new names?
    r
    2 replies · 2 participants
  • g

    gildor

    05/23/2019, 6:10 AM
    I think names is not the hardest part of migration, after all API and overall approach is completely different
    👆 3
    g
    b
    +2
    12 replies · 5 participants
  • g

    Gil Goldzweig

    05/23/2019, 6:16 AM
    Will there be an option to mix "regular" views with compose, so existing UI open source libraries are still usable?
    g
    r
    +1
    6 replies · 4 participants
  • a

    Antanas A.

    05/23/2019, 2:15 PM
    Hi, I'm curious about design decisions between Compose and Scala.Binding ( https://github.com/ThoughtWorksInc/Binding.scala#design ) and why Compose wasn't designed towards Scala.Binding, but went to kind of "virtual DOM" way.
    g
    k
    +3
    15 replies · 6 participants
  • c

    Chuck Jazdzewski [G]

    05/23/2019, 4:47 PM
    This can be done automatically (without needing
    Key
    ) if
    Item
    uses a
    @Pivotal
    parameter such as,
    fun Item(@Pivotal item: DataItem) {
       ...
    }
    then calls to
    Item
    automatically track the value of
    item
    .
    e
    l
    12 replies · 3 participants
  • u

    uli

    05/23/2019, 5:01 PM
    Thanks for the details. What I do not quite understand is the meaning of
    source location
    in
    unique to the source location of the call site.
    in the blog, and in your explanation the meaning of
    source property
    in
    you introduce a key that is combined with the source property to introduce a group specific key.
    l
    5 replies · 2 participants
  • f

    Fudge

    05/24/2019, 6:29 AM
    Do you plan to handle accepting a component of a certain type? Like having the
    appBar
    parameter of
    Scaffold
    only accept "a component of type appBar"
    t
    c
    2 replies · 3 participants
  • m

    Miguel Vargas

    05/24/2019, 7:38 PM
    Is the plan that Compose will use the framework's app resource system, eg res/drawable-land etc? All the snippets I've seen show things like
    Text ("Hello World")
    instead of
    Text (R.string.hello_world)
    l
    l
    +12
    107 replies · 15 participants
  • l

    Leland Richardson [G]

    05/24/2019, 9:50 PM
    backpressure can mean different things depending on the context, but in the case of @Model objects, mutating a property does not synchronously cause a recomposition. Mutations are observed in a transaction, and recomposition happens when the transaction commits. When recomposition happens, the tree is traversed again from top-down, with higher up invalidated scopes recomposing before ones further down. Though we haven’t built things at true scale with compose yet, this was designed specifically to prevent some of the typical scalability issues you see with observable UIs
    t
    2 replies · 2 participants
  • l

    Leland Richardson [G]

    05/24/2019, 9:57 PM
    to be fair, we’re more like:
    fun composition() {
        Column {
            Text("Hello")
            Image("<https://image>")
            repeat(2) { Text("Hello") }
        }
    }
    j
    1 reply · 2 participants
  • j

    Jacob Applin

    05/24/2019, 10:00 PM
    fun composition() {
    	Column(
    		Text(HeaderText, "Hello"),
    		Image("<https://image>", Size(Material, Material)),
    		*Array(2) { Text("Hello") },
    		Button(Primary),
    		Button(Secondary)
    	)
    }
    👎 2
    t
    2 replies · 2 participants
  • j

    Jacob Applin

    05/24/2019, 10:02 PM
    how would a user add an extra param to the Text method?
    👍 1
    s
    4 replies · 2 participants
  • f

    Fudge

    05/25/2019, 6:51 AM
    I would like to further express the problem brought up by @Jacob Applin. Say you have a component that is a text field named
    TextField
    . And then I want to make a version of that that validates text input named
    ValidatedTextField
    . I would now need to copy paste the possibly extremely long declaration of
    TextField
    , as part of the declaration of
    ValidatedTextField
    , and then feed all of these parameters into
    TextField
    , and then every time
    TextField
    adds new arguments I need to add those to
    ValidatedTextField
    .
    l
    c
    6 replies · 3 participants
  • r

    romainguy

    05/25/2019, 7:27 AM
    Something like:
    fun ValidateTextField(foo: Bar, @ParamsOf<TextField> p)
    e
    c
    7 replies · 3 participants
  • g

    Gil Goldzweig

    05/28/2019, 5:25 AM
    Will the system handle memory and resources cleanup? And will individual components be lifecycle aware? for example: dialogs
    m
    5 replies · 2 participants
  • f

    Fudge

    05/30/2019, 7:05 AM
    why are
    mainAxisSize
    ,
    mainAxisAlignment
    , etc ints instead of enums?
    Oh it says right there that it should be changed nvm
    d
    1 reply · 2 participants
  • f

    Fudge

    05/31/2019, 8:44 AM
    Is there a way to draw based on the size of an element? Something like
    Layout(children = {Text("Hello")},  layoutBlock = { measurables, incomingConstraints ->
        val sizeOfTheHelloText = /*calculate size*/
        Draw {
        /* draw some special border around the text */
        }
    }
    Or
    OnChildPositioned(onPositioned = { coords->
        Draw {
        /* draw some special border around the text */
        }
    }) {
        Text("Hello")
    }
    The problem lies in
    Draw
    , as 'there is no composition context' there. Getting the size of the text I managed to figure out how to do. For context, I'm trying to make a button that fills up like a progress bar.
    a
    5 replies · 2 participants
  • f

    Fudge

    05/31/2019, 11:45 AM
    https://medium.com/@luca.nicolett/android-mvi-with-jetpack-compose-b0890f5156ac
    💯 2
    👍 7
    v
    1 reply · 2 participants
  • m

    moetouban

    05/31/2019, 10:16 PM
    Is there a plan where we can have a
    hot reload
    feature supported with compose just like in flutter or react ? One of downside of compose is that you can't visualize your UI anymore.
    👍 1
    s
    r
    +2
    4 replies · 5 participants
  • l

    louiscad

    06/03/2019, 9:23 AM
    @Antanas A. HTML and CSS are not desirable. Just look at the massively inconsistent ecosystem of WEB UI frameworks and helpers. We don't want to be lost in a jungle of solutions that all have unsatisfying drawbacks. The cascading nature of CSS leads to many display bugs where some style is often applied to elements that were not designed for it. HTML is more verbose than what Kotlin can bring us, and lacks any logic. That's why there's "magic" frameworks or things like JSX. There are plenty of other reasons, but I think that's enough to justify trying to make something better, without the decades of legacy HTML and CSS have.
    ➕ 2
    👎 2
    👍 1
    j
    17 replies · 2 participants
  • a

    Antanas A.

    06/03/2019, 11:04 AM
    but I'm questioning the way why it's started from scratch and nothing reused (with exception: did they reuse low level 2d rendering engine which was in Chrome? Same as flutter - https://skia.org/ ?)
    g
    2 replies · 2 participants
  • a

    Antanas A.

    06/03/2019, 11:07 AM
    If so, how to implement this use case: for slow devices, animations for "slow devices" must be off , or in portrait mode do not show some UI elements
    r
    1 reply · 2 participants
  • j

    jw

    06/03/2019, 4:36 PM
    the greatest failure of Android may turn out to be its inability to blur the line between an APK and a webpage which have no meaningful difference except for the platform chooses to elevate one above the other
    n
    2 replies · 2 participants
  • r

    Robert Menke

    06/03/2019, 7:16 PM
    So... Swift UI? Looking pretty similar to compose 😎
    👆 19
    👍 12
    f
    b
    +1
    4 replies · 4 participants
  • j

    Jurriaan Mous

    06/03/2019, 7:17 PM
    SwiftUI. What a developer experience. I am now hoping for a common Kotlin bridge between Compose and SwiftUI. 😄 I am curious what Compose devs think of these developments
    j
    g
    3 replies · 3 participants
Powered by Linen
Title
j

Jurriaan Mous

06/03/2019, 7:17 PM
SwiftUI. What a developer experience. I am now hoping for a common Kotlin bridge between Compose and SwiftUI. 😄 I am curious what Compose devs think of these developments
I hope Compose will get a lot of inspiration from the tutorials! 😄 https://developer.apple.com/tutorials/swiftui/tutorials
➕ 1
j

Jonas Bark

06/03/2019, 8:37 PM
I'd be happy if we can easily glue in state managment with Kotlin Multiplatform - and use Compose / SwiftUI for UI 👍
👍 4
g

Gil Goldzweig

06/04/2019, 12:01 PM
Due to it being so similar it could mean that we wont need a "native" developer anymore just kotlin
View count: 4