DEV Community: Abdur Rafay Saleem

Building a Robust Local Storage Service in Flutter

Abdur Rafay Saleem — Mon, 23 Dec 2024 23:46:26 +0000

Modern mobile applications often need to store various types of data locally - from user preferences to authentication tokens. While Flutter provides SharedPreferences for basic storage and FlutterSecureStorage for encrypted storage, managing these effectively in a large application requires careful architectural planning.

In this article, we'll explore how to build a robust key-value storage system that separates concerns, provides type safety, and makes storage operations maintainable and secure.

The Two-Layer Architecture

Our implementation uses a two-layer architecture:

KeyValueStorageBase: A low-level base class that directly interfaces with storage plugins
KeyValueStorageService: A high-level service that provides typed, domain-specific storage operations

Why Two Layers?

This separation serves several important purposes:

Separation of Concerns
- Base class is more generic and handles raw storage operations
- Service class handles business logic and data transformation according to the app domain
- Clear boundary between storage mechanism and business logic
Single Responsibility
- Base class: How to store and retrieve data
- Service class: What to store and when as well as managing the keys.
Dependency Isolation
- Only the base class knows about SharedPreferences and FlutterSecureStorage
- Application code only interacts with the service layer

The Base Layer: KeyValueStorageBase

Let's look at our base class key_value_storage_base.dart implementation:

Initialization

WidgetsBinding.ensureInitialized();
...
// For preparing the key-value mem cache
await KeyValueStorageBase.init();
...
runApp();

The init() method is a crucial part of our base layer design. By initializing both storage systems (SharedPreferences and FlutterSecureStorage) at app startup, we ensure that the storage instances are ready before any part of the app tries to access them. It allows us to perform synchronous reads from SharedPreferences throughout our app's lifecycle.

Without this initialization pattern, we'd need to handle async operations for every read operation, which would significantly complicate our storage API and force unnecessary complexity onto the rest of our application code. This "initialize once, use synchronously" pattern is particularly valuable for accessing critical data like user authentication state or app configuration during app startup.

Key Features of the Base Layer

Unified Storage Interface

   T? getCommon<T>(String key)
   Future<String?> getEncrypted(String key)
   Future<bool> setCommon<T>(String key, T value)
   Future<bool> setEncrypted(String key, String value)

Type-Safe Operations

   T? getCommon<T>(String key) {
     return switch (T) {
       const (String) => _sharedPrefs!.getString(key) as T?,
       const (List<String>) => _sharedPrefs!.getStringList(key) as T?,
       const (int) => _sharedPrefs!.getInt(key) as T?,
       const (bool) => _sharedPrefs!.getBool(key) as T?,
       const (double) => _sharedPrefs!.getDouble(key) as T?,
       _ => _sharedPrefs!.get(key) as T?
     };
   }

Error Handling

   try {
     return _secureStorage!.read(key: key);
   } on PlatformException catch (ex) {
     appLogger.debug('$ex');
     return Future<String?>.value();
   }

The Service Layer: KeyValueStorageService

The service layer provides domain-specific storage operations:

Key Features of the Service Layer

Domain-Specific Operations
- Methods map directly to business needs
- Handles serialization/deserialization
- Provides type safety at the domain level
Centralized Key Management

   static const _authTokenKey = 'authToken';
   static const _authUserKey = 'authUserKey';

Intelligent Storage Decisions
- Sensitive data uses encrypted storage
- Regular data uses shared preferences
Bulk Operations

   void clearUserData() {
     _keyValueStorage
       ..removeCommon(_authUserKey)
       ..removeCommon(_firstMapLoadKey)
       ..removeEncrypted(_authTokenKey);
   }

Benefits of This Architecture

Type Safety
- Compile-time type checking for stored values
- Domain models are properly serialized/deserialized
Security
- Clear separation between secure and non-secure storage
- Encrypted storage for sensitive data
- Centralized security decisions
Maintainability
- Single source of truth for storage operations
- Easy to add new storage operations
- Consistent error handling
Testability
- Base class can be mocked for testing
- Service layer can be tested independently
- Clear boundaries for unit tests
Performance
- Async operations where needed
- Synchronous operations where possible
- Background execution for non-critical writes

Usage in Application Code

The service is easily accessible through a Riverpod provider:

final keyValueStorageServiceProvider = Provider((ref) {
  return KeyValueStorageService();
});

// In application code
final user = ref.read(keyValueStorageServiceProvider).getAuthUser();

However, you don't have to use riverpod and you can easily change it to some other DI service or simply make it a singleton pattern as well.

Conclusion

This two-layer architecture provides a robust foundation for key-value storage in Flutter applications. By following this pattern you create a clean, maintainable, and secure storage system that can grow with your application.

Credit

If you like it, please also take a look at the Analytics Service article I wrote to see it in action.

Finally, please keep following me as I will be posting about many more advanced stuff like PermissionService, LocationService, and NotificationService etc.

Flutter Analytics Service using Facade Design Pattern

Abdur Rafay Saleem — Mon, 23 Dec 2024 19:19:29 +0000

Previous Article: Part 3: Implementing PostHog Analytics in Flutter

In this final part, we'll create a unified analytics service that orchestrates multiple analytics clients using the Facade design pattern, demonstrating how to manage complex subsystems through a simplified interface.

Understanding the Facade Pattern

The Facade pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use. In our analytics architecture:

The subsystem consists of multiple analytics clients (Logger, Server, PostHog)
Each client has its own complex implementation and dependencies
The facade (AnalyticsService) provides a single, simplified interface to use all clients

Why Use a Facade?

Simplified Interface: Clients of the analytics system don't need to know about the complexity of multiple analytics providers
Decoupling: The application code is decoupled from specific analytics implementations
Centralized Control: Analytics configuration and dispatching logic is centralized in one place
Easier Testing: The facade can be mocked or replaced easily for testing

The Analytics Facade Implementation

Our AnalyticsService implements the Facade pattern while also adhering to the AnalyticsClientBase contract:

class AnalyticsService implements AnalyticsClientBase {
  // List of analytics clients managed by the facade
  static const _clients = [
    if (AppConfig.isDebug) LoggerAnalyticsClient(),
    if (AppConfig.isStaging) ServerAnalyticsClient(...) // insert your api service or dio/http etc.
    if (AppConfig.isProd) PosthogAnalyticsClient(),
  ];

  // Singleton instance
  static const instance = AnalyticsService._();
  const AnalyticsService._();

  // Local storage for analytics preferences
  static const _collectUsageStatisticsKey = 'collectUsageStatisticsKey';
  static const _keyValueStorage = KeyValueStorageBase.instance;

It has the following characteristics:

Implements the base contract to ensure the unified service contains all methods that the clients have.
The _clients list contains all of the client implementations we wanna use. Analytics will be sent to all these for their own handling.
We can add/remove the clients based on our debug/dev/prod logic.

Managing Analytics State

The facade handles analytics state management using KeyValueStorageService, which is just a wrapper around SharedPreferences. You can read about it here in a seperate guide. Here's how it handles collection:

  void _setCollectUsageStatistics(bool value) {
    _keyValueStorage.setCommon(_collectUsageStatisticsKey, value);
  }

  bool get collectUsageStatistics {
    return _keyValueStorage.getCommon(_collectUsageStatisticsKey) ?? true;
  }

@override
Future<void> toggleAnalyticsCollection(bool enabled) {
  _setCollectUsageStatistics(enabled);
  return _dispatch(
    (c) => c.toggleAnalyticsCollection(enabled),
  );
}

The Dispatch Method

The key to our facade is the _dispatch method which is used by every overriden method in the service:

Future<void> _dispatch(
  Future<void> Function(AnalyticsClientBase client) work,
) async {
  final worksList = _clients.map(work).toList();
  await Future.wait(worksList);
}

This method:

Takes a function that operates on an analytics client
Applies that function to all registered clients
Runs all operations concurrently
Waits for all operations to complete

Using the Facade

The facade makes analytics calls simple and consistent:

// In application code
void onUserAction() {
  AnalyticsService.instance.trackButtonPressed(
    'submit_button',
    {'screen': '/checkout'},
  );
}

Code

Here is the full code for the service:

Benefits of the Facade Pattern

Single Point of Entry: Application code only needs to interact with one service
Concurrent Execution: Analytics events are dispatched to all clients simultaneously for better performance
Implementation Hiding: Clients of the facade don't need to know about the dispatch mechanism. Each client handles its own implementation details.
Error Isolation: Failures in one client don't affect others
Extensibility: New analytics providers can be added without changing existing code based on build configuration.
Easy Testing: The facade can be easily mocked for testing.

Advanced Facade Features

Adding New Analytics Providers

The facade pattern makes it easy to add new analytics providers:

static const _clients = [
  ...
  // Add new clients here
  FirebaseAnalyticsClient(),
  MixpanelAnalyticsClient(),
];

Conditional Client Activation

The facade can conditionally activate clients based on configuration:

static List<AnalyticsClientBase> _getClients() {
  return [
    if (AppConfig.isDebug) LoggerAnalyticsClient(),
    if (AppConfig.isProd) PosthogAnalyticsClient(),
    if (AppConfig.isStaging) ServerAnalyticsClient(),
  ];
}

Error Handling

The facade can implement centralized error handling. I haven't done this for the sole reason that I don't care about catching errors on logs. If you want to, here's how you do it:

Future<void> _dispatch(
  Future<void> Function(AnalyticsClientBase client) work,
) async {
  try {
    final worksList = _clients.map((client) async {
      try {
        await work(client);
      } catch (e) {
        // Handle individual client errors
        appLogger.error('Analytics client error', e);
      }
    }).toList();
    await Future.wait(worksList);
  } catch (e) {
    // Handle catastrophic errors
    appLogger.error('Analytics dispatch error', e);
  }
}

Event Batching

The facade could implement event batching for better performance. However, Posthog does batch dispatching internally, so I avoided re-inventing the wheel:

class AnalyticsService implements AnalyticsClientBase {
  final _eventQueue = <AnalyticsEvent>[];

  Future<void> _batchDispatch() async {
    if (_eventQueue.isEmpty) return;

    final events = [..._eventQueue];
    _eventQueue.clear();

    await _dispatch((client) => client.trackBatchEvents(events));
  }
}

Conclusion

Our analytics architecture demonstrates several key software design principles:

How to simplify complex subsystems
Abstract base classes for contract enforcement
Interface segregation for clean client implementations
Maintain flexibility while providing a consistent API
Handle cross-cutting concerns like error handling and performance

This robust foundation allows for easy addition of new analytics providers while maintaining clean, maintainable code. The facade pattern proves particularly valuable in analytics implementations where multiple providers need to coexist without increasing complexity for the rest of the application.

Credits

If you like it, please keep following me as I will be posting about many more advanced stuff like PermissionService, LocationService, and NotificationService etc.

Implementing Posthog Analytics in Flutter Tutorial

Abdur Rafay Saleem — Mon, 23 Dec 2024 09:52:32 +0000

Previous Article: Part 2: Implementing Logger and Server Analytics

PostHog is a powerful open-source analytics platform that provides comprehensive user behavior tracking. In this article, we'll implement PostHog analytics in Flutter using our analytics architecture.

PostHog Setup

You need to follow the following series of steps in order to prepare posthog for flutter.

1. PostHog account creation

Visit Posthog Website and signup to create your account using either email, google, or github etc.

2. Project setup

Once you open you new account, you will see a default project already opened.

Click the dropdown arrow next to its name > Click the gear icon to open settings.
Set a custom name for your project.
Scroll down and copy the API_KEY value
Also note the if the region is US or EU

3. Flutter package setup + configuration

Add the package posthog_flutter to your pubspec.yaml.
Add the following line to your AndroidManifest.xml inside <application> tags

<application>
....
    <meta-data android:name="com.posthog.posthog.AUTO_INIT" android:value="false" />
</application>

The reason we are disabling AUTO_INIT is because we will provide the config inside flutter code. That allows us to apply dynamic logic for flavors.

Do the same for ios inside Info.plist file:

<dict>
    ....
    <key>com.posthog.posthog.AUTO_INIT</key>
    <false/>
</dict>

In main.dart or whatever your entry file is, add the following code:

import 'package:posthog_flutter/posthog_flutter.dart';
....
Future<void> main() async {
  WidgetsBinding.ensureInitialized();
  final config = PostHogConfig(`<YOUR_API_KEY>`)
    ..debug = true
    ..captureApplicationLifecycleEvents = true // Allows tracking backgrounded, foregrounded etc. events
    ..host = 'https://us.i.posthog.com'; // or for EU Region 'https://eu.i.posthog.com'
  await Posthog().setup(config);

  runApp();
}

PostHog Analytics Implementation

Our PosthogAnalyticsClient implements the AnalyticsClientBase contract while utilizing PostHog's specific APIs:

Key Features

User identification
Event tracking
Screen tracking
Custom properties
User properties
Session management

Attaching user to analytic events

When you originally track events, they are done so anonymously. Posthog provides methods to attach events to users and maintain nice sessions. To attach events to logged in user, you can use the identify() method:

await Posthog().identify(
   userId: userId,
   userProperties: { // optional
     'email': email,
     'role': role,
   },
)

After this, all tracked events will automatically be attached to your logged in user, based on their userId. If you want to logout user then make sure to call reset() so you can identify the next logged in user.

await Posthog().reset();

Tracking Screen Views

If you want to track screen changes use:

_posthog.screen(
  screenName: routeName,
  properties: {'action': action},
)

Custom Events

Or for custom events use:

_posthog.capture(
  eventName: 'button_pressed',
  properties: {
    'button_name': buttonName,
    ...?data,
  },
);

Implementation Notes

Using posthog this way allows maximum flexibility and a nice wrapper around the original methods.

Coming Up Next

In Part 4: Creating a Unified Analytics Service Facade, we'll bring everything together with a facade service that manages multiple analytics clients seamlessly.

Implementing Logger and Server Analytics in Flutter

Abdur Rafay Saleem — Mon, 23 Dec 2024 09:06:47 +0000

Previous Article: Part 1: Building a Robust Analytics Architecture in Flutter

Now that we have our analytics foundation in place, let's implement two concrete analytics clients: a logger client for development and a server client for custom backend analytics.

App Logger Service

First we will setup our logging service using the logger package. Here is the code for a service wrapper around this package:

import 'package:clock/clock.dart';
import 'package:logger/logger.dart';

final appLogger = LogService.forClass('[DEBUG]', level: Level.debug);

class LogService {
  final Logger _logger;

  const LogService(this._logger);

  LogService.forClass(
    String className, {
    Level? level,
  }) : _logger = Logger(
          printer: _SimpleLogPrinter(className),
          level: level,
        );

  void debug(dynamic message, {StackTrace? stackTrace}) =>
      _logger.d(message, stackTrace: stackTrace);
  void info(dynamic message) => _logger.i(message);
  void error(dynamic message) => _logger.e(message);
  void warn(dynamic message) => _logger.w(message);
  void verbose(dynamic message) => _logger.t(message);
  void wtf(dynamic message) => _logger.f(message);
}

class _SimpleLogPrinter extends PrettyPrinter {
  final String className;

  _SimpleLogPrinter(this.className);

  @override
  List<String> log(LogEvent event) {
    final level = event.level;
    final color = PrettyPrinter.defaultLevelColors[level]!;
    final emoji = PrettyPrinter.defaultLevelEmojis[level];
    final message = event.message as Object?;
    final date = clock.now();
    var msg = '${date.year}/${date.month}/${date.day}';
    msg += ' ${date.hour}:${date.minute}:${date.second}';
    msg += ' $message';
    return [color('$emoji $className - $msg')];
  }
}

This wrapper allow nicely formatted messages to be logged to the console and also provides utility methods to log events of different priorities.

Finally there is a global appLogger that we use for debugging purposes.

Logger Analytics Client

The LoggerAnalyticsClient is a development-focused implementation that logs all analytics events to the console:

class LoggerAnalyticsClient implements AnalyticsClientBase {
  const LoggerAnalyticsClient();

  @override
  Future<void> trackEvent(String eventName, [Map<String, Object>? eventData]) async {
    appLogger.debug('trackEvent($eventName, $eventData)');
  }
  // ... other implementations
}

This client has the following characteristics:

Implement the AnalyticsClientBase class to be injectable later on.
Override all the contract methods to provide own logic for logging using the appLogger.

This implementation serves several purposes:

Development debugging and testing
Documentation of analytics events in logs
Verification of analytics integration during development

Benefits of Logger Analytics

Immediate feedback during development
No external service dependencies for testing
Clear visibility of all tracked events
Easy debugging of analytics implementation

The full code for the service is found here:

Server Analytics Client

The ServerAnalyticsClient sends analytics data to your custom backend:

class ServerAnalyticsClient implements AnalyticsClientBase {
  final ApiService _apiService;

  const ServerAnalyticsClient(this._apiService);

  @override
  Future<void> trackEvent(String eventName, [Map<String, Object>? eventData]) async {
    return _apiService.setData(
      endpoint: '/analytics',
      data: {
        'event': eventName,
        'data': eventData,
      },
      converter: (res) => res.headers.isSuccess,
    );
  }
  // ... other implementations
}

This client has the same characteristics as above:

Implement the AnalyticsClientBase class to be injectable later on.
Override all the contract methods to provide own logic for sending analytics to the backend using your own api service.

It uses my custom implementation of ApiService that I have explained in detail in my Clean Flutter Networking Architecture series. Or you can customize it to use either the Dio or http package for simplicity.

Server Analytics Features

Custom backend integration
Full control over analytics data
Consistent event format
Error handling and response validation
Dependency injection for API service

Here is the entire code for the client:

Design Pattern Benefits

Both implementations demonstrate the power of our base class approach:

Consistent Interface: Both clients implement the same methods, ensuring consistent usage
Implementation Freedom: Each client handles events in its own way while maintaining the contract
Single Responsibility: Each client focuses on its specific analytics target
Easy Testing: Mock implementations can be created for testing
Open Closed Principle: New services can be added by simple implementation of the interface, without modifying existing code.

Coming Up Next

In Part 3: Implementing PostHog Analytics in Flutter, we'll integrate PostHog, a popular open-source analytics platform. We'll cover PostHog setup, configuration, and implementation details.

Flutter Analytics Like Production

Abdur Rafay Saleem — Mon, 23 Dec 2024 08:34:02 +0000

Part 1: Building a Robust Analytics Service in Flutter

Analytics is a crucial part of any production application, helping teams understand user behavior, track important metrics, and make data-driven decisions. However, implementing analytics properly requires careful architectural planning to ensure maintainability, extensibility, and clean separation of concerns.

There are several tutorials out there showing how to setup analytics in flutter but lets be honest, they are all just a mess of random buggy functions and lead to spagetti code. Moreoever, they are so strongly focused on one platform that it leads to more painful refactoring down the line for adding more services. In reality, such tutorials are of no great value while making production quality apps.

In this series, we'll build a robust analytics system for Flutter applications that can handle multiple analytics providers while maintaining clean, maintainable code. This is how it is done by professionals in the industry and how you should do it too.

We'll start by establishing a solid foundation with a base analytics client.

The Analytics Contract

At the heart of our analytics architecture is the AnalyticsClientBase abstract class. This class serves as a contract that all analytics implementations must follow:

abstract class AnalyticsClientBase {
  Future<void> toggleAnalyticsCollection(bool enabled);
  Future<void> identifyUser({
    required String userId,
    required String email,
    required String role,
  });
  Future<void> resetUser();
  // ... other methods
}

This abstract class defines a comprehensive set of tracking methods that cover common analytics scenarios:

User identification and session management
Screen views and navigation tracking
UI interaction events (button presses, dialogs, bottom sheets)
App lifecycle events (foreground/background)
Permission tracking
Custom events with additional data

Here is the full code:

Why Use an Abstract Base Class?

The AnalyticsClientBase serves several important purposes:

Contract Enforcement: Any new analytics implementation must implement all required tracking methods, ensuring consistency across different providers.
Type Safety: The abstract class provides compile-time type checking and clear method signatures.
Dependency Inversion: Our application code depends on the abstract interface rather than concrete implementations.
Easy Integration: New analytics providers can be added by simply implementing the base class, without changing existing code.

For example, if we want to track a button press, our UI code only needs to know about the abstract interface:

void onButtonPressed(AnalyticsClientBase aClient) {
  aClient.trackButtonPressed('submit_button', {'screen': 'checkout'});
}

This code remains unchanged regardless of whether we're using Firebase Analytics, PostHog, or any other analytics provider.

Key Methods Explained

Let's look at some key methods in our analytics contract:

identifyUser: Associates analytics events with a specific user, typically called after login
resetUser: Clears user association, usually called during logout
trackScreenView: Monitors navigation patterns with additional context about the action
trackButtonPressed: Used to log button interactions by the user. We can pass in a button name and other things as data like screen, enable/disable etc. This way we add a lot of insightful context to the event.
trackEvent: A flexible method for custom events with optional key-value data

Similarly, we have many more methods for some common tasks. You can adjust these as per your own requirements or add more if you want to track more things like scroll_event, swipe_event etc.

Each method is designed to be future-proof and flexible enough to work with various analytics providers.

Coming Up Next

In Part 2: Implementing Logger and Server Analytics, we'll create our first two concrete implementations of this contract:

A debug logger client for development
A server-side analytics client for custom backend tracking

We'll see how these implementations leverage our base class while providing their own unique functionality.

CustomFormField - Custom Widgets Series

Abdur Rafay Saleem — Sun, 22 Dec 2024 22:52:56 +0000

Welcome to another article for my Custom Widgets Series. In this series I share some tips and code about creating reusable and advanced flutter widgets. These widgets are used by me and many professionals out there in production level flutter apps. Now they are available to you!

Introduction
Usage
Code
Credits

Introduction

Are you tired of dealing with the complexities of form fields in Flutter? Do you wish there was a simpler way to handle form validation, error styling, and value changes without writing tons of boilerplate code or messing with the Form API? I designed my own custom widget to make form handling in Flutter a breeze.

I recently shared some screenshots of forms from my Famony app on X(twitter).

These forms contained validations for different field types like dropdowns, textfields, date picker, gender cards etc. You can see in the image below:

Many people inboxed me asking how I was able to do that since not every widget has validations and it gets very messy to sync them all.

CustomFormField ✨

Introducing the CustomFormField widget, wrapper around FormField widget that takes in validation, onSaved, onChanged callbacks etc.

With CustomFormField, you can easily manage form validation, error display, and value changes with minimal effort. No more struggling with the default FormField API to achieve basic functionality. It provides a clean and intuitive way to handle form fields, allowing you to focus on building great user experiences.

It has built-in support for validation errors which you can style as you want. Just wrap any child to add validation without worrying about form reactive logic. You can see the it in the example below.

CustomValueListener

The CustomFormField needs a way to keep the form in sync and allow updating it from anywhere using a controller. Since the field can be of dynamic nature, the most suitable option for a controller was a ValueNotifier<T>, where <T> is the type you pass to your CustomFormField<T>. In order to listen to this custom controller we needed a custom listener widget as well.

The CustomValueListener widget is essential for efficiently managing state changes in the CustomFormField. It listens to a ValueNotifier and triggers updates whenever the value changes, ensuring that the form field's state is kept in sync. This separation of concerns simplifies the code, making it cleaner and more maintainable. Additionally, it handles the lifecycle of the listener, adding it during initialization and removing it upon disposal, which prevents memory leaks and ensures optimal performance. This approach allows for a more responsive and dynamic form handling experience in Flutter.

Code

Here is the crux of it all, the code for this amazing widget. I decided to place it at the end to avoid confusion, because it was important to see the usage and benefits before the implementation. I have included it as gist so I can update it in the future, if needed.

Credits

If you like it, please keep following me as I have around 40 such widgets and I will post many more of these.

CustomText - Custom Widget Series

Abdur Rafay Saleem — Sun, 22 Dec 2024 05:39:55 +0000

Introduction
Usage
Code
Credits

Introduction

Are you guys tired of writing down the Text widget in flutter with tedious amount of boilerplate for even the simplest of styling? Do you wish you didn't have to touch the TextStyle for just changing one or two fields? Now there is a way to quickly create fixed style texts, with much simpler properties.

Moreover, I am sure you have struggled with the RichText API to just print simple multi styled text or make a certain link clickable without affecting the rest of the para. This widget introduces simple and intuitive ways to make that happen. You won't ever need to touch RichText again.

CustomText ✨

A wrapper around Text widget to directly pass in frequent properties like:

color
font size
font weight
max lines

etc. without creating seperate TextStyle. You can see the it in the example below.

CustomText(
  message ?? 'FindingJobsNearYou',
  fontSize: 18,
  letterSpacing: 0.3,
  color: context.colorScheme.onPrimary,
  fontWeight: FontWeight.bold,
),

Style Factories

Moreover, it has factories for different styles like .body(), .subtitle(), and .title(). They have certain font sizes, weights and colors predefined according to my choice so I can use them in a plug n play fashion.

Column(
  crossAxisAlignment: CrossAxisAlignment.start,
  children: [
    // Title
    CustomText.body(
      title,
      fontWeight: FontWeight.bold,
    ),

    Insets.gapH10,

    // Message
    CustomText.subtitle(
      message,
      maxLines: 3,
    ),

    Insets.gapH10,

    // Time
    CustomText.label(
      time,
      color: context.colorScheme.onSurface.withValues(alpha: 0.6),
    ),
  ],
)

Rich text

Then comes in the heavy lifting factory .rich() for the annoyingly complex RichText.

See how simple the API is? All you have to do is use .rich() factory. You no longer need to fight between Text and TextSpan. Just pass in instance of another CustomText as textWidget. Also, notice the Insets.gap widget? It is a simple SizedBox. You can pass any widget in between the text without worrying about WidgetSpan. And just like that you can create complex text widgets.

Links and clickable text

Very often you want to make a text clickable with some custom callback. You can wrap it with InkWell or similar widgets but it is cumbersome. And, it is even more difficult to make only a part of the text clickable.

Now just pass in isLink: true and onLinkTap() callback to the CustomText or simply use the .link() constructor. See the below example of creating a complex hyperlinked legal statement.

// Legal Links
CustomText.rich(
  text: 'By signing you agree to the ',
  maxLines: 2,
  lineHeight: 1.7,
  fontSize: 14,
  letterSpacing: -0.1,
  textAlign: TextAlign.center,
  children: [
    CustomText.link(
      'Terms',
      fontWeight: FontWeight.bold,
      fontSize: 14,
      letterSpacing: -0.1,
      onLinkTap: () {
        AppUtils.openUrl(AppConstants.termsOfServiceUrl);
      },
    ),
    CustomText.body(
      ' and ',
      fontSize: 14,
      letterSpacing: -0.1,
    ),
    CustomText.link(
      'Privacy Policy',
      fontSize: 14,
      letterSpacing: -0.1,
      fontWeight: FontWeight.bold,
      onLinkTap: () {
        AppUtils.openUrl(AppConstants.privacyPolicyUrl);
      },
    ),
  ],
),

Code

Credits

If you like it, please keep following me as I have around 40 such widgets and I will post many more of these.

DEV Community: Abdur Rafay Saleem

Building a Robust Local Storage Service in Flutter

The Two-Layer Architecture

Why Two Layers?

The Base Layer: KeyValueStorageBase

Initialization

Key Features of the Base Layer

The Service Layer: KeyValueStorageService

Key Features of the Service Layer

Benefits of This Architecture

Usage in Application Code

Conclusion

Credit

Flutter Analytics Service using Facade Design Pattern

Understanding the Facade Pattern

Why Use a Facade?

The Analytics Facade Implementation

Managing Analytics State

The Dispatch Method

Using the Facade

Code

Benefits of the Facade Pattern

Advanced Facade Features

Adding New Analytics Providers

Conditional Client Activation

Error Handling

Event Batching

Conclusion

Credits

Implementing Posthog Analytics in Flutter Tutorial

PostHog Setup

1. PostHog account creation

2. Project setup

3. Flutter package setup + configuration

PostHog Analytics Implementation

Key Features

Attaching user to analytic events

Tracking Screen Views

Custom Events

Implementation Notes

Coming Up Next

Implementing Logger and Server Analytics in Flutter

App Logger Service

Logger Analytics Client

Benefits of Logger Analytics

Server Analytics Client

Server Analytics Features

Design Pattern Benefits

Coming Up Next

Flutter Analytics Like Production

Part 1: Building a Robust Analytics Service in Flutter

The Analytics Contract

Why Use an Abstract Base Class?

Key Methods Explained

Coming Up Next

CustomFormField - Custom Widgets Series

Table of Contents

Introduction

CustomFormField ✨

CustomValueListener

Code

Credits

CustomText - Custom Widget Series

Table of Contents

Introduction

CustomText ✨

Style Factories

Rich text

Links and clickable text

Code

Credits