Hello

whoops -- hello, Kai!

sorry if there was a delay there

how can I help you today?

With Java, I was wondering what the proper way(s) to include a self made library is.

is the library a module in the same project as the app? or is it in a separate project?

It is in a separate (git) project.

Why would you put it in the same app? Wouldn't that kinda defeat the idea of a library?

I mean same project.

mostly, I wasn't certain how you wanted to define "library" -- multi-module projects are popular nowadays

It's more common functionality that can be used by several apps.

getting back to your question: is this a team app project, or is it just you as the developer?

Like a file system wrapper etc.

I am the team :D

um, in that case, if you wanted to cheat and just copy the JAR or AAR output from the library into libs/ and go with the new-project-standard Gradle line for pulling in such libraries, you could

That doesn't sound very automatic.

And it sounds like the library must be developed quite independently from the rest, which atm it is not.

well... the only automatic option would be for the library to be a module in the same project as the app :-)

So there is no good "local" way to do it? (non-local being to pull it in from a nexus or something)

well, the next step up in sophistication would be to publish the library to mavenLocal(), and to have the app(s) pull it from there

now, it's "push" vs. "pull", so for a single app it's equivalent work, but for N apps it is a bit more automatic

Currently I have it done that way I think, with an include in settings.gradle that points to a relative directory.

that works too

(assuming you mean what I think you mean)

neither of those solutions works great beyond a solo developer

once you get into a team, you'll want a shared artifact repo, somewhere all team members can reach

And I guess that is the proper solution as well.

that's closer to my first recommendation, though a bit more automatic

publishing to mavenLocal() allows/requires you to use Maven-style versioning

unless the apps are being updated in lock-step, versioning is important

Which would in turn allow for certain versions of the lib to be referenced, right?

right

so, App A could pull in 1.0.0 of the library, App B could pull in 1.0.1, and Apps C through Z could pull in 0.0.1-dev01

or whatever

That sounds very nice.

when you "ship" a new version of the library, you would increment the version information in Gradle, then run a Gradle task to put the artifact in your repository (mavenLocal() being one that is just on your own hard drive)

And then the app can pull in the new version :)

right -- your apps would include mavenLocal() in their repository list, then use standard Gradle lines (implementation "foo.bar:goo:1.0.1") no different than stuff you get from Maven Central, JCenter, Google's artifact repo, etc.

I wish we already had that, that would have spared me some trouble in the past.

Currently we have 4 apps and some are on androidx and some aren't, which is a probem I am yet to tackle :)

yeah, I think we were discussing that recent

er, recently

(and because using androidx is an "all or nothing" thing I kinda have to use an old version or switch or something).

another advantage of the mavenLocal() approach is that you also publish a POM file with the "transitive" dependencies that the library needs

that POM is versioned along with the artifact, so when the apps depend on an artifact version, they also pull in the transitive dependencies for that version

So it's version stable, pretty much.

yes

What if I pull in another version of the same library in the app?

standard Gradle dependency version resolution rules apply, no different than with two libraries from Maven Central, etc.

Ok

I'd have a question about ConstraintLayout too.

other than the fact that mavenLocal() is on your hard drive, it's a Maven-style repository the same as any other, and gets treated by Gradle the same as any other

That sounds very nice.

if you get teammates someday, you would revise the library Gradle script to publish to a common repository, and tweak the apps to pull from there

for my current main customer, we're using Amazon S3 for hosting a repo, so it is reachable by all team members, the CI server, etc.

Couldn't I push to both local and online, the second option being manually?

Ok

you could, but usually it is better to have one "system of record" for the artifacts

One source of truth

bingo

About ConstraintLayout: I wanted to have several textviews with a button below them and failed to "group" them. Each TextView + Button should be like one item and the items equally spread out over the whole height. How would I do that?

the most straightforward approach would be to wrap each TextView+Button in something (e.g., a LinearLayout), then use the ConstraintLayout to set up a chain of those somethings

Ok. I thought so, but didn't want to use LinearLayout, as I was so set on using _just_ ConstraintLayout without any nesting.

the inner containers could be LinearLayout or ConstraintLayout

I felt it would kinda defeat the purpose of using a ConstraintLayout to begin with

well, not all layout rules can be expressed directly in ConstraintLayout "language"

Hm. So I do have to nest to some degree? I felt like one of the strenghts of ConstraintLayout was pretty much "no nesting".

(or very little, I guess).

well, I suppose it depends on your "equally spread out" requirement

suppose you have 4 pairs of these things

are you saying that the 8 widgets are equally spread out?

No, the 4 pairs.

right, yeah, I don't think that can be expressed directly in ConstraintLayout language

Ok. Good to know.

I thought I was stupid and didn't see the solution :D

if you were very certain that you had enough screen space, you might be able to fake it by having a chain of the TextViews, leaving the Buttons out of the chain and just having them "hang" below their respective TextView

but I don't know if that will wind up giving you the desired overall spacing, and you will get overlapping widgets if the screen is too short for the content

And it would mean more space before the first group than after the last

Or some (non-relative?) offset.

probably, yes

if the widgets weren't paired this way, you would have just a single chain

and I don't know of a way to tell ConstraintLayout "OK, it looks like these are in one big chain, but really it's 4 pairs"

or "OK, treat these pairs as mini-chains, and then chain those four mini-chains together"

I can't rule out that there is some trickeration with ConstraintLayout to pull it off

but I don't know of any

Yes, it's either chain all the way or not at all, it seems.

ConstraintLayout is powerful; it is not all-powerful

"The all powerfull ConstraintLayout"

we're running out of chat time -- any last questions?

None that would be solved in that little time

I guess.

OK, well, if you need answers for those, try "42" or "Abraham Lincoln" -- they're probably not the right answers, but they're worth trying :-)

42 is used quite often by me

And "because"

Though I have trouble acception the last one.

"Why is Android Programming so hard?"

And "Is it me or (Android) programming?" ;-)

I'd go with "Abraham Lincoln" for both of those

OK, that's a wrap for the chat -- next one is Tuesday at 8:30am US Eastern

Well...

Have a good time rest of the weekend.

you too!