hello, Ivan!

how can I help you today?

Well hello there Mark! Never been to one of your office hours sessions - thanks for hosting 😁 please excuse slow typing, I'm mobile atm

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?

Oh, and your challenge: make sure all is well with state recreation for rotations, app death, etc.

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

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

Ivan: BTW, by "ViewModel", I am referring to the one in the Architecture Components

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.

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

Endorsed is good. If it's convenient enough to participate in saved state binding too, that might just be the ticket.

I wouldn't describe it as "convenient", but it is possible

I have material on that in the "Android's Architecture Components" book

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?

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;

then, what do you mean by "doesn't recognize"? are you getting a red error on the import statement itself?

isCompleted is red (cannot resolve method)

are you referring to the creator() method that you are adding in Step #6?

if so, isCompleted() should be a method on your Builder

see https://github.com/commonsguy/cw-andexplore/blo...

Yes.

I have a method:

public abstract Builder isCompleted(boolean isCompleted)

OK, then you should be calling isCompleted() on the Builder returned by builder(): https://github.com/commonsguy/cw-andexplore/blo...

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

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

But it's java.util.UUID, not java.net.UUID.

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

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?

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

Would you lose a large percentage of users if you made that condition?

if you are distributing via the Play Store, probably not

see https://developer.android.com/about/dashboards/...

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

and, if you are distributing through other channels, you might see if they offer similar sorts of statistics

OK. Thanks. I will study AutoValue more. Right now, I'm still pretty uncomfortable with the idea of immutable classes for this application.

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)

Would you recommend learning Kotlin?

sometime, ye

er: sometime, yes

To what advantage?

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

What would I gain from it?

How does it compare to Android java?

it is generally less verbose than Java

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

Learning Android Java is certainly much more difficult than learning standard Java. Do you think Kotlin is easier to learn?

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

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.

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!