atanu-sabyasachi/snackify

This repository is a Flutter package, not a standalone app. Its architecture is centered around a single public API for showing highly customizable SnackBars, with the rest of the library providing configuration, rendering, lifecycle, and optional text-to-speech behavior.

1. Public entrypoint

- lib/snackify.dart is the main facade the consumer imports.

- The README shows the core usage pattern: Snackify.show(...).

- This file likely re-exports the package types and presents the stable surface area.

2. Snack display pipeline

- The main flow starts when client code calls Snackify.show(context, ...).

- The call is translated into a visual snack overlay, with parameters such as type, title/subtitle, duration, position, animation timing, shadows, and persistence.

- The package is responsible for mounting and removing the snack independently of a standard ScaffoldMessenger-only approach.

3. Overlay-based presentation layer

- lib/overlay_entry.dart suggests the snackbar is injected via Flutter overlays.

- This is the boundary that attaches the snack UI to the current screen and controls visibility/dismissal.

- This design allows top/bottom positioning, persistent display, and animated entrance/exit without requiring a dedicated page or route.

4. Snack UI rendering

- lib/snackify_snackbar.dart likely contains the actual widget tree for the snackbar card/banner.

- This is where the title, subtitle, action widget, close affordance, background gradient, border radius, shadows, and layout rules are assembled.

- It is the main visual component that consumers experience.

5. Type-driven styling system

- lib/enums/snack_enums.dart defines core enum concepts such as SnackType and SnackPosition.

- lib/snack_type_details.dart and lib/snacktype_configuration.dart model the defaults and overrides for each snack type.

- The architecture uses type as a styling and behavior selector, so success, error, warning, info, and custom each map to a distinct visual configuration.

6. Configuration as data, not code

- SnackTypeConfiguration lets callers override colors, icon, text style, margins, elevation, and border radius.

- TTSConfiguration packages speech-related settings such as speakOnShow, language, speech rate, and pitch.

- This keeps the rendering logic mostly declarative: the UI is built from configuration objects rather than ad hoc branching in application code.

7. Initialization and defaults

- lib/initializers.dart likely contains helper logic for normalizing parameters, applying defaults, and building the final snack configuration.

- This is an important boundary between the API layer and the rendering layer: user inputs are resolved here before the overlay widget is created.

- It is also where defaults for duration, animation, and fallback visuals probably converge.

8. Text-to-speech side effect path

- TTS is an optional side effect triggered when a snack is shown.

- The flow is separate from the visual snack rendering: the snack appears, and the message may be spoken based on TTSConfiguration.

- This makes TTS an auxiliary subsystem attached to the show lifecycle rather than part of the UI tree itself.

9. Consumer-facing example and verification

- example/main.dart is a usage sample that demonstrates the package in a real Flutter app context.

- test/snackify_test.dart provides a minimal verification boundary for the public API and expected behavior.

- These two pieces show the intended integration contract without adding runtime complexity to the package itself.

10. Assets and documentation

- assets/images and assets/snack_images are documentation/demo assets used in the README.

- They support the package’s visual identity and examples, but they are not part of the runtime control flow.

- The README acts as the primary integration documentation for consumers.

11. Overall architectural shape

- The package is a small layered system: API facade → config normalization → overlay lifecycle → snackbar widget rendering → optional TTS side effect.

- The boundaries are cleanly separated between “what the caller wants” and “how Flutter displays it.”

- For an architecture diagram, the most important nodes are the Snackify.show() entrypoint, the overlay controller, the snackbar widget, the type/config model, and the TTS path.