3

I'm using the shared element transition with a recyclerview, as you can see in this gif:

enter image description here

there is a delay starting the shared element transition, It's not about the animation's speed, it's like a loading delay at the start, if you notice, there is a moment where the whole background disappear and just the image remains there, that moment is what I want to remove, that is the delay I talked about. How can I remove it and make the whole thing more smoother? it's really ugly right now, it's my first time with this animation so If you have advice I'd be thankful.

This is the code that handle the shared element transition inside my adapter:

holder.image.setTransitionName("example_transition");
            Intent intent = new Intent(context, ShowElementActivity.class);
            intent.putExtra("Element", elemento);
            ActivityOptionsCompat options = ActivityOptionsCompat.makeSceneTransitionAnimation(
                    (AnimeActivity)context, holder.image, ViewCompat.getTransitionName(holder.image));
            context.startActivity(intent, options.toBundle());

This is the code that handle it inside the destination:

postponeEnterTransition();
    Glide.with(this)
            .load(elemento.image_url)
            .listener(new RequestListener<Drawable>() {
                @Override
                public boolean onLoadFailed(@Nullable GlideException e, Object model, Target<Drawable> target, boolean isFirstResource) {
                    supportStartPostponedEnterTransition();
                    return false;
                }

                @Override
                public boolean onResourceReady(Drawable resource, Object model, Target<Drawable> target, DataSource dataSource, boolean isFirstResource) {
                    startPostponedEnterTransition();
                    return false;
                }
            })
            .into(showelement_image);

    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
        getWindow().getSharedElementEnterTransition().setDuration(200);
        getWindow().getSharedElementReturnTransition().setDuration(200)
                .setInterpolator(new DecelerateInterpolator());
    }
    Fade fade = new Fade();
    fade.excludeTarget(android.R.id.statusBarBackground, true);
    fade.excludeTarget(android.R.id.navigationBarBackground, true);
    getWindow().setEnterTransition(fade);
    getWindow().setExitTransition(fade);
C-Gian
  • 62
  • 2
  • 19

1 Answers1

1

This delay is cost of new Activity not cost of Transition, if you don't use Animation you will see same performance. So use Fragment rather than Activity.

Because of new Activity performance, I am developing applications via Single Activity with Multiple Fragments for best performance.

utrucceh
  • 1,076
  • 6
  • 11
  • I never used fragments, searching I can't get how to use them to replace my endactivity, do you have any suggestions? I only found a tutorial where the use was: call the fragment when you need and then set activity elements visibility to gone. is this really the way to use fragments? – C-Gian Dec 27 '22 at 20:05
  • 1
    Fragments lifecycle is a bit different from Activity. Simply Activity is skeleton, has menus from side panels or in ActionBars, but contents must be fully fragments (for best performance). If contents managed via only fragments, you will not need to handle view visibilities. I use this design in all commerical apps. And also there is a lot of projects using Multiple Activities, but all of them has same performance problems. Usually developers using Activities rather than Fragments, because of it is easier than Fragments :). Android has some bad designs, this is one of them :) – utrucceh Dec 28 '22 at 07:47
  • 1
    For example I didn't examine skyscanner's android app code, but I can feel quickly they use Activities rather than Fragments via transitions :) – utrucceh Dec 28 '22 at 07:50
  • oh ok, thanks for explanation, do you have some project example? just to understand how to convert my app with full activities to activities with fragments inside. And another question: everything that can be done in activities can be done in fragments right? are there no restrictions? – C-Gian Dec 28 '22 at 10:32
  • so basically I need to create a main activity with a fragment that handle the content, in my case a recyclerview, then also a fragment that replace the endactivity of shared element transition, and once I did this I need to handle manually the life of the fragments? or calling one fragment automatically makes the other one inactive? sorry for the amount of questions but online I find only fragment tutorial to show 2 views togheter – C-Gian Dec 28 '22 at 10:38
  • 1
    You can do everythink and more with fragments (for example orientation change works better on fragments). Lifecycle is like Activity a bit different. Change between fragments managing via FragmentManager, like `activity.getSupportFragmentManager().beginTransaction().replace(R.id.yourIdd, fragment).commit()` – utrucceh Dec 28 '22 at 12:37
  • ok, so I tried in a new project and I did like this: main activity with only appbar, bottomnavbar etc.., the main content is a fragment, so inside the mainactivity oncreate I add the fragment to the activity, then on the fragment added, there is a button , inside its listener I call: getActivity().getSupportFragmentManager().beginTransaction().replace(R.id.fragmentHolder, new LoginFragment()).commit(); it works, It's the way I should do it or I just messing up? – C-Gian Dec 28 '22 at 16:52
  • what makes me doubt is the fact that every time I need to switch fragment view, I call "new fragment", by doing so I recreate the same problem of the activities or is it ok? in case it's wrong should i use singleton pattern? – C-Gian Dec 28 '22 at 16:55
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/250714/discussion-between-c-gian-and-utrucceh). – C-Gian Dec 28 '22 at 16:59