hello, David

how can I help you today?

Hi, I have a question about shared element transitions.

um, you can ask, but I haven't played with those yet :-(

so, I wouldn't hold out a lot of hope that I'll be able to help

OK, pointers to info are as welcome as anything.

Let me describe what I am trying to accomplish and what I have tried and what I have seen on the web.

I want to share an element between a fragment and the toolbar during a transition. Basically I'm opening up a card and want the cards icon to animate to the toolbar.

is the toolbar being managed by the fragment, or by the activity?

The toolbar is managed by the activity. Which is the problem.

yeah, OK, I can imagine that

An activity transition allows the shared element because the root of transition includes everything.

But fragment transitions are "rooted" at the fragment holder.

I can do this with an activity transition and it works fine, but I have a single activity multiple fragment organization and would prefer not to change that.

just to confirm: what you are looking for is a smooth animation (scale and translate) from something in the fragment into the activity-managed toolbar, right?

I started to deep dive into animations and scene support to see if I could do something on my own, and while I'm learning alot about views / scenes and transitions, that may be a bridge too far.

Yes, I am looking to animate an thumbnail from cardview in fragment to toolbar in activity.

actually, I suspect that you're on the right track

I am curious when you mentioned toolbar managed by fragment.

well, Toolbar can be placed anywhere

I'm assuming from context that you are using a top-of-the-screen Toolbar

as an action bar replacement

but you could have a Toolbar elsewhere

Correct. I am trying to make use of coordinator layout / appbarlayout to handle scrolling and collapsing if I want it.

yeah, I've been avoiding those too

anyway, my guess is that you will need to roll your own animation

So am I making a mistake trying to "embrace" material design and its support classes. Because some of it seems half baked.

OK, that is something, other than looking at code over the weekend, I've not done.

well, personally, I avoid appcompat-v7

which in turn means I have to avoid the Android Design Support library, since that's tied to appcompat-v7, except for some bits that I have cross-ported to work with Theme.Material

I'm trying to do what google recommends. Sigh.

Google frequently doesn't do what Google recommends

I'm a design curmudgeon, so take my opinions with a large grain of a salt-like substance

for example, hiding/showing the action bar/toolbar/app bar/whatever based on scrolling is really cute, but if that's in my top 100 things to worry about, IMHO I screwed up

Fair enough. I don't know how to tie the animation with the fragment transaction.

"tie the animation with the fragment transaction" -- can you explain a bit more about this?

I had not realized that was part of the puzzle

Realize I have very little experience with animation other than the activity and fragment transition support. So When I commit a replacement of one fragment to another I want to animate the old fragment's selected icon to the toolbar.

well, your choices are either to start the animation at the commit() call or to start the animation on some fragment callback (either for the outgoing fragment or the incoming one)

there's a new synchronous commit in the alpha 24 edition of the support library I think, as they added that in Android N, but I haven't tried it

OK, that makes sense. I have not looked at N.

the biggest hiccup that I see is knowing where in the toolbar your animation should go to

as I assume you want the animation to go to the specific spot where the icon would show up when managed by the toolbar

you might be able to use a custom view/custom layout/custom action provider for this, with a transparent placeholder for when there is no icon to show

yes, without reimplementing google's shared element transition support.

oh, well, I can't promise you that

Yeah that is why I started to dive into scene / scene transition and was trying to find code in activity and fragment where the shared element animation setup is done. Again, that was rough going, fun, but rough going.

as I noted earlier, that, or lower-level view animation, probably will be required

I am not aware that the shared element stuff covers your scenario, though ideally it would fit in there somewhere

you're probably not the first to want to do this, and I doubt that you'll be the last

I appreciate your advice and may just use activity transition.

Yes, this is typical of what I have seen in google's apis. They seem low level and not quite complete. I would have assumed this would be a very common scenario to support given what I have seen in their flagship apps.

not everything that they use in their apps makes it into the SDK (built-in or support library)

for example, I just blogged today about the better ExifInterface implementations floating around the AOSP than the one that is available to us in the Android SDK

Google usually aims for rich lower-level support, figuring that the community can come up with higher-order solutions, in addition to any higher-order ones that Google themselves later implement

so, I can't quibble with the fact that this scenario isn't covered

it just seems likely enough that it probably ought to be covered

Yes, but everyone ends up implementing their own solutions to fill the gap and that becomes a mess.

One more question about appcompat, do you use the v4 or none at all.

well, the term "appcompat" refers specifically to appcompat-v7 (AppCompatActivity, Theme.AppCompat, etc.)

outside of a few book examples, I avoid this

I use support-v4, though

typically by way of support-v13, as my minSdkVersions are usually over 13

right I conflate the two.

We have debates at work about appcompat, with me towing the google line, and then suffering through multiple api calls.

I think I have what I need and if I come up with a solution and have specific questions I'll jump on another chat. This was helpful.

sorry I didn't have a magic bullet for you, though

I didn't expect one give what I've seen. I appreciate the advice.

later

have a pleasant day!

hello, Vincent!

sorry for the delay

how can I help you?

Hi! I would like to know why it's not a good idea to implement a constructor on a Fragment

I guess I'm trying to understand why we implement it via a static factory method

a fragment needs a public zero-argument constructor to work properly

I'm looking at the chapter of swiping with viewpager

we need to hold onto information across configuration changes

we also need to hold onto information that survives process termination but rapid restarts

So, a default ctor with no arguments wouldn't work here?

for that stuff, we use the saved instance state Bundle

a default zero-argument public constructor is fine, which is what the example shows (i.e., no constructor)

the arguments Bundle in a fragment is automatically attached to the saved instance state Bundle by Fragment itself

so anything we put in the arguments Bundle, such as via the factory method, is automatically saved across configuration changes and such

now, there is nothing stopping you from implementing multiple constructors: a public zero-argument one plus additional ones that take arguments, then stuffing those arguments in the Bundle the way the factory method does

this is incrementally more work, as you have to remember to implement the public zero-argument constructor, since the default one goes away once you start implementing other constructors

hence, Google recommended the factory method pattern

ah ok, makes sense, and one more thing, why static? I am a bit iffy when it comes to static

non-static implies an instance

if you want to create an instance, and you do not already have another instance, you cannot use an instance (non-static) method

static is basically 'global' and can be called by any object, subject to visibility rules (and a public static method can be called by anything anywhere)

Ok, thanks a lot Mark

and that's a wrap for today's chat

the transcript will be posted to http://commonsware.com/office-hours/ shortly

the next chat is tomorrow at 4pm US Eastern

have a pleasant day!