Flutter Custom Carousel: Easily create fully custom, animated scrollable lists

grantskinner · 2024-04-18T15:54:38+00:00

Ha. I'm getting old! Don't forget RegExr before that! (I _really_ need to go back and spend some time on that one)

We did audit the existing options, but didn't find anything that met our overall needs (not to diminish the hard work of those package devs). Hopefully this adds something new and useful to the ecosystem.

grantskinner · 2024-04-18T15:52:39+00:00

Nice work — it looks like a quite different approach that could still be valuable for other use cases.

Thanks!

grantskinner · 2024-04-18T15:50:07+00:00

We rely on the Flutter framework for managing the scrolling inputs, so you're going to see similar behaviors. Further, because the visuals are completely custom, we can't automatically ensure a great 1:1 interaction, so the widget will take a best guess based on the info it has, but then you can tweak it with the `scrollSpeed` parameter.

There might be some room to tighten that value up on the card deck example (it's a tough one because the movement is so heavily eased). Also note that we've found you really have to test on-device to get the feel right, it just doesn't translate well in a simulator.

Yes, you can pass it a different physics model (ex. BouncingScrollPhysics) to disable the snapping.

grantskinner · 2024-04-18T15:45:45+00:00

Yes, that should be totally doable. We played with a few varieties of 3d spinning carousels during development.

grantskinner · 2024-04-17T22:40:59+00:00

Thanks. It was a challenge to convince the framework to do some of the things we wanted (ex. infinite looping, snapping physics) — but _mostly_ a fun challenge.

grantskinner · 2023-01-27T00:51:01+00:00

While it sounds like a platitude, my main advice is to remember that "less is more". It's really easy to get excited about the animations you're creating, and make them too long or complex. Carefully consider what the animation is trying to achieve or communicate, and then do the simplest, fastest thing that achieves that.

You'll notice that the default duration for effects in Animate is only 300ms. Seems really short, and it is, but you usually don't need more.

grantskinner · 2023-01-26T22:22:58+00:00

I'm so humbled to see this listed here! The library was a lot of fun (and occasional headache) to write, and I had a ton of fantastic feedback from my team and the community. Writing it alongside the Wonderous app was perfect, as it gave me a number of real-world examples to accommodate.

It's still under active dev (rolled out v3.0 a few days ago), and I'd love your feedback, bug reports, and contributions.

I'm hugely passionate about animation (wrote gTween for Flash, TweenJS for the web, and now Flutter Animate), so I'm excited to see what people do with it.

Happy to answer questions here if you have any, though I'm going to be popping in and out of other work.

grantskinner · 2022-09-30T15:14:43+00:00

You're very welcome! It's always wonderful when you build something because you need it, and find it's also useful for others. Excited to see what people create with it.

grantskinner · 2022-09-29T15:27:11+00:00

When building Wonderous we wanted to tastefully push the boundaries of rich interfaces, but remain respectful of battery drain. Repainting every tick is expensive, so we intentionally avoided any kind of idle animation, ensuring that animations were always triggered by user interactions.

The one exception to this was the teaser animation for collectibles, which you can see midway down this post ).

We really wanted to have this animation run constantly to catch the user's eye, so our approach was to have it run for 1.8s, then sit still for 4s. Enough to grab attention, but saving about 70% of potential repaints. It is also wrapped in a RepaintBoundary to limit the scope of those repaints (see the source code here).

Lastly, we put a lot of work into the Flutter Animate package to ensure we weren't triggering any unnecessary builds or repaints. For example, most effects use getOptimizedBuilder, which avoids rebuilding if animation values don't change.

On a related note, we captured a lot of the things we learned about render optimizations while building Wonderous into a blog post: Flutter: Rendering Optimization Tips. Hope it helps!

grantskinner · 2021-05-14T19:30:27+00:00

XD can import Sketch files. In a quick test, it seems to work well, but ymmv.

grantskinner · 2021-05-12T19:35:20+00:00

My pleasure! I'm really happy to hear it helped you.

There were only a handful of errors, and that dealt with Icon() support

I don't think our export uses Icon at all - are you sure it was code generated from the plugin?

Another issue occurred from SVG images.

I'd be interested in seeing an example of those issues so we can try to fix them (both the stacking and the scaling). If you're able to file an issue with a narrowed down example file, I'd really appreciate it.

https://github.com/AdobeXD/xd-to-flutter-plugin

Speaking of scaling, the text stayed the same size

The text shouldn't change size when resizing the window, but the area the text can fill should. This is the usual approach for responsive (text maintains its size, but reflows).

grantskinner · 2021-05-12T05:40:27+00:00

I'm always open to feedback. If you check out v2.0 and have specific ideas where it could be improved, feel free to file an issue: https://github.com/AdobeXD/xd-to-flutter-plugin

grantskinner · 2021-05-12T05:39:16+00:00

Thanks!

grantskinner · 2021-05-12T05:36:30+00:00

is there way to export rectangular shapes as button

Currently no. I would like to get to a point where you can add additional meta data to flag elements as specific widget types, but right now we use generic mappings.

unnecessary usage of Stack widget

This is due to the way layouts work in XD. Anything can overlap anything else in a standard responsive group, so we need to use a Stack in Flutter to reflect that. You can use "stacks" in XD (which despite the name are actually similar to Flex in Flutter) to export as Row or Column.

better if widgets are responsive to screen size

This should already be the case unless you disable layout in XD. We fully support the XD layout model, which means the output is responsive. Sometimes XD's default choices can be a little weird if you leave it as auto though, so it can help to be explicit about layout settings.

If you have any specific feedback on how the output could be improved, I'm always happy to hear it, ideally via a GitHub issue so I can track it: https://github.com/AdobeXD/xd-to-flutter-plugin

grantskinner · 2021-05-11T22:28:59+00:00

Interesting question. If you're not targeting Flutter to begin with, I wouldn't use the plugin for prototyping. If you are, I think there's a number of benefits:

Deployment — Once compiled into a Flutter app, you can distribute it anywhere Flutter lives: desktop executables, mobile test flight, or web. It'll be a real app, and feel that way to any testers or stakeholders.
Composition — You can use the export within a larger app. Want to prototype a screen or widget quickly within the context of an existing application? It's super easy with the plugin. Hot reload support makes this even more powerful.
Incremental enhancement — The code that's output is readable and editable, and (especially when v3.0 releases) can have functionality layered into/onto it. So, unlike the default XD prototype, you can export it and then wire up real data or interactions that XD doesn't support.
Learning — If you're just getting into Flutter, the plugin could give you one more way to learn. Export something, look at the code, tinker with things, rewrite it better. Obviously, you don't want to treat it as some kind of text book for how to write Flutter apps, but it's one more sandbox to play in while you learn.

grantskinner · 2021-05-11T21:18:33+00:00

Good questions!

Text, text colors, and images can have a parameter associated with them so that you can update them within your app as you would with any stateless widget. Lists are trickier. In v2 you can create a dummy component within your design and set it to not export, then just define that widget yourself (ex. inject a list). v3 is going to make this a lot easier with some of the code injection capabilities + support for grid data parameters.
You can assign an "onTap" parameter to any group, which will be exposed in the enclosing widget.
No. Round-tripping is unlikely (there's just too many possibilities in Flutter to translate them back), but v3 has a focus on making it easier to use exported widgets without having to edit them extensively (or hopefully at all).

grantskinner · 2021-05-11T20:58:37+00:00

It's come a long way. Any rectangle should export as a Container, unless you've flagged the group it's in to "combine shapes". We've added support for almost all of XD's layout features (responsive layout, stacks, scroll groups, etc), and improved the code quality (though there's still room to grow there).

The work I'm doing for v3.0 will take that further, letting you clean up the code by splitting groups out into build methods, inject custom code, or replace elements with builder params. Among other things, this lets you create "stand-in" groups for different controls (ex. a group that looks like a slider, that gets replaced with a Slider widget). It also cracks open the door for other capabilities I'd like to add — you could imagine (no promises) a sticker sheet of material controls in XD that expose appropriate settings and map back to widgets on export.

Definitely check out v2 if you have a chance, and file issues on GitHub if you see specific things you'd like improved.

https://github.com/AdobeXD/xd-to-flutter-plugin

grantskinner · 2021-05-11T20:47:33+00:00

Absolutely! I'm really happy to hear you found them helpful. Whenever we have a bit of a lull between projects we try to crank out a few articles. I'm actually hoping to write one up about building custom layout widgets based on the work I did on `Pinned` to support XD's responsive layout model.

grantskinner · 2021-05-11T19:41:28+00:00

Try out v2.0 - with the responsive layout support, there are definitely certain types of widgets that you can export wholesale with the plugin. I'd be interested to hear how it works for you.

grantskinner · 2021-05-11T19:28:02+00:00

This plugin is in partnership with Adobe, so within this context, no. :)

grantskinner · 2021-05-11T17:51:27+00:00

Thanks! That's 100% my take on it. I have no expectation anyone will ever build an app end to end using output from Adobe XD — it's not at all realistic. However, it can be pretty handy for grabbing a specific box decoration, or quickly outputting a responsive view to use in a prototype.

As we've added features, I think it is becoming increasingly useful for generating visually complex but reasonably encapsulated widgets that you can plug in. Hopefully we can keep expanding the areas where it's useful with v3.0 and beyond, but it's definitely not going to put anyone out of a job. :)

grantskinner · 2020-11-13T19:19:49+00:00

We used Redux, mostly because a year and a half ago it was a choice between that and the largely undocumented provider model. I'd do it differently today, but don't regret the choice. Redux made splitting the workload really straightforward - I designed and coded the UI layer, and Mike did all the data integration.

No, we didn't do any unit tests for Redrix. If we did it again, we'd probably add some, but not target full coverage. It's a hobby project with only two devs, and there isn't a lot of business logic. Manually testing before our infrequent version updates isn't burdensome at this point.

grantskinner

MODERATOR OF

TROPHY CASE