Office Hours — Today, April 27

Tuesday, April 24

Mark M.
has entered the room
Mark M.
turned on guest access
Apr 27
7:45 PM
Ivan L.
has entered the room
Mark M.
hello, Ivan!
how can I help you today?
Ivan L.
Well hello there Mark! Never been to one of your office hours sessions - thanks for hosting 😁 please excuse slow typing, I'm mobile atm
7:50 PM
Ivan L.
I had a bit of a thought experiment for ya, nothing too crazy. Involves fragment arguments and saved states.
Long story short is: I've got a fragment instantiated with some arguments. File names, in this case. Said fragment presents some UI to delete, make new, or just discard changes to said files.
If you were writing this up, what kind of things would you do to hold the state of the files? As in, which files were too be deleted, what state your UI was in, maybe even a transient state saying such and such had been done. Would you keep those actions in the fragment proper, letting it maintain it's state, or would you invest some more time in plumbing out that business-ruley-stuff to a different persistence layer?
7:55 PM
Ivan L.
Oh, and your challenge: make sure all is well with state recreation for rotations, app death, etc.
Mark M.
I would lean towards pulling that stuff out into a ViewModel, allowing it to handle configuration changes
in terms of "app death", you could have a ViewModel participate in the saved instance state Bundle
but if the files in question are things on external storage, I would make few assumptions about the state of external storage after your process is terminated, and so I would recommend starting the UI from scratch
Diana M.
has entered the room
Mark M.
(hello, Diana -- I will be with you shortly!)
Ivan: BTW, by "ViewModel", I am referring to the one in the Architecture Components
8:00 PM
Ivan L.
Yeah, I see what you're saying. I've been sluggish trying out those new tools, it might make life better. For those ViewModels, they seem a bit like baby controllers or.presenters. last question: do you think they'd be good candidates for housing additional dependencies? Logic layers and the like.
Mark M.
I am not certain what you consider "logic layers" to be
my gut instinct is to have the ViewModel be fairly small, focusing on retaining data and managing some data flows
there is probably something else that manages business logic
but all of this is contingent upon your GUI architecture, and I am not a GUI architecture expert
tactically, from the standpoint of Android, ViewModel is a clean and endorsed way to hold data across configuration changes, which is why I suggested it
Ivan L.
Endorsed is good. If it's convenient enough to participate in saved state binding too, that might just be the ticket.
Mark M.
I wouldn't describe it as "convenient", but it is possible
I have material on that in the "Android's Architecture Components" book
8:05 PM
Mark M.
let me take a question from Diana, but given your keyboarding issues, feel free to keep chatting, and I'll time-slice between you
Diana: your turn! do you have a question?
Diana M.
I am going through Exploring Android studying AutoValue. On p 133, I'm getting an error with isCompleted, and it doesn't recognize import java.net.UUID;.
I already imported java.util.UUID;
Mark M.
then, what do you mean by "doesn't recognize"? are you getting a red error on the import statement itself?
Diana M.
isCompleted is red (cannot resolve method)
Mark M.
are you referring to the creator() method that you are adding in Step #6?
if so, isCompleted() should be a method on your Builder
Diana M.
Yes.
8:10 PM
Diana M.
I have a method:
public abstract Builder isCompleted(boolean isCompleted)
Mark M.
OK, then you should be calling isCompleted() on the Builder returned by builder(): https://github.com/commonsguy/cw-andexplore/blo...
8:15 PM
Diana M.
I copied your code and replaced mine. I don't see the error. I will go through and check the difference. Your code doesn't have a library called "java.net.UUID" which is what you refer to on p 133
Mark M.
if either of you have a question, go right ahead
I have an import statement for UUID: https://github.com/commonsguy/cw-andexplore/blo...
otherwise, it would not compile
Diana M.
But it's java.util.UUID, not java.net.UUID.
Mark M.
ah!
OK, now I see what you are getting at
I am not certain why you would get an error on isComplete()
but, yes, that is a typo in the book
...and, now it is fixed for the next book update
when in doubt, check the GitHub repo's source code
8:20 PM
Diana M.
On a more general note, if you were going to make an app with a lot of crowd-sourced data (thousands of objects) that continually change, would AutoValue be a bad idea?
Mark M.
not necessarily, though I would be a bit more worried if your minSdkVersion is below 21
garbage collection, as of Android 5.0, is better at handling short-lived objects
Diana M.
Would you lose a large percentage of users if you made that condition?
Mark M.
if you are distributing via the Play Store, probably not
right now, Android 4.x is ~15% of the market, with tiny amounts of Android 2.x
and those numbers will continue to decline
now, if you are specifically targeting countries where you know that older devices tend to be used longer, that's a separate issue
8:25 PM
Mark M.
and, if you are distributing through other channels, you might see if they offer similar sorts of statistics
Diana M.
OK. Thanks. I will study AutoValue more. Right now, I'm still pretty uncomfortable with the idea of immutable classes for this application.
Mark M.
they are not a natural feature of Java, which is why you need something like AutoValue
immutable classes *are* a natural feature of Kotlin (called "data classes" there)
Diana M.
Would you recommend learning Kotlin?
Mark M.
sometime, ye
er: sometime, yes
Diana M.
To what advantage?
Mark M.
I am not certain what you mean
if you mean "why learn Kotlin?", because in ~4 years it will be the dominant Android programming language in many countries
Diana M.
What would I gain from it?
How does it compare to Android java?
Mark M.
it is generally less verbose than Java
8:30 PM
Ivan L.
has left the room
Mark M.
and it offers some language features that can simplify development further
but, to be honest, a lot of the reason why people are moving to Kotlin is that "all the cool kids are moving to Kotlin"
that, coupled with Google pushing it, and with tangible benefits for its use, means that Kotlin is likely to do fairly well
it may not be adopted as quickly as Swift was for iOS development, though
which is why I have a longer timeframe (~4 years) and limits on scope ("in many countries") on my estimate
Diana M.
Learning Android Java is certainly much more difficult than learning standard Java. Do you think Kotlin is easier to learn?
Mark M.
in terms of the language itself, "Android Java" is "standard Java" -- the difference is in the libraries and what you do to build a program
I would not say that Kotlin is easier to learn
if anything, it may be more difficult to learn
it is somewhat easier to write, and it is easier to write something that is terse
that
er, that's a wrap for today's chat
Diana M.
I can write code in standard Java after studying the language for several months. With Android, because of all the entry points and layers upon layers, it's taking me a long time.
Thanks. Have a good weekend.
Mark M.
the transcript will be posted to https://commonsware.com/office-hours/ shortly
the next chat is tomorrow at 9am US Eastern
have a pleasant day!
8:35 PM
Diana M.
has left the room

Tuesday, April 24

 

Office Hours

People in this transcript

  • Diana Marmorstein
  • Ivan Lugo
  • Mark Murphy