Apr 18 |
4:35 PM |
Paul R. |
If memory serves they are distributed as a single app via the Play store but multiple apps via HockeyApp (sp?)
|
Mark M. |
I have no idea why they think that's a good idea, or how they are pulling that off
|
Mark M. |
a project can certainly have several app modules
|
Mark M. |
and those can depend upon common library modules, also in the same project
|
Mark M. |
it is possible that they are doing some dynamic code stuff -- I have a chapter on that in the book
|
Paul R. |
I get the multiple library part but not the multiple apps.
|
Mark M. |
modules are modules
|
Mark M. |
whether a module builds a JAR, an AAR, or an APK is simply up to the module's build.gradle file
|
Paul R. |
Oh cool. I'll look into that dynamic aspect.
|
Mark M. |
so, having multiple apps in a project is easy
|
Mark M. |
a few of my open source libraries have multiple apps in a project
|
Mark M. |
but, those are individual standalone apps, not under some larger umbrella thing
|
Paul R. |
I did see some verbiage that test apps are separate modules but I do not grok that either.
|
Mark M. |
and the primary lesson that you should take from the dynamic code chapter is: use this approach only if you have a large legal defense fund, as from a security standpoint, it's difficult to do correctly
|
Paul R. |
:-)
|
Mark M. |
let me switch back to Joseph for a bit, and I'll return to you shortly
|
Mark M. |
Joseph: your turn! do you have another question?
|
Paul R. |
ok
|
Joseph |
Hi again, thanks
|
Joseph |
if possible
|
Joseph |
one more about the tests
|
Joseph |
i know i can load different resources/classes to flavors
|
Apr 18 |
4:40 PM |
Joseph |
can i do it with tests ?
|
Mark M. |
um, well, you can have different tests for different flavors, IIRC, if that is what you are asking
|
Mark M. |
and your test classes clearly are different than your production classes, getting merged together when the tests are run
|
Joseph |
i mean to have 2 server classes that will run for tests or prod
|
Mark M. |
not really
|
Joseph |
:(
|
Mark M. |
it doesn't make sense to test something that does not need testing
|
Mark M. |
the point behind the tests is to test the production code
|
Joseph |
so i must build as much as pure function code for the tests to be as agile as possible
|
Mark M. |
I do not understand that part, sorry
|
Joseph |
yes, but when i don't need the entire code for the stuff i want to test
|
Mark M. |
that would not *replace* your production code, though
|
Mark M. |
which is what replacing classes across flavors is for
|
Joseph |
i can't just disable these methods to no op
|
Mark M. |
that might be *an additional class*, but then you would just have that in androidTest/
|
Joseph |
i c
|
Mark M. |
and you might wind up doing some refactoring to make it easier to have that test-only server class, without lots of code duplication
|
Mark M. |
if you wanted to create a dedicated flavor and a dedicated set of test classes for that flavor, you could replace the production code for just that one class
|
Apr 18 |
4:45 PM |
Mark M. |
but that seems like overkill
|
Joseph |
View paste
just trying to sum things up :
with multi thread test like mine you suggested countdown latch and some sort of observer together with some code refactoring for the issues i stated.
|
Mark M. |
off the cuff, that is how I would start approaching the problem
|
Joseph |
Thank you.
|
Joseph |
and a different question if possible please
|
Mark M. |
go ahead
|
Mark M. |
but, um, quickly :-)
|
Joseph |
When using shared element transition i have an image on my card that needs to grow
|
Mark M. |
sorry, but I have never played with shared element transitions
|
Joseph |
Thanks anyway :)
|
Joseph |
And again , Thank you for your time.
|
Apr 18 |
4:50 PM |
Mark M. |
you are welcome!
|
Joseph |
it was very helpful
|
Mark M. |
Paul: back to you -- do you have another question?
|
Paul R. |
Sure.
|
Paul R. |
I want to beat this project vs module stuff to death. :-)
|
Paul R. |
I think it is safe to say that a project is defined by the presence of an *.iml file. Would you agree?
|
Mark M. |
no
|
Mark M. |
projects and modules have .iml files
|
Mark M. |
and that's an Android Studio thing anyway
|
Paul R. |
Is there a difference between a Gradle project and an Android Studio module?
|
Mark M. |
Google went with JetBrains' terminology, rather than Gradleware's, when setting up Android Studio
|
Mark M. |
so, when Gradle docs refer to subprojects, that equates to Android Studio modules
|
Mark M. |
in Gradle, we have a project with subprojects; in Android Studio, we have a project with modules
|
Mark M. |
for example, that's why in the top-level build.gradle, we have things like an allprojects {} closure
|
Mark M. |
because Gradle refers to modules as subprojects
|
Mark M. |
if Gradle happened to use Android Studio terms, that would be a modules {} or allmodules {} closure, or something like that
|
Paul R. |
So with an AS project containing two apps, app1 and app2, each app* will have a .iml file and is a module?
|
Mark M. |
yes
|
Mark M. |
the settings.gradle would list both app1 and app2
|
Mark M. |
app1/ and app2/ would be directories off the project root (in a typical setup)
|
Apr 18 |
4:55 PM |
Paul R. |
OK, that helps.
|
Mark M. |
and they would each use the com.android.application plugin, if they are building apps
|
Paul R. |
Just to be clear though, each gradle subproject does not need a build.gradle file. A single top level one can suffice.
|
Mark M. |
well, almost always there will be a module/subproject-level build.gradle file
|
Paul R. |
But there must be one entry in settings.gradle for each sub-project.
|
Mark M. |
correct
|
Mark M. |
the module/subproject-level build.gradle file would contain the instructions for building that thing's artifact(s)
|
Mark M. |
so, it would apply some sort of Gradle plugin to do that, as Gradle otherwise cannot do much with the contents of the module/subproject
|
Mark M. |
that could be the java plugin, if you are creating a stock Java JAR, or com.android.library for an AAR, or com.android.application for an APK, or...
|
Paul R. |
I've managed to build at least two Gradle projects with only the top-level gradle file. Mind you, after a while it got too hairy.
|
Mark M. |
I have never tried that
|
Mark M. |
I expect that YMMV
|
Paul R. |
Ok, that does it for me for today. Thanks for your insight.
|
Mark M. |
and that's a wrap for today's chat
|
Apr 18 |
5:00 PM |
Mark M. |
the next chat is tomorrow at 9am US Eastern
|
Mark M. |
the transcript of this chat will be posted to https://commonsware.com/office-hours/ shortly
|
Mark M. |
have a pleasant day!
|
Mark M. |
turned off guest access |
Paul R. |
has left the room |
Joseph |
has left the room |