Mar 16 | 7:20 PM |
Mark M. | has entered the room |
Mark M. | turned on guest access |
Mar 16 | 7:30 PM |
Scott W. | has entered the room |
Mark M. |
hello, Scott!
|
Scott W. |
hello!
|
Mark M. |
how can I help you today?
|
Scott W. |
you ever use travis?
|
Mark M. |
nope, sorry
|
Scott W. |
ok next question
|
Scott W. |
we talked about using the maven repo for release builds, and local modules for debug last time.
|
Scott W. |
I implemented debugImplementation... and releaseImplementation... for the sdk
|
Scott W. |
however, there are other variants
|
Scott W. |
staging for example
|
Mark M. |
is that a build type or a product flavor?
|
Scott W. |
build type
|
Scott W. |
What I ended up doing is defining a boolean (USE_MAVEN) at the top of the build script and setting it to true in the release build variant definition
|
Scott W. |
false otherwise
|
Mar 16 | 7:35 PM |
Scott W. |
then I put an if statement in the dependencies block
|
Scott W. |
It seems to work, but doesn't seem elegant
|
Mark M. |
why not just add a stagingImplementation line?
|
Mark M. |
if staging is a build type, it's a peer of debug and release
|
Scott W. |
what does it mean to be a peer?
|
Mark M. |
debug and release are build types
|
Mark M. |
staging is a build type
|
Mark M. |
so, all three are build types
|
Scott W. |
ok
|
Mark M. |
if you are using debugImplementation and releaseImplementation, then stagingImplementation would seem to be what you are missing
|
Scott W. |
well we have... 5 build variants and 2 flavors
|
Mark M. |
do you mean 5 build types? with 2 flavors, the count of build variants would have to be even
|
Scott W. |
I guess so. 5 build types, 2 flavors, so 10 versions of the library
|
Mark M. |
right
|
Mar 16 | 7:40 PM |
Mark M. |
in principle, you would need five editions of the ...Implementation line: debugImplementation, stagingImplementation, releaseImplementation, and two more for whatever those other build types are named
|
Mark M. |
there may be ways to simplify that, but I haven't had a need for that many build flavors, so I am not certain what the options are
|
Scott W. |
ok
|
Scott W. |
I'll stick with this boolean then. The main module has to define the other modules, so that would be something like 5 * 4 lines for the dependencies is I specified each build type
|
Scott W. |
next question
|
Scott W. |
I think I know the answer to this, but I'm having a hard time keeping all of this stuff straight
|
Scott W. |
the repositories defined by my sdk are not preserved in the packaging process. Is that right?
|
Mark M. |
correct
|
Scott W. |
why is that?
|
Scott W. |
security reasons?
|
Mark M. |
¯\_(ツ)_/¯
|
Mark M. |
that would be a question for the people who developed Maven
|
Scott W. |
ok
|
Mar 16 | 7:45 PM |
Scott W. |
next question
|
Scott W. |
In Android Studio, I can press cmd + option + L to autoformat the focused file
|
Scott W. |
it's an option in the Code menu I think
|
Mark M. |
yes
|
Scott W. |
I would like to make it so that ./gradlew lint fails if that code formatting would have any work to do.
|
Scott W. |
I do not know how
|
Mark M. |
you're looking for something like ktlint
|
Mark M. |
oh, wait -- which language are you using again?
|
Scott W. |
java
|
Mark M. |
ah, ok, ktlint is for Kotlin
|
Mark M. |
something like Checkstyle might have a Lint-style Gradle task for Java -- I have never looked for one
|
Mark M. |
there is nothing built into Android Studio, but you should be able to find a Gradle plugin that does what you want for Java
|
Mar 16 | 7:50 PM |
Scott W. |
ok I'll look around.
|
Scott W. |
I posted in the /r/androiddev hiring thread.
|
Scott W. |
I'll let you know next week if I get any bites.
|
Mark M. |
sounds good! best o' luck!
|
Scott W. |
aight
|
Scott W. |
well that's it for me. Have a good night!
|
Mark M. |
you too!
|
Mar 16 | 8:10 PM |
Scott W. | has left the room |
Mar 16 | 8:30 PM |
Mark M. | turned off guest access |