hello, Ivano!

how can I help you today?

Good (US) morning Mark I would like to learn better how to troubleshot Gradle challenges, for instance yesterday I was installing firebase-auth and i noticed that a transitive dependency twitter something did not allow to make the compilation possible, so I looked in stack overflow and

i discovered that the solution was to add a maven repository in the all repositories build.gradle :

now...

why happens this? is because gradle have to conect with a remote updated maven repository that retrieve a library that fix a bug?

i runned ./gradlew app:dependencies as you recommended in so, but did not help too much

stop

by firebase-auth, do you mean https://bintray.com/danijax/maven/firebase-auth ?

or, what is the exact compile statement you put into build.gradle in the dependencies closure to pull in firebase-auth?

was firebase-auth:1.1.1

that is not the complete compile statement

now i resolved backgrading

I found really strange there is nothing on internet, even not a blog that explain how to manage the most common issues in gradle for android

well, none of this really has much to do with Gradle

your problem seems to line up with https://github.com/firebase/FirebaseUI-Android/...

amazing

and the Fabric requirement is covered in the documentation for that library: https://github.com/firebase/FirebaseUI-Android/...

I see

the problem is that the Maven repository system does not handle inter-repository links very well

aaah

so you need to add manually

you need to add the repositories manually, yes

once the full set of repositories is available, then inter-repository links are fine

and the guy that replied on SO, just looked up on the git known issues, where the dev explain

great

I struggle often with gradle

if you happen to have a C/C++ background, it's akin to having one #include reference another #include -- so long as all the include paths are set up right, everything works

instead to look to SO, I would like some logic guidelines to follow

I knew include but not as reference to another #include

anyway clear

thank you very much

the build error you received should have said something to the effect of "could not resolve fabric-such-and-so", where fabric-such-and-so is the artifact that it could not find

(I'm not sure the exact Fabric artifact that firebase-auth depends upon)

mmh did not see, I peeked into the messages errors

but great tip to follow next time

if you get the "could not resolve" message, then you need to determine where that particular artifact comes from

aah

now i understand

you will get the same sort of problem if you use some library from Maven Central/JCenter that happens to depend upon one of my CWAC libraries

is what i got. could not resolve compile 'com.google.firebase:firebase-auth:1.1.1'

as I too use a custom Maven repository for my libraries, instead of Maven Central/JCenter

aah

never had problems with your projects

hmmm.... I would have expected that error message if Gradle could not find com.google.firebase:firebase-auth itself

I have never used Firebase, and so I do not know where they publish their artifacts

you are right

the error message was

could not find twitter something

and i saw with your app:dependency magic command

that twitter was a transitive dependency under firebase-auth

I thought to exclude

but then downgrading worked as a charm

yes, the GitHub issue I linked to suggests that the dependency upon Fabric is fairly new

ehy... by the way

could I ask you please a second question?

go right ahead

thanks

I read a LOOOOOOT of blogs over MVP that is the most popular way to arrange classes and packages in android, and regarding the lifecycle.... I have some

doubts, some blogs say you should not save the lifecycle. others you should save on the View as usual, others that you should save to the presenter. I am reading all and the contrary of all, and I am going to convert my god class big ball of mud to MVP and I am scared that I could cause some damage not respecting the lifecycle do you have some tips. Please consider my idea is to move the Cursor Loaders in the Model

stop

Android's UI system does not directly lend itself to MVC, MVP, MVVM, etc.

any implementation of such an architecture will have some points where the architecture is pure and some points where the architecture has to be bent to accommodate Android

(true is conceived as a simple model view as far as i read)

I see

and there are lots of different approaches that I have seen for MVP/MVVM for dealing with those places where the architecture needs to be bent

personally, I tend to focus less on maintaining the purity of any such UI architecture

but, I also tend to work on smaller projects

true

your repository

this is why I do not have a GUI architecture chapter in my book, nor am I planning on one any time soon

my focus tends to be: make the Android stuff work

sure, you are doing a great job to keep up with all the new stuff imo

thanks!

is true

OK Mark

have a pleasant day

you too!

I remain on line to intercept new comments

from new visitors

well, there are only ~5 minutes left in the chat

it is unlikely that anyone else will show up at this point

time is relative as EInstein said

so i give you my shutdown

see you soon

bye!

that is a wrap for today's chat

the transcript will be uploaded to https://commonsware.com/office-hours/ shortly

the next chat is Tuesday at 9am US Eastern