hello, Kai!

how can I help you today?

Hi Mark.

I have no proper question atm, but wanted to "be here" for another office hour.

um, OK

if you come up with a question, let me know!

Sure :)

BTW, I think I just sent you an email

hello, Paul!

Good morning.

Paul: right now, Kai is just lurking, so... how can I help you today?

So I want to use the debugger to walk though Compose code to get a feel for how it works. Good idea, bad idea?

Anything to be aware of?

beats me -- I have never tried that directly

How are you learning Compose?

slowly

:-)

but, generally, not using a debugger

so far, I have settled for some amount of logging

I've been consuming articles and videos -- your talk included.

the only breakpoints I have set in a Compose project have been outside of the Compose code itself

such as inside my periodic attempts to invoke composables via reflection

Do you have a good feel for what the Compose compiler is all about?

technically, it's a compiler plugin -- not a full replacement for the Kotlin compiler

Do you "get" the compiler plugins for Kotlin?

Have you written one? Used one?

written one? no -- used one? only with Compose AFAIK

talked with people about the Compose one? yes

while we normally associate @ThingsWithLeadingAtSigns as annotations for annotation processors, compiler plugins can work with them as well

so the Compose plugin basically rewrites all of our calls to @Composable-annotated functions

adding in a bunch of extra parameters to help Compose keep track of what's going on

it used to rewrite the functions themselves, but they switched to call-site modification a couple of months ago

I would guess that the plugin generated more byte code. This correct?

yes, my guess is that if you looked at DEX bytecode, these composable calls will have a few more lines to them

call-site modification ... can you elaborate?

(though I'm far from a DEXpert)

suppose we have @Composable fun Foo() { TODO() }

and we have @Composable fun Bar() { Foo(); TODO() }

so, Bar() is calling Foo()

the Compose compiler plugin is changing that Foo(); call

and, in truth, also changing the Foo() function signature

a bunch of additional parameters get added

(BTW, hello Leora -- I will be with you shortly!)

Hi everyone!

Is the rewritten code available in Kotlin form?

Hi Leora

not that I am aware of

Debugging this code must be awful!

AFAIK, the compiler plugin is generating this as part of the actual compilation process

yeah, I can't imagine that it's much fun

now, how much this compiler plugin affects the debugger, I can't say

simply because I haven't experimented with that yet

Is it easy to read?

is what easy to read?

my books? I like to think so... :-)

Can you read Compose code and understand what it is actually doing?

Your books are wonderful! Can't wait for the Compose series. :-)

if you mean @Composable functions, as we write them, they aren't bad... but my guess is that you are referring to something else

if you mean decompiled @Composable functions, I have not tried that

I can generally read code and have a very good idea what the computer is doing because of that code. I'm not sure this will be true with Compose code.

in the theater and films and stuff, they talk about "willing suspension of disbelief"

you need an element of that with Compose as well

there will be a bunch of places where we hand-wave around "Compose compiler plugin magic"

such as: why do state() and mutableStateOf() actually work?

in explanations, we can go through many layers of the Compose onion, and then get to "and here is where the Compose compiler plugin performs some magic"

I do not like the sound of that. I already hate that they butcher conventions like function call names are verbs that start with lower case.

TheyAreAllGoodFunctionNamesPaul() :-)

but, while I hope to write about one more onion layer than most people will -- in the context of reflection and interop concerns -- eventually I too will wave my hands and say "here is where the compiler plugin takes over"

Uncle Bob is having massive coronaries just thinking about Compose violations of Clean Code principles.

let me take a question from Leora, and I will return to you shortly

Leora: hi! how can I help you today?

I have a hankering to get grounded in the compiler plugin technology. Got a decent reference?

ok

(Paul: I assume there's documentation for Kotlin compiler plugins somewhere, but I haven't gone looking for it)

Leora: do you have a question?

yes sorry I was distracted

How do I go about choosing a CDN?

I have never used one, so I cannot really answer that

I don't have much data

and, to be more clear: I have never signed a deal with a CDN and placed content in one

so, other than "if you use Cloudflare, you'll go down when half the Internet does", I don't really have much advice :-)

ok :)

although I don't get the joke ;)

Cloudflare had an outage on Friday

ahhhh

that briefly took down vast quantities of the Internet

anyway, I suppose my actual best advice is: know why you are engaging with a CDN

CDN as a DDoS mitigation service might be different than a CDN as a high-traffic site solution

but, on the whole, this is far from my area of expertise

I like small things, which usually do not need a CDN as a result

Umm, just so users can download language packs (each zip of mp3's is about 3MB)

and avoid being tied to google

since I want to release in China as well

whether a CDN operates in China would be another concern that you would need to check out

yes

ignoring the China part, the rest does not sound like you need a CDN, unless you expect a zillion users

than how would i manage the downloads? from where?

for example, I use Amazon S3 for book distribution, but that's mostly because they had a canned solution for short-lived signed URLs

if it weren't for that, I would just have them on my Web site

there are 23 languages in the app

Hmmm

23 ~3MB files is not that big

not it's not

now, if you expect those to be downloaded a million times per day, that's a different matter

no, they definitely won't be

so, from a bandwidth standpoint, this does not feel like a problem that needs a CDN as a solution

China or other considerations might steer you towards a CDN

so, the alternaives would be...? Amazon S3, website..

yes, or S3-like services (Rackspace has theirs, for example)

basically, just hosted files

and the question also is why not a CDN? it's not expensive. is there another consideration?

partly, it's a question of "points of failure"

for example, with my books, subscribers like you get locked out if either my Web site is down or Amazon S3 is down

whereas if I had the books just on my site, you would not care if Amazon is having a bad day

in your case, if your app is not talking to some server of yours already, then you only have this one point of failure, and a CDN might have better uptime guarantees than other solutions

but, if your app is already dependent on some server of yours, adding a CDN or other file host adds another point of failure

no server

better uptime = time uploading the files?

cause they will be uploaded once or twice a year

no, better uptime = least likelihood that a client will fail to download due to some hosting problem

ah

Uptime = the time a server/host is up

ah :)

so, you're looking for uptime assurances in service-level agreements, plus assurances that your files will be reachable by all your clients (e.g., the China concern)

yes

and for that, a CDN may be better than S3, which may be better than running your own Web site

let me take questions from the others, and I'll try to get back to you before the end of the chat

Kai: do you have a question?

ok thanks, i'll continue research on the CDN

Yes

I started being a full time Android dev pretty much a year ago (on 01.08.).

And I don't feel like a... real Android developer. I have touched some topics, some deeper than others, but still feel lacking.

My question is pretty much this: What, in your opinion, are the most important skills I should have to call myself a "real" Android developer? :)

um, you probably already are a real Android developer

bear in mind that Android is vast, and so expecting to know everything about Android is unrealistic

for example, I don't know everything about Android, and I have been working in this space for a while

Thing is that I don't think I could even write a simple Android app, as I lack quite a bit of the fundamentals.

but, if you can assemble a UI and have it load and store data (locally, server, or both), that would qualify as a "real" Android developer IMHO

ah

Hokay :D

basically, if you can do the sorts of things that *Exploring Android* guides you through, you should feel like you are a real Android developer

(Which is part of the reason why I am still planning to go through one of your books. Haven't implemented it yet though...)

That sounds like a good target.

beyond that, you would need to determine what specifically concerns you about your skill level or areas of expertise

I may be able to provide advice about filling those gaps, but I cannot tell you where your gaps lie

I guess beyond that it goes more into soft skills or overarching skills, like being able to learn something new, being able to implement a feature in a certain amount of time etc.

those concerns are eternal, to a degree

with experience, you will be able to better guess how those things may play out

I guess I'll have to live with the fact that no one can know everything and even the best are either quite specialized or learn very fast.

this is delving into psychology, and I'm far better at providing advice on CDNs than on psychology

(and I'm not expert at either of those things)

I guess that concludes my question for now.

sorry that I didn't have a simple solution for you

Paul: back to you! do you have another question?

I have another topic: the sorry state of on-device Android code coverage support from the tools team.

Why is this?

well, unless Google is going to write its own coverage solution, they are somewhat dependent on what other outside-of-Google teams are doing

And what do you do for code coverage (on-device only as off device is fairly well supported)

JetBrains is doing some stuff but not for on-device.

for my current client, I am using Jacoco for both instrumented and unit tests, and living with the fact that some Kotlin stuff gets missed

Jacoco is a sorry mess for Kotlin. It cannot keep up with Kotlin version changes. lateinit is now broken, much to my chagrin.

yes, ideally, we would have better options here

there are lots and lots and lots of things that I would use that phrase for, though

at least when used with Compose. It seemed to work last time I used it, about a year ago.

I have never tried running code coverage with Compose, but I would expect that the compiler plugin modifications would increase the likelihood of problems

If you were going to write your own solution to solve the problem for the Android world of on-device testing (you love pain) where would you start?

I would try to get a better handle on how current solutions like Jacoco do what they do

as frankly that's a black box to me

Actually, you really want to solve the problem for KMP.

that then would force me to start with more fundamental concerns, like "how do we write tests with KMP?", as I have not fairly little with it

sorry, that should have been: "I have done fairly little with it"

it's on my roadmap, probably for 2021, assuming space aliens haven't invaded by then

I just read a paper on source-source transformation. That is where I'm going to start. I've done both JVM and native testing. JVM is good, native is poor but getting better.

are you a member of Kotlinlang Slack?

btw, the IntelliJ code coverage is pretty decent for Kotlin.

Absolutely, along with about a hundred or so others. :-)

your questions seem like likely candidates for channels there, such as #multiplatform

Slack workspaces that is.

(and #compose for Compose internals stuff)

I created the #code-coverage channel there and have asked many questions about the topic. I am blazing a trail here for sure. I've even interacted with Andry Breslov on the topic. Apparently with little success. :-)

yeah, you're probably way beyond my level of expertise in the subject at this point

You still have much to teach me. I'm counting on it.

I'll try to help!

Collaborating is always preferable over solo endeavors.

but, that's a wrap for today's chat

the next office hours are Saturday in the 4pm US Eastern time slot

Good enough. Thanks

have a pleasant day!