hello, Kai!

how can I help you today?

Hello Mark

How are you?

OK, and you?

Ok ;-)

Do you have a best practic for increasion versionCode automatically, eg. when using CI?

I have not done that too much

when I did, I had some Gradle code that uses a properties file to hold the version code

that code would increment the value, update the properties file, and use that value in the build configuration

I have read about that.

and I doubt that will work in a CI environment

And when would you upgrade? On commit? On push? On creating a tag?

Yes, probably not.

ah, I interpreted "automatically" as meaning "on every build", under the premise that you're not going to do 2 billion buids

er, buildws

er, builds

(yeesh, can't type today...)

What qualifies as a "build"?

clicking "Run" in the IDE, or running the equivalent Gradle tasks

I'm sure that there are patterns out there for deriving a version code from other values like git tags, or for using those as signals for an "increment the version code" -- personally, I have never done that

and those sorts of build solutions are the sorts of things that I do not research much before I need them

"On every build" would be waaay to often then.

well, you are unlikely to run out of integers :-)

That is true too. It still feels strange though.

some places use a timestamp, as that too results in monotonically-increasing integers

and you're unlikely to have two builds within a second of each other

but, again, this is not something I have spent time on

Ok

In hour app we sometimes update Accounts by removing and adding them again. I was wondering if there could be any bad side effects or if Accounts in Android are pretty much only key value stores.

"Accounts" as in AccountManager and the Accounts portion of the Settings app?

Yes, as in AccountManager

that too I have never used

I read the documentation when it came out, cringed, and never bothered with it afterwards

Why did you cringe? What did you use instead?

what pretty much every other developer does: anything but AccountManager

seriously, I think I have installed about 2-3 apps, ever, that have used it, at least in any user-visible fashion

That's interesting, as you usually go for the standard way in Android.

ummm... that's actually an interesting statement, as you'll find others who think that I "rock the boat" too much

but the approach that every one of my customers has been to handle credentials themselves

That's what I got from the chats we have. That you recommend going for the standard way first.

it varies

Ok, interesting. Could you outline the negatives of AccountManager?

not off the top of my head -- this is probably the first I have thought about it in 3 years or so

I rarely see it come up in developer discussions

I only ask because I had to play around with it or rather around it.

But it's interesting to know it so little used.

Let's say you have to change accounts from different points in your app (could be loaded via a file on the device, could be loaded by MDM + RestrictionManager, could be input manually in a settings screen), what

would your architecture around that look like?

I have never worked with RestrictionsManager -- this is probably the first that I have heard of it since Android 5.0 shipped

bear in mind that I'm not an enterprise app developer

and so things like MDM are waaaaaaaaaaaaaaay outside my area of expertise

The question should be more an architectural one.

except that I haven't the foggiest notion of how MDM affects app development

Right now we call some methods in various places and often the logic is in the place that the accounts get added or removed, which makes it rather hard to reason about how the app reacts and what happens when.

yeah, the most complex I have ever had to deal with is "how to we clean things up when the user logs out?"

So I was close to refactoring to an "Accounts" repository that would encapsulate all the logic and just expose a few distinct methods.

off the cuff, that doesn't sound bad, but I cannot tell you how well it fits your needs

With our app you can add several accounts at once, with rules like "set an account active if it was just added and there was not account prior", "don't set an account active if another account is already active" and so on.

in my case, that sort of thing has always been handled by a server, or else there were no explicit accounts

Maybe your remember me asking about how an Activity can be started from another Activity, this was actually the use case behind it.

There is an activity that gets started when an account gets added from a file, and after being done with this the App should be shown as if it was started from the launcerh.

In our case the accounts are used to connect to a server, so they need to be on the device.

OK, I have skimmed our 15 December chat where you were discussing some of this

that being said, I am not certain how I can help you

I was hoping you'd have an architecture recommendation.

For that use case.

But it might be hard to tell from that far away.

yeah, I don't know how you can decouple this from the rest of your app concerns

at least, in terms of the level of advice that I could give

so, other than "use dependency inversion to help with cleaning up singletons that might have per-account info", I am uncertain what to advise

I have no idea how I would introduce DI in our app. That is a thing for another day.

I just recently tried writing tests and was quite pleased with that.

But found out that we do a lot of stuff in Activities and that is kinda hard to test.

in the end, a lot of the modern Android architecture stuff has centered around trying to get code out of activities and fragments and into more-testable things

because UI testing is... unpleasant

And a lot of the time kinda unneeded, I guess.

So if I REALLY wanted to test it, I'd probably refactor the code in question out of the Activity. Thought as much.

Do you test Activity, as part of integration tests or something similar?

that would depend on the customer -- and, in practice, that means "not much"

Btw, you said you aren't doing enterprise development. Who do you then develop for?

my past clients have all been delivering consumer apps

Ofc.

I was like "what is there besides app by enterprises", but of course there is b2b and b2c.

That's all I have for today I guess :D

OK, I am sorry that I was not of much use this time

I guess those were kinda details questions anyway.

And no unsovled problems, just things I wondered.

mostly, you just hit a bunch of topics for which I have limited experience

Thanks for your continuing book releases btw, I plan to go through "Exploring Android" soon, to continue my hobby app in Kotlin instead of Java.

sounds good!

let me know if you run into any problems with it that I can fix!

And I have gone through your Kotlin book(s) and have used the other books as references, to look up different topics

As you might have noticed I am not shy on that front ;-)

Did you convert an App from Java to Kotlin somewhat recently?

in 2018-2019 I helped two firms that were part-way through that conversion

I was wondering how much of an architectural change might come with that.

by default, zero

I mean, Kotlin does not impose any architectural requirements

nor does it require you to change the API of your classes

Well, yes, you can do "convert Java to Kotlin" on a file, but afterwards you'd probably look at it and go "well, this can be done much nicer in Kotlin".

yes, though a lot of that is below the level of what I would consider "architecture"

Well, sure.

the automatic conversion usually results in a faithful conversion, but the resulting Kotlin can use cleanup at minimum

and there are a lot of tweaks that you can make beyond that

I've made that experience, hence the question.

And then there is AsyncTask vs Coroutines, Lazy Properties and so on and so forth.

there may be cases where Kotlin makes you more inclined to *also* adopt other things that trigger architectural changes (e.g., DI)

AsyncTask is another good example: there is nothing stopping you from having AsyncTasks written in Kotlin

you might choose to move to something else

I guess once we start using Kotlin, a lot of code that would have become AsyncTask with Java will instead become Coroutines.

personally, I'd look at that as a multi-step code overhaul

I don't like AsyncTask too much tbh. It's a lot of confusing jumping around in our code.

IOW, until you're pretty comfortable with Kotlin, do not go in and simultaneously change language *and* change significant bits of the implementation

Ok

AsyncTask had its day and its uses, mostly for earlier, simpler apps

Or for kinda big Apps like ours X) Where there are like 50 of them in total.

And 5 level deep inheritance structures and whatnot.

And lots of static nested classes to execute them.

So go Kotlin first and then change architecture, or the other way around?

that's a business decision, by and large

to the extent that "change architecture" involves writing lots of new classes, though, write them in Kotlin

the projects that I helped did not do a "OK, we're moving everything from Java to Kotlin" phase

instead, new stuff was written in Kotlin, and developers were encouraged to convert Java to Kotlin as part of other minor cleanup work

Sounds very reasonable.

with an objective of eventually getting rid of all the Java, but only as part of ordinary work

That would mean a lot of refactoring in the company, right?

Otherwise there will always be some Java code left.

sorry, I am not certain what you mean by that

oh, I see

If you don't look at your code regularly

well, there was a steady stream of other work, such as beefing up test suites, that helped

eventually, there would need to be some final "get rid of the lingering Java" task

I see

That feels so... unlikely for our App.

Hard to imagine.

OTOH, if the Java code is working, there is no huge rush to convert it to Kotlin

it's not like users will be able to tell the difference

Well, I'd like to one day not want to rip my eyes out when having to add a feature or find a bug ;-)

Kotlin neither causes nor prevents blindness

:-)

I mean Java.

In our App

my point is that you are likely to want to rip your eyes out over some Kotlin sometime too

Oh, sure. Yes

That is not Java as such, more of an architecture thing

ah

Combined with no comments and no tests.

And variable names like "d", "fnct" and so on

that's OK -- in Kotlin, they will all be "it" :-)

aaaaaaaaaaaaaahhhhhhhhhhhh

and, with that, I'll wrap up today's chat

X)

8)

Have a good time

next one is *tomorrow*, same time, 4pm US Eastern

And stay healthy

you too!