DEV Community: Codexlancers

From Design to Flutter Code: Using Google Stitch MCP with Antigravity AI

Codexlancers — Tue, 21 Jul 2026 04:30:00 +0000

Design-to-code workflows are becoming increasingly efficient with the introduction of the Model Context Protocol (MCP). By connecting Google Stitch with Antigravity AI, developers can allow AI agents to access design context directly and generate Flutter implementations with significantly less manual effort.

In this article, we'll walk through the complete setup process and demonstrate how to generate Flutter UI code directly from Google Stitch designs using MCP.

What is MCP?

The Model Context Protocol (MCP) is an open standard that enables AI applications to securely connect with external tools and data sources.

Benefits include:

Direct access to design context
Reduced manual design interpretation
Faster UI implementation
Improved code consistency
Better collaboration between designers and developers

Why Use Google Stitch with Antigravity AI?

Google Stitch provides AI-powered design generation, while Antigravity AI can consume that design context through MCP and generate implementation code.

Key Benefits

✅ Faster design-to-development workflow
✅ Reduced UI implementation time
✅ Better design accuracy
✅ Reusable Flutter components
✅ Production-ready code generation

Architecture Overview

Google Stitch
│
▼
MCP Server
│
▼
Antigravity AI
│
▼
Flutter Code

Step 1: Generate UI Design in Google Stitch

Open Google Stitch.
Generate your mobile application design.
Select all screens you want to export.

Best Practices:

Finalize navigation flow before exporting
Use consistent design patterns
Keep component naming organized

Step 2: Export MCP Configuration

Click Export
Select MCP
Click Set Up MCP
Choose your preferred IDE

After selecting Antigravity, Google Stitch provides:

MCP Configuration
API Key
Connection Details

Copy the generated configuration.

Step 3: Configure MCP in Antigravity AI

Navigate to:

Agent Panel
└── Three Dot Menu
└── MCP Servers
└── Manage MCP Servers
└── View Raw Config

Paste the Stitch MCP configuration:

{
  "mcpServers": {
    "stitch": {
      "serverUrl": "https://stitch.googleapis.com/mcp",
      "headers": {
        "X-Goog-Api-Key": "YOUR-API-KEY"
      }
    }
  }
}

Replace: YOUR-API-KEY with the API key provided by Google Stitch.

Step 4: Verify the Connection

After saving the configuration:

Restart Antigravity if needed.
Open MCP Servers.
Verify that Stitch appears in the configured server list.
Confirm the connection status is active.

Common Fixes

1. Server Not Visible

Restart the Antigravity service.
Verify that the server is running successfully.
Check logs for startup errors.

2. Authentication Error

Ensure your API key is correct.
Confirm that the key has not expired.
Verify environment variables are properly configured.

3. Connection Failure

Check your internet connection.
Verify firewall or proxy settings.
Ensure the target endpoint is reachable.

4. Invalid Configuration

Validate your JSON configuration file.
Check for missing commas, brackets, or quotation marks.
Use a JSON validator before restarting the service.

Tip: Most startup issues can be resolved by validating the configuration file and restarting the Antigravity server.

Step 5: Generate Flutter UI Code

Once the MCP connection is established, Antigravity AI can access the Stitch design context.
Example prompt:

Implement the selected Google Stitch mobile app screens in Flutter.

Requirements:
- Use GetX for state management
- Follow Material Design guidelines
- Create reusable widgets
- Maintain responsive layouts
- Use proper folder structure
- Generate clean production-ready code
- Match the Stitch design closely

The AI agent will analyze the design through MCP and generate Flutter code accordingly.

Example Development Workflow

Design Creation
      │
      ▼
Google Stitch
      │
      ▼
Export MCP
      │
      ▼
Antigravity AI
      │
      ▼
Flutter Code Generation
      │
      ▼
Developer Review
      │
      ▼
Production App

Lessons Learned

During testing, the following practices produced the best results:

Export complete screen flows instead of individual screens.
Provide detailed implementation requirements.
Request reusable widgets and proper architecture.
Review generated code before production deployment.
Use GetX modules for scalable project organization.

Conclusion

By integrating Google Stitch with Antigravity AI through MCP, Flutter developers can significantly accelerate the design-to-code process. Instead of manually translating designs into code, developers can focus on refining business logic and user experience while AI handles much of the UI implementation work.

If you're already using Flutter and GetX, this workflow can dramatically reduce UI development time while maintaining consistency with your original designs.

Advanced PDF Toolkit for Flutter

Codexlancers — Thu, 16 Jul 2026 10:00:00 +0000

A premium, high-performance, native PDF viewer plugin for Flutter. It renders PDFs smoothly via Flutter PlatformViews directly on top of platform-native PDF frameworks:

Android - PdfRenderer for high-performance page rendering, combined with pdfbox-android for text search and bookmark/outline extraction.
iOS - PDFKit for full native rendering, text search, and outline support.

The plugin exposes a powerful Dart-side controller and an optional, fully-customizable built-in toolbar for common viewer interactions.

Features

Open PDFs from assets, network URLs, local file paths, raw bytes (Uint8List), or base64-encoded strings
Built-in toolbar with page navigation, zoom controls, search, bookmarks, page thumbnails, and a theme toggle - each shown/hidden independently
Programmatic control via FlutterPdfToolkitController: jump to page, next / previous page, zoom in / out / reset, search, bookmarks, dark mode, page thumbnails
Horizontal or vertical scrolling, single-page or continuous page modes
Pinch-to-zoom and double-tap-to-zoom on both Android and iOS
Initial page and initial zoom level configuration
Password-protected PDF support, with an automatic unlock dialog
Dark mode toggle at the Flutter UI level
Text search with result highlighting and bookmark/outline support on both Android and iOS
Page thumbnails rendered natively from the PDF and shown in a grid for quick navigation
Built-in "Sign document" toolbar action: draw a signature, position and resize it on the current page, and stamp it onto the PDF natively via FlutterPdfToolkit.signPdf()
Built-in "Reorder pages" toolbar action: drag page thumbnails into a new order and save the rearranged PDF natively via FlutterPdfToolkit.reorderPages()
Built-in "Delete pages" toolbar action: tap page thumbnails to mark them for removal and save the trimmed PDF natively via FlutterPdfToolkit.removePages()
Built-in "Add pages" toolbar action: pick where to insert new pages from a page-thumbnail grid, then insert PDF and/or image files supplied by the host app natively via FlutterPdfToolkit.insertPages() and FlutterPdfToolkit.imagesToPdf()
Built-in "Add image" toolbar action: pick an image supplied by the host app, position and resize it on the current page, and stamp it onto the PDF natively via FlutterPdfToolkit.addImageToPdf()
Merge multiple PDF files into a single document natively via FlutterPdfToolkit.mergePdfs()
Split a PDF into multiple documents by page range natively via FlutterPdfToolkit.splitPdf(), with FlutterPdfToolkit.getPdfPageCount() to read a PDF's page count
Save or share a PDF file via FlutterPdfToolkit.downloadPdf() - saves to the Downloads folder on Android, or opens the share sheet on iOS

Platform Support

Android (API 21 / Android 5.0)
Rendering: PdfRenderer + pdfbox-android
Features: Search and bookmarks via pdfbox-android

iOS (iOS 13.0)
Rendering: PDFKit
Features: Full search and bookmark/outline support

⚠️ Unsupported Platforms
Web, desktop, and macOS are not implemented. FlutterPdfToolkit renders via AndroidView/UiKitView, so usage outside Android/iOS will fail at runtime.

Requirements

Flutter >=1.17.0 and Dart SDK ^3.11.5 (as declared in pubspec.yaml).
Android: minSdkVersion 21 or higher (raise it in android/app/build.gradle if your app currently targets lower).
iOS: deployment target 13.0 or higher (set platform :ios, '13.0' in your ios/Podfile).

Installation

Add the dependency to your pubspec.yaml:

dependencies:
  flutter_pdf_toolkit: ^0.0.1

Then run:

flutter pub get

No additional native setup is required - the plugin registers its platform views automatically on Android and iOS.

If you load PDFs from the network, make sure your app has internet access permission (already enabled by default for Android, and allowed by default on iOS unless you've restricted App Transport Security).

Quick Start

import 'package:flutter/material.dart';
import 'package:flutter_pdf_toolkit/flutter_pdf_toolkit.dart';

class PdfScreen extends StatelessWidget {
  const PdfScreen({super.key});
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('PDF Viewer')),
      body: const FlutterPdfToolkit(
        source: PdfSource.network(
          'https://cdn.syncfusion.com/content/PDFViewer/flutter-succinctly.pdf',
        ),
      ),
    );
  }
}

With a Controller

A FlutterPdfToolkitController lets you drive the viewer programmatically and read its current state (page number, zoom level, bookmarks, search results, etc.).

class PdfScreen extends StatefulWidget {
  const PdfScreen({super.key});

  @override
  State<PdfScreen> createState() => _PdfScreenState();
}
class _PdfScreenState extends State<PdfScreen> {
  final FlutterPdfToolkitController _controller = FlutterPdfToolkitController();
  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('PDF Viewer'),
        actions: [
          IconButton(
            icon: const Icon(Icons.skip_next),
            onPressed: _controller.nextPage,
          ),
        ],
      ),
      body: FlutterPdfToolkit(
        source: const PdfSource.asset('assets/sample.pdf'),
        controller: _controller,
      ),
    );
  }
}

PDF Sources

PdfSource is a sealed class with a factory constructor for each supported input type:

// From an asset bundled with your app
const PdfSource.asset('assets/sample.pdf');
const PdfSource.asset('assets/sample.pdf', bundle: myAssetBundle);

// From a network URL, optionally with custom headers (e.g. auth tokens)
const PdfSource.network('https://example.com/sample.pdf');
const PdfSource.network(
  'https://example.com/sample.pdf',
  headers: {'Authorization': 'Bearer <token>'},
);

// From an absolute local file path
const PdfSource.filePath('/storage/emulated/0/Download/sample.pdf');

// From raw bytes (e.g. downloaded or generated in-memory)
PdfSource.bytes(bytes); // Uint8List

// From a base64-encoded string (data URLs such as "data:application/pdf;base64,..." are also accepted)
PdfSource.base64(base64PdfString);
PdfSource.base64(base64PdfString, password: 'secret');

Internally, asset, network, bytes, and base64 sources are written to a temporary file before being handed to the native viewer; file path sources are passed through as-is.

FlutterPdfToolkit widget reference

Core properties

source (PdfSource) - Required. The PDF to display.
controller (FlutterPdfToolkitController?) - Controller to drive the viewer. If omitted, internal controller is created.

Toolbar controls

showToolbar (bool) = true - Show/hide the built-in toolbar.
showSearch (bool) = true - Show search icon.
showBookmarks (bool) = true - Show bookmarks icon.
showThumbnails (bool) = true - Show page thumbnails.
showZoomControls (bool) = true - Show zoom controls.
showPageControls (bool) = true - Show prev/next buttons.
showThemeToggle (bool) = true - Show light/dark toggle.

Document editing

showSignature (bool) = true - Show "Sign document" icon.
onSigned (void Function(String)?) - Called with signed file path.
showReorder (bool) = true - Show "Reorder pages" icon.
onPagesReordered (void Function(String)?) - Called with reordered file path.
showDeletePages (bool) = true - Show "Delete pages" icon.
onPagesRemoved (void Function(String)?) - Called with trimmed file path.
showAddPages (bool) = true - Show "Add pages" icon.
onAddPagesRequested (Future?> Function()?) - Return file paths to insert.
showAddImage (bool) = true - Show "Add image" icon.
onAddImageRequested (Future Function()?) - Return JPEG/PNG bytes.

Styling

darkMode (bool) = false - Initial dark mode state.
toolbarBackgroundColor (Color?) - Toolbar background.
toolbarForegroundColor (Color?) - Icon/text color.
backgroundColor (Color?) - Background during load/error.

Configuration

initialZoomLevel (double) = 1.0 - Zoom level on load.
initialPage (int) = 1 - Starting page (1-indexed).
password (String?) - Password for encrypted PDFs.
scrollDirection (Axis) = Axis.vertical - Vertical or horizontal scrolling.
singlePage (bool) = false - One page at a time vs continuous.

Note: If the toolbar is hidden (showToolbar: false), drive the viewer using a FlutterPdfToolkitController.

Controller reference (FlutterPdfToolkitController)

FlutterPdfToolkitController extends ChangeNotifier, so you can listen to it directly or wrap the viewer in an AnimatedBuilder / ListenableBuilder to rebuild your own UI in response to state changes.

FlutterPdfToolkitController reference

State (read-only)

Observable properties of the current document and viewer state.

pageNumber (int) - Current page (1-indexed).
pageCount (int) - Total number of pages in the document.
zoomLevel (double) - Current zoom level.
isReady (bool) - Whether the native view has finished initializing.
errorMessage (String?) - Non-null if document failed to load.
bookmarks (List) - Outline/bookmarks from platform.
searchText (String?) - The active search query, if any.
searchResultCount (int) - Number of matches for active search.
currentSearchResultIndex (int) - Index (1-based) of highlighted match.

Actions

Methods to control the viewer and document interaction.

Navigation

jumpToPage(int pageNumber) - Jump to page (1-indexed).
nextPage() - Go to next page.
previousPage() - Go to previous page.

Zoom

zoomIn([double step = 0.25]) - Increase zoom by step.
zoomOut([double step = 0.25]) - Decrease zoom by step.
resetZoom() - Reset to default zoom.

Search

search(String text, {bool caseSensitive = false}) - Search the document.
clearSearch() - Clear active search and highlights.
nextSearchResult() - Jump to next match.
previousSearchResult() - Jump to previous match.

Other

requestBookmarks() - Re-request bookmark/outline list.
setDarkMode(bool enabled) - Toggle dark mode.
getPageThumbnail(int pageNumber, {int width = 200}) - Returns PNG thumbnail as Uint8List.

PdfBookmarkItem

class PdfBookmarkItem {
  final String title;
  final int pageNumber;
}

Password-Protected PDFs

There are two ways to supply a password:

Pass password directly to FlutterPdfToolkit:

FlutterPdfToolkit(
  source: const PdfSource.filePath('/path/to/protected.pdf'),
  password: 'samplefiles',
)

Attach a password to a PdfSource.base64 source:

FlutterPdfToolkit(
  source: PdfSource.base64(base64PdfString, password: 'samplefiles'),
)

If no password is supplied (or the supplied password is incorrect), the widget shows a built-in "Password Required" dialog and prompts the user to enter the password. The dialog re-displays with an "Incorrect password" error if the entered password is rejected, and can be cancelled to abort loading the document.

Search

Text search is supported on both Android and iOS.

On iOS, search uses PDFKit's native text search.
On Android, the page text is extracted with pdfbox-android (cached after first use) and matched case-insensitively.

Matches are highlighted on the page and the view automatically scrolls to the first/selected match.
Use controller.search('query'), nextSearchResult(), previousSearchResult(), and clearSearch() to drive search programmatically. The toolbar reflects the active query and match count when present.

Bookmarks

Bookmarks (PDF outline entries) are populated automatically on view creation via requestBookmarks() and exposed through controller.bookmarks.
Tapping the bookmarks icon in the toolbar opens a bottom sheet listing all bookmarks; tapping an entry jumps to that page.
Supported on both Android and iOS - Android extracts the document outline with pdfbox-android, while iOS reads it via PDFKit's outlineRoot. If a PDF has no outline/bookmarks defined, bookmarks will be empty on either platform.

Page Thumbnails

Tapping the thumbnails icon in the toolbar opens a grid of page previews; tapping a thumbnail jumps to that page.
Each thumbnail is rendered natively (via PDFKit on iOS and PdfRenderer on Android) and fetched lazily as the grid is shown, then cached for the lifetime of the document.
Use controller.getPageThumbnail(pageNumber, width: 200) to fetch a thumbnail yourself, e.g. to build a custom page picker.

Signing PDFs

Tapping the "Sign document" icon (the pen/draw icon) in the toolbar opens a built-in flow:

A dialog where the user draws their signature with a finger/stylus (powered by SignaturePad).
A bottom sheet showing a preview of the current page, where the user can drag and resize the signature before confirming placement.
The signature is stamped onto the current page natively and the viewer reloads the signed copy. onSigned is called with the path to the new file.

Hide the built-in action with showSignature: false if you want to build your own signing UI.

SignaturePad and SignaturePadController are exported so you can build a custom signature-capture UI:

final SignaturePadController controller = SignaturePadController();
final GlobalKey<SignaturePadState> padKey = GlobalKey<SignaturePadState>();

SignaturePad(key: padKey, controller: controller);

// Later, e.g. when the user taps "Done":
final Uint8List? pngBytes = await padKey.currentState?.toPngBytes();

toPngBytes() renders the drawn strokes to a transparent PNG. Call controller.clear() to reset the pad and controller.isEmpty to check whether anything has been drawn.

Stamp a signature (or any PNG image) onto a PDF page yourself with FlutterPdfToolkit.signPdf():

final String? signedPath = await FlutterPdfToolkit.signPdf(
  sourcePath: '/path/to/document.pdf',
  outputPath: '/path/to/output/signed.pdf',
  signatureImageBytes: pngBytes,
  pageNumber: 1, // 1-indexed
  xRatio: 0.6,   // left edge, as a fraction of the page width
  yRatio: 0.8,   // top edge, as a fraction of the page height
  widthRatio: 0.3,  // signature width, as a fraction of the page width
  heightRatio: 0.1, // signature height, as a fraction of the page height
);

Signing parameters

Parameters for the PDF signing operation. The signature image is stamped onto the specified page at the given position and size.

Parameters

sourcePath (String) - Absolute file path of the PDF to sign.
outputPath (String) - Absolute file path where the signed PDF should be written.
signatureImageBytes (Uint8List) - PNG image to stamp onto the page, ideally with transparent background.
pageNumber (int) - 1-indexed page number to stamp the signature onto.
xRatio / yRatio (double) - Top-left position of signature as fraction (0.0–1.0) of page width/height.
widthRatio / heightRatio (double) - Size of signature as fraction (0.0–1.0) of page width/height.

Returns outputPath on success, or null if signing failed. Runs natively - pdfbox-android on Android (appended to the page's content stream) and CoreGraphics on iOS (the page is redrawn into a new PDF context with the signature composited on top) - so sourcePath must be a local file path and existing vector content is preserved.

Reordering Pages

Tapping the "Reorder pages" icon (the swap icon) in the toolbar opens a built-in flow:

A bottom sheet shows every page as a thumbnail in a grid.
The user presses and holds a page, then drags it to a new position. Each tile shows a badge with its current position in the new order.
Tapping "Save order" rewrites the document with the pages in their new order natively, and the viewer reloads the rearranged copy. onPagesReordered is called with the path to the new file.

Hide the built-in action with showReorder: false if you want to build your own reordering UI.

Reorder (and optionally drop) pages yourself with FlutterPdfToolkit.reorderPages():

final String? reorderedPath = await FlutterPdfToolkit.reorderPages(
  path: '/path/to/document.pdf',
  outputPath: '/path/to/output/reordered.pdf',
  pageOrder: [3, 1, 2], // moves page 3 to the front, drops the rest
);

Reordering parameters

Parameters for the PDF page reordering operation. Reorder pages, drop unwanted pages, or duplicate pages in the output.

Parameters

path (String) - Absolute file path of the PDF to reorder.
outputPath (String) - Absolute file path where the reordered PDF should be written.
pageOrder (List) - 1-based page numbers from source PDF, in desired output order. Omit a page number to drop that page.

Returns outputPath on success, or null if reordering failed. Runs natively - pdfbox-android on Android and PDFKit on iOS - so path must be a local file path. Use getPdfPageCount() to determine valid page numbers beforehand.

Examples

Keep pages 1, 3, 5 in order:

pageOrder: [1, 3, 5]

Reverse page order:

pageOrder: [5, 4, 3, 2, 1]

Drop page 2, keep others:

pageOrder: [1, 3, 4, 5]

Removing Pages

Tapping the "Delete pages" icon (the trash icon) in the toolbar opens a built-in flow:

A bottom sheet shows every page as a thumbnail in a grid.
The user taps pages to mark them for removal. Selected pages are highlighted with a checkmark.
Tapping "Delete N pages" rewrites the document without the selected pages natively, and the viewer reloads the trimmed copy. onPagesRemoved is called with the path to the new file.

Hide the built-in action with showDeletePages: false if you want to build your own page-removal UI.

Remove pages yourself with FlutterPdfToolkit.removePages():

final String? trimmedPath = await FlutterPdfToolkit.removePages(
  path: '/path/to/document.pdf',
  outputPath: '/path/to/output/trimmed.pdf',
  pageNumbers: [2, 4], // removes pages 2 and 4
);

Removing pages parameters

Parameters for the PDF page deletion operation. Remove unwanted pages from the document.

Parameters

path (String) - Absolute file path of the PDF to trim.
outputPath (String) - Absolute file path where the trimmed PDF should be written.
pageNumbers (List) - 1-based page numbers from source PDF to remove.

Examples

Delete pages 2 and 5:

pageNumbers: [2, 5]

Delete first page:

pageNumbers: [1]

Delete last 3 pages (10–12 of 12-page doc):

pageNumbers: [10, 11, 12]

Returns outputPath on success, or null if removal failed (including if pageNumbers covers every page in the document). Runs natively - pdfbox-android on Android and PDFKit on iOS - so path must be a local file path. Use getPdfPageCount() to determine valid page numbers beforehand.

Adding Pages

Tapping the "Add pages" icon (the document-plus icon) in the toolbar opens a built-in flow:

A bottom sheet shows every page as a thumbnail in a grid, plus a "Start" tile. Tap a page to insert the new pages after it (or tap "Start" to insert them before page 1).
onAddPagesRequested is called - your app should show its own file and/or image picker here and return the chosen local file paths, in the order they should be inserted. Return null or an empty list to cancel.
Any image files (.jpg, .jpeg, .png, .heic, .heif, .webp, .bmp, .gif) are converted to single-page PDFs and combined with any PDF files, preserving the given order. The combined pages are inserted at the chosen position natively, and the viewer reloads the updated copy. onPagesAdded is called with the path to the new file.

showAddPages defaults to true, but the action requires onAddPagesRequested to be provided - without it, tapping the icon shows a message that adding pages isn't configured. Set showAddPages: false if you want to build your own add-pages UI instead.

Insert another PDF's pages yourself with FlutterPdfToolkit.insertPages():

final String? updatedPath = await FlutterPdfToolkit.insertPages(
  path: '/path/to/document.pdf',
  insertPath: '/path/to/pages_to_insert.pdf',
  outputPath: '/path/to/output/updated.pdf',
  afterPageNumber: 2, // insert after page 2 (0 = before page 1)
);

Insert pages parameters

Parameters for the PDF page insertion operation. Insert pages from one PDF into another at a specific position.

Parameters

path (String) - Absolute file path of the PDF to insert pages into.
insertPath (String) - Absolute file path of the PDF whose pages should be inserted.
outputPath (String) - Absolute file path where the updated PDF should be written.
afterPageNumber (int) - 1-based page number to insert after. 0 inserts before page 1. Document's page count appends at end.

Examples

Insert at beginning (before page 1):

afterPageNumber: 0

Insert after page 3:

afterPageNumber: 3

Append at end (5-page document):

afterPageNumber: 5

Returns outputPath on success, or null if insertion failed. Runs natively - pdfbox-android on Android and PDFKit on iOS - so both path and insertPath must be local file paths.

Convert images into a PDF (one page per image) with FlutterPdfToolkit.imagesToPdf():

final String? pagesPath = await FlutterPdfToolkit.imagesToPdf(
  imagePaths: ['/path/to/photo1.jpg', '/path/to/photo2.png'],
  outputPath: '/path/to/output/photos.pdf',
);

Parameters

imagePaths (List) - Absolute file paths of the images to convert, in page order.
outputPath (String) - Absolute file path where the resulting PDF should be written.

Returns outputPath on success, or null if conversion failed. Each page is sized to match its source image. Runs natively - pdfbox-android on Android and CoreGraphics on iOS.

Adding images to a PDF

Tapping the "Add image" icon (the image-plus icon) in the toolbar opens a built-in flow:

onAddImageRequested is called - your app should show its own image picker (e.g. via the image_picker package) and return the chosen image's bytes (JPEG or PNG). Return null to cancel.
A bottom sheet shows a preview of the current page, where the user can drag and resize the image before confirming placement.
The image is stamped onto the current page natively and the viewer reloads the updated copy. onImageAdded is called with the path to the new file.

showAddImage defaults to true, but the action requires onAddImageRequested to be provided - without it, tapping the icon shows a message that adding images isn't configured. Set showAddImage: false if you want to build your own add-image UI instead.

Stamp an image onto a PDF page yourself with FlutterPdfToolkit.addImageToPdf():

final String? updatedPath = await FlutterPdfToolkit.addImageToPdf(
  sourcePath: '/path/to/document.pdf',
  outputPath: '/path/to/output/with_image.pdf',
  imageBytes: imageBytes, // JPEG or PNG bytes
  pageNumber: 1, // 1-indexed
  xRatio: 0.1,   // left edge, as a fraction of the page width
  yRatio: 0.1,   // top edge, as a fraction of the page height
  widthRatio: 0.3,  // image width, as a fraction of the page width
  heightRatio: 0.3, // image height, as a fraction of the page height
);

File paths

sourcePath (String) - Absolute file path of the PDF to modify.
outputPath (String) - Absolute file path where the updated PDF should be written.

Image content

imageBytes (Uint8List) - JPEG or PNG image to stamp onto the page.

Page targeting

pageNumber (int) - 1-indexed page number to stamp the image onto.

Position and size

xRatio / yRatio (double) - Top-left position of the image as a fraction (0.0–1.0) of page width/height.
widthRatio / heightRatio (double) - Size of the image as a fraction (0.0–1.0) of page width/height.

Returns outputPath on success, or null if adding the image failed. Runs natively - pdfbox-android on Android (appended to the page's content stream) and CoreGraphics on iOS (the page is redrawn into a new PDF context with the image composited on top) - so sourcePath must be a local file path and existing vector content is preserved.

Merging, Splitting, and Downloading PDFs

FlutterPdfToolkit exposes several static helper methods that don't require a viewer instance - they call straight into the native platform code via a shared method channel.

Merging PDFs

final String? mergedPath = await FlutterPdfToolkit.mergePdfs(
  paths: ['/path/to/first.pdf', '/path/to/second.pdf'],
  outputPath: '/path/to/output/merged.pdf',
);
if (mergedPath != null) {
  // Open it in the viewer, e.g.:
  // FlutterPdfToolkit(source: PdfSource.filePath(mergedPath));
}

paths (List) - Absolute file paths of the PDFs to merge, in the order they should appear in the output.
outputPath (String) - Absolute file path where the merged PDF should be written.

Returns the outputPath on success, or null if merging failed (e.g. an invalid or unreadable input path). The merge is performed natively - PDFKit on iOS and pdfbox-android on Android - so all input paths must be local file paths. If a source is an asset, network URL, or in-memory bytes, write it to a temporary file first (see PDF sources).

Getting a PDF's page count

final int? pageCount = await FlutterPdfToolkit.getPdfPageCount('/path/to/document.pdf');

Returns the total number of pages, or null if the file could not be read. Useful for working out valid page ranges before calling splitPdf().

Splitting a PDF

final List<String>? files = await FlutterPdfToolkit.splitPdf(
  path: '/path/to/document.pdf',
  outputDirectory: '/path/to/output',
  pageRanges: [
    [1, 3], // pages 1-3 -> split_1.pdf
    [4, 4], // page 4    -> split_2.pdf
    [5, 10], // pages 5-10 -> split_3.pdf
  ],
);
if (files != null) {
  for (final path in files) {
    // e.g. open one of the resulting files in the viewer:
    // FlutterPdfToolkit(source: PdfSource.filePath(path));
  }
}

path (String) - Absolute file path of the PDF to split.
outputDirectory (String) - Absolute path of the directory where split files are written. Directory is created automatically if it doesn't exist.
pageRanges (List>) - One [startPage, endPage] pair per output file, 1-based and inclusive (e.g., [1, 3] = pages 1–3).
outputFileNamePrefix(String) -Optional prefix for output file names. Defaults to 'split'. Files are named <prefix>_<n>.pdf.

Returns the list of output file paths, in the same order as pageRanges, or null if splitting failed (e.g. an invalid path or an out-of-range page number). Like mergePdfs(), this runs natively via PDFKit on iOS and pdfbox-android on Android, and path must be a local file path.

Downloading / sharing a PDF

final bool success = await FlutterPdfToolkit.downloadPdf(
  sourcePath: '/path/to/merged.pdf',
  fileName: 'merged_document.pdf',
);

sourcePath (String) - Absolute path of the PDF file to save or share.
fileName (String) - Suggested file name for the saved or shared copy.

On Android, the file is copied into the device's public Downloads folder under fileName.

On iOS, the system share sheet is opened so the user can save the file to Files, AirDrop it, etc.

Returns true if the save/share action completed successfully, false otherwise.

Zoom

Pinch-to-zoom is supported on both platforms via the built-in scroll/zoom view.
Double-tapping the page toggles between the default zoom level and 2x zoom, centered on the tap location, on both Android and iOS.
controller.zoomIn(), zoomOut(), and resetZoom() drive zoom programmatically; the toolbar's zoom buttons call these directly.

Dark Mode

darkMode sets the initial state of the native viewer's color scheme.
The built-in toolbar includes a sun/moon toggle (showThemeToggle) that calls controller.setDarkMode(...) and rebuilds the toolbar's icon.
controller.setDarkMode(bool enabled) can be called at any time - including before the native view is ready, in which case it is applied once the view finishes initializing.
Dark mode only affects the PDF viewer's chrome/background at the native level; it does not alter the content of the PDF itself.

Limitations

Only Android and iOS are currently supported - there is no web, desktop, or macOS implementation.
Search is case-insensitive on both platforms; advanced query syntax (regex, whole-word, etc.) is not supported.

Conclusion

Building PDF functionality in Flutter shouldn't require multiple plugins, complex native integrations, or performance trade-offs. With flutter_pdf_toolkit, you get a powerful all-in-one solution for viewing, searching, editing, signing, and managing PDFs using native rendering on Android and iOS. If your app works with documents, this package can help you deliver a faster, smoother, and more professional user experience with minimal effort. 🚀

🚀 How to Create EXE Installer for a Flutter Windows App Using Inno Setup

Codexlancers — Tue, 14 Jul 2026 04:30:00 +0000

Flutter makes it easy to build Windows desktop applications, but distributing your application can become messy if you share the entire release folder containing multiple files and directories.

Instead of sending users a folder like this:

MyApp.exe
flutter_windows.dll
data/
other dependency files...

You can package everything into a single installer:

CodexInstaller.exe

In this guide, you'll learn how to create a professional Windows installer for your Flutter desktop application using Inno Setup.

Prerequisites

Before getting started, make sure you have:

Flutter installed and configured for Windows development
A Flutter Windows application
Inno Setup installed
A Windows release build generated using:

flutter build windows --release

Your release files will be generated in:

build/windows/x64/runner/Release

Why Use Inno Setup?

Inno Setup allows you to:

✅ Package your Flutter application into a single installer
✅ Create desktop and Start Menu shortcuts
✅ Install application files automatically
✅ Add custom icons
✅ Configure installation paths
✅ Provide a professional installation experience

Step 1: Launch Inno Setup

Open Inno Setup after installation.

Select:

Create a new script file using the Script Wizard

Then click OK.

Step 2: Enter Application Information

Fill in your application's basic information:

Application Name
Application Version
Publisher Name
Publisher Website (Optional)

Example:

Click Next.

Step 3: Configure the Installation Folder

Choose where the application should be installed.

Recommended settings:

Application destination base folder:
Program Files Folder

Enter your application name as the folder name.
You may optionally allow users to change the installation location.
Click Next.

Step 4: Add Flutter Release Files

This is the most important step.

Navigate to:

build/windows/x64/runner/Release

You need to include the required Flutter release files.

Select the Main Executable

Click Browse and choose:

CodexApp.exe

This becomes the application's primary executable.

Add Additional Files

Click:

Add File(s)

Select:

flutter_windows.dll
CodexApp.exe

Add the Data Folder

Click:

💡 Tip

Every Flutter Windows application is different.

Some apps may contain additional DLL files, native libraries, AI models, assets, or plugin resources.

If your application uses packages that generate extra files in the Release folder, include those files and folders in your installer as well.

Step 5: Configure the Data Folder Destination

After adding the data folder:

Select the folder entry.
Click Edit.
Set:

Destination Subfolder:

data\*

This ensures the Flutter assets are installed correctly.

Without this step, your application may fail to load resources after installation.

Step 6: File Association (Optional)

If your application opens custom file types, configure them here.

Example:

Most Flutter applications don't require file associations.

Leave this unchecked and click Next.

Step 7: Create Application Shortcuts

Recommended settings:

✅ Create a Start Menu shortcut
✅ Allow users to create a Desktop shortcut

This improves accessibility for end users.

Click Next.

Step 8: Choose Installation Mode

Select:

Administrative Install Mode
(Install for all users)

This installs the application for all users on the computer.

Click Next.

Step 9: Configure Compiler Settings

This step controls how the final installer will be generated.

Configure:

Output Folder

Choose where the installer should be generated.

Example:

C:\Installers

Installer Name

Example:

CodexInstaller

Custom Icon (Optional)

You can specify a custom:

.ico

file for your installer.

Password Protection (Optional)

You may also password-protect the installer if needed.

Click Next.

Step 10: Generate the Installer Script

Continue through the remaining wizard pages and click Finish.

Inno Setup will ask:

Would you like to save the script before compiling?

Select Yes to save the installer script. This allows you to quickly rebuild or update the installer whenever you release a new version of your Flutter Windows application.

Step 11: Build the Installer

Inno Setup will compile your script and package all required files.

Once the compilation completes successfully, your output folder will contain:

CodexInstaller.exe

Testing the Installer

Before distributing your installer:

Verify Installation

Install on a clean machine or VM.
Launch the application.
Verify assets load correctly.
Confirm shortcuts work.

Verify Uninstallation

Open Control Panel.
Uninstall the application.
Confirm files are removed properly.

Common Issues and Solutions

App Opens But Shows a Blank Screen

Usually caused by:

Missing data folder
Incorrect destination subfolder configuration

Make sure the data folder is installed as:

Application Folder\data

Missing DLL Errors

Ensure:

flutter_windows.dll

is included in the installer.

Assets Not Loading

Verify:

data/

has been added recursively.

Final Folder Structure

Your release folder should look similar to:

Release/
│
├── MyApp.exe
├── flutter_windows.dll
├── data/
├── other dependency files

After packaging with Inno Setup, users only need:

CodexInstaller.exe

Conclusion

Inno Setup is one of the easiest and most reliable tools for packaging Flutter Windows applications into a professional installer.

With just a few minutes of setup, Inno Setup can transform your Flutter Windows release files into a professional installer that users can install with a few clicks.

Whether you're distributing applications internally, sharing software with clients, or preparing for a public release, creating a proper installer provides a much better user experience than distributing raw release files.

Happy coding! 🚀

Building AI-Powered .NET Applications Without Learning Python

Codexlancers — Fri, 10 Jul 2026 04:30:00 +0000

For years, AI felt like something only Python developers could build.

Every tutorial started with Jupyter notebooks, TensorFlow, and dozens of packages that backend developers had never heard of.

Today, that's no longer true.

If you're already building applications with ASP.NET Core, AI is becoming another capability you can add to your application rather than an entirely new field to learn.

The good news is that Microsoft has built an ecosystem that allows developers to stay inside C# while adding intelligent features to their applications.

In this article, we'll look at three approaches every .NET developer should know:

ML.NET for training custom models
ONNX for consuming existing models
Azure AI for plug-and-play intelligence

Option 1: Build Your Own Models with ML.NET

ML.NET allows developers to train and consume machine learning models entirely inside .NET.

Install it first.

dotnet add package Microsoft.ML

Define your data model

public class SentimentData
{
    public string Text { get; set; } = string.Empty;

    public bool Label { get; set; }
}

public class SentimentPrediction
{
    public bool PredictedLabel { get; set; }

    public float Probability { get; set; }

    public float Score { get; set; }
}

Train a model

using Microsoft.ML;

var context = new MLContext();

var data = context.Data.LoadFromTextFile<SentimentData>(
    "data.csv",
    hasHeader: true,
    separatorChar: ',');

var pipeline = context
    .Transforms
    .Text
    .FeaturizeText(
        "Features",
        nameof(SentimentData.Text))
    .Append(
        context.BinaryClassification
        .Trainers
        .SdcaLogisticRegression(
            labelColumnName: "Label",
            featureColumnName: "Features"));

var model = pipeline.Fit(data);

context.Model.Save(
    model,
    data.Schema,
    "sentiment_model.zip");

Make a prediction

var engine = context.Model.CreatePredictionEngine<
    SentimentData,
    SentimentPrediction>(model);

var result = engine.Predict(
    new SentimentData
    {
        Text = "I love this product"
    });

Console.WriteLine(
    $"Prediction: {result.PredictedLabel}");

Option 2: Use ONNX Models

Sometimes training a model is unnecessary.

You simply want to use one that already exists.

Install the runtime.

dotnet add package Microsoft.ML.OnnxRuntime

Load an ONNX model.

using Microsoft.ML.OnnxRuntime;
using Microsoft.ML.OnnxRuntime.Tensors;

var session =
    new InferenceSession(
        "model.onnx");

var tensor =
    new DenseTensor<float>(
        new[] { 1f, 2f, 3f },
        new[] { 1, 3 });

var inputs =
[
    NamedOnnxValue.CreateFromTensor(
        "input",
        tensor)
];

using var results =
    session.Run(inputs);

This approach is great when performance matters or when data scientists already provide trained models.

Option 3: Add AI Without Building Models

Sometimes developers overcomplicate AI.

You don't always need machine learning.

Sometimes you simply need intelligent features.

Azure AI provides services for:

OCR
Translation
Speech recognition
Sentiment analysis
Document extraction

Example:

using Azure;
using Azure.AI.TextAnalytics;

var client =
    new TextAnalyticsClient(
        endpoint,
        new AzureKeyCredential(key));

var response =
    client.AnalyzeSentiment(
        "The service was excellent.");

Console.WriteLine(
    response.Value.Sentiment);

No training required.

Just consume the API.

How I Choose Between Them

Over time, I started using a simple rule.

ML.NET

When my application needs to learn from my own data.

ONNX

When a trained model already exists.

Azure AI

When I simply need intelligent features quickly.

You don't have to pick only one.

Many applications combine all three.

Final Thoughts

The biggest mindset shift is realizing that AI is no longer a separate world.

It's becoming another layer of software development.

Just like databases.

Just like caching.

Just like Docker.

As .NET developers, we no longer have to leave our ecosystem to build intelligent applications.

And honestly, that's probably the most exciting part.

The barrier to entry has never been lower.

How to Make Flutter Web Apps Fully Responsive Across All Screen Sizes

Codexlancers — Thu, 09 Jul 2026 10:00:00 +0000

Building for the web with Flutter is powerful - but making it truly responsive across mobile, tablet, and desktop is where most apps struggle.

At our team, we've seen one consistent pattern:

👉 Apps don't fail because of features - they fail because of layout breakdown on different screen sizes.

In this guide, we'll walk through how we approach fully responsive Flutter Web design, using production-ready patterns that scale across devices.

Why Responsiveness Matters in Flutter Web

Unlike mobile apps, Flutter Web runs on:

Small mobile screens (320px–480px)
Tablets (600px–1024px)
Laptops (1024px–1440px)
Large desktops (1440px+)

If your UI is not adaptive:

Buttons overflow
Text becomes unreadable
Layout breaks on wide screens
Users drop off instantly

So instead of designing for one screen, we design for breakpoints + flexible layouts.

1. Define Clear Breakpoints for All Screen Sizes

The first step in any responsive system is defining consistent screen breakpoints. Without this, layouts become unpredictable and hard to maintain.

We usually divide screens into three categories:

Mobile
Tablet
Desktop

This gives us a clean structure to base all UI decisions on.

class ScreenSizes {
  static const mobile = 600;
  static const tablet = 1024;
  static const desktop = 1440;
}

Once breakpoints are defined, they act as the foundation of the entire responsive system.

2. Build a Central Responsive Helper

Instead of writing MediaQuery conditions everywhere, we centralize all logic into a single helper class.

This keeps the code clean, reusable, and scalable across large projects.

import 'package:flutter/material.dart';

class Responsive {
  static bool isMobile(BuildContext context) =>
      MediaQuery.of(context).size.width < ScreenSizes.mobile;

  static bool isTablet(BuildContext context) =>
      MediaQuery.of(context).size.width < ScreenSizes.tablet &&
      MediaQuery.of(context).size.width >= ScreenSizes.mobile;

  static bool isDesktop(BuildContext context) =>
      MediaQuery.of(context).size.width >= ScreenSizes.tablet;
}

This approach ensures consistency across the entire app.

3. Avoid Fixed Layouts - Use Flexible Widgets

One of the most common mistakes in Flutter Web is using fixed widths and heights.

This breaks UI instantly on different screen sizes.

Instead, we rely on flexible widgets like Expanded and Flexible.

Row(
  children: [
    Expanded(
      flex: 2,
      child: Container(color: Colors.blue),
    ),
    Expanded(
      flex: 3,
      child: Container(color: Colors.green),
    ),
  ],
)

This ensures layouts naturally adjust to available space.

4. Use LayoutBuilder for Real-Time Responsiveness

Instead of guessing device size, we let Flutter tell us the actual constraints using LayoutBuilder.

This is one of the most reliable ways to build adaptive UIs.

LayoutBuilder(
  builder: (context, constraints) {
    if (constraints.maxWidth < 600) {
      return MobileView();
    } else if (constraints.maxWidth < 1024) {
      return TabletView();
    } else {
      return DesktopView();
    }
  },
)

This pattern allows us to fully control UI per screen type.

5. Design Adaptive Navigation Systems

Navigation is one of the most overlooked parts of responsive design.

A single navigation style does not work across all screen sizes.

We follow this approach:

Mobile → Bottom Navigation
Tablet → Navigation Rail
Desktop → Sidebar Navigation

Widget buildNavigation(BuildContext context) {
  if (Responsive.isMobile(context)) {
    return BottomNavigationBar(items: [...]);
  } else {
    return NavigationRail(
      extended: Responsive.isDesktop(context),
      destinations: const [
        NavigationRailDestination(
          icon: Icon(Icons.home),
          label: Text('Home'),
        ),
      ],
    );
  }
}

This ensures usability across all devices.

6. Use GridView for Adaptive Layouts

Instead of fixed columns, we use adaptive grids that automatically adjust based on screen width.

This removes the need for manual layout tuning.

GridView.builder(
  gridDelegate: SliverGridDelegateWithMaxCrossAxisExtent(
    maxCrossAxisExtent: 300,
    crossAxisSpacing: 16,
    mainAxisSpacing: 16,
  ),
  itemCount: 20,
  itemBuilder: (context, index) {
    return Card(
      child: Center(child: Text("Item $index")),
    );
  },
)

This approach ensures the UI always looks balanced.

7. Implement Responsive Typography

Typography often gets ignored, but it plays a huge role in readability across devices.

We scale font sizes based on screen width.

double getFontSize(BuildContext context) {
  double width = MediaQuery.of(context).size.width;

  if (width < 600) return 14;
  if (width < 1024) return 16;
  return 18;
}

Then apply it consistently across the app:

Text(
  "Responsive Design",
  style: TextStyle(fontSize: getFontSize(context)),
)

8. Avoid Fixed Width Containers

Fixed-width containers break layouts on smaller screens and waste space on larger ones.

Instead, we use fluid layouts with constraints.

Container(
  width: double.infinity,
  constraints: BoxConstraints(maxWidth: 500),
)

This ensures:

Mobile → full width usage
Desktop → centered readable layout

9. Structure Code for Scalability

Responsiveness is not just UI - it's architecture.

We always structure our projects in a way that scales:

/responsive
  breakpoints.dart
  screen_helper.dart

/screens
  mobile/
  tablet/
  desktop/

Then we use a simple switch system:

Widget build(BuildContext context) {
  return Responsive.isMobile(context)
      ? MobileHome()
      : Responsive.isTablet(context)
          ? TabletHome()
          : DesktopHome();
}

This keeps code clean, maintainable, and production-ready.

Common Mistakes in Flutter Web Responsiveness

Here are some mistakes we often see while building Flutter Web apps:

1. Overusing MediaQuery

Using MediaQuery everywhere makes code messy and hard to manage. It's better to centralize responsiveness logic.

2. Designing Only for Mobile

Many apps are built for mobile first and later stretched for web, which breaks layouts on larger screens.

3. Using Fixed Widths

Hardcoded sizes don't adapt well. Always prefer flexible layouts over fixed dimensions.

4. Ignoring Desktop UI

A lot of apps simply scale up mobile screens instead of designing proper desktop layouts.

5. Poor Typography Scaling

Same font size across all devices hurts readability. Text should adapt to screen size.

6. Not Testing Real Screens

Only testing in emulator is not enough - real devices often reveal layout issues.

Final Thoughts

Responsive design in Flutter Web is not about adding a few conditions - it's about building a system that scales by default.

At our team, the goal is simple:

"If a UI breaks on any screen, the architecture is wrong - not the screen."

If you follow:

Breakpoints
Adaptive layouts
Flexible widgets
Grid-based scaling
Device-aware navigation

you'll already be ahead of 80% of Flutter web apps today.

Flutter + WebRTC + Firebase: Build a Real-Time Video App

Codexlancers — Tue, 07 Jul 2026 04:30:00 +0000

How we built a cross-platform video calling app with camera, mic, screen sharing, live chat, polls, and emoji reactions using WebRTC, Flutter, and Firebase.

Why WebRTC?
WebRTC (Web Real-Time Communication) is an open-source technology that enables browsers and mobile applications to exchange:

Audio
Video
Arbitrary data

directly between users.
The biggest advantage?

Peer-to-Peer Communication
Instead of routing every video frame through your servers, WebRTC allows devices to communicate directly whenever possible.
That means:

Lower latency
Better privacy
Reduced infrastructure costs

But it raises an important question:
How do two devices on different networks actually find each other?
That question is where the real WebRTC journey begins.

Understanding WebRTC: The Phone Call Analogy
WebRTC has two completely separate parts:
1. Signaling
Helps peers discover each other and exchange connection information. WebRTC doesn't provide this. You build it yourself.

2. Media/Data Transport
Once peers know how to connect, WebRTC handles the actual communication.
Think of it like making a phone call.

📖 Phone book → Signaling
☎️ Actual conversation → Peer Connection

The phone book doesn't hear the conversation. It only helps establish it. The Firebase Firestore acts as the phone book.

The WebRTC Handshake
Whenever someone joins a meeting, this sequence occurs:

Breaking Down the Terminology
SDP (Session Description Protocol)

A text description of what each peer supports.
It contains information such as:

Supported codecs
Video resolutions
Audio capabilities

The caller creates an Offer. The receiver responds with an Answer.

ICE Candidates
Possible network routes that peers can use to communicate.

Examples include:

Local IP addresses
Public IP addresses discovered through STUN

WebRTC automatically selects the best working path.

STUN Servers
STUN servers answer one simple question:
"How does the internet see me?" They help devices discover their public IP addresses. Google provides free STUN servers that are perfect for learning and prototypes.

Building the app

Step 1: Capturing Camera and Microphone
Everything begins with obtaining media access.

_cameraStream = await navigator.mediaDevices.getUserMedia({
  'audio': true,
  'video': {
    'facingMode': 'user',
    'width': {'ideal': 1280},
    'height': {'ideal': 720},
  },
});

Simple enough. Until real users show up.
What if:

Camera permission is denied?
No webcam exists?
Another app is already using the camera?

In production, you need fallbacks.

Step 2: Creating the Peer Connection
The heart of WebRTC is: RTCPeerConnection
This object represents the live connection.

_peerConnection = await createPeerConnection({
 'iceServers': [
   {'urls': 'stun:stun.l.google.com:19302'},
   {'urls': 'stun:stun1.l.google.com:19302'},
 ],
});

STUN vs TURN
One important production consideration:
STUN

Direct peer-to-peer
Free
Low latency

TURN

Relays media through a server
Works behind restrictive NATs
Costs bandwidth

STUN is enough for demos.
TURN is required for production reliability.

Step 3: Signaling with Firebase Firestore
This is the part tutorials often skip. WebRTC doesn't tell you how to exchange Offers and Answers.
Many implementations use:

Node.js
Socket.IO

We choose: Firebase Firestore
Because Firestore provides:

Realtime listeners
Serverless infrastructure
Minimal backend maintenanceon.

Step 4: The ICE Candidate Race Condition
Every WebRTC developer eventually encounters this bug. ICE candidates often arrive before the remote description has been set.

If you process them immediately: WebRTC throws errors.
The solution: Buffer them.

if (!_remoteDescriptionSet) {
 _pendingCandidates.add(data);
 return;
}

Once the remote description is available:

_flushPendingCandidates();

Step 5: Data Channels
Most people think WebRTC only handles video. It doesn't.

It also supports:
RTCDataChannel
A peer-to-peer data pipeline.
we used it for:

💬 Chat
😄 Emoji reactions
📊 Live polls
🔇 Mic status
📷 Camera status

Example:

sendMessage(String text);
sendReaction(String emoji);

switch(data['type']) {
 case 'chat':
 case 'reaction':
 case 'poll':
}

Chat messages never touch a server. They're encrypted and delivered directly between peers.

Step 6: Mute, Camera, and Screen Sharing
Real meetings aren't static.
Users:

Mute microphones
Disable cameras
Share screens

Muting is surprisingly simple.

track.enabled = false;

Screen sharing is even cooler. Instead of rebuilding the connection:

replaceTrack(screenTrack);

The remote user seamlessly sees your screen. No renegotiation required.

The Reality of Production WebRTC
This is where the real work begins. A demo can be built quickly. A product is much harder.

Here are some of the problems we had to solve while building a production-ready implementation.

Peer-Left Detection
Users don't always leave gracefully. They close browser tabs, force-stop the app, or lose connectivity.

We relied on Firestore room state to detect this:

roomSubscription = roomRef.snapshots().listen((snapshot) {
  final data = snapshot.data();

  if (data == null) return;

  if (data['calleeJoined'] == false) {
    leaveCall();
    showMessage("The other participant left the meeting.");
  }
});

Without proper cleanup, cameras remain active and rooms become unusable.

Reconnection Logic
Mobile networks are unreliable. Users switch between Wi-Fi and cellular networks all the time.

Instead of assuming a stable connection, we watched the ICE connection state:

_peerConnection?.onIceConnectionState = (state) {
  if (state == RTCIceConnectionState.RTCIceConnectionStateDisconnected) {
    attemptReconnect();
  }

  if (state == RTCIceConnectionState.RTCIceConnectionStateFailed) {
    restartIce();
  }
};

A failed connection shouldn't automatically end the call. Sometimes it just needs another chance.

Lifecycle Management
Users minimize apps. Browsers close. Operating systems kill background processes.

We used Flutter lifecycle callbacks to release resources safely:

@override
void didChangeAppLifecycleState(AppLifecycleState state) {
  if (state == AppLifecycleState.detached) {
    leaveCall();
  }
}

Ignoring lifecycle events often leads to stuck cameras and orphaned sessions.

Renderer Management
RTCVideoRenderer instances are expensive. Creating and disposing them repeatedly can cause black screens.

Instead, initialize them once:

await localRenderer.initialize();
await remoteRenderer.initialize();

// Reuse throughout the call
localRenderer.srcObject = localStream;
remoteRenderer.srcObject = remoteStream;

Dispose them only after the meeting ends.

Camera Hardware Timing
Stopping camera tracks immediately doesn't always release hardware properly.

We introduced a small delay:

await Future.delayed(const Duration(milliseconds: 300));

await localStream
    ?.getVideoTracks()
    .first
    .stop();

Without this, some devices kept the camera indicator active even after leaving the call.

ICE Candidate Race Conditions
ICE candidates can arrive before the remote description is set. Processing them too early causes exceptions.

Buffer first:

if (!_remoteDescriptionSet) {
  pendingCandidates.add(candidate);
  return;
}

await addIceCandidate(candidate);

Flush them later:
for (final candidate in pendingCandidates) {
  await addIceCandidate(candidate);
}

pendingCandidates.clear();

This tiny piece of logic eliminated one of the most common WebRTC bugs. A WebRTC demo is 20% of the work. The remaining 80% is handling edge cases.
WebRTC User Limits: A Quick Guide
"How many users can WebRTC support?" It depends on your architecture:

1-on-1 Calls (P2P) - Perfect for two users: low latency, minimal infrastructure.
Small Groups (Mesh) - Each participant connects to all others. Works for 3–6 users; connections grow rapidly beyond that.
Large Meetings (SFU) - A server forwards each user's stream to others. Supports dozens or hundreds of participants with lower CPU and bandwidth usage, but requires server infrastructure.

When to use what:

1–2 users → Pure P2P
3–6 users → Mesh (use with caution)
6+ users → SFU
Large webinars → SFU with recording and simulcast

Architecture Overview

Firebase only handles signaling.Media flows directly between peers.
That separation is the essence of WebRTC.

Should You Use WebRTC?
Yes, if you're building:

Video conferencing
Audio calling
Collaborative applications
Peer-to-peer file sharing
Realtime gaming experiences

Plan ahead for:

TURN infrastructure
Reconnection strategies
Edge cases
Group-call scalability

Once you move beyond one-to-one calls, you'll eventually need an SFU.
But for MVPs and real-world one-to-one applications:
Flutter + WebRTC + Firebase is an incredibly powerful combination.

Key Takeaways

WebRTC handles media, not signaling.
Firebase Firestore makes an excellent serverless signaling layer.
Offer → Answer → ICE is the universal handshake.
Data channels are massively underrated.
Edge cases are where production engineering happens.

we'd love to hear your experiences building with WebRTC. Drop your questions in the comments.

Running Local AI Models in .NET with Ollama (Step-by-Step Guide)

Codexlancers — Fri, 03 Jul 2026 04:30:00 +0000

Build AI-powered ASP.NET Core applications without relying entirely on cloud providers.

Introduction

If you've been experimenting with AI recently, your journey probably looked something like this:

Sign up for an AI provider
Generate an API key
Send a prompt
Get a response

It's simple, fast, and honestly, it's amazing how quickly you can build something useful.

But once AI moves beyond a proof of concept, a different set of questions starts to appear.

How much will this cost at scale?
Do we really want sensitive data leaving our infrastructure?
What happens if we hit API limits?
Do we want our internal tools to depend entirely on an external service?

This is exactly where local AI becomes interesting.

Recently, I started experimenting with Ollama and was surprised by how easy it has become to run AI models locally and integrate them into a regular ASP.NET Core application.

The best part?

From a .NET developer's perspective, it mostly feels like integrating another HTTP service.

In this guide, we'll:

Install Ollama
Download and run a local model
Integrate it into ASP.NET Core
Build a simple AI-powered endpoint

Why Run AI Models Locally?

Cloud AI is fantastic.

I'm not here to replace it.

But local AI solves a different set of problems.

Better Privacy

Many business applications work with sensitive information.

Things like:

Internal documentation
Support tickets
Customer records
Application logs

Sending that information to an external AI provider may introduce security, compliance, or governance concerns.

Running models locally keeps everything inside your own infrastructure.

Predictable Costs

Cloud providers charge based on usage.

That works well initially, but costs can grow quickly as applications scale.

Local AI removes the per-request pricing model entirely.

Fewer Dependencies

Your application no longer depends on:

Internet connectivity
External outages
API rate limits

Everything runs on your own machine or server.

What Is Ollama?

Ollama is a tool that allows developers to run Large Language Models (LLMs) locally.

Instead of manually configuring machine learning environments, Ollama handles:

Model downloads
Runtime management
Memory handling
HTTP APIs

Once installed, interacting with AI becomes as simple as making an HTTP request.

Popular models include:

Model	Best Use Case
llama3	General AI tasks
mistral	Fast responses
codellama	Code generation
gemma	Lightweight applications

Step 1: Install Ollama

Download Ollama from:

https://ollama.com

Verify the installation.

ollama --version

Download a model.

ollama pull llama3

Run it.

ollama run llama3

Ask it something simple.

Explain dependency injection in ASP.NET Core

If you get a response, you're ready to go.

By default, Ollama exposes a local API at:

http://localhost:11434

This is what our ASP.NET Core application will communicate with.

Step 2: Create an ASP.NET Core API

Create a new project.

dotnet new webapi -n LocalAIApi

Recommended structure:

Controllers
Services
Models
Program.cs

Keep your AI logic separate from controllers.

It'll make your application easier to maintain.

Step 3: Register HttpClient

Inside Program.cs:

builder.Services.AddHttpClient<IAiService, OllamaService>(client =>
{
    client.BaseAddress = new Uri("http://localhost:11434");

    client.Timeout = TimeSpan.FromMinutes(2);
});

Step 4: Create an AI Service

Interface:

public interface IAiService
{
    Task<string> GenerateAsync(
        string prompt,
        CancellationToken cancellationToken);
}

Implementation:

public class OllamaService : IAiService
{
    private readonly HttpClient _httpClient;

    public OllamaService(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public async Task<string> GenerateAsync(
        string prompt,
        CancellationToken cancellationToken)
    {
        var request = new
        {
            model = "llama3",
            prompt,
            stream = false
        };

        var response = await _httpClient.PostAsJsonAsync(
            "api/generate",
            request,
            cancellationToken);

        response.EnsureSuccessStatusCode();

        var result = await response.Content
            .ReadFromJsonAsync<OllamaResponse>(
                cancellationToken: cancellationToken);

        return result?.Response ?? string.Empty;
    }
}

Response model:

public class OllamaResponse
{
    public string Response { get; set; } = string.Empty;
}

At this point, AI integration starts looking very similar to integrating any third-party API.

That's probably the biggest surprise when working with Ollama for the first time.

Most of the complexity is already handled for you.

Step 5: Expose an AI Endpoint

Request model:

public class AiRequest
{
    public string Prompt { get; set; } = string.Empty;
}

Controller:

[ApiController]
[Route("api/ai")]
public class AiController : ControllerBase
{
    private readonly IAiService _aiService;

    public AiController(IAiService aiService)
    {
        _aiService = aiService;
    }

    [HttpPost("generate")]
    public async Task<IActionResult> Generate(
        AiRequest request,
        CancellationToken cancellationToken)
    {
        if (string.IsNullOrWhiteSpace(request.Prompt))
        {
            return BadRequest("Prompt is required.");
        }

        var result = await _aiService.GenerateAsync(
            request.Prompt,
            cancellationToken);

        return Ok(new
        {
            response = result
        });
    }
}

Your API can now expose AI functionality without relying on a cloud provider.

Architecture Overview

Client
   ↓
ASP.NET Core API
   ↓
AI Service Layer
   ↓
Ollama HTTP API
   ↓
Local LLM

Keeping AI behind a dedicated service layer makes it easier to swap providers later if needed.

Is Local AI Always Better?

No.

Cloud AI is still the better choice in many scenarios.

For example:

Use cloud AI when:

You need state-of-the-art reasoning models
You have thousands of concurrent users
You need globally distributed infrastructure

Use local AI when:

Privacy matters
Cost control matters
You're building internal business tools

In reality, many teams will likely use a hybrid approach.

Final Thoughts

A few years ago, running large language models felt like something only machine learning engineers could do.

Today, tools like Ollama have changed that.

As a .NET developer, integrating local AI is often just another HTTP integration.

And that's what makes this so exciting.

Local AI isn't replacing cloud AI.

It's simply giving developers another architectural option.

For internal tools, private assistants, documentation search, and AI-powered business applications, that option is becoming increasingly practical every day.

Flutter Firebase Remote Config: Control Your App Without Releasing Again

Codexlancers — Thu, 02 Jul 2026 08:30:00 +0000

There's a moment every developer hits. You ship an app and then immediately realize :

"I should hide this feature"
"This API needs to change"
"We need a quick banner or message"

But now you're stuck waiting for users to update the app.

That's where Firebase Remote Config quietly becomes one of the most powerful tools in your Flutter toolkit.

Why This Matters More Than You Think

Most apps today aren't build once and forget.

They evolve constantly:

Features roll out gradually
Experiments need testing
Bugs need quick mitigation

Without a remote control system, every small change becomes:
Build → Upload → Review → Wait → Hope users update
That's slow and sometimes risky.

Remote Config flips that completely.

🧠 The Idea

Instead of hardcoding values in your app:

const bool showNewUI = true;

You move that control to the cloud.

Now it becomes:

bool showNewUI = remoteConfig.getBool("show_new_ui");

And suddenly…

👉 You can turn features ON/OFF from Firebase
👉 You can change behavior without redeploying
👉 You can react instantly to real-world issues

Where It Actually Helps in Real Apps

Let's not talk theory - here's where it actually shines:

1. Emergency Fixes

API breaking? Feature crashing?
Just disable it remotely instead of pushing a hotfix build.

2. Feature Flags

Roll out a feature to:

10% users first
Then 50%
Then everyone

All without touching the code again.

3. Maintenance Mode

Add a config like:

is_app_under_maintenance: true

Your app can instantly switch to a maintenance screen.

4. A/B Testing

Try:

Two different home screens
Different button colours
Different pricing UI

Measure what works best.

Flutter Integration

The setup is simple - but how you structure it matters more.

Step 1: Initialize once

final remoteConfig = FirebaseRemoteConfig.instance;

await remoteConfig.setConfigSettings(
  RemoteConfigSettings(
    fetchTimeout: const Duration(seconds: 10),
    minimumFetchInterval: const Duration(hours: 1),
  ),
);

Step 2: Always define defaults

This is your safety net.

await remoteConfig.setDefaults({
  "show_new_ui": false,
  "is_app_under_maintenance": false,
});

👉 If fetch fails and you don't define defaults → your app can break.

Step 3: Fetch & activate

await remoteConfig.fetchAndActivate();

👉 This does two things:

Fetches latest values from Firebase
Activates them immediately in the app

Step 4: Use it like normal data

if (remoteConfig.getBool("is_app_under_maintenance")) {
  return const MaintenanceScreen();
}

A Cleaner Way

If you directly access Remote Config everywhere… things get messy fast.

A better approach is to centralize it:

class AppConfig {
  static final _remote = FirebaseRemoteConfig.instance;

  static bool get isMaintenance =>
      _remote.getBool("is_app_under_maintenance");

  static bool get showNewUI =>
      _remote.getBool("show_new_ui");
}

Now your UI stays clean:

if (AppConfig.isMaintenance) {
  return const MaintenanceScreen();
}

⚠️ Things That Will Save You Later

1. Don't treat it like real-time

Remote Config is not instant.

It works on fetch intervals - so don't use it for:

Live chat
Real-time counters

2. Be careful with fetch frequency

During development: minimumFetchInterval: Duration.zero

In production:
minimumFetchInterval: Duration(hours: 12)

Otherwise, Firebase will throttle your requests.

3. Never store sensitive data

This is not for:

API keys
Secrets
Tokens

Everything here can be exposed.

4. Defaults are not optional

If fetch fails and you didn't define defaults → your app can break.

🧠 When You Should Actually Use It

Use Remote Config when:

You want flexibility after release
You run experiments
You need quick toggles for features
You want safer rollouts

Avoid it when:

You need real-time updates
You're storing secure data
You're passing large payloads

💡 Final Take

If you're already using Firebase and not using Remote Config You're honestly missing out on one of the easiest wins in Flutter development.

Start small:

Add one flag
Control one UI change

And once you see it working You won't want to go back.

How to Implement Biometric Authentication in a Flutter App (The Right Way)

Codexlancers — Wed, 01 Jul 2026 06:30:00 +0000

In today's world, security is no longer optional - it's expected. Whether it's a fintech app, a fitness tracker, or an internal company tool, users want fast and secure access without the hassle of remembering passwords.

That's exactly where biometric authentication comes in.

In this guide, we'll walk through how we implement biometric authentication in a Flutter app, the practical approach we follow in production, and the common mistakes developers often make (and how to avoid them).

Why Biometric Authentication?

Before jumping into implementation, let's quickly understand why it matters:

Faster login experience (no typing passwords)
More secure than traditional authentication
Native support across Android & iOS
Better user trust and retention

What We Use in Flutter

To implement biometric authentication, we rely on:

local_auth package (official Flutter plugin)
Native biometric APIs under the hood (Face ID, Touch ID, Fingerprint)

Step 1: Add Dependency

dependencies:
  local_auth: ^3.0.1

Then run:

flutter pub get

Step 2: Platform Setup

✅ Android Setup

Inside android/app/src/main/AndroidManifest.xml:

<uses-permission android:name="android.permission.USE_BIOMETRIC"/>

Also ensure:

<uses-feature android:name="android.hardware.fingerprint" android:required="false"/>

✅ iOS Setup

Inside ios/Runner/Info.plist:

<key>NSFaceIDUsageDescription</key>
<string>We use Face ID to authenticate you securely</string>

⚠️ Without this, Face ID will NOT work and your app may crash.

Step 3: Implement Biometric Logic

Here's how we structure it in production:

import 'package:flutter/foundation.dart';
import 'package:local_auth/local_auth.dart';

class BiometricService {
  final LocalAuthentication _auth = LocalAuthentication();

  /// Check if device supports biometrics
  Future<bool> isBiometricAvailable() async {
    try {
      final bool canCheckBiometrics = await _auth.canCheckBiometrics;
      final bool isDeviceSupported = await _auth.isDeviceSupported();

      return canCheckBiometrics && isDeviceSupported;
    } catch (e) {
      debugPrint('Biometric availability error: $e');
      return false;
    }
  }

  /// Get available biometric types (fingerprint, face, etc.)
  Future<List<BiometricType>> getAvailableBiometrics() async {
    try {
      return await _auth.getAvailableBiometrics();
    } catch (e) {
      debugPrint('Error fetching biometrics: $e');
      return [];
    }
  }

  /// Authenticate user (with optional fallback to device PIN/password)
  Future<bool> authenticate({
    bool biometricOnly = false,
  }) async {
    try {
      final bool isAvailable = await isBiometricAvailable();

      if (!isAvailable) {
        debugPrint('Biometric not available on this device');
        return false;
      }

      final bool isAuthenticated = await _auth.authenticate(
        localizedReason: 'Please authenticate to continue',
        options: AuthenticationOptions(
          biometricOnly: biometricOnly,
          stickyAuth: true,
          useErrorDialogs: true,
        ),
      );

      return isAuthenticated;
    } catch (e) {
      debugPrint('Authentication error: $e');
      return false;
    }
  }
}

Step 4: Use It in UI

final BiometricService biometricService = BiometricService();

Future<void> loginWithBiometrics(BuildContext context) async {
  final bool isAuthenticated = await biometricService.authenticate();

  if (isAuthenticated) {
    ScaffoldMessenger.of(context).showSnackBar(
      const SnackBar(
        content: Text('Authentication successful'),
      ),
    );
  } else {
    ScaffoldMessenger.of(context).showSnackBar(
      const SnackBar(
        content: Text('Authentication failed. Please try again'),
      ),
    );
  }
}

Works for Face ID & Fingerprint (No Extra Code Needed)

One thing we really like about this approach is that we don't have to write separate logic for different biometric types.

The same implementation works for:

Fingerprint (Android)
Face ID (iOS)
Touch ID (older iOS devices)

The local_auth package automatically detects and uses the available biometric method on the device.

So whether the user is using Face ID or fingerprint - the flow remains exactly the same from our side.

What We Actually Add in Production Apps

In real apps, we don't stop at just authentication:

✅ Store a flag (biometric enabled/disabled) using secure storage
✅ Provide fallback (PIN or password)
✅ Show a toggle in settings
✅ Auto-trigger biometrics on app launch (if enabled)

Mistakes We've Seen While Implementing This

This is where most implementations go wrong 👇

1. Not Handling Unsupported Devices

Many developers assume biometrics will always be available.

👉 Always check:

✅ canCheckBiometrics
✅ isDeviceSupported

2. Ignoring iOS Permission Setup

Missing NSFaceIDUsageDescription is one of the most common issues.

👉 Result: App crash or silent failure.

3. Not Providing a Fallback Option

Biometrics can fail due to:
Wet fingers
Face not recognized
Sensor issues

👉 Always provide:

PIN and Password fallback

4. Forcing Biometric Without User Consent

Never enable biometrics by default.

👉 Always:

Ask user permission
Let them enable/disable in settings

5. Poor Error Handling

Most developers just return false on failure.

👉 Instead:

Handle exceptions properly
Show meaningful messages to users

6. Not Testing Edge Cases

Biometric flows behave differently when:

App goes to background
Device is locked/unlocked
Multiple failed attempts occur

👉 Always test:

Background/foreground transitions
Lock screen scenarios

7. Using Biometrics as the Only Security Layer

Biometric authentication should not replace backend authentication.

👉 Always combine with:

Secure tokens
Backend validation

Things That Helped Us Get This Right

From our experience, this is what works best:

Keep biometric logic separate (service class)
Always provide fallback authentication
Respect user choice and privacy
Test on real devices (not just emulators)
Keep UX smooth and non-intrusive

Final Thoughts

Biometric authentication is powerful - but only when implemented thoughtfully.

It's not just about adding a fingerprint or Face ID button. It's about creating a secure, seamless, and reliable user experience.

When done right, it can significantly improve both security and user satisfaction.

If you're building a Flutter app and want to level up your authentication flow, this is one feature you shouldn't skip.

Implementing Google Authentication in Flutter Without Firebase: Using the Latest google_sign_in (7.2.0)

Codexlancers — Tue, 30 Jun 2026 05:00:00 +0000

There's a point in almost every Flutter project where authentication comes into the picture.

And more often than not, the default answer is:

"Just use Firebase."

We've done that too. It works well.

But in one of our recent projects, we already had a backend handling authentication. We didn't need Firebase - we just needed Google Sign-In as a login option.

So we went with a direct approach using Google OAuth.

What we didn't expect?

Most tutorials online were outdated.

If you're using the latest google_sign_in (7.2.0), things have changed quite a bit.

This guide is based on what actually worked for us in production.

Why We Didn't Use Firebase

In our case, Firebase would have added unnecessary complexity.

We already had:

A backend handling users
Our own JWT/session system
APIs ready for auth

All we needed was:
👉 A way to let users log in with Google
👉 A secure way to verify them on our backend

That's it.

What the Flow Looks Like (High-Level)

The flow is still simple:

User taps "Continue with Google"
Google account picker opens
User selects an account
We receive an ID Token
We send that token to our backend
Backend verifies it with Google
User is logged in / created

Nothing Firebase-specific here.

Step 1: Google Cloud Setup (Don't Skip This)

Before writing code, make sure this part is correct:

Create a project in Google Cloud Console
Configure OAuth Consent Screen
Create OAuth Client IDs:
Android
iOS
Web (important for backend verification)

Things we double-check every time:

Correct package name / bundle ID
SHA-1 fingerprint added (Android)
Using the correct client ID in the app

If anything is wrong here, your code will look fine… but sign-in will fail silently.

Step 2: Add Dependency

google_sign_in: ^7.2.0

Step 3: Implementation

New Working Version (7.2.0)

import 'package:google_sign_in/google_sign_in.dart';

final GoogleSignIn _googleSignIn = GoogleSignIn.instance;

Future<void> signInWithGoogle() async {
  try {
    // Step 1: Initialize (Required in v7+)
    await _googleSignIn.initialize(
      serverClientId: 'YOUR_WEB_CLIENT_ID', // Get this from Google Cloud Console
    );

    // Step 2: Trigger Sign-In
    final GoogleSignInAccount account = await _googleSignIn.authenticate();

    // Step 3: Fetch Tokens
    final GoogleSignInAuthentication auth = await account.authentication;

    final String? idToken = auth.idToken;
    final String? accessToken = auth.accessToken;

    // Step 4: Validate Token
    if (idToken == null) {
      throw Exception("ID Token is null");
    }

    // Step 5: Send token to backend
    print("ID Token: $idToken");
    print("Access Token: $accessToken");

  } catch (error) {
    print("Google Sign-In Error: $error");
  }
}

Step 3: What We Send to Backend

We only send: idToken
Not accessToken. Not profile data.
Just the ID token.

Step 4: Backend Verification (Where Security Actually Happens)

This step is not optional.

Here's a simple Node.js example:

const { OAuth2Client } = require('google-auth-library');
const client = new OAuth2Client(CLIENT_ID);

async function verifyGoogleToken(idToken) {
  const ticket = await client.verifyIdToken({
    idToken,
    audience: CLIENT_ID,
  });

  const payload = ticket.getPayload();
  return payload;
}

This ensures:

Token is issued by Google
Token is not tampered
User identity is valid

Mistakes We've Seen

This is the part that saves hours of debugging.

1. Forgetting initialize()

In v7+, if you skip this:
👉 Authentication will fail
👉 Or behave inconsistently

2. Using Wrong Client ID

You must use:
👉 Web Client ID in serverClientId
Not Android / iOS.

3. Skipping Backend Verification

This is a security flaw.
Anyone can fake a token if you trust it directly from the app.

4. Not Handling Errors Properly

Don't just print(error).

At least:

Show a snackbar
Handle cancellation gracefully

5. Expecting Old Code to Work

A lot of developers copy older snippets and assume something is wrong with Flutter.

It's not.
The API changed.

6. Confusing ID Token vs Access Token

idToken → authentication (you need this)
accessToken → Google APIs (optional)

What We Added in Production

The basic flow works, but in real apps we also add:

Silent login (check if user already signed in)
Proper loading states
Retry handling for network issues
Backend session management (JWT)

When This Approach Makes Sense

We use this method when:

We already have a backend
We want full control over authentication
Firebase would be overkill

Final Thoughts

Google Sign-In without Firebase is not a workaround - it's actually the more direct and flexible approach.

But with google_sign_in 7.2.0, things have clearly evolved.

Once you understand the new flow:

Initialize
Authenticate
Get token
Verify on backend

it becomes straightforward again.

If these are right, your implementation is solid.

One Last Thing

Most tutorials haven't caught up with the 7.2.0 changes yet.

So if you've been stuck trying to make old code work - it's not you.

It's the docs lagging behind real-world usage.

The Complete Guide to Firebase Security Rules: Why They Matter and how to Write Them

Codexlancers — Mon, 29 Jun 2026 05:30:00 +0000

When building modern web and mobile applications, backend security is often the most stressful piece of the puzzle. Traditional architectures require you to spin up a custom server, write middleware, and handle authentication routing just to protect a single database row.

Firebase flips this model on its head. By allowing client applications to talk directly to backend services like Firestore and Cloud Storage, it drastically speeds up development. But this architectural shift introduces a critical question: If the client can touch the database directly, what stops a user from modifying someone else's data?

The answer is Firebase Security Rules. Let's break down what they are, why they are non-negotiable for production apps, and exactly how to implement them across different Firebase services.

What is Firebase Security, and Why Is It Crucial?

Firebase Security Rules are server-side access control configurations that sit directly between your client app and your cloud data. They act as an invisible, structural shield. Every single incoming read or write request is intercepted by Firebase and evaluated against these rules. If the request doesn't meet your criteria, Firebase rejects it entirely.

Why You Can't Ignore Them

The Client is Insecure: No matter how secure your Flutter, React, or native mobile code feels, an advanced user can decompile your app package, extract your Firebase configuration keys, and make direct calls to your endpoints via tools like Postman or custom scripts.
Data Integrity: Security rules do more than just check user identity - they validate schemas. They ensure strings aren't passed into number fields, field lengths don't exceed limits, and mandatory fields aren't missing.
Billing Protection: Leaving your database wide open allows malicious actors or rogue bots to scrape your data continuously, executing millions of reads that can instantly maximize your billing tier.

Which Firebase Services Use Security Rules?

Firebase applies individual security rule structures across three core backend services:

Cloud Firestore: Flexible, scalable NoSQL cloud database.
Realtime Database: Original, low-latency document-store database.
Cloud Storage: Built for storing and serving user-generated content like images, audio, and videos.

Let's look at two practical, real-world examples for each service to see how these rules look in action.

1. Cloud Firestore Examples

Firestore rules leverage granular path matching and custom conditions to control access down to specific document fields.

Example A: User-Owned Data Only (CRUD Isolation)

In a social or note-taking application, a user should only be able to view, edit, or delete notes that they created. This rule matches the user's logged-in unique ID (request.auth.uid) against the document's path variable.

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId}/notes/{noteId} {
      // Allow access only if the authenticated user matches the path ID
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Example B: Strict Content and Type Validation

If you run an e-commerce platform or inventory app, any authenticated user can browse products, but only incoming data that passes formatting checks can be added to the catalog.

service cloud.firestore {
  match /databases/{database}/documents {
    match /products/{productId} {
      // Anyone can read product details
      allow read: if true;

      // Enforce data integrity during creation
      allow create: if request.auth != null 
        && request.resource.data.price is int 
        && request.resource.data.price > 0
        && request.resource.data.title.size() <= 50;
    }
  }
}

request.resource.data: Points to the map data of the document as it will look if the write succeeds.

2. Realtime Database Examples

Realtime Database rules use a unique, hierarchical JSON structure rather than matching specific service paths.

Example A: Chat Room - Read Allowed, Write Restrained

In a global chat application, any user who is logged in should be able to read the history of a chat room, but they can only post messages that carry their own UID.

{
  "rules": {
    "public_chats": {
      "$roomId": {
        ".read": "auth != null",
        "messages": {
          "$messageId": {
            ".write": "auth != null && newData.child('senderId').val() === auth.uid"
          }
        }
      }
    }
  }
}

Example B: Preventing Data Overwrites (Immutable Records)

For critical logging data, financial audits, or transaction histories, you want users to be able to submit a log once, but prevent anyone from editing or deleting it later.

{
  "rules": {
    "transaction_logs": {
      "$logId": {
        ".read": "auth != null",
        // Allow creation only if data doesn't exist yet; prevent modifications
        ".write": "auth != null && !data.exists() && newData.exists()"
      }
    }
  }
}

3. Cloud Storage Examples

Firestore security parameters do not automatically safeguard your file assets. Cloud Storage handles rules separately to regulate asset uploads and size caps.

Example A: Restricting Upload File Sizes and MIME Types

To keep your storage costs under control and prevent bad actors from executing Denial of Service (DoS) attacks via massive files, you can restrict uploads to specific image file formats under 5MB.

service firebase.storage {
  match /b/{bucket}/o {
    match /profile_pictures/{userId}/{allPaths=**} {
      // Profiles are publicly readable
      allow read: if true;

      // Uploads must belong to the user, be an image, and be under 5MB
      allow write: if request.auth != null && request.auth.uid == userId
                   && request.resource.size < 5 * 1024 * 1024
                   && request.resource.contentType.matches('image/.*');
    }
  }
}

Example B: Private Business Document Multi-User Access

Imagine an app where multiple users belong to an organization account. They need access to a shared bucket of secure PDFs, while outside users are completely blocked.

service firebase.storage {
  match /b/{bucket}/o {
    match /organizations/{orgId}/documents/{docId} {
      // Allow access if the user's custom auth token contains the matching organization ID
      allow read, write: if request.auth != null 
                         && request.auth.token.organizationId == orgId;
    }
  }
}

Best Practices for Writing Firebase Security Rules

As your application grows, security rules can quickly become difficult to manage. Following a few best practices can help keep your Firebase project secure and maintainable.

Start With Deny-By-Default

Instead of allowing broad access and restricting it later, begin with restrictive rules and explicitly grant permissions where needed. This reduces the risk of accidentally exposing sensitive data.

Never Trust Client-Side Validation

Validating forms in your app improves user experience, but it does not provide security. Attackers can bypass your UI entirely and send requests directly to Firebase. Always enforce critical validations in your security rules.

Follow the Principle of Least Privilege

Users should only have access to the data and operations they absolutely need. Avoid granting collection-wide write access when document-level access is sufficient.

Use Custom Claims for Roles

For applications with administrators, moderators, or organization-based permissions, use Firebase Authentication custom claims instead of storing roles directly in client-accessible documents.

Test Rules Before Deployment

Firebase provides the Emulator Suite to test security rules locally. Verify both successful and failed requests to ensure your rules behave exactly as expected.

Keep Rules Under Version Control

Treat security rules like application code. Review changes carefully, track them in Git, and include them in your deployment process.

Conclusion

Writing Firebase Security Rules can feel like extra overhead when you are trying to ship features quickly, but they are the literal foundation of your app's security model. Treat your security rules with the same respect as your frontend architecture - write them early, test them using the local Firebase Emulator Suite, and track them under version control.

Flutter Animations for Beginners: What You Can Build Without Plugins

Codexlancers — Fri, 26 Jun 2026 10:30:00 +0000

Animations are often where apps start to feel alive instead of just functional.
And if you're just getting started with Flutter, it's easy to assume:
"I'll need a bunch of animation libraries to make things look good."

We used to think the same.
But in reality, Flutter already gives you a powerful set of built-in animation tools - no plugins required.

In this blog, we'll walk through real UI animations we've built in production apps, using only Flutter's default capabilities.

Why Avoid Plugins (At First)?

From our experience:

Plugins increase dependency risk
Updates can break things unexpectedly
Debugging becomes harder

Flutter's built-in animations are:

Lightweight
Performant
Fully customizable

And honestly more than enough for most use cases.

Animations You Can Build Without Plugins

1. Button Click Animation (Scale Effect)

On tap, the button slightly scales down and then smoothly returns to its original size.

It's a subtle effect, but it plays a big role - without feedback like this, users can feel unsure if their action was registered. This small touch makes the UI feel responsive and polished.

Where to use?

Buttons
Cards
Any tappable UI

import 'package:flutter/material.dart';

class AnimatedButton extends StatefulWidget {
  @override
  _AnimatedButtonState createState() => _AnimatedButtonState();
}

class _AnimatedButtonState extends State<AnimatedButton> {
  double _scale = 1.0;

  void _onTapDown(_) => setState(() => _scale = 0.95);
  void _onTapUp(_) => setState(() => _scale = 1.0);

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTapDown: _onTapDown,
      onTapUp: _onTapUp,
      child: AnimatedScale(
        scale: _scale,
        duration: Duration(milliseconds: 150),
        child: Container(
          padding: EdgeInsets.all(16),
          color: Colors.blue,
          child: Text("Tap Me", style: TextStyle(color: Colors.white)),
        ),
      ),
    );
  }
}

2. Expand / Collapse Cards

When tapped, the container smoothly expands or collapses to reveal or hide content.

Rather than content appearing abruptly, this creates a more natural flow, making the UI easier to read and noticeably more polished.

Where to use?

FAQs
Settings
Dashboards

class ExpandableCard extends StatefulWidget {
  @override
  _ExpandableCardState createState() => _ExpandableCardState();
}

class _ExpandableCardState extends State<ExpandableCard> {
  bool isExpanded = false;

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: () => setState(() => isExpanded = !isExpanded),
      child: AnimatedContainer(
        duration: Duration(milliseconds: 300),
        padding: EdgeInsets.all(16),
        height: isExpanded ? 150 : 70,
        color: Colors.grey[200],
        child: Column(
          children: [
            Text("Tap to Expand"),
            if (isExpanded) Text("More content here...")
          ],
        ),
      ),
    );
  }
}

3. Image Zoom (Hero Animation)

The image smoothly moves from one screen to another, as if it's the same element transitioning between pages.

This creates a seamless experience and makes the app feel more polished.

Where to use?

Profile pictures
Product previews
Galleries

Hero(
  tag: "imageHero",
  child: Image.network("https://via.placeholder.com/150"),
)

Next screen:

Hero(
  tag: "imageHero",
  child: Image.network("https://via.placeholder.com/600"),
)

4. Fade-In Screens

Instead of instantly appearing, the screen fades in smoothly.

This removes the harshness of sudden transitions and creates a more pleasant, polished user experience.

Where to use?

Onboarding
Splash to home
First load screens

class FadeScreen extends StatefulWidget {
  @override
  _FadeScreenState createState() => _FadeScreenState();
}

class _FadeScreenState extends State<FadeScreen> {
  double opacity = 0;

  @override
  void initState() {
    super.initState();
    Future.delayed(Duration(milliseconds: 200), () {
      setState(() => opacity = 1);
    });
  }

  @override
  Widget build(BuildContext context) {
    return AnimatedOpacity(
      duration: Duration(milliseconds: 500),
      opacity: opacity,
      child: Scaffold(
        body: Center(child: Text("Welcome")),
      ),
    );
  }
}

5. Smooth List Insert / Remove

When items are added or removed, they animate smoothly instead of just appearing or disappearing.

This makes the changes feel more natural and easier to follow.

Where to use?

Chat apps
Todo lists
Notifications

AnimatedList(
  initialItemCount: items.length,
  itemBuilder: (context, index, animation) {
    return SizeTransition(
      sizeFactor: animation,
      child: ListTile(
        title: Text(items[index]),
      ),
    );
  },
)

6. Page Transitions (Custom Navigation)

This controls how screens transition when navigating between them.

While default transitions work fine, custom ones can make the experience feel smoother and more intentional.

Where to use?

Screen navigation
Onboarding flows

Navigator.push(
  context,
  PageRouteBuilder(
    pageBuilder: (_, __, ___) => NextScreen(),
    transitionsBuilder: (_, animation, __, child) {
      return FadeTransition(
        opacity: animation,
        child: child,
      );
    },
  ),
);

7. Toggle UI Animations

The switch smoothly slides and updates its color when toggled.

This clear visual feedback helps users instantly understand the current state, making interactions feel more intuitive.

Where to use?

Settings
Filters
Feature toggles

class ToggleAnimation extends StatefulWidget {
  @override
  _ToggleAnimationState createState() => _ToggleAnimationState();
}

class _ToggleAnimationState extends State<ToggleAnimation> {
  bool isOn = false;

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: () => setState(() => isOn = !isOn),
      child: AnimatedContainer(
        duration: Duration(milliseconds: 300),
        width: 60,
        height: 30,
        decoration: BoxDecoration(
          color: isOn ? Colors.green : Colors.grey,
          borderRadius: BorderRadius.circular(20),
        ),
        alignment: isOn ? Alignment.centerRight : Alignment.centerLeft,
        child: Padding(
          padding: EdgeInsets.all(4),
          child: CircleAvatar(radius: 10),
        ),
      ),
    );
  }
}

8. Tween Animation (Advanced Control)

This approach lets you animate values such as size, position, or opacity from one state to another.

It offers much finer control, making it ideal for cases where built-in animation widgets don't quite meet your needs.

Where to use?

Custom animations
Complex UI interactions

class TweenExample extends StatefulWidget {
  @override
  _TweenExampleState createState() => _TweenExampleState();
}

class _TweenExampleState extends State<TweenExample>
    with SingleTickerProviderStateMixin {
  late AnimationController controller;
  late Animation<double> animation;

  @override
  void initState() {
    super.initState();

    controller = AnimationController(
      duration: Duration(seconds: 1),
      vsync: this,
    );

    animation = Tween<double>(begin: 0, end: 200).animate(controller);

    controller.forward();
  }

  @override
  Widget build(BuildContext context) {
    return AnimatedBuilder(
      animation: animation,
      builder: (_, child) {
        return Container(
          width: animation.value,
          height: 50,
          color: Colors.blue,
        );
      },
    );
  }

  @override
  void dispose() {
    controller.dispose();
    super.dispose();
  }
}

Common Mistakes Beginners Make

Overusing animations

Just because you can animate something doesn't mean you should.

If everything is moving, nothing really stands out - and the UI starts to feel noisy instead of smooth.

Making animations too slow

Long animations often feel frustrating instead of smooth.

In most cases, anything above ~500ms starts to feel laggy and hurts the experience.

No consistency in motion

If every screen uses a different animation style, the app starts to feel disconnected.

Consistency in motion is just as important as consistency in colors or fonts.

Ignoring performance

Animations can get expensive if not handled carefully.

Avoid rebuilding heavy widgets unnecessarily while animations are running - it can quickly impact performance.

Final Thoughts

If you're just starting with Flutter animations, don't jump to plugins.

Start with:

AnimatedContainer
AnimatedOpacity
Hero
AnimatedList
Tween + AnimationController

These alone can help you build smooth, production-level UI.

From our experience, mastering these basics gives you:

Better control
Cleaner code
More confidence

And honestly most apps don't need more than this.