Developing Native Modules
Relevant source files
The following files were used as context for generating this wiki page:
- artifacts/mobile/modules/silent-switch/index.ts
- artifacts/mobile/modules/silent-switch/expo-module.config.json
- replit.md
- attached_assets/Pasted-Build-a-production-ready-native-iPhone-mobile-app-using_1773627288076.txt
- attached_assets/Pasted-Build-a-complete-new-feature-for-the-Hospice-Roadmap-mo_1774923100510.txt
Developing native modules within the Hospice Roadmap project involves extending the React Native and Expo framework to access platform-specific APIs that are not available through standard JavaScript. The project utilizes a scalable architecture including a dedicated modules directory for native extensions, ensuring that the application can leverage iPhone-specific functionality while maintaining a clean TypeScript interface. Sources: replit.md, attached_assets/Pasted-Build-a-production-ready-native-iPhone-mobile-app-using_1773627288076.txt
This system is designed specifically for the iPhone experience, focusing on high-performance, native-feeling interactions. By creating custom native modules, the app can implement features like hardware switch monitoring (e.g., the silent switch) and other low-level device integrations required for a premium healthcare product. Sources: attached_assets/Pasted-Build-a-production-ready-native-iPhone-mobile-app-using_1773627288076.txt, artifacts/mobile/modules/silent-switch/index.ts
Native Module Architecture
The project follows the Expo Module API pattern to bridge TypeScript code with native Swift or Kotlin implementations. Each module is encapsulated within its own directory under artifacts/mobile/modules/. Sources: artifacts/mobile/modules/silent-switch/expo-module.config.json
Module Structure
A typical native module consists of a configuration file, a TypeScript interface, and the native source code (Swift for iOS).
| Component | File | Purpose |
|---|---|---|
| Config | expo-module.config.json | Defines the native classes and the package name for the module. |
| Interface | index.ts | The TypeScript entry point that exports the native functionality to the rest of the app. |
| Native Implementation | (Swift files) | Contains the actual platform code that interacts with iOS hardware/APIs. |
Sources: artifacts/mobile/modules/silent-switch/expo-module.config.json, artifacts/mobile/modules/silent-switch/index.ts
Initialization Flow
The following diagram illustrates how a native module like silent-switch is initialized and accessed by the application.
The application uses Expo's autolinking to automatically discover and register native modules defined in the configuration files. Sources: artifacts/mobile/modules/silent-switch/expo-module.config.json
Case Study: Silent Switch Module
The silent-switch module provides a specialized interface to detect the hardware silent switch state on an iPhone. This is critical for ensuring that the app respects user preferences regarding sound and haptics in a clinical environment. Sources: artifacts/mobile/modules/silent-switch/index.ts
TypeScript Interface
The module is accessed through a standard TypeScript interface located in index.ts. It utilizes requireNativeModule from the expo-modules-core package.
import { requireNativeModule } from 'expo-modules-core';
// It loads the native module object from the JSI or falls back to a proxy object.
// The name passed to requireNativeModule must match the name defined in native code.
export default requireNativeModule('SilentSwitch');
Sources: artifacts/mobile/modules/silent-switch/index.ts:1-5
Configuration
The native module's identity and its underlying implementation classes are declared in the expo-module.config.json.
| Field | Value | Description |
|---|---|---|
name | SilentSwitch | The name used by TypeScript to require the module. |
ios.modules | ["SilentSwitchModule"] | The Swift class implementing the module logic. |
Sources: artifacts/mobile/modules/silent-switch/expo-module.config.json
Integration with Feature Components
Native modules are integrated into UI components and services to provide enhanced functionality. For example, a legal feature might use native modules to handle document previews or secure link opening. Sources: attached_assets/Pasted-Build-a-complete-new-feature-for-the-Hospice-Roadmap-mo_1774923100510.txt
Sequence of Native Interaction
When a user interacts with a feature requiring native support (like opening an official legal document link), the following sequence occurs:
This flow ensures that the user remains within the secure, native context of the application while performing external actions. Sources: attached_assets/Pasted-Build-a-complete-new-feature-for-the-Hospice-Roadmap-mo_1774923100510.txt
Development Guidelines
- Naming Consistency: Native module names must match exactly across the native implementation, the
expo-module.config.json, and therequireNativeModulecall in TypeScript. Sources: artifacts/mobile/modules/silent-switch/index.ts, artifacts/mobile/modules/silent-switch/expo-module.config.json - Platform Specificity: Focus development on iPhone-native patterns, such as utilizing Swift for iOS-specific hardware interactions. Sources: attached_assets/Pasted-Build-a-production-ready-native-iPhone-mobile-app-using_1773627288076.txt
- Type Safety: Always define TypeScript types for native module exports to ensure compile-time safety and better developer experience. Sources: replit.md
Summary
Developing native modules in Hospice Roadmap allows the application to transcend the limitations of the JavaScript environment. By leveraging the Expo Module API, the project maintains a structured and scalable way to implement hardware-level features like the silent-switch, ensuring a premium, responsive, and medically credible user experience on iPhone. Sources: attached_assets/Pasted-Build-a-production-ready-native-iPhone-mobile-app-using_1773627288076.txt, artifacts/mobile/modules/silent-switch/index.ts