louiscad
01/09/2019, 11:00 PMDerk-Jan Karrenbeld
01/10/2019, 1:30 AMrkeazor
01/10/2019, 3:36 AMghedeon
01/10/2019, 4:29 AMrkeazor
01/10/2019, 6:10 AMvishna
01/10/2019, 7:31 AMsngrekov
01/10/2019, 12:09 PMlouiscad
01/10/2019, 12:25 PMDerk-Jan Karrenbeld
01/10/2019, 12:35 PMlouiscad
01/10/2019, 12:57 PMrkeazor
01/10/2019, 12:59 PMlouiscad
01/10/2019, 1:07 PMrkeazor
01/10/2019, 1:10 PMDerk-Jan Karrenbeld
01/10/2019, 1:11 PMincludes
have caveats, but these limitations actually help you to separate between... again composition and function.
And then in your pros of splitties, your arguments are again not equivalent. Splitties DSL is more concise because you're basically building custom views. Compare custom views with custom views, not out of the box XML configurable views with custom view builders.
You can only reuse it better because you don't know how to do reusable components with XML, which is clear from the document. More apples and oranges comparisions here.louiscad
01/10/2019, 1:13 PMrkeazor
01/10/2019, 1:15 PModay
01/10/2019, 1:44 PMsngrekov
01/10/2019, 4:54 PMUse custom views, and do composition in XML and function in the code. Same as before.Can hardly agree with that. Even if you will do your custom TextView, you always have write <MyTextView android:blablabla android:blablabla /> in order to include it onto another layout and set android:text for example, right? But if you use your custom view as a function, you simply have to write myTextView(text="bla"). And I am not even talking about all the hussle when you want to create your custom attributes.
rkeazor
01/10/2019, 5:32 PMlouiscad
01/10/2019, 5:38 PMSome things that affect your Views can only be done from code, leading to 2 problems: You can't preview them, and your UI code is split over at least 2 files.When using xml, any UI stuff that needs code (beyond what xml can offer) is done in the Activity or Fragment, which needs to be run on the device, which may mean going deep into the app, possibly with login, unless you find a workaround or have a special way to preview with code using the xml layouts. When using Kotlin code, and preview system like Splitties Views DSL has, you preview everything, except code not tied to the UI. So I think that stands true. If you want to clarify this point, you can fork the project, create a branch based on
develop
and submit a PR.
You repeat android and app over and over, cluttering the code, resulting in hardly readable code.Don't get me wrong, I can read xml, it's just more characters than when I use Splitties Views DSL, which makes it longer/harder to read. I didn't spend time doing thorough comparisons regarding metrics, but I remember migrating several files, resulting in half the lines of code, not even counting the number of characters decrease. Maybe "hardly" isn't the best word, yes, you can also submit a PR for this if you want.
If you support API 16 and lower, LTR support is subpar.And it is true. Did you read what's stated below? And it has to do with the tools given by Google for xml layouts. With Kotlin, you make an extension function/property (which are provided OOB in Splitties) and forget about it. With xml, you have to specify left+start and right+end. I'm now replying to the rest of your message: I'm comparing what Kotlin and Splitties Views DSL allow vs XML alone. Apart from
<include/>
, there's no such thing as reusable xml, it's all custom views with Kotlin or Java code, or bytecode. You completely missed the point I think. Anyway, as said above, feel free to submit PRs if you want to make things more specific. Finally, remember Google Pixel, iPhone, Java, Kotlin and many other great things would ne nowehere near they are without what you call "marketing". I tried to make something objective, and I'm happy to receive contributions. Doing the thing and designing the API is already (free) time consuming. Writing the docs only adds up, and I'm the only maintainer for now. If you want to debate the docs further, please open an issue, or submit a PR directly if you know how you think it should be edited 🙂ghedeon
01/10/2019, 5:41 PMnotifyProperty
, notifyall
, another Observable interface in the project (like the third one?), BR files, stupid behaviour like this one, that you can debug for months without knowing what's going on https://stackoverflow.com/questions/46680862/android-databinding-onlongclick-not-working. Terrible IDE support, yeah, yeah, it's getting better, but my layout is still red unless I compile/recompile 10 times. Compilation errors because of broken compatibility with gradle plugin. Bad navigation from xml to source (to adapters). Sometimes it's possible, sometimes not. And with kotlin you don't need adapters at all, because it's basically an extension. The difference is that kotlin extension is better from any point of view and adapters are hard to debug. You can't easily copy & paste layouts, because they're coupled with models.. etc, etc.
I prefer to think of my UI as of something very thin and static. With DB I'm getting something liquid, heavy, buggy, non-debuggable... something is happening somewhere. Reminds me of EventBus days a little.louiscad
01/10/2019, 5:41 PMDo you want the android development to be more like Java Swing Development lol@rkeazor I'm more inclined to dance with #tornadofx than with Swing 😉
rkeazor
01/10/2019, 5:44 PMlouiscad
01/10/2019, 5:53 PMI can put my UI views in another Kt file. My activity and Fragment will be coupled to that fileI have some (unfortunately non open source) projects where my Activity overrides thelol
onCreate
method and calls a single suspend fun
from a launched coroutine. And that's all. If I need to trt an alternative implementation, I just have to call another function. The function can create and set the UI, and start all the logic. I'm looking forward showing examples of this in an open source project, but my time is limited, so it won't come tomorrow morning.rkeazor
01/10/2019, 5:57 PMlouiscad
01/10/2019, 5:58 PM@louiscad guess what , wherever you put your UI Logic , your activities and fragments will be tightly coupled to it hahah. That's why I said that statement doesnt make no senseAs I said above, you can have UI code less coupled to the host Fragment and Activity. If you doubt it and want to be proven wrong, read Splitties Views DSL docs (especially the part about the
Ui
interface) and give it a try to see the difference.rkeazor
01/10/2019, 5:59 PMlouiscad
01/10/2019, 6:00 PMrkeazor
01/10/2019, 6:03 PMlouiscad
01/10/2019, 6:05 PMDerk-Jan Karrenbeld
01/10/2019, 6:07 PMrkeazor
01/10/2019, 6:09 PMsngrekov
01/10/2019, 6:10 PMDo you want the android development to be more like Java Swing Development lolMe personally want React-like style UI programming in Android
Derk-Jan Karrenbeld
01/10/2019, 6:10 PMrkeazor
01/10/2019, 6:10 PMDerk-Jan Karrenbeld
01/10/2019, 6:12 PMWhen using xml, any UI stuff that needs code (beyond what xml can offer) is done in the Activity or Fragment, which needs to be run on the device, which may mean going deep into the app, possibly with login, unless you find a workaround or have a special way to preview with code using the xml layouts.This just proves to me you don't understand custom views. No need to do anything in the activity or fragment, and if you MUST have special handling, the
View.isInEditMode
solves that for you.
Most of the other argumentation you give can be solved exactly the same, and that's that.rkeazor
01/10/2019, 6:13 PMlouiscad
01/10/2019, 6:15 PMrkeazor
01/10/2019, 6:20 PMlouiscad
01/10/2019, 6:21 PMsngrekov
01/10/2019, 6:22 PMThats what Flutter is forThat fact that Flutter chose React-like paradigm for building UI is telling something... Why do Android community can't adopt same patterns? Only because Google advocating on xml? Those Google that made fragments and were advocating to write all your logic in Activities and Fragments?
rkeazor
01/10/2019, 6:22 PMsngrekov
01/10/2019, 6:29 PMrkeazor
01/10/2019, 6:32 PMghedeon
01/10/2019, 6:38 PMReload
button I'm not getting a reliable preview in design ToolView. So, the UI development cycle on big projects is "move the button 2dp to the left, recompile, go for a smoke, check reddit, see the result. Repeat". I actually caught myself avoiding ui tasks because it's irritating and you can't stay in the flow with such delays. Hot reload from Flutter sounds like heaven, but that's probably another discussion about advantages of having direct access to your VM (DartVM)...rkeazor
01/10/2019, 6:42 PMlouiscad
01/10/2019, 6:45 PMrkeazor
01/10/2019, 6:52 PMsngrekov
01/10/2019, 7:16 PMiOS developers are making UIs with Swift code tooThis is true in my experience, my iOS collegues dropped XIBs and do all UI stuff programmatically
Preview requires a build (but you're less likely to need preview thanks to additional type safety and more expressive UI code).As far as I know, if your layout completely in code, then full build is not required, but only "compileKotlinDebug", which is much much faster then full build. The only downside of this is that you have to run this task and refresh preview manually
nwh
01/10/2019, 9:15 PMlouiscad
01/10/2019, 10:00 PMclass SomeActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
val ui: SomeUi = SomeUiImpl(this)
setContentView(ui)
coroutineScope.launch { // coroutineScope is an extension on a subclass of the enclosing class.
doSomething(ui) // This is a cancellable suspending function that never resumes because
// it is either working, or waiting for user input/interaction
}
}
}
The `doSomething`function could be called displayNotesListAndAwaitForUserActions
in the main Activity/Fragment/Whatever of a notes app like Google Keep.nwh
01/10/2019, 11:23 PMLeoColman
01/11/2019, 5:25 PMandroid
and app
are not pollution. I do believe they are indeed. (
& )
are also readable and understandable; ;
is readable and understandable... But Kotlin does what it can for you to not use them.get
and set
everywhere are also understandable, but are also considered visual pollutionrkeazor
01/11/2019, 5:28 PMlouiscad
01/11/2019, 5:32 PMget
and set
keywords in Kotlin, but to the prefixes in Java getSomething
and setSomething
, compared to the less visually polluted property syntax that Kotlin offers.rkeazor
01/11/2019, 5:32 PMLeoColman
01/11/2019, 5:36 PMlouiscad
01/11/2019, 5:37 PMandroid:
), verbosity (e.g. SAM anonymous classes), etc, add to the effort your brain needs to do to read and understand some code (just like a book, an article or anything that can be read or seen). That effort is felt when first encountered, but over time, while you stop noticing it, you still get tired more as this is consuming a bigger part of the unconscious side of your brain resources, that are not used to read faster, understand better the point, have it fell like it's simpler…rkeazor
01/11/2019, 5:37 PMlouiscad
01/11/2019, 5:38 PMrkeazor
01/11/2019, 5:39 PMLeoColman
01/11/2019, 5:43 PMrkeazor
01/11/2019, 5:44 PMLeoColman
01/11/2019, 5:48 PMget
and set
vs property access with no get and set and no ()
is betterrkeazor
01/11/2019, 5:50 PMlouiscad
01/11/2019, 9:01 PM