Office Hours — Today, April 11

Thursday, April 9

Apr 11
3:55 PM
Mark M.
has entered the room
Mark M.
turned on guest access
4:10 PM
Kai H.
has entered the room
Kai H.
Hello
Mark M.
hello, Kai!
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)
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
unless you're doing something in a tight loop, in which case you probably are not using the "old" approaches either
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
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
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
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
SavedStateHandle is the mechanism for that
I cover that in the latest *Elements of Android Jetpack*
Kai H.
Ok, I'll have a look
Cool
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
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
Kai H.
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
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.
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.
Mark M.
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
trocchietto_Ivano
has entered the room
Mark M.
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
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
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
Ivano: how can I help you today?
trocchietto_Ivano
HI Mark and Kai, no questions
just chilling out
Kai H.
Hi Ivano
Mark M.
OK -- if you come up with one, chime in!
trocchietto_Ivano
ill do sir!
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
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)
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
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
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.
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
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)
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
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.
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.
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!!!!!!
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?
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.
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
coding is not changed since the 1930
Kai H.
Yes, all the basics are already there
And have been for quite some time
trocchietto_Ivano
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?
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.
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)
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
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
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
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
5:00 PM
Kai H.
Yes
unfortunately
Mark M.
sorry!
Kai H.
Have a good weekend everyone
And stay well
trocchietto_Ivano
:)
Mark M.
you too!
trocchietto_Ivano
and good easter if you are in achristian country
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

Thursday, April 9

 

Office Hours

People in this transcript

  • Kai Hatje
  • Mark Murphy
  • trocchietto_Ivano