flutter-adaptive-ui

name

flutter-adaptive-ui

description

Build adaptive and responsive Flutter UIs that work beautifully across all platforms and screen sizes. Use when creating Flutter apps that need to adapt layouts based on screen size, support multiple platforms including mobile tablet desktop and web, handle different input devices like touch mouse and keyboard, implement responsive navigation patterns, optimize for large screens and foldables, or use Capability and Policy patterns for platform-specific behavior.

Flutter Adaptive UI

Overview

Create Flutter applications that adapt gracefully to any screen size, platform, or input device. This skill provides comprehensive guidance for building responsive layouts that scale from mobile phones to large desktop displays while maintaining excellent user experience across touch, mouse, and keyboard interactions.

Quick Reference

Core Layout Rule: Constraints go down. Sizes go up. Parent sets position.

3-Step Adaptive Approach:

1. Abstract - Extract common data from widgets
2. Measure - Determine available space (MediaQuery/LayoutBuilder)
3. Branch - Select appropriate UI based on breakpoints

Key Breakpoints:

• Compact (Mobile): width < 600
• Medium (Tablet): 600 <= width < 840
• Expanded (Desktop): width >= 840

Adaptive Workflow

Follow the 3-step approach to make your app adaptive.

Step 1: Abstract

Identify widgets that need adaptability and extract common data. Common patterns:

• Navigation UI (switch between bottom bar and side rail)
• Dialogs (fullscreen on mobile, modal on desktop)
• Content lists (reflow from single to multi-column)

For navigation, create a shared Destination class with icon and label used by both NavigationBar and NavigationRail.

Step 2: Measure

Choose the right measurement tool:

MediaQuery.sizeOf(context) - Use when you need app window size for top-level layout decisions

• Returns entire app window dimensions
• Better performance than MediaQuery.of() for size queries
• Rebuilds widget when window size changes

LayoutBuilder - Use when you need constraints for specific widget subtree

• Provides parent widget's constraints as BoxConstraints
• Local sizing information, not global window size
• Returns min/max width and height ranges

Example:

// For app-level decisions
final width = MediaQuery.sizeOf(context).width;

// For widget-specific constraints
LayoutBuilder(
  builder: (context, constraints) {
    if (constraints.maxWidth < 600) {
      return MobileLayout();
    }
    return DesktopLayout();
  },
)

Step 3: Branch

Apply breakpoints to select appropriate UI. Don't base decisions on device type - use window size instead.

Example breakpoints (from Material guidelines):

class AdaptiveLayout extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final width = MediaQuery.sizeOf(context).width;
    
    if (width >= 840) {
      return DesktopLayout();
    } else if (width >= 600) {
      return TabletLayout();
    }
    return MobileLayout();
  }
}

Layout Fundamentals

Understanding Constraints

Flutter layout follows one rule: Constraints go down. Sizes go up. Parent sets position.

Widgets receive constraints from parents, determine their size, then report size up to parent. Parents then position children.

Key limitation: Widgets can only decide size within parent constraints. They cannot know or control their own position.

For detailed examples and edge cases, see layout-constraints.md.

Common Layout Patterns

Row/Column

• Row arranges children horizontally
• Column arranges children vertically
• Control alignment with mainAxisAlignment and crossAxisAlignment
• Use Expanded to make children fill available space proportionally

Container

• Add padding, margins, borders, background
• Can constrain size with width/height
• Without child/size, expands to fill constraints

Expanded/Flexible

• Expanded forces child to use available space
• Flexible allows child to use available space but can be smaller
• Use flex parameter to control proportions

For complete widget documentation, see layout-basics.md and layout-common-widgets.md.

Best Practices

Design Principles

Break down widgets

• Create small, focused widgets instead of large complex ones
• Improves performance with const widgets
• Makes testing and refactoring easier
• Share common components across different layouts

Design to platform strengths

• Mobile: Focus on capturing content, quick interactions, location awareness
• Tablet/Desktop: Focus on organization, manipulation, detailed work
• Web: Leverage deep linking and easy sharing

Solve touch first

• Start with great touch UI
• Test frequently on real mobile devices
• Layer on mouse/keyboard as accelerators, not replacements

Implementation Guidelines

Never lock orientation

• Support both portrait and landscape
• Multi-window and foldable devices require flexibility
• Locked screens can be accessibility issues

Avoid device type checks

• Don't use Platform.isIOS, Platform.isAndroid for layout decisions
• Use window size instead
• Device type ≠ window size (windows, split screens, PiP)

Use breakpoints, not orientation

• Don't use OrientationBuilder for layout changes
• Use MediaQuery.sizeOf or LayoutBuilder with breakpoints
• Orientation doesn't indicate available space

Don't fill entire width

• On large screens, avoid full-width content
• Use multi-column layouts with GridView or flex patterns
• Constrain content width for readability

Support multiple inputs

• Implement keyboard navigation for accessibility
• Support mouse hover effects
• Handle focus properly for custom widgets

For complete best practices, see adaptive-best-practices.md.

Capabilities and Policies

Separate what your code can do from what it should do.

Capabilities (what code can do)

• API availability checks
• OS-enforced restrictions
• Hardware requirements (camera, GPS, etc.)

Policies (what code should do)

• App store guidelines compliance
• Design preferences
• Platform-specific features
• Feature flags

Implementation Pattern

// Capability class
class Capability {
  bool hasCamera() {
    // Check if camera API is available
    return Platform.isAndroid || Platform.isIOS;
  }
}

// Policy class
class Policy {
  bool shouldShowCameraFeature() {
    // Business logic - maybe disabled by store policy
    return hasCamera() && !Platform.isIOS;
  }
}

Benefits:

• Clear separation of concerns
• Easy to test (mock Capability/Policy independently)
• Simple to update when platforms evolve
• Business logic doesn't depend on device detection

For detailed examples, see adaptive-capabilities.md and capability_policy_example.dart.

Examples

Responsive Navigation

Switch between bottom navigation (small screens) and navigation rail (large screens):

Widget build(BuildContext context) {
  final width = MediaQuery.sizeOf(context).width;
  
  return width >= 600 
    ? _buildNavigationRailLayout()
    : _buildBottomNavLayout();
}

Complete example: responsive_navigation.dart

Adaptive Grid

Use GridView.extent with responsive maximum width:

LayoutBuilder(
  builder: (context, constraints) {
    return GridView.extent(
      maxCrossAxisExtent: constraints.maxWidth < 600 ? 150 : 200,
      // ...
    );
  },
)

Resources

Reference Documentation

• layout-constraints.md - Complete guide to Flutter's constraint system with 29 examples
• layout-basics.md - Core layout widgets and patterns
• layout-common-widgets.md - Container, GridView, ListView, Stack, Card, ListTile
• adaptive-workflow.md - Detailed 3-step adaptive design approach
• adaptive-best-practices.md - Design and implementation guidelines
• adaptive-capabilities.md - Capability/Policy pattern for platform behavior

Example Code

• responsive_navigation.dart - NavigationBar ↔ NavigationRail switching
• capability_policy_example.dart - Capability/Policy class examples

Scripts

This skill currently has no executable scripts. All guidance is in reference documentation.

Assets

This skill includes complete Dart example files demonstrating:

• Responsive navigation patterns
• Capability and Policy implementation
• Adaptive layout strategies

These assets can be copied directly into your Flutter project or adapted to your needs.