Apr 11 | 3:55 PM |
Mark M. | has entered the room |
Mark M. | turned on guest access |
Apr 11 | 4:10 PM |
Kai H. | has entered the room |
Kai H. |
Hello
|
Mark M. |
hello, Kai!
|
Mark M. |
how can I help you today!
|
Kai H. |
I have started implementing ViewModel and wanna have a look at LiveData. My boss is concerned that it will slow down the app
|
Mark M. |
(insert thinking emoji here)
|
Mark M. |
what are you comparing it to?
|
Kai H. |
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?
|
Mark M. |
not directly, but... at the level of user perception, the differences between those things are going to be non-existent
|
Mark M. |
unless you're doing something in a tight loop, in which case you probably are not using the "old" approaches either
|
Apr 11 | 4:15 PM |
Kai H. |
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
|
Mark M. |
but "ViewModel/LiveData/<insertjetpackthinghere>" isn't changing the nature of whatever the slow work is
|
Mark M. |
suppose, for example, you are making a network call
|
Mark M. |
and suppose that network call takes 500ms just on its own, irrespective of how you get the results back to the UI layer
|
Kai H. |
I think the fear is that the overhead of the "new" approaches is way bigger than the "new" ones.
|
Mark M. |
but that overhead will be measured in fractions of a millisecond, at most
|
Kai H. |
But you're saying that the speed is negligible because most IO bound things will take magnitudes more?
|
Mark M. |
correct
|
Kai H. |
I see
|
Apr 11 | 4:20 PM |
Kai H. |
Concerning ViewModel, do you know why they didn't implement a mechanism that would also make it replace the whole "instance state" thing?
|
Mark M. |
they did, just not in the original release
|
Mark M. |
SavedStateHandle is the mechanism for that
|
Mark M. |
I cover that in the latest *Elements of Android Jetpack*
|
Mark M. |
see https://gitlab.com/commonsguy/cw-jetpack-java/-... for example
|
Kai H. |
Ok, I'll have a look
|
Kai H. |
Cool
|
Apr 11 | 4:25 PM |
Kai H. |
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.
|
Mark M. |
¯\_(ツ)_/¯ -- since I cannot see either the "before" or the "after" code, I can't really comment on that
|
Mark M. |
however, on the whole, the Jetpack alone isn't strictly designed to reduce your lines of code count
|
Mark M. |
it's more trying to steer you towards maintainable, reliable patterns
|
Mark M. |
Google is more relying on developers adopting Kotlin to reduce the verbosity of the code
|
Kai H. |
I guess it would have been easier with Kotlin.
|
Kai H. |
Even though I don't know much about Kotlin yet, I often thought "this would already be there in Kotlin"
|
Kai H. |
Like getters/setters and data classes
|
Apr 11 | 4:30 PM |
Mark M. |
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
|
Kai H. |
I end up having a few calls that pretty much just call a method on the wrapped object.
|
Kai H. |
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.
|
Kai H. |
So Java seems easier to understand for someone who doesn't have experience yet or hasn't learned Kotlin.
|
Mark M. |
I agree
|
Mark M. |
while Java is verbose, its syntax does not have a ton of options
|
Mark M. |
Kotlin, on the other hand, has loads and loads of options, the vast majority of which ordinary developers won't use
|
trocchietto_Ivano | has entered the room |
Mark M. |
part of that is because Kotlin is largely built in Kotlin itself
|
Mark M. |
so they added language features they wanted for making other language features, and exposed them as part of what everyone gets
|
Kai H. |
Kotlin is built in Kotlin?
|
Mark M. |
it makes writing libraries and DSLs and stuff very slick, but it makes looking at the Kotlin docs a bit daunting
|
Mark M. |
by which, I mean that most of the classes and functions are written in Kotlin itself
|
Kai H. |
Ok
|
Mark M. |
but, let me take a question from Ivano, and I'll swing back to you in a bit
|
Mark M. |
Ivano: how can I help you today?
|
trocchietto_Ivano |
HI Mark and Kai, no questions
|
trocchietto_Ivano |
just chilling out
|
Kai H. |
Hi Ivano
|
Mark M. |
OK -- if you come up with one, chime in!
|
trocchietto_Ivano |
ill do sir!
|
Apr 11 | 4:35 PM |
Mark M. |
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
|
Mark M. |
take 1 + 1, for example
|
Mark M. |
+ is an operator function, more than a baked-in part of the language syntax
|
Mark M. |
1 + 1 is simplified syntax for 1.plus(1)
|
Kai H. |
I see
|
Mark M. |
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
|
Mark M. |
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
|
Kai H. |
So it does have a steeper learning curve I suppose
|
trocchietto_Ivano |
ehm
|
Mark M. |
most of what you need can be accomplished with a fraction of the overall Kotlin syntax
|
Mark M. |
and you can slowly adopt other stuff as needed
|
Kai H. |
I guess my problem starts when I look at other's code
|
Mark M. |
ah, yeah, that can be a challenge
|
trocchietto_Ivano |
:)
|
Mark M. |
depending on how it was written
|
Kai H. |
And don't understand where things happen and have a harder time following it than in Java.
|
Apr 11 | 4:40 PM |
Kai H. |
Often it's mostly me lacking some knowledge. But examples using Koin come to mind
|
trocchietto_Ivano |
ahah
|
Mark M. |
because Java doesn't have a ton of syntax options, one person's Java is likely to resemble another person's Java
|
Mark M. |
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)
|
Kai H. |
Yes. The complexity comes in at another point (inheritance, interfaces,...)
|
Mark M. |
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)
|
Mark M. |
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?
|
Mark M. |
fortunately, in the Android docs, they are going dual-language in many places, which helps
|
Kai H. |
Won't just everyone have to learn Kotlin eventually?
|
Mark M. |
for some definition of "eventually", yes :-)
|
Kai H. |
We are still mostly a Java shop, so I guess I should stay on Java.
|
trocchietto_Ivano |
(and there is still a bigger mistery, why flutter uses ugly dart :troll)
|
Mark M. |
team leads/management will need to decide when to start experimenting with Kotlin
|
trocchietto_Ivano |
I am praying for that
|
Kai H. |
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.
|
Apr 11 | 4:45 PM |
trocchietto_Ivano |
When I started to do Kotlin, I hated it, because Java still was not 100% clear to me
|
Kai H. |
So what happened?
|
trocchietto_Ivano |
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,
|
Kai H. |
I see
|
trocchietto_Ivano |
you start to find not Kotlin strange/difficult, but java extremly verbose and lacking functionalities
|
Kai H. |
So I should not look into Kotlin (yet). I might have to stay on Java.
|
Kai H. |
And the higher learning curve is actually a argument against Kotlin, I guess
|
Mark M. |
for your job, Java will be your language of choice, apparently
|
Kai H. |
Yes.
|
trocchietto_Ivano |
are you android dev? back end?
|
Mark M. |
for *you*, you should start learning Kotlin
|
Kai H. |
Mark: That is on my agenda :D
|
Mark M. |
having Kotlin on your resume/CV is going to be fairly important
|
Kai H. |
I am an Android dev
|
trocchietto_Ivano |
do it!!!!!!
|
trocchietto_Ivano |
go for it
|
Mark M. |
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?
|
Apr 11 | 4:50 PM |
trocchietto_Ivano |
Kai what helped me?
|
Mark M. |
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
|
Kai H. |
I wanna learn Kotlin, as I don't wanna be an "Android dev" who only knows old technologies.
|
Kai H. |
That is also why I am looking into the "new" components, namely jetpack based app architecture
|
trocchietto_Ivano |
togheter with Java and Kotlin I started to do Python, Lisp
|
Kai H. |
I see
|
trocchietto_Ivano |
and you get.....is all about sequence, selection and iteration
|
trocchietto_Ivano |
coding is not changed since the 1930
|
Kai H. |
Yes, all the basics are already there
|
Kai H. |
And have been for quite some time
|
trocchietto_Ivano |
more languages you know and better you get in your specific language
|
trocchietto_Ivano |
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
|
trocchietto_Ivano |
and you have a tool in intelliJ convert to java bytecode
|
trocchietto_Ivano |
so you can see how kotlin is interpreted as Java by the virtual machine, is not fun that?
|
Kai H. |
Yes, that is a good functionality
|
trocchietto_Ivano |
you feel lik god
|
Mark M. |
you have an interesting definition of "fun" :-)
|
trocchietto_Ivano |
fun mydefinition() Unit
|
Kai H. |
I was about to ask if there is something like Javadoc for documenting android code, then I remembered the Kotlin thing of that exists.
|
Kai H. |
My question was gonna be "how to best document an android app, is there something like Javadoc?"
|
Mark M. |
the KDoc format is basically JavaDoc with extra options (e.g., Markdown)
|
Apr 11 | 4:55 PM |
Kai H. |
(How) do you document Android code?
|
Mark M. |
I write books about it :-)
|
trocchietto_Ivano |
lol
|
Kai H. |
Lol. I meant in a project you do.
|
Mark M. |
and for my clients' projects, I adopt whatever system they use
|
Mark M. |
which, all too often, is "few code comments"
|
Kai H. |
I don't wanna adopt "no comments at all" ;-)
|
trocchietto_Ivano |
better know algorithms,data structures, and design patterns with a bit of assembly that languages syntax
|
Mark M. |
personally, I don't bother with strict KDoc/JavaDoc syntax, unless the project is going to generate HTML out of it
|
Mark M. |
so, I'm more of a "simple block and line comment" sort of guy by default
|
Kai H. |
Is the reason why there are so few comments in your example code that it's all explained in the book?
|
Mark M. |
yes
|
trocchietto_Ivano |
good code should comment itself
|
Mark M. |
it's a nudge to get people to subscribe, frankly
|
trocchietto_Ivano |
you spare a lot of superfluos read
|
trocchietto_Ivano |
lol
|
Kai H. |
Ivaon: I kinda disagree. I think the code is about the "how", comments are about the "what" and "why".
|
trocchietto_Ivano |
too late we gotta wrap up:( in ten sec
|
Apr 11 | 5:00 PM |
Kai H. |
Yes
|
Kai H. |
unfortunately
|
Mark M. |
sorry!
|
Kai H. |
Have a good weekend everyone
|
Kai H. |
And stay well
|
trocchietto_Ivano |
:)
|
Mark M. |
you too!
|
trocchietto_Ivano |
and good easter if you are in achristian country
|
trocchietto_Ivano |
bye
|
Mark M. |
FYI, the next chat is Tuesday at 7:30pm US Eastern
|
Kai H. | has left the room |
trocchietto_Ivano | has left the room |
Mark M. | turned off guest access |