Mobile App

E Commerce Main AndroidApp

Dart

Mobile App

E Commerce Main AndroidApp

Two Flutter e-commerce apps: a Firebase storefront, and a peer-to-peer marketplace with bidding, chat and a JWT REST API.

0 stars 0 forks 0 issues Created Jul 2026

Preview

App screenshot
E Commerce Main AndroidApp — app screenshot

A real screenshot taken from the app, included in the project repository.

What this demonstrates

  • Primary language: Dart (86.7%)
  • Multi-language stack (9 languages)
  • Last updated 4 months ago

Tech stack

Dart 86.7%C++ 5.9%CMake 4.7%HTML 1.3%Swift 0.7%C 0.4%Ruby 0.3%Kotlin 0.1%Objective-C 0%
E-commerceResponsive UIMobile DevelopmentCross-platform UIDartFlutterC++CMakeHTMLSwift

Overview

E Commerce Main AndroidApp is an online storefront with product browsing and a shopping experience, also serving as a cross-platform mobile application. It is built primarily with Dart, C++, CMake. Two Flutter e-commerce apps: a Firebase storefront, and a peer-to-peer marketplace with bidding, chat and a JWT REST API..

Project README

E-Commerce Android App (Flutter)

This repository holds two independent Flutter e-commerce applications. They are not modules of a single app — each has its own pubspec.yaml, its own package name, and its own build. Pick one and run it on its own.

e_commerce_v1e_commerce_v2
Packagee_commercetest_project
What it isClassic storefront — browse, cart, checkout, ordersPeer-to-peer marketplace with bidding, selling, and chat
BackendFirebaseCustom REST API (Dio + JWT)
ArchitectureFeature-first (screens + controllers)Clean Architecture (data / domain / presentation)
State managementGetXGetX
Dart SDK>=3.0.6 <4.0.0^3.11.0
ThemingLight + darkLight only
StatusFeature-complete UIUI complete, backend partially wired
PlatformsAndroid, iOS, WebAndroid, iOS, Web, Linux, macOS, Windows

Prerequisites

  • Flutter SDK (v2 needs Dart 3.11+, so use a recent stable channel)
  • Android Studio or Xcode for device/emulator targets
  • Run flutter doctor and clear any blockers before starting

e_commerce_v1 — Firebase storefront

A full shopping app with a polished UI in both light and dark mode. 118 Dart files, 60 screenshots.

Stack: GetX (state, routing, DI) · GetStorage (local persistence) · Firebase Core · Iconsax · Lottie · carousel_slider · flutter_native_splash

Features: onboarding carousel · email login / signup / password reset · home feed with banners and categories · store, brands, and sub-category browsing · product details with reviews and ratings · cart · checkout with payment method selection · order history · wishlist · profile, settings, and address management

Layout:

lib/
├── common/       # Shared widgets (appbar, product cards, shapes, loaders)
├── data/         # Repositories — currently authentication only
├── features/
│   ├── authentication/    # Onboarding, login, signup, password reset
│   ├── personalization/   # Profile, settings, addresses
│   └── shop/              # Home, store, product, cart, checkout, orders, wishlist
└── utils/        # Theme, constants, validators, formatters, helpers, popups

Setup

cd e_commerce_v1
flutter pub get
flutter run

Firebase config files (android/app/google-services.json, ios/Runner/GoogleService-Info.plist, lib/firebase_options.dart) are committed, so it builds against the existing Firebase project as-is. To point it at your own Firebase project instead, install the FlutterFire CLI and run flutterfire configure from inside e_commerce_v1/, which regenerates all three.

Note: app startup is gated on Firebase initializing. AuthenticationRepository.screenRedirect() reads an isFirstTime flag from GetStorage and sends you to onboarding on first launch, or to login afterwards. If Firebase fails to initialize, the app sits on a loading spinner rather than erroring visibly.

Screenshots

All 60 light/dark screenshots are catalogued in e_commerce_v1/README.md.


e_commerce_v2 — REST marketplace with bidding

A newer rebuild on a different premise: users both buy and sell, and products are bid on rather than simply added to a cart. Structured with Clean Architecture throughout.

Stack: GetX (state, routing, bindings) · Dio (HTTP, with a JWT interceptor) · flutter_dotenv (config) · SharedPreferences (token storage) · animated_bottom_navigation_bar · carousel_slider · otp_text_field · page_transition

Features: animated splash and onboarding · sign in / sign up / forgot password with OTP verification and password reset · home feed and category browsing · product detail with bidding · post an item for sale · items you're selling · items you've bought or bid on · direct chat and inbox · wishlist · notifications · language selection · profile and public profile view

Layout — every feature follows the same three-layer split:

lib/
├── core/
│   ├── binding/     # Global DI
│   ├── constants/   # API endpoints, colors, assets, strings
│   ├── network/     # Dio client + auth interceptor
│   ├── routes/      # Route names and GetPage table
│   └── themes/
└── features/<name>/
    ├── data/          # Models, remote datasources, repository impls
    ├── domain/        # Entities, repository contracts, use cases
    └── presentation/  # Bindings, controllers, views, widgets

Setup

cd e_commerce_v2
flutter pub get

Create a .env file in e_commerce_v2/ before running. It is declared as an asset in pubspec.yaml and loaded in main(), so the app will not start without it. .env is gitignored, so it does not ship with the repo:

API_URL=http://your-api-host:5000

If API_URL is unset, ApiConstant falls back to http://localhost:5000. Then:

flutter run

Expected backend

The app talks to a REST API exposing these routes (see lib/core/constants/api_constant.dart):

MethodEndpointPurpose
POST/auth/registerSign up
POST/auth/loginSign in — returns the JWT
POST/auth/forgot-passwordRequest a reset
POST/auth/reset-passwordComplete a reset
GET/auth/meCurrent user
GET/category/allCategoriesCategory list

On login the token is written to SharedPreferences under auth_token; the Dio interceptor then attaches it as Authorization: Bearer <token> on every subsequent request.

Implementation status

Only auth and home have their data/ and domain/ layers implemented and wired to the API. The other fourteen features — product, category, chat, inbox, wishlist, sell_items, bought_bid_items, add_product, notifications, profile, view_profile, language, onboarding, bottom_nav — have their folder scaffolding and a working presentation layer, but no datasources or use cases yet. They render against placeholder data. That scaffolding is the intended shape for filling them in.


Contributing

Please read CODE_OF_CONDUCT.md before opening a pull request. Keep changes scoped to a single app — the two do not share code.

License

MIT — see LICENSE.