Onboarding Screen

[badnikhil]

PR Description

I have added an Onboarding Screen with only one line change to the existing code!

Lottie Animation Sources:
→ lottie1.json
→ lottie2.json
→ lottie3.json
→ lottie3.json

Packages Added:

• 📦 introduction_screen (v3.1.8)
• 📦 flutter_animate (v4.5.0)

Related Issues

• Closes Feature Request: Onboarding Screen for Mobile UI #651

Checklist

• I have gone through the contributing guide
• I have updated my branch and synced it with project main branch before making this PR
• I am using the latest Flutter stable branch (run flutter upgrade and verify)
• I have run the tests (flutter test) and all tests are passing
  • ⚠️ A Test is failing as dicussed in Errors Encountered During Flutter Tests #646 .

Added/updated tests?

• Yes
• No, and this is why: I am currently focusing on making improvements and will add tests later.

OS on which you have developed and tested the feature?

• Android
• iOS

[badnikhil]

Is multiple commits an issue? If needed, I can squash them into one in a fresh repo for a cleaner commit history!
The overall improvements in this PR go beyond what is in the preview video.
I have made some enhancements since then.
You can Effortlessly tweak animations, content, and design to fit any use case.
Onboarding Screen Preview

Screenrecorder-2025-03-14-17-44-30-498.mp4

[animator]

PR #671 is a better approach.

[badnikhil]

PR #671 is a better approach.

@animator, I’d appreciate it if you could share the reasoning behind choosing that approach. I’d love to understand what makes it a better fit so I can improve for the future.

[animator]

@badnikhil I would like you to take it up as a homework and let us know why do you think we decided to go with 671 instead of this PR.

[badnikhil]

@animator

My initial approach was quite similar to the merged one(adding onboarding inside the app), but my goal was to align with community expectations like minimum changes to current code structure and follow the most efficient and maintainable approach. I put in significant effort to make my PR better than the approach used in merged one.

That being said, I want to emphasize that I fully respect your decision and I am not against it. However, I would like to share my perspective on why I believe my approach was more suitable:

• It checks the onboarding status early in the app lifecycle, before any UI is rendered.
• It avoids displaying a loading indicator while waiting for the onboarding status, ensuring a smoother user experience.
• It makes a clean decision at startup rather than conditionally rendering within the widget tree.
• It maintains better separation of concerns—keeping app initialization logic in main() rather than embedding it within UI components.
• The app's initial route is determined before the widget tree is built, making it more efficient.

The alternative approach using FutureBuilder introduces a temporary loading state and adds unnecessary complexity to the widget tree, which can be avoided by handling onboarding status during app initialization.

Additionally, the use of a package - introduction_screen :

• It is specifically designed for onboarding screen.
• It includes features like back navigation, standardized dot indicators with an explicit "done" action.

flutter animate provides animations

What i think is better in other approach is use of carousal slider:
More flexibility to design custom slides with animations, videos, or unique UI elements.
Allows custom indicators and navigation controls.

My sincere apologies if this sounds dumb.
But i'll do my best to make sure my next PR do not disappoints you!