Skip to main content
Utilice esta página antes de escribir el código del adaptador. El camino correcto depende de si la integración es ampliamente útil, si necesita SDK de proveedor o puentes nativos y si se mantendrá como una superficie de SDK pública.

​
Valor predeterminado recomendado

Si es probable que el dispositivo sea útil para una audiencia más amplia del SDK de Elata, colóquelo en @elata-biosciences/eeg-web-ble. Esto mantiene el comportamiento de transporte centralizado y evita adaptadores paralelos entre múltiples aplicaciones.

​
Elija por resultado

​
Ruta 1: aguas arriba en eeg-web-ble

Elija esto cuando:
  • el dispositivo puede funcionar a través de Web Bluetooth en un navegador
  • Es probable que la integración sea reutilizada por más de una aplicación.
  • quieres una implementación compartida del comportamiento de transporte
Este camino suele significar:
  1. agregar un módulo de dispositivo bajo el paquete BLE
  2. reutilizar BleTransport
  3. agregar pruebas simuladas
  4. actualizar documentos del consumidor y notas del dispositivo
Este es el mejor camino para una integración pública y duradera que debería sentirse como una parte de primera clase del SDK.

​
Ruta 2: paquete separado

Elija esto cuando el dispositivo necesite más que un flujo BLE de navegador limpio. Razones típicas: El paquete aún debería exponer un HeadbandTransport, o una envoltura delgada alrededor de uno, para que el código de la aplicación se mantenga consistente con el resto de la pila de Elata.

​
Ruta 3: Adaptador local de aplicación

Elija esto cuando la velocidad importe más que la reutilización. Esta es una buena opción para:
  • una implementación de cliente privado
  • una prueba de concepto rápida
  • trabajo de evaluación antes de que exista un paquete público
Mantenga el contrato igual incluso si el código permanece privado. Eso hace que sea más fácil avanzar hacia arriba más adelante.

​
Orden de decisión

1

Preguntar si la integración debería ser reutilizable

Si varias aplicaciones se beneficiarían, comience por asumir una ruta ascendente.
2

Compruebe si hay bloqueadores BLE del navegador

Si Web Bluetooth no funciona, o si se requiere un puente nativo, cambie a un paquete separado.
3

Decidir quién posee el apoyo a largo plazo

El apoyo compartido suele pertenecer a las fases anteriores. Las líneas de lanzamiento propiedad de los proveedores a menudo encajan mejor en un paquete separado.
4

Mantenga estable el contrato de la aplicación

No importa dónde se encuentre el código, el contrato de la aplicación debería seguir siendo HeadbandTransport y HeadbandFrameV1.

​
Caminos a evitar

No elija un adaptador de aplicación local sólo porque sea fácil en la primera hora. Esto normalmente genera trabajo extra más adelante si la integración se hace pública. Tampoco impulse una integración pesada, basada en puente o con licencia en el paquete BLE compartido. Mantenga el paquete público reducido.

​
Documentos relacionados

​
Siguiente

Contrato de transporte

Revise las interfaces compartidas que la ruta elegida aún debe satisfacer.

Requisitos de protocolo

Reúna los detalles del protocolo que necesita antes de que comience la implementación.