انتقالات Hero وحركة العناصر المشتركة

A Hero transition animates a single widget so it appears to fly from one screen to another during a route push or pop. Instead of the user losing track of an element across screens, the same visual object morphs in place.

• Think of a thumbnail in a list that expands into a full-screen detail image.
• Flutter computes the start and end rectangles and tweens the widget between them.
• This continuity is what designers call shared element motion.

In this lesson you will coordinate Hero widgets and customize the flight shuttle that actually renders during the in-between frames.

To create a Hero animation you wrap the source and destination widgets in a Hero widget and give both the same tag. The tag is how Flutter pairs them across routes.

• Tags must be unique per screen but identical between the two screens.
• If two Heroes on the same screen share a tag, Flutter throws an assertion at navigation time.

Below, a product thumbnail on the list screen uses the product id as its tag.

The detail screen must wrap its large image in a Hero with the exact same tag. When you push the detail route, Flutter detects both Heroes and starts the flight automatically.

• The child widgets do not have to be identical — only the tag must match.
• Here the destination is a full-width image, while the source was an 80x80 thumbnail.

During a route transition Flutter scans both the outgoing and incoming routes for Heroes, then builds a map keyed by tag. Only tags present on both routes animate; an unmatched Hero simply fades with its page.

Because tags are matched by equality, you can use any object as a tag — strings, ints, or enums — as long as == and hashCode behave correctly.

The widget rendered during the flight is called the flight shuttle. By default Flutter uses the destination Hero's child for the entire flight, cross-fading where needed.

This works well when the two children look alike. But when the source and destination have very different shapes — for example a square avatar becoming a rounded banner — the default can look like an abrupt swap. That is when you supply a custom flightShuttleBuilder.

The flightShuttleBuilder lets you control exactly what is painted mid-flight. Its signature gives you the animation, the direction (push or pop), and both Hero contexts.

• flightDirection is HeroFlightDirection.push or .pop.
• Return any widget; it will be positioned inside the interpolated rectangle for you.

Here we rotate the child slightly as it flies to add polish.

A common shuttle pattern is cross-fading from the source child to the destination child so the morph reads smoothly. You can drive a FadeTransition from the same flight animation.

• On push, fade the source out and the destination in.
• On pop, reverse the roles using flightDirection.

By default the Hero moves along a straight line. You can bend that path with createRectTween, which controls how the bounding rectangle is interpolated.

Material's MaterialRectArcTween gives a curved, more natural arc — the same motion Material Design recommends for shared element transitions.

The most frequent Hero bug is a duplicate tag on a single screen. In a ListView of items, every Hero needs a tag unique to its data row.

• Never use a constant string like 'hero' for all items.
• Derive the tag from a stable identity such as the model id.

This helper guarantees uniqueness when building list rows.

When a Hero's child has elevation, rounded corners, or ink — like a Card or Material surface — the flight can show clipped or square corners because the in-flight widget is detached from its original ancestors.

Wrap the shuttle (or the children) in a Material with type: MaterialType.transparency so text, shadows, and clipping render correctly mid-flight.

In this track we pair Hero transitions with Rive animations for richer motion. A clean approach is to let the Hero handle position and size, while a Rive state machine plays a micro-animation on arrival.

• Drive a Rive SMITrigger when the destination route finishes its transition.
• Use animation.addStatusListener on the flight to fire the trigger at AnimationStatus.completed.

Keep the Hero shuttle simple; let Rive own the expressive part so the two systems do not fight over the same frames.

You have a grid of avatars; tapping one pushes a profile screen. The avatar is a 56x56 circle, and the destination is a 200-tall rounded banner. The default flight looks like an abrupt swap and the corners flicker square during motion. Which combination best fixes this?

You now know how to build polished shared element transitions:

• Matching tags on source and destination Heroes drive the pairing; tags must be unique per screen and identical across screens.
• The flight shuttle is what renders mid-flight; customize it with flightShuttleBuilder to cross-fade differing children.
• Wrap shuttle content in a transparent Material to keep shadows, text, and rounded corners correct.
• Bend the path with createRectTween and MaterialRectArcTween for a natural arc.
• Let Hero own position and hand expressive micro-motion to a Rive state machine, fired on AnimationStatus.completed.

Combine these to make screen changes feel continuous and intentional.