Offline Support

Relevant source files

The following files were used as context for generating this wiki page:

• src/core/services/offline/offlineManager.js
• TASK_4_SUMMARY.md
• TASK_4_DISCUSSION.md
• src/core/config/features.config.js
• src/services/autoSaveService.js
• src/config/constants.js
• README.md

The Offline Support system is an architectural placeholder designed to provide functionality when the application is not connected to the internet. It is implemented as a singleton, OfflineManager, which handles network status detection, operation queueing, and data caching. The entire feature is controlled by a feature flag and is currently disabled by default.

This system is intended exclusively for mobile, tablet, and desktop platforms and is explicitly disabled on the web. The implementation is present but commented out, awaiting the installation of dependencies like @react-native-community/netinfo and a backend integration to be fully functional.

Sources: src/core/services/offline/offlineManager.js:1-8, TASK_4_SUMMARY.md, README.md

Architecture

The core of the offline support system is the OfflineManager class, which is instantiated as a singleton. This ensures a single, consistent state for network status and queued operations across the application.

Sources: src/core/services/offline/offlineManager.js:10, 201-204

Class Structure

The OfflineManager class encapsulates all logic related to offline handling.

This diagram shows the properties and methods of the OfflineManager singleton.

Sources: src/core/services/offline/offlineManager.js:12-18, 23-198

Configuration

Offline support is managed via a feature flag. It can be enabled or disabled globally without code changes.

Feature Flag Path	Description	Default Value
FEATURES.OFFLINE.ENABLED	Controls whether the OfflineManager initializes and performs any operations.	false (disabled)

To enable the feature, the following steps are required:

1. Install @react-native-community/netinfo.
2. Set ENABLE_OFFLINE_SUPPORT: true in the environment configuration (which likely toggles the feature flag).
3. Uncomment the implementation code within src/core/services/offline/offlineManager.js.

Sources: src/core/config/features.config.js, src/core/services/offline/offlineManager.js:24-27, TASK_4_SUMMARY.md

Platform Specificity

The offline manager is designed to run only on native platforms (iOS, Android) and desktop. It explicitly checks for the web platform and disables itself if detected.

// src/core/services/offline/offlineManager.js:32-35
if (Platform.OS === 'web') {
  console.log('[Offline] Offline support not available on web');
  return;
}

Sources: src/core/services/offline/offlineManager.js:32-35, README.md

Core Functionality

The manager's functionality is divided into network detection, operation queueing, and data caching. All of this logic is currently commented out and serves as a placeholder.

Sources: src/core/services/offline/offlineManager.js, TASK_4_SUMMARY.md

Initialization and Network Detection

The init() method is the entry point for the service. When enabled, it performs the following actions:

1. Loads any previously saved operation queue from AsyncStorage.
2. Attaches a listener to NetInfo to monitor network state changes.
3. When the network state changes, it updates the isOnline property and notifies any registered listeners.
4. If the device comes back online, it triggers processQueue() to sync pending operations.

This diagram illustrates the initialization flow.

Operation Queueing

When the application is offline, actions that require a network connection (e.g., saving a design to the cloud) are not executed immediately. Instead, they are added to a persistent queue.

The addToQueue(operation) method is responsible for this. Each operation is an object containing details about the action to be performed. The queue is then saved to AsyncStorage.

Sources: src/core/services/offline/offlineManager.js:55-68

Queue Processing

When the network connection is restored, processQueue() is called. It iterates through the queued operations and attempts to execute them one by one.

• If an operation succeeds, it is removed from the queue.
• If an operation fails, it remains in the queue to be retried later.

The executeOperation(operation) method contains a switch statement to handle different types of operations, such as SAVE_DESIGN, DELETE_DESIGN, and UPLOAD_IMAGE.

This sequence diagram shows the process of queueing and processing an operation.

Data Caching

To provide a seamless offline experience, the manager includes methods for caching data.

• cacheData(key, data): Saves data to an object in AsyncStorage.
• getCachedData(key): Retrieves previously cached data.

This allows the app to display data (e.g., user designs) even when it cannot be fetched from a server.

Sources: src/core/services/offline/offlineManager.js:125-156

Data Storage

The OfflineManager relies on AsyncStorage for persistence. It uses two primary keys to store its state. This is similar to how other services like autoSaveService persist data locally.

Key	File	Purpose
@eefashionita:offline_queue	offlineManager.js	Stores the array of operations to be executed when the app is back online.
@eefashionita:offline_cache	offlineManager.js	Stores a key-value map of data cached for offline use.
@designs	constants.js	Example of another key used for local persistence by other services.

Sources: src/core/services/offline/offlineManager.js:10-11, src/services/autoSaveService.js, src/config/constants.js:100

Summary

The Offline Support feature is a well-architected but currently unimplemented placeholder. It provides a clear blueprint for handling network-dependent operations in an offline-first manner for mobile and desktop platforms. Key components like the OfflineManager singleton, operation queueing, and data caching are defined but commented out. To make this feature functional, developers must install the required NetInfo dependency, enable the corresponding feature flag, and uncomment the placeholder code.