And because I'm me, a week into developing Paperback for Android I've got an issue opened on Google's tracker requesting a feature in compose.
-
And because I'm me, a week into developing Paperback for Android I've got an issue opened on Google's tracker requesting a feature in compose. Happy to code it up myself even, but I don't want to open a PR without an issue to point to and get it closed. https://issuetracker.google.com/u/1/issues/515811295
@TheQuinbox So, because I did Android development (a small amount, just the app that became Sero) back before Compose was a thing, I can't help but wonder if Compose really gives you anything of value compared to working with the OS-provided framework directly. Don't you have to ship a copy of Compose (hopefully with dead code elimination) with your app? The original Android UI framework is pretty similar to the wx style of API. Are you already wishing you had Compose on desktop?
-
@TheQuinbox So, because I did Android development (a small amount, just the app that became Sero) back before Compose was a thing, I can't help but wonder if Compose really gives you anything of value compared to working with the OS-provided framework directly. Don't you have to ship a copy of Compose (hopefully with dead code elimination) with your app? The original Android UI framework is pretty similar to the wx style of API. Are you already wishing you had Compose on desktop?
@matt Composes syntax is super duper nice, it reminds me a lot of SwiftUI. That said I've never looked at talking directly to the native APIs, it's quite possible and I'd even say likely that I wouldn't mind it. I do love how easy compose makes, for example, accessibility actions. Plus, for older android, don't you *have* to write xml? Or is that something else.
-
@matt Composes syntax is super duper nice, it reminds me a lot of SwiftUI. That said I've never looked at talking directly to the native APIs, it's quite possible and I'd even say likely that I wouldn't mind it. I do love how easy compose makes, for example, accessibility actions. Plus, for older android, don't you *have* to write xml? Or is that something else.
@matt Also, as far as dead code elimination goes: 32-bit Paperback's APK is 8 MB, ARM64 is 12 MB. So the 64-bit Paperback APK is about the size of the desktop executable, if not a teny bit smaller. In other words, I don't think it adds much with the right settings.
-
And because I'm me, a week into developing Paperback for Android I've got an issue opened on Google's tracker requesting a feature in compose. Happy to code it up myself even, but I don't want to open a PR without an issue to point to and get it closed. https://issuetracker.google.com/u/1/issues/515811295
@TheQuinbox Hm... I sent you a gitHub issue for TaskMon, have you seen it yet?
-
@matt Composes syntax is super duper nice, it reminds me a lot of SwiftUI. That said I've never looked at talking directly to the native APIs, it's quite possible and I'd even say likely that I wouldn't mind it. I do love how easy compose makes, for example, accessibility actions. Plus, for older android, don't you *have* to write xml? Or is that something else.
@TheQuinbox Yeah, in the original Android framework, you write the UI view hierarchy as XML, then look up elements by ID from Java code, more or less like the split between HTML and JavaScript.
-
@TheQuinbox Hm... I sent you a gitHub issue for TaskMon, have you seen it yet?
@menelion I did, yes. Let me go try and repro that real quick.
-
@menelion I did, yes. Let me go try and repro that real quick.
@TheQuinbox No rush, thanks!
-
@TheQuinbox Yeah, in the original Android framework, you write the UI view hierarchy as XML, then look up elements by ID from Java code, more or less like the split between HTML and JavaScript.
@matt Okay, that makes sense, and doesn't sound too bad. Modern kotlin with compose though does lead to some very pretty UI code, at least in my opinion.
-
@TheQuinbox Yeah, in the original Android framework, you write the UI view hierarchy as XML, then look up elements by ID from Java code, more or less like the split between HTML and JavaScript.
@matt Thought experiment: if HTML hadn't become the standard, would we prefer writing webpages via Compose/SwiftUI-style declarative code?
I know people have tried to create ways of generating HTML, CSS, and JS event handlers from various other programming languages (JSX doesn't count). How much do we look at those and get turned off by the relative overheads and comfortable familiarity with HTML, vs it actually being an objectively bad idea?
All of that aside: a lot of effort has gone into allowing people to write HTML by hand without some of the traditional verbosity and intricacies of XML. If Android's framework is overly rigid because it was designed to be generated by a visual layout tool, it wouldn't really be comparable.
-
@matt Thought experiment: if HTML hadn't become the standard, would we prefer writing webpages via Compose/SwiftUI-style declarative code?
I know people have tried to create ways of generating HTML, CSS, and JS event handlers from various other programming languages (JSX doesn't count). How much do we look at those and get turned off by the relative overheads and comfortable familiarity with HTML, vs it actually being an objectively bad idea?
All of that aside: a lot of effort has gone into allowing people to write HTML by hand without some of the traditional verbosity and intricacies of XML. If Android's framework is overly rigid because it was designed to be generated by a visual layout tool, it wouldn't really be comparable.
@jscholes @matt @TheQuinbox I recall reading that before HTML was adopted, a proposal was made to adopt s-expressions, like in lisp languages.
-
R relay@relay.an.exchange shared this topic
