Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aspect to consider about the Expression-UI FrameWork #13

Open
fr98acsta opened this issue Apr 24, 2024 · 2 comments
Open

Aspect to consider about the Expression-UI FrameWork #13

fr98acsta opened this issue Apr 24, 2024 · 2 comments

Comments

@fr98acsta
Copy link

Congratulations on the project, it is very exciting. I have been following you from your channel with the videos as well as the news letter and always waiting for updates

However, I see a drawback and that is that Rive only so far would allow you to implement designs for static pages, like the ones you show in your videos. For applications where changing content must be used and is updated such as a list of cards or comments, I cannot see how to implement it efficiently.

The way I tried to approach it is by modifying the BaseExpressionView class or creating others that extend it so that we use a Listview or some dynamic flutter widget that allows us to maintain a single file but recreate the page design by sections where each section has its own ArtBoard. This could generate pages with more complex designs, such as those that have several sections integrated with Rows.

But here are some considerations:

  • Memory Consumption: Each artboard loaded into memory is an instance with its own resources. If you have multiple artboards active at the same time, it can significantly increase the memory usage of your application.

  • Rendering Performance: Rendering multiple artboards might reduce the frame rate, especially if these artboards contain complex animations or are displayed on lower-end devices. This can make the application feel slower and less responsive.

  • Resource Management: Managing multiple artboards can complicate resource management, as each artboard might need to be loaded, initialized, and disposed of separately.

Please correct me or explain to me what other approach could be applied or what solution you would do. Thank you very much and Regards

@FilledStacks
Copy link
Owner

Hey,

Thank you for the detailed issue, I appreciate the interest in the project.

Your assumptions are incorrect, but that is possibly due to the misconception that you'll build your App using rive, and not ONLY your app UI.

Here's an example of me getting data from the backend and using it a rive artboard.

Rive allows you to replace the text dynamically through code.

You'll see this as the textValues map in the BaseExpressionView.

This is a keyValue pair where you can pass in the key and the value will be replaced in the artboard.

The only thing I don't want to do currently is replace images dynamically in list items. I don't like that idea, so I'm going to recommend using the normal image widgets in whichever framework to load iimages.

We're only replacing UI, or pieces of the UI. So you can replace only your list item only, and pass in data to it. Then the rest of the app is built with normal UI code.

In terms of the concerns there's a few things to note:

  1. Rive manages artboard loading smartly, they only load the artboards required and have done numerous demo's where there are 100+ artboards on screen and it stays at 60fps. This is my experience as well.
  2. The same as point 1, haven't seen it go under 60fps
  3. That might be the case, I haven't seen any issues with it yet. But I've only built 1 production app this way, there might be other scenarios where I have to handle this specifically. So far it's not been required.

Hope that answers your questions.

If it doesn't let's walk through specific scenarios.

You can post the feature you want to build I can instruct how that can be built using expressionUI and we can see if it makes sense.

This is still all in development.

@fr98acsta
Copy link
Author

Man thanks for the reply, all very insightful .
Looking forward to seeing more content and how you execute your workflow.
Greetings.

@fr98acsta fr98acsta reopened this Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants