Hello

hello, Kai!

how can I help you today!

I have started implementing ViewModel and wanna have a look at LiveData. My boss is concerned that it will slow down the app

(insert thinking emoji here)

what are you comparing it to?

Do you have any experience concerning the performance of ViewModel/LiveData/<insertjetpackthinghere> compared to "old" approaches like loaders, data sharing over interfaces and the such?

not directly, but... at the level of user perception, the differences between those things are going to be non-existent

unless you're doing something in a tight loop, in which case you probably are not using the "old" approaches either

In most places data is held in the fragment itself or a "data class" of some kind. A lot of data is loaded with loaders, mostly AsyncTaskLoader afaik, or directly with AsyncTask

but "ViewModel/LiveData/<insertjetpackthinghere>" isn't changing the nature of whatever the slow work is

suppose, for example, you are making a network call

and suppose that network call takes 500ms just on its own, irrespective of how you get the results back to the UI layer

I think the fear is that the overhead of the "new" approaches is way bigger than the "new" ones.

but that overhead will be measured in fractions of a millisecond, at most

But you're saying that the speed is negligible because most IO bound things will take magnitudes more?

correct

I see

Concerning ViewModel, do you know why they didn't implement a mechanism that would also make it replace the whole "instance state" thing?

they did, just not in the original release

SavedStateHandle is the mechanism for that

I cover that in the latest *Elements of Android Jetpack*

see https://gitlab.com/commonsguy/cw-jetpack-java/-... for example

Ok, I'll have a look

Cool

Implementing ViewModel was quite the journey. I ended up with an AndroidViewModel sporting an "initialize(...)" method to initialize the needed classes. Also it's quite big imo and it feels like quite a bit more code compared to before.

¯\_(ツ)_/¯ -- since I cannot see either the "before" or the "after" code, I can't really comment on that

however, on the whole, the Jetpack alone isn't strictly designed to reduce your lines of code count

it's more trying to steer you towards maintainable, reliable patterns

Google is more relying on developers adopting Kotlin to reduce the verbosity of the code

I guess it would have been easier with Kotlin.

Even though I don't know much about Kotlin yet, I often thought "this would already be there in Kotlin"

Like getters/setters and data classes

Kotlin definitely has its advantages, and I can't really say that there is anything that I have encountered where I felt that Java 8 handled it better

I end up having a few calls that pretty much just call a method on the wrapped object.

You have to learn more for Kotlin, I believe. There is quite a bit of syntactic sugar that you won't get from just looking at it.

So Java seems easier to understand for someone who doesn't have experience yet or hasn't learned Kotlin.

I agree

while Java is verbose, its syntax does not have a ton of options

Kotlin, on the other hand, has loads and loads of options, the vast majority of which ordinary developers won't use

part of that is because Kotlin is largely built in Kotlin itself

so they added language features they wanted for making other language features, and exposed them as part of what everyone gets

Kotlin is built in Kotlin?

it makes writing libraries and DSLs and stuff very slick, but it makes looking at the Kotlin docs a bit daunting

by which, I mean that most of the classes and functions are written in Kotlin itself

Ok

but, let me take a question from Ivano, and I'll swing back to you in a bit

Ivano: how can I help you today?

HI Mark and Kai, no questions

just chilling out

Hi Ivano

OK -- if you come up with one, chime in!

ill do sir!

Kai: a lot of Kotlin syntax looks may not look like classes and functions, but is "under the covers", and that "under the covers" code is in Kotlin

take 1 + 1, for example

+ is an operator function, more than a baked-in part of the language syntax

1 + 1 is simplified syntax for 1.plus(1)

I see

that's also why you can do listOne + listTwo, for a pair of List<> objects, because anything can implement plus() and automatically get the ability to be used with + syntax

Kotlin has a lot of that sort of thing, where "the stuff that makes the language work" and "stuff that users of the language can use" overlap

So it does have a steeper learning curve I suppose

ehm

most of what you need can be accomplished with a fraction of the overall Kotlin syntax

and you can slowly adopt other stuff as needed

I guess my problem starts when I look at other's code

ah, yeah, that can be a challenge

:)

depending on how it was written

And don't understand where things happen and have a harder time following it than in Java.

Often it's mostly me lacking some knowledge. But examples using Koin come to mind

ahah

because Java doesn't have a ton of syntax options, one person's Java is likely to resemble another person's Java

Kotlin, on the other hand, because of all those language-supplied capabilities, makes it possible to write something like Koin that has a very custom API (such as the module {} DSL)

Yes. The complexity comes in at another point (inheritance, interfaces,...)

but, that also means that in Kotlin, it is easy to step over the line from concise (short but readable) to terse (short but tough to read)

it's one of the biggest concerns that I have with Google's hard shift to Kotlin: will this make it more difficult for the Android ecosystem to learn new Android things, when they have not learned Kotlin yet?

fortunately, in the Android docs, they are going dual-language in many places, which helps

Won't just everyone have to learn Kotlin eventually?

for some definition of "eventually", yes :-)

We are still mostly a Java shop, so I guess I should stay on Java.

(and there is still a bigger mistery, why flutter uses ugly dart :troll)

team leads/management will need to decide when to start experimenting with Kotlin

I am praying for that

But as I start refactoring, things like "this should be a coroutine" and "this class would be so much simpler as a Kotlin data class" come up.

When I started to do Kotlin, I hated it, because Java still was not 100% clear to me

So what happened?

yep I am telling you cause I sympatized 100 with you, but is common after few projects to not go back to java, because once I start to think in Kotlin,

I see

you start to find not Kotlin strange/difficult, but java extremly verbose and lacking functionalities

So I should not look into Kotlin (yet). I might have to stay on Java.

And the higher learning curve is actually a argument against Kotlin, I guess

for your job, Java will be your language of choice, apparently

Yes.

are you android dev? back end?

for *you*, you should start learning Kotlin

Mark: That is on my agenda :D

having Kotlin on your resume/CV is going to be fairly important

I am an Android dev

do it!!!!!!

go for it

conversely, one argument for your management is: will you be able to hire Android talent in 3 years, if your app is still in Java?

Kai what helped me?

because hiring Android developers in many markets is difficult as is, let alone if you reduce your field to those interested in a Java-dominant project

I wanna learn Kotlin, as I don't wanna be an "Android dev" who only knows old technologies.

That is also why I am looking into the "new" components, namely jetpack based app architecture

togheter with Java and Kotlin I started to do Python, Lisp

I see

and you get.....is all about sequence, selection and iteration

coding is not changed since the 1930

Yes, all the basics are already there

And have been for quite some time

more languages you know and better you get in your specific language

Kotlin is gorgeous because has a lot of functional stuff, for instance I do not know Java 12, never read nothing, but knowing Kotlin I can read it for free

and you have a tool in intelliJ convert to java bytecode

so you can see how kotlin is interpreted as Java by the virtual machine, is not fun that?

Yes, that is a good functionality

you feel lik god

you have an interesting definition of "fun" :-)

fun mydefinition() Unit

I was about to ask if there is something like Javadoc for documenting android code, then I remembered the Kotlin thing of that exists.

My question was gonna be "how to best document an android app, is there something like Javadoc?"

the KDoc format is basically JavaDoc with extra options (e.g., Markdown)

(How) do you document Android code?

I write books about it :-)

lol

Lol. I meant in a project you do.

and for my clients' projects, I adopt whatever system they use

which, all too often, is "few code comments"

I don't wanna adopt "no comments at all" ;-)

better know algorithms,data structures, and design patterns with a bit of assembly that languages syntax

personally, I don't bother with strict KDoc/JavaDoc syntax, unless the project is going to generate HTML out of it

so, I'm more of a "simple block and line comment" sort of guy by default

Is the reason why there are so few comments in your example code that it's all explained in the book?

yes

good code should comment itself

it's a nudge to get people to subscribe, frankly

you spare a lot of superfluos read

lol

Ivaon: I kinda disagree. I think the code is about the "how", comments are about the "what" and "why".

too late we gotta wrap up:( in ten sec

Yes

unfortunately

sorry!

Have a good weekend everyone

And stay well

:)

you too!

and good easter if you are in achristian country

bye

FYI, the next chat is Tuesday at 7:30pm US Eastern