Hey Mark

hello, Scott!

how can I help you today?

I'd like to continue our discussion about hosting an Android library on Maven Central

OK

It looks like Maven Central has an open source policy

My company doesn't want to open source our library.

OK

I want to make sure I understand what that would mean though. Does it mean I would I have to upload un-obfuscated code?

usually, the reference to "open source" is more of a licensing thing

So I wouldn't have to upload my actual java files or anything?

I guess I'm curious how the AAR wraps all of this stuff up.

I'm still trying to confirm that open source policy

ok

the AAR is a compiled library and does not contain source code

a common pattern with open source libraries is to have a separate artifact that is the source code

that's is what allows you to view the source of the library in Android Studio, for example

but, that's not a technical requirement to be able to use the library

ah, but I do see where Maven Central requires sources

at least for "packaging other than pom", and I'm not completely certain what that entails

there is little question that Maven Central is dominated by open source -- I guess I had not realized that was a requirement

no worries

I'm reading a document our company hosts saying we "adopted this Open Source Software Policy"

Can you link me the page you were on detailing the requirements for maven central?

here is what appears to be their main page for "producers" of artifacts: https://central.sonatype.org/pages/producers.html

roughly speaking, there are two ways to get into the Central Repository

one is to publish as open source and use their "Open Source Software Repository Hosting" service

the other is to be using some other repository manager software and sync with theirs -- that's the "Large Organization/Forges" section

"Forges" refers to hosted project management services, but of the ones that they list, the only active one that I recognize is Atlassian

(there, presumably, they are referring to Bitbucket, an Atlassian service)

and I don't know whether there is a closed source option via Bitbucket for publishing artifacts, either directly or via sync to the Central Repository

again, I'd like to point out: this isn't really my area

I've done a bit of this sort of thing, but mostly using homebrew solutions, and I'm far from expert at publishing artifacts

so, I'm happy to help, but... imagine a grain of salt about 12" on a side, and take that grain of salt with my recommendations :-)

I understand. You know a lot more about all parts of this than me, so it still helps to talk through.

but, from reading that page (and https://central.sonatype.org/pages/requirements...), I do agree that you are likely to find it a struggle, at best, to publish closed source artifacts this way

what about through jfrog, jcenter and all that stuff that is dying soon?

The example we looked at last week was OpenTok. I don't recall seeing their source code.

they might be using hosted JFrog Artifactory or something

I know that commercial software exists for hosting artifact repositories, and Artifactory is one (Sonatype, the folks behind Central Repository, have their Nexus product)

I have not looked into these solutions

OpenTok is backed by Vonage IIRC, and so they have somewhat more horsepower behind them than, say, I do

The Amazon S3 bucket is starting to look a lot better.

sonatype nexus looks way too complicated.

S3 is what I use for my CWAC libraries

and, my current consulting client is using it for internal artifact distribution

ok I've got another question.

the sorts of posts that we discussed last time are likely focused on public-access S3 buckets -- AFAIK, there is no publishing-side differences for authenticated buckets

right. I saw in those articles the library user was still having to add authentication to the s3 bucket in build.gradle

so we would need to hand the authentication out to our customers, and only they would be able to access the library.

is that correct?

correct

obviously, you have issues of the password being leaked or otherwise passed around, so it's not exactly Fort Knox

yeah

but it should greatly constrain access to your artifacts

well we don't really care if people get the artifacts.

we just don't want to publish the source code. That's my understanding.

in that case, skipping the authentication to read the S3 bucket makes things a bit easier for you and the customers

true

and there is no requirement for you to publish source code, other than the XML of the POM file itself

the AAR is compiled code

that sounds good

I'll try to set that up with a sample library this week and present a proof of concept.

sounds like a plan!

Does in matter if my library is signed with a specific key?

you don't have to sign an AAR

for publishing through Maven Central, you do, but that's a policy, not a technical requirement

so, for example, my CWAC libraries' AARs are not signed

./gradlew assemble —- will this sign the AAR?

not normally, though there may be a recipe to configure Gradle to do that

would the fact that it's signed prevent anyone from using it?

APKs get signed when assembled, which is why you need to teach Gradle about signing keys to get assembleRelease to work

no

all signing does, for APKs or AARs or JARs, is allow people to confirm that Thing 1 was signed by the same party as Thing 2

AARs and JARs might go the next step and use real certificates -- like you do for SSL -- that have some ties to real-world identities

but they are not a DRM solution

signing also makes the APKs/AARs/JARs a bit tamper-resistant, though I'm not sure if AARs/JARs have signatures validated that way

What is Thing 1 and Thing 2 in the example of me publishing an APK through Google Play Store?

Thing 1 is version 1 of your app

Thing 2 is version 127 of your app, or a pirated copy of the app, or a hacked version of the app being distributed on "the dark Web"

got it

ok running out of time. I have another question!

go ahead!

I started work on a feature today to allow 12 people in our video chat app.

so with 12 video feeds, we want to display 4 at a time in a 2x2 grid

and there can be 3 pages of grids that the user can navigate to by tapping an arrow or something.

Google really wants me to use RecyclerView for some reason.

I'm looking into using GridView

GridView is rather old and is designed for a vertically scrolling grid

and when the user taps the arrow, I'll just swap out the feeds in the GridView cells.

ah

if what you want is a 2 x 2 grid, use ConstraintLayout

GridLayout then?

hmm

(or TableLayout or RelativeLayout or maybe GridLayout if you can find somebody who actually used it)

I would have a ConstraintLayout inside of a ConstraintLayout then.

if you already have a ConstraintLayout, you might not need a second one to set up a 2 x 2 grid, then

just add the cells and set up appropriate constraints

There are some issues with multiple SurfaceViews as direct children of my parent ConstraintLayout

punching holes in things and covering up other UI elements.

that's a SurfaceView issue -- I doubt that adding another container layer will help

Keeping all of them in the same ViewGroup under the ConstraintLayout has fixed the issues for me.

the point of SurfaceView is to punch a hole in the normal UI processing and hand it over to something low-level for high-speed rendering, like video playback

OK

but, then, having a ConstraintLayout in a ConstraintLayout is not a problem

or, at least, no more of a problem than is having a GridLayout or TableLayout or RelativeLayout in a ConstraintLayout

ok I figured it might create some issues, but I'll give that a try.

yeah

the "no nested ConstraintLayout" guideline is because usually you don't need it

I get some weird behavior on older devices with nested ViewGroups

if you need it for reasons (e.g., you're applying a background to the nested one), then it's fine

aight well thanks again for the help!

you're more likely to have better results with ConstraintLayout nesting, then, as that's a library

older devices don't get bug fixes for framework layout types

oh that's a good tip

ok I'll sign off. Have a good night!

you too!