hello, CodeApprentice!

how can I help you today?

Good morning.

I'm trying to set up UI Automator 2.0 in an existing project in Android Studio 1.2.1.1.

the IDE gives me "Warning:Conflict with dependency 'com.android.support:support-annotations'. Resolved versions for app (22.2.0) and test app (22.0.0) differ."

Hello

(BTW, hello Bryan, I will be with you in a moment!)

sounds good

CodeApprentice: what are "app" and "test app"?

my dependencies

I don't understand your question.

your error cites "Resolved versions for app (22.2.0) and test app (22.0.0) differ."

does the name "test app" ring any bells?

no, I believe that's a generic name for the code under androidTest.

I'm using the "new" gradle project structure

ah, OK

kinda confusing -- they should be citing something like androidTest there

yah, the error message is unclear in lots of ways

anyway, you'll probably want to run a Gradle dependency report

gradle dependencies

run at the command line

./gradlew :app:dependencies isn't very helpful...it gives the same error.

(BTW, hello Bill, I will be with you in a bit, after CodeApprentice and Bryan!)

well the dependency report should show you who is asking for what

Yep! No problem. Thanks Mark. Hello all.

one of your direct dependencies wants 22.2.0 of support-annotations, the other wants 22.0.0

you need to determine who wants what, so you can add exclude directives in the Gradle build file, to eliminate the requirement for the older one, and then hope it all holds together

or, perhaps you can raise the version of the direct dependency that is looking for 22.0.0 to something higher, one that will be happy with 22.2.0

From http://stackoverflow.com/questions/29857695/and... it looks like the conflict is between the dependencies of `com.android.support.test0.2` and `com.android.support:support-v4:22.1.0`

well, that emoji is a first for this chat... :-)

and that emoji is supposed to be the word "runner"

hah!

ahh...the colon separator turned it into an emoji

anyway, either you need to synchronize the direct dependencies, or exclude the older 22.0.0 transitive dependency and hope that the library that wanted it will be happy with 22.2.0

let me take questions from the others, and I'll be back with you in a bit

Bryan: your turn! do you have a question?

yes

I have 2 questions the first has to do with "Fragment already added" errors I am getting. We are doing a single activity app that manages fragment "ups" synonmous with "back". We are getting this error at "random" (meaning I can't reproduce reliably yet) times. (crash = http://pastebin.com/wzuA7xiQ). What I am confused about is that we first try to find a fragment by tag and then use that otherwise we create a new one and then we just use .replace(). How can hitting "back" add a fragment that has already been added?

how are you creating a new one? are you sure there isn't some logic in there that tries to recycle an existing instance?

sounds good. I'll be working on things on my end.

when we navigat to new ones, we do try to recycle and use replacr

the error sure sounds like it is the existing HomeFragment instance that is trying to be added again

this only happens on back

I don't mean your findFragmentByTag() call; are you holding onto HomeFragment anywhere?

oh, meaning a memory leak of sorts?

if so, it is very possible

you might experiment with dump() on FragmentManager

so if I have an instance of homefragment still being held by something and we hit back, it won't "reuse" the hoemfragment in memory, but will error out because it is?

(is held in memory)

well, I don't know all the ins and outs of your code

anyway, back to dump()

yeah, how would you recommend using that?

I haven't played with it, but ideally it outputs the current contents of the FragmentManager

you might experiment with in the lab, to see whether the FragmentManager contents match your expectations

Ok, interesting, I think i will focus first on trying to reliably duplicate the error and then see what is in dump on error vs not on error

and depending on what you are doing in production, when you catch this error, you might dump() the state and include it in some report to your server

perfect, thank you!

let me take questions from the others, and I'll be back with you in a bit

can I wait in line for my second question?

kk

Bill: your turn! do you have a question?

Ready?! :)

GCM related questions regarding Registration ID.

Can an OS update actually reset the system token, like a factory reset?

*Registration ID

beats me

lol

outside of what you see in the GCM chapter, I know diddly-squat about GCM

that being said, registration IDs seem to be twitchy, from what I've seen on Stack Overflow

Alright. No worries. I'll follow up with you when I get a response from the Googles :) Reaching out to their GDEs.

Thanks Mark.

CodeApprentice: back to you! do you have another question?

still working on this

OK, I'll be back with you later

Bryan: back to you! do you have another question?

bill, are you working on the behavior of the back button (at the bottom of the screen) or the up/home button in the action bar?

yes, it is already in stackoverflow, should I just paste link

or paste question?

link is probably better

you are referring to the deep-linking stuff Google has been promoting, to allow search results to drive into an app?

no

to the stuff they currently have to do deep linking, hang on I'll get link I used

it is really bizarre behavior

that's what I was referring to, actually

not really

I have never seen the ability to open 2 distince app instances

they are not two instances

they are two tasks

if I understand your question correctly, Chrome is properly launching your activity in a new task

whereas the other browsers are not

yes

on Android 5.x, the title bar of the overview screen is driven by the task owner, if you will, which in this case would be the browser

but the thumbnail will be of the top-most activity in that task

and if they didn't open the link with new-task semantics, that'll be your activity

is there a way to tell different browsers to launch in a new task or to force them to use chrome only?

for that particular link scheme

no and no, but you can control the task stuff through manifest entries

what do you mean?

or, what specifically do you mean

Whenever you are ready, here's the relevent output of my dependencies: https://gist.github.com/codeguru42/64d284f54a7d...

I think setting the task affinity on your activity can help manage this

(CodeApprentice: after Bryan and Bill, I'll be with you)

Ok, I can look into that, thank you

I'll need to work out a specific recipe for this and add it to the task chapter of the book

I had thought browser developers would always spawn these things in new tasks, if it's not being handled directly by their own app (i.e., a link to a regular Web page)

let me take questions from the others, and I'll be back with you in a bit

I need to ready up on tasks too, I am thinking in a different paradigm

ok

Bill: your turn! do you have another question?

Bill: if you have another question, chime in and let me know; for the moment, I'll focus on the others

CodeApprentice: so appcompat-v7 wants 22.2.0 of support-annotations, and runner wants 22.0.0

so how do I resolve the conflict?

change androidTestCompile 'com.android.support.test0.2' slightly

beyond fixing the emoji

go androidTestCompile(...) { exclude module: 'support-annotations' }

where ... is the artifact string that gets emojified here in chat

and "go" is just a verb I used in the not-exactly sentence there

AFAIK you need the parentheses to allow the closure syntax

the exclude line says "pay no attention to this transitive dependency"

you are filling that dependency elsewhere

now, there's a chance that this won't work, in that something in 22.2.0 breaks what runner wants from 22.0.0

in which case, you could try excluding support-annotations from appcompat-v7, to force the older edition, but that seems even more likely to have problems

and, if neither combination works, AFAIK, you're screwed

which is why runner really needs to be more flexible in its dependency requirement

one other option is to revert to an earlier version of appcompat-v7

that too

not ideal, but doable

though that has other ramifications, particularly since it's a GUI bit, so the older edition won't necessarily tint all the widgets you'd like

plus bug fixes and whatnot

and btw, yes, the parens are required.

let me take questions from the others, and I'll be back with you shortly

Bryan: your turn! do you have another question?

hmmm....still getting the same error. Maybe another of my recently added dependencies also depends on support-annotations...

(CodeApprentice: grep through the dependency report, I guess, seeing who else wants it)

working on that ;-)

OK, it's free-for-all time -- if anyone has a question, go right ahead

what is the best way to manage apk size?

exercise and eating right

:-)

nice

could you be more specific?

I have a chapter on APK size tips in the book

plus Cyril Mottier has http://cyrilmottier.com/2014/08/26/putting-your...

and there's other stuff I need to add in there, like shrinkResources

perfect, I will read both of those~!

again, if anyone has any question, go right ahead

that doesn't restart an app

sorry, acgivity

it shouldn't be needed

just move your onCreate() and related code out to some other method

that you call from onCreate() and on an authentication state change

hmmmm

that seems very simple and elegant

almost too easy

it'll also have less UI flicker

as we skip the activity transition

I wonder if I had issues with the pulling the drawer stuff out of the oncreate? Authenticated there is a drawer, not so with unauthenticated

i will have to take a look, thanks

well, adding "exclude module: 'support-annotations'" still results in the same error. And I can't find anything in the dependencies report that shows another library with a transitive dependency.

would it be possible for you to post the whole report to another gist or something?

just support-v4 and runner depend on support-annotations

yah, I can do that

that's the one with the "exclude module"

well, here's one possibility, rolling back to my original "app"/"test app" question

let's assume that "app" means the actual app and "test app" is the app with the androidTest sourceset included

your exclude stuff means that only one support-annotations will be used in each of those

however, the error message is complaining about the difference between "app" and "test app"

and, based on the reports, those do indeed differ

the test apps are using 22.0.0; the app is using 22.2.0

now, *why* the tooling would care, I can't say

so are you thinking that "test app" refers to the combination of both the main app and the androidTest stuff?

correct

hmm...

and that, for some reason, the tools want the dependencies to jive between the app and the test app

I see what you mean. In other words, the error message isn't very good.

actually, it's better than what I had been originally thinking, if my guess is correct :-)

"test app" isn't especially clear

now, to fix this, you'd basically need to pin the regular and test editions of each build variant to the same support-annotations version

if nothing else, you'd exclude {} the transitive dependency from appcompat-v7 and runner, and manually require some version of support-annotations

though there may be some simpler Gradle syntax for handling this

Shouldn't excluding the support-annotations from runner be the same thing?

um, probably

to quote the old Infocom game Zork, "you are in a maze of twisty little passages, all alike" :-)

hmm...https://code.google.com/p/android-test-ki... seems to be a bug report about this issue

yeah, resolutionStrategy was the simpler Gradle syntax that I was thinking of

basically, a single place to pin the version of a particular transitive dependency

trying that now

we are running out of chat time -- now's a fine time to get any last questions in!

Is there a way to get a transcript of this emailed to me?

no, but you can view one at https://commonsware.com/office-hours/ shortly after the chat ends

ok, great, thanks!

well, the resolutionStrategy worked...now to figure out the next error message.

well, it's good to know that you're making progress

and with that, that's a wrap for today's chat

I'll bump an SO question and/or be back for the next office hours.

thanks for your help!

the next one is Thursday at 4pm US Eastern

you are very welcome

have a pleasant day, all!