@webority-technologies/mobile-core 0.0.1 → 0.0.3

package/lib/module/network/networkStatus.js

@@ -1,5 +1,6 @@
 "use strict";
 
+import * as ExpoNetwork from 'expo-network';
 import { useEffect, useState } from 'react';
 import { Logger } from "../logger/index.js";
 const DEFAULT_STATUS = {
@@ -7,21 +8,53 @@ const DEFAULT_STATUS = {
   isInternetReachable: null,
   type: 'unknown'
 };
-let netInfo = null;
-let resolved = false;
-const resolveNetInfo = () => {
-  if (resolved) {
-    return netInfo;
-  }
-  resolved = true;
-  try {
-    const mod = require('@react-native-community/netinfo');
-    netInfo = mod.default ?? mod;
-  } catch {
-    Logger.warn('[network] @react-native-community/netinfo is not installed; ' + 'useNetworkStatus() will report a default "online" status.');
-    netInfo = null;
+/**
+ * expo-network is imported directly, not resolved through a seam.
+ *
+ * `expo` is a REQUIRED peer of this package, so every consumer has the Expo
+ * modules by construction and the static-require problem that forced the old
+ * injection design does not arise. An app wires nothing: connectivity works
+ * because the library uses Expo, which is the point of the Expo-first policy.
+ * One backend also means one behaviour, rather than each app choosing.
+ */
+let override = null;
+
+/**
+ * Replace the backend. Intended for TESTS and for the showcase, which uses it
+ * to reach error paths that a healthy device never takes; it is not the way an
+ * app is meant to configure the library. Pass `null` to restore expo-network.
+ */
+export const setNetworkStatusImplementation = impl => {
+  override = impl;
+};
+const resolveNetInfo = () => override ?? expoNetworkBackend;
+
+/**
+ * expo-network in the shape this module already speaks.
+ *
+ * The conversion is not cosmetic: expo reports its type as an UPPERCASE enum
+ * where this module's vocabulary is lowercase, marks every field optional, and
+ * returns an EventSubscription where an unsubscribe function is expected.
+ */
+const expoNetworkBackend = {
+  fetch: async () => {
+    const state = await ExpoNetwork.getNetworkStateAsync();
+    return {
+      isConnected: state?.isConnected !== false,
+      isInternetReachable: state?.isInternetReachable ?? null,
+      type: state?.type ? String(state.type).toLowerCase() : undefined
+    };
+  },
+  addEventListener: cb => {
+    const subscription = ExpoNetwork.addNetworkStateListener(state => {
+      cb({
+        isConnected: state?.isConnected !== false,
+        isInternetReachable: state?.isInternetReachable ?? null,
+        type: state?.type ? String(state.type).toLowerCase() : undefined
+      });
+    });
+    return () => subscription.remove();
   }
-  return netInfo;
 };
 const normalize = state => {
   if (!state) {

package/lib/module/permissions/index.js

@@ -21,6 +21,28 @@ const resolveModule = () => {
   }
   return permsModule;
 };
+
+/**
+ * Inject a custom permissions implementation at runtime.
+ * Pass `null` to reset to the default lazily-resolved native module.
+ *
+ * `resolved` goes FALSE on null, never true. Marking it resolved with a null
+ * backend would permanently disable permissions: the resolver short-circuits and the
+ * real module is never loaded again, which contradicts this function's own
+ * documented contract. That exact bug shipped once, in the storage seam.
+ *
+ * THIS MODULE IS THE EXPO-FIRST EXCEPTION, and deliberately keeps the old
+ * shape. Expo ships no permissions package: each module carries its own
+ * (expo-location's requestForegroundPermissionsAsync, expo-image-picker's, and
+ * so on), so there is no single object to adapt and the library must not guess
+ * which Expo modules an app installed. react-native-permissions stays, behind
+ * this module's own import path so an app that never asks for permissions
+ * never names the package to Metro.
+ */
+export const setPermissionsImplementation = impl => {
+  permsModule = impl;
+  resolved = impl !== null;
+};
 const mapToNative = kind => {
   const m = resolveModule();
   if (!m) {

package/lib/module/sqlite/adapters/expo.js

@@ -0,0 +1,48 @@
+"use strict";
+
+/**
+ * expo-sqlite. Shape verified against 57.0.2 rather than assumed, and it is the
+ * one driver that cannot share an adapter with the others: expo splits reads
+ * from writes. `getAllAsync` yields rows but no change count, `runAsync` yields
+ * `{ changes, lastInsertRowId }` but no rows, and SqliteResultSet needs all
+ * three from one call. `prepareAsync` + `executeAsync` is the only call that
+ * returns both, so every statement goes through it rather than being routed by
+ * sniffing the SQL for a leading SELECT.
+ *
+ * The REQUIRE lives in the driver entry point beside this file, never here.
+ */
+
+export const adaptExpoSqlite = mod => ({
+  // expo takes the directory as a third positional argument rather than an
+  // option, so `location` cannot be passed through the options object.
+  open: async (name, options) => {
+    const db = await mod.openDatabaseAsync(name, undefined, options?.location);
+    return {
+      execute: async (sql, params) => {
+        const statement = await db.prepareAsync(sql);
+        try {
+          const result = await statement.executeAsync(params ? [...params] : []);
+          // Safe on a write: expo returns [] when the statement produced no
+          // first row rather than stepping the statement a second time.
+          const rows = await result.getAllAsync();
+          return {
+            rows,
+            rowsAffected: result.changes,
+            // expo always reports lastInsertRowId, so unlike the other drivers
+            // this is never undefined. It is the connection's last insert rowid,
+            // which is only meaningful immediately after an INSERT.
+            insertId: result.lastInsertRowId
+          };
+        } finally {
+          // A statement left unfinalised holds a native handle for the life of
+          // the connection, and the core executes one per call.
+          await statement.finalizeAsync();
+        }
+      },
+      close: async () => {
+        await db.closeAsync();
+      }
+    };
+  }
+});
+//# sourceMappingURL=expo.js.map

package/lib/module/sqlite/adapters/op.js

@@ -0,0 +1,38 @@
+"use strict";
+
+/**
+ * @op-engineering/op-sqlite. Shape verified against 18.1.4 rather than assumed:
+ * `open({ name, location })` is synchronous and returns a DB whose `execute` is
+ * ASYNC, and whose `rows` is already a plain array of objects rather than the
+ * `{ _array, item() }` shape the older drivers use. Both differences are why it
+ * cannot share the sync adapter.
+ *
+ * The REQUIRE lives in the driver entry point beside this file, never here.
+ */
+
+export const adaptOpSqlite = mod => ({
+  open: async (name, options) => {
+    const db = mod.open({
+      name,
+      location: options?.location
+    });
+    return {
+      execute: async (sql, params) => {
+        const result = await db.execute(sql, params ? [...params] : undefined);
+        return {
+          rows: result.rows ?? [],
+          rowsAffected: result.rowsAffected ?? 0,
+          insertId: result.insertId
+        };
+      },
+      close: async () => {
+        if (db.closeAsync) {
+          await db.closeAsync();
+          return;
+        }
+        db.close();
+      }
+    };
+  }
+});
+//# sourceMappingURL=op.js.map

package/lib/module/sqlite/adapters/rows.js

@@ -0,0 +1,28 @@
+"use strict";
+
+/**
+ * Row shapes differ per driver: a plain array, `{ _array, length, item() }`, or
+ * `{ length, item() }` alone. Every adapter normalises to a plain array here so
+ * nothing driver-specific escapes into the Db layer.
+ */
+export const rowsToArray = rows => {
+  if (Array.isArray(rows)) {
+    return rows;
+  }
+  const shaped = rows;
+  if (!shaped) {
+    return [];
+  }
+  if (Array.isArray(shaped._array)) {
+    return shaped._array;
+  }
+  if (typeof shaped.item === 'function' && typeof shaped.length === 'number') {
+    const out = [];
+    for (let i = 0; i < shaped.length; i += 1) {
+      out.push(shaped.item(i));
+    }
+    return out;
+  }
+  return [];
+};
+//# sourceMappingURL=rows.js.map

package/lib/module/sqlite/adapters/storage.js

@@ -0,0 +1,46 @@
+"use strict";
+
+import { rowsToArray } from "./rows.js";
+
+/** react-native-sqlite-storage: callback-based by default, promise-based once
+ * `enablePromise(true)` is called; `executeSql` resolves an array whose first
+ * element is the result set. */
+
+/**
+ * Adapt an already-required `react-native-sqlite-storage` module. Exported for
+ * the same reason as the filesystem adapters: the library cannot name a package
+ * the app did not install without breaking the app's bundle.
+ */
+export const adaptSqliteStorage = mod => ({
+  open: async (name, options) => {
+    // This is a GLOBAL side effect, not a per-connection setting: the vendor
+    // implements it by rewriting SQLitePlugin and SQLiteFactory prototype
+    // methods. An app that also uses react-native-sqlite-storage directly in
+    // callback mode will find its own callbacks converted to promises from the
+    // moment this adapter opens a database. Unavoidable, since the adapter
+    // cannot work otherwise, and worth knowing before mixing the two.
+    mod.enablePromise(true);
+    const db = await mod.openDatabase({
+      name,
+      location: options?.location ?? 'default'
+    });
+    return {
+      execute: async (sql, params) => {
+        const [result] = await db.executeSql(sql, params ? [...params] : undefined);
+        return {
+          rows: rowsToArray(result.rows),
+          rowsAffected: result.rowsAffected ?? 0,
+          insertId: result.insertId
+        };
+      },
+      // Not `() => db.close()`: in promise mode this driver resolves the
+      // success-callback ARGUMENTS array rather than void, so returning it
+      // directly would make SqliteDatabase.close() resolve an array while
+      // typed as void. Awaiting and discarding makes the type honest.
+      close: async () => {
+        await db.close();
+      }
+    };
+  }
+});
+//# sourceMappingURL=storage.js.map

package/lib/module/sqlite/adapters/sync.js

@@ -0,0 +1,41 @@
+"use strict";
+
+import { rowsToArray } from "./rows.js";
+
+/**
+ * nitro-sqlite and quick-sqlite share one synchronous shape, so one adapter
+ * serves both. The REQUIRE lives in the driver entry points beside this file,
+ * never here and never in the core: Metro resolves requires statically, so a
+ * package named anywhere reachable becomes mandatory for every consumer.
+ */
+
+/** Shape shared by react-native-nitro-sqlite and react-native-quick-sqlite: a
+ * synchronous `open({ name, location })` whose `db.execute()` and `db.close()`
+ * are also synchronous. Both are wrapped in Promise.resolve to fit SqliteDriver. */
+
+/**
+ * Adapt an already-required nitro-sqlite or quick-sqlite module. Both expose the
+ * same synchronous shape. Exported so an app on quick-sqlite can inject it.
+ */
+export const adaptSyncSqlite = mod => ({
+  open: async (name, options) => {
+    const db = mod.open({
+      name,
+      location: options?.location
+    });
+    return {
+      execute: async (sql, params) => {
+        const result = db.execute(sql, params ? [...params] : undefined);
+        return {
+          rows: rowsToArray(result.rows),
+          rowsAffected: result.rowsAffected ?? 0,
+          insertId: result.insertId
+        };
+      },
+      close: async () => {
+        db.close();
+      }
+    };
+  }
+});
+//# sourceMappingURL=sync.js.map