Skip to content

README.md

Latest commit

 

History

History
269 lines (174 loc) · 10.2 KB

README.md

File metadata and controls

269 lines (174 loc) · 10.2 KB

This is a new React Native project, bootstrapped using @react-native-community/cli.

Getting Started

Note: Make sure you have completed the Set Up Your Environment guide before proceeding.

Step 1: Start Metro

First, you will need to run Metro, the JavaScript build tool for React Native.

To start the Metro dev server, run the following command from the root of your React Native project:

# Using npm
npm start

# OR using Yarn
yarn start

Step 2: Build and run your app

With Metro running, open a new terminal window/pane from the root of your React Native project, and use one of the following commands to build and run your Android or iOS app:

Android

Before the first Android build (and after cloning the repo), vendor the Notifee native core so Gradle compiles it from source instead of downloading app.notifee:core (needed for F-Droid and avoids the notifee.app Maven repo):

npm run vendor:notifee

The checkout under third_party/notifee/ is not committed (it is gitignored). A fresh clone has no :notifee_core sources, so Gradle fails dependency resolution for that project—often with a message like No matching variant of project :notifee_core or No variants exist. Running npm run vendor:notifee (or npm run android, which runs it via the preandroid script) creates that tree. If you build with ./gradlew or npx react-native run-android directly, run npm run vendor:notifee first when third_party/notifee/ is missing.

Then:

# Using npm
npm run android

# OR using Yarn
yarn android

See third_party/README.md for pinning the vendored commit when you upgrade @notifee/react-native.

iOS

For iOS, remember to install CocoaPods dependencies (this only needs to be run on first clone or after updating native deps).

The first time you create a new project, run the Ruby bundler to install CocoaPods itself:

bundle install

Then, and every time you update your native dependencies, run:

bundle exec pod install

For more information, please visit CocoaPods Getting Started guide.

# Using npm
npm run ios

# OR using Yarn
yarn ios

If everything is set up correctly, you should see your new app running in the Android Emulator, iOS Simulator, or your connected device.

This is one way to run your app — you can also build it directly from Android Studio or Xcode.

Step 3: Modify your app

Now that you have successfully run the app, let's make changes!

Open App.tsx in your text editor of choice and make some changes. When you save, your app will automatically update and reflect these changes — this is powered by Fast Refresh.

When you want to forcefully reload, for example to reset the state of your app, you can perform a full reload:

  • Android: Press the R key twice or select "Reload" from the Dev Menu, accessed via Ctrl + M (Windows/Linux) or Cmd ⌘ + M (macOS).
  • iOS: Press R in iOS Simulator.

Congratulations! 🎉

You've successfully run and modified your React Native App. 🥳

Now what?

  • If you want to add this new React Native code to an existing application, check out the Integration guide.
  • If you're curious to learn more about React Native, check out the docs.

WebView Assets Setup

This project includes custom WebView assets that need to be available to the Android app. Here's how the setup works:

Asset Location

  • Source files are located in assets/webview/
  • These files are automatically copied during the build process

Android Configuration

The Android build is configured to:

  1. Copy webview assets during the build process
  2. Make them available at file:///android_asset/webview/ in the WebView

Accessing Assets in Code

Reference the assets in your React Native code like this:

const INJECTION_SCRIPT_PATH =
  Platform.OS === 'ios'
    ? 'FormulusInjectionScript.js'
    : 'file:///android_asset/webview/FormulusInjectionScript.js';

Generating the injection script

The injection script is autogenerated based on the src\webview\FormulusInterfaceDefinition.ts file. To generate the injection script, run the following command:

npm run generate

Development Notes

  • When adding new files to assets/webview/, ensure they are included in the build by:
    1. Running a clean build: cd android && ./gradlew clean && cd ..
    2. Rebuilding the app: npx react-native run-android

The javascript interface that is injected into the webviews and thus exposed to the custom_app (and the formplayer) is autogenerated based on the TypeScript definition in src\webview\FormulusInterfaceDefinition.ts. To generate the injection script, run the following command:

npm run generate

The Synkronus API client is auto generated based on the OpenAPI spec from synkronus

To generate the API client, run the following command:

npm run generate:api

Synchronization considerations

This section describes the design strategy for synchronizing both observation records and their associated attachments in the ODE sync protocol.

The key principle is decoupling metadata sync (observations) from binary payload sync (attachments) to keep the protocol robust, offline-friendly, and simple to implement.

Two-phase sync

We separate sync into two distinct phases:

  • Phase 1: Observation data sync

    • Uses the existing /sync/pull and /sync/push endpoints.
    • Syncs only the observation records as JSON (including references to attachment IDs in their data).

  • Phase 2: Attachment file sync

    • Upload or download attachment files after a successful observation sync.
    • Handles binary data transfers independently
      • Download of attachment is done effeciently by requesting a manifest from the server describing changes since last sync (that included attachments)
      • Upload of attachment is handled as simple as possible, by having a copy all un-synced attachment waiting to be synced in a "pending_uploads" folder within the app's storage. Once uploaded, the file will be removed from the "pending_uploads" folder.

Immutable attachments

  • Attachments are immutable: once uploaded, they cannot change.
  • If an attachment needs to be updated, a new GUID/filename is generated and stored in the observation’s data.
  • This design prevents conflicts and simplifies syncing.

Local attachment tracking table

To optimize client sync and avoid repeatedly checking the entire observation database, the client maintains a local table (e.g. in SQLite or WatermelonDB):

Suggested schema:

Column Type Description
attachment_id String Unique ID (e.g. GUID + extension)
direction String Either 'upload' or 'download'
synced Boolean True if successfully uploaded/downloaded
last_attempt_at Timestamp Optional, for retry logic
error_message String Optional, records the last error if any

This table is client-local only; the server remains agnostic about the client's attachment sync state.

Upload flow

  • When a new observation is saved locally and references a new attachment:

    • Insert a row in the attachment tracking table with direction = 'upload' and synced = false.

  • The client attachment uploader runs periodically:

    • Queries for direction = 'upload' AND synced = false.
    • For each record:
      • Checks that the local file exists.
      • Uploads it to the server.
      • Marks synced = true on success.

Download flow

  • After completing /sync/pull, the client receives new or updated observations.

  • It parses the data field of those records to extract referenced attachment IDs.

  • For each attachment ID:

    • Checks if it's already present locally.
    • If missing, inserts into the tracking table with direction = 'download' and synced = false.

  • The client attachment downloader runs periodically:

    • Queries for direction = 'download' AND synced = false.
    • For each record:
      • Downloads the file from the server.
      • Stores it locally.
      • Marks synced = true on success.

Advantages of this design

  • Keeps observation sync and attachment transfer logically separate.
  • Allows partial or incremental attachment sync.
  • Supports offline-first workflows.
  • Minimizes redundant network checks (no repeated HEAD calls).
  • Enables efficient batching and retry strategies.
  • Server remains stateless regarding which attachments the client has.

Future enhancements

This approach can evolve to support:

  • Hash-based deduplication.
  • Server-side manifests of missing attachments.
  • Bucketed storage layout for server files.
  • Presigned URLs for cloud storage.
  • Attachment lifecycle policies (e.g. pruning old unused files).
  • Per-table or per-schema-type attachment sync versions.

This strategy ensures the MVP implementation is simple yet robust while leaving the door open for sophisticated future features.

Troubleshooting

If you're having issues getting the above steps to work, see the Troubleshooting page.

Learn More

To learn more about React Native, take a look at the following resources: