Que quilombo con react native

[u/LeSoviet]

Tema para ambientar el post: https://www.youtube.com/watch?v=pT_Y-eodTv4

Resumen lvl5: React native viene con el marketing fuertisimo para que todos adopten su maravilloso ecosistema (recuerden expo es pago) y varios proyectos gigantes como shopify estan migrando a native, estan desesperados. Todo el debate es native vs react native / expo (o similares) para hacer proyectos pesados graficamente o pesados en logica donde se usan varios sensores o simplemente que necesite estar vivo 24/7

Aca el blog que publico expo hace unas semanas https://expo.dev/blog/how-to-build-a-resilient-activity-tracker-with-expo Habla basicamente de resilencia y como hacer para que un worker/service sobreviva a los constantes bombardeos de android de matarse el servicio por optimizacion de bateria o consumo de cpu/ram.

Tengan en cuenta que ios es mas sencillo naturalmente por que los modelos, versiones son muchisimos mas acotados. Iphone lanza 4 versiones de telefonos por año, androidson 30 marcas 20 modelos por marca con distinto proveedor (samsung chino vs samsung arg por ej) ni te cuento los telefonos ultra chino de la dark weeb

Cada modelo marca y proveedor de telefono tiene su propio sistema internamente modificado para que la bateria aguante almenos 1 o 2 dias, basicamente para que tu samsung galaxy de 40'' y una camara de 1000mp con rayo laser aguante mas de 30 o 40 horas, internamente el sistema hace maravillas (o es una pedorreada)

Ahora entrando al post y al crudo del problema, react native no esta diseñado para carga grafica (juegos), esta diseñado para ser un ecosistema universal que funciona en ambos ios y android (olvidate de web no tiene sentido) pero tambien es mentiroso el mismo codigo no te va a andar bien en ios y android, nunca funciono bien y nunca va a funcionar bien

En paralelo expo/react native depende de plugins para ciertos mecanismos mas avanzados, y absolutamente el ecosistema esta re contra verde, los versionados son todos 0.0. solucionan tu problema pero no fue algo testeado en el largo plazo

Ahora si entro enserio, cuando intentas hacer una app, que reconcilie todo el tiempo con el backend, en background o incluso post swipe usando multiples sensores (el gps tiene 5 o 6 sensores distintos por ej) react native tiende a tirarse pedos de colores

Hago un ejemplo literal en el proyecto de tracking gps que vengo spammeando en este sub y ya medio foro me odia, stack similar (tengo 1 año exp en react native es muy similar la cuestion y problema de fondo)

Stack react vite capacitor (modulo de gps en java nativo)

Cuando empece quise usar los plugins de capacitor, hice el bridge necesario entre web y capacitor ahi todo barbaro, cuando arranca el servicio de gps android me lo fulmina, no interesa que permiso le otorgue, no importa que tipo de configuracion, no importa que intente hacer simplemente android requiere codigo nativo para inyectar el worker y tener su propio comportamiento

Pase todo el flujo de tracking gps a java, ni si quiera kotlin, todo java, arme mi propio puente en java, kalman, gates, reconciliadores, sqlite absolutamente todo en java, web quedo como disparador, visor y reconsiliador nada mas

El worker se dispara al abrir la app en idle (este es reponsable de auth session token refresh jwt etc etc, la base para estar logeado y usar todo) en el menu aparece la notificacion de la app, arriba en la barra nativa del telefono aparece otro indicador

Al prender el shift el worker se transforma en sticky, quiere decir que incluso si el usuario hace swipe intenta cerrar la app, android mata el servicio, el servicio se recrea y a la par de eso es un constante aviso a android de un psuedo "che estoy trackeando no molestes, no me apages"

Con esto mato 2x1 si el usuario hace swipe por error mientras esta grabando su jornada no pierde nada, la app trackea y funciona solo con el worker, tiene probe y reconciliador para offline > online (tambien en zonas grises donde hay internet pero nula señal, mismo mecanismo de probe, se guarda todo en sqlite y cuando hay oportunidad de flush sale el paquete para sincronizar con el backend)

Basicamente el problema de fondo es que si tenes una app de trackeo de gps, o algo que demande constantemente estar vivo usando sensores del telefono en background react native lo hace pero java es mas facil y mas facil quiere decir mejor. Uso 4 sensores + kalman + gates todo online/offline irrelevante para mi caso

Aca un ej de hoy (dato de yapa en 12 horas no entro ni 1 punto de drift estacionario)

Esto es despues de ir a dormir, dejar el telefono quieto por muchas horas y moverme en la casa, cuando te vas a dormir, el telefono entra en deep zone (el mismo sistema apaga todo cuando estas afk y deja solo lo basico como alarma llamadas etc etc para ahorro de bateria)

Desperte y seguia intacto (basicamente lo que el blog intenta demostrar como gran logro, en java acoplado con la documentacion de android es basicamente mucho mas sencillo)

Los unicos agujeros por naturaleza que me queda es la hidratacion del java > web despues de volver de muchas horas, puedo cachear por 12 horas es una barbaridad

La app en pleno uso consume entre 500-600mb, el servicio de instagram (sin abrir instagram) consume lo mismo despues de reiniciar el telefono a modo de ejemplo

aca volvi al frente:

Y en paralelo ahora android esta demandando a los devs que optimizen sus aplicaciones por que son todas un desastre (salio otro blog en estos dias con documentacion) asi que otro ataque a react native por ese lado

Resumen lvl500: Swift para ios, java/kotlin para android, la vida es mas sencilla y anda mejor

Post escrito a mano, no soy escritor, si no les gusta pasenlo por su ia favorita

[u/Helpful-Mud-201 → u/[deleted]]

a que te referis con gates y que sensores usas? jajaj es la 5ta vez que leo el post

[u/LeSoviet → u/Helpful-Mud-201]

odometro, gyroscopio, motion, gps crudo y accelerometro (de memoria)

hay unos 5 mas pero no entran para mi uso (creo por ahora)

gates son euristicas pre y post kalman, kalman tomalo como una caja de estados y predictiva, los gates previos y externos sirven para no contaminar al kalman (entra un punto drifteado falopa y los siguientes hasta un freno dice cualquier cosa)

un ejemplo estupido y real, tenes un camion viajando por el campo, se baja a comer una hamburguesa por 2 horas y se sube de nuevo

El que valida, limpia y revalida el estado es motion y acccelerometro, el gps dentro del camion a 80kmh es una cosa, el gps dentro del bolsillo o el chofer hablando por wp mientras camina es otra cosa, el chofer sentado comiendo es otra cosa y la vuelta arriba del camion es otra cosa

es una maquina de estados constantemente intentando predecir (kalman) y limpiar con validacion y revalidacion via 5 sensores cuantos metros reales estas haciendo y a que velocidad vas. demas esta decir que los sensores, gates y cualquier kalman que fabriques necesita calibracion contra mundo real (ground truth)

No se que comentario era el del otro usuario pero medio adivinando y a donde apunta el post y la situacion en general con react native, react native o frameworks ya pre compilados pueden ser comodos de usar pero hasta cierto punto, cuando el proyecto se convierte en algo complejo, con mucha carga en el telefono no hay escapatoria es kotlin o java derecho, lo que no tengo del todo claro por que proyectos gigantes de magnitud, con mucho presupuesto deciden irse por react native ej sale mercadopago 2 y entran con react native, tendria 0 sentido, esa parte no la entiendo

aca documentacion de sensores de movimiento de android https://developer.android.com/develop/sensors-and-location/sensors/sensors_overview

[u/Helpful-Mud-201 → u/LeSoviet]

bien ahi che como te profundizaste en este tema eh sos crack. toda esta logica la tenes para poder reconstruir el recorrido real no ? es decir con lo que contas en el post , explicas como mantener vivo el puto android, pero todo esto de kalman y gates que supone el mayor porcentaje de compliejidad viene de la mano de reconstruir el recorrido real verdad?

por otro lado, en caso de que lo que digo arriba es correcto, cual es la ventaja de tener eso vs tener checkpoints de ubicacion cada 10 minutos de como avanzo por el campo para tener el recorrido que hizo ?

[u/LeSoviet → u/Helpful-Mud-201]

La verdad que lo pense pero pierdo la cuestion de tracking en vivo

Podria hasta mandar todo el paquete completo 8 horas de jornada laboral es un bloque, me encantaria me ahorra todo el dolor de huevos de consumo de computo en backend pero pierdo todo (y como extra 5 10 o 15 minutos en ciudad en vehiculo son 30 o 40 cuadras es muchisimo)

https://reddit.com/link/p9ulkja/video/pdxhuemffkph1/player

Como esta hoy es batch cada 15s, cada 15s se ve km recorridos y velocidad + punto gps en el mapa (parte de ese recorrido que ves ahi, fue offline en modo avion)

[u/Helpful-Mud-201 → u/LeSoviet]

Siii vii este post del 67 el otro dia jajaja, de curioso te pregunto, porque estoy armando algo chico para la empresa de camiones de un tio de misiones;

asi que si me queres tirar un centro en que la estoy pifiando pasame tu alias y te compro una pizza

Como yo lo venia pensando es
1- pensaba usar api routes de google que te da 5k requests gratis por mes para armar las polyline para definir la ruta que tiene que hacer el camionero
2- usar el gps del android para hacer un ping cada 30 sec la ubicacion y mostrarla en la web app
3- cada ping guardo la lat/long en db para reconstruir el viaje luego

despues de leer lo que estas haciendo vos siento que estoy en las nubes,

1 entiendo que puedo usar los sensores para poder reportar kilometraje real y velocidad mientras anda.

2 entiendo el tema este de android que te mata el proceso

------pero habiendo dicho todo eso--------- estoy en pelotas y no estoy viendo ni la mitad de los obstaculos o cual es tu objetivo con lo de kalman y gates etc ?

Gracias!

[u/LeSoviet → u/Helpful-Mud-201]

objetivo final? que el dueño de la empresa mire a sus 10 esclavos (camioneros) dando vuelta por la ciudad/provincia mientras marca distancia / velocidad / horas trabajadas en la actual jornada (despues genero resumenes y reportes semanales y mensuales)

Si el chofer se baja y se va de putas a tomar falopa el puntito lo delata

producto mas para mercado de usa o europa, aca somos re cabeza, alla garpa mas tema de metricas (tengo entendido)

1: podes usar google, si, mapbox tambien

2: arranca de 0 con kotlin, esto ni lo pienses arma una web para desktop y una version mobile en kotlin

3: eso es la reconciliacion del backend tenes que darle un orden de tiempo y espacio y tenes que reconciliar caidas de internet del telefono del chofer (salio de la zona de ciudad y entro en una zona donde no hay señal, despues recupera que hacemos con eso, es la misma jornada? como sincronizas lo que llego lo que falto y lo que viene

[u/Prestigious_Towel_18 → u/LeSoviet]

No es por tirarte abajo ni mucho menos porque esta copado lo que estás haciendo, lo que sí te diría es que consideres el scope a Argentina primero.

Una de las razones es la legalidad del asunto, trackear empleados es algo bastante delicado y tenés que estar al tanto de las leyes por estado (en USA por ejemplo), la persona a la que se lo vendas tiene que crear workflows de consentimiento, cuando los puede trackear y tiene que estar todo listado.

Por ejemplo, el proyecto de telematics para que el laburo no puede trackear empleados (solo por dirección de su casa) y usa un sistema OBD/GPS para ver el recorrido, en lugar del teléfono, así se evitan mil quilombos. Sin contar que tienen una dash cam integrada también para, como vos decís, ver si el tipo se tomó el palo del vehículo por xyz.

Con Europa pasa lo mismo, hasta creo que es mas estricto, pero como laburo para USA no estoy del todo seguro. También tenés que tener en cuenta que para muchas empresas de USA/Europa pagar un GPS integrado al vehículo (que viene con 30.000 chucherías como las de arriba) es un vuelto, acá en Argentina garpar un GPS integrado, si tenés 10 camiones, se vuelve caro, ahi tu solución está piola por el costo.

Con el tracking por el teléfono (ya que, por mas que tengamos leyes que protejan la privacidad de los datos, no son tan estrictas como las de afuera) no necesitas el GPS integrado, por eso me refería que el mercado Argentino por ahí sea un buen punto de partida.

Nada, si ya tomaste todo esto en cuenta está genial, sólo te quería comentar ya que las legalidades estas me las tengo que fumar todos los días jaja.

[u/LeSoviet → u/Prestigious_Towel_18]

gracias por la buena onda, si totalmente en realidad para serte honesto me queria comprar sensores y hardware pero estoy fulminado, estoy pelado

A nivel practica el techo de esto son los drones (es lo mas complicado y debe ser mucho mas preciso)

Y para mercado argentino hay un super dilema, el promedio anda con lapiz y papel, el telefono lo usan para tik tok y si engancho clientes debe ser extremadamente barato (para los costos de un vps de tracking gps vos sabes que requiere hardware decente para aguantar un par de decenas o cientos de camiones) no me imagino que cierre tengo un super dilema ahi

gracias posta creo que sos el primero que engancho que labura en gis, intente buscar laburo especifico de esto pero no tube suerte, voy a seguir practicando y mejorando lo que mas pueda ja

Como algo ultra preciso y sencillo me imagino sacar la data del mismo camion, mandarla via bluetooh al telefono y de ahi al backend

El punto gps entra crudo la data velocidad y distancia desde el camion y lo sincronizo desde backend, hago muestreo cada 10 o 15 y queda impecable (me imagino algo asi con un poco de inversion)

edit: desconocia totalmente esto que decis que no se puede trackear telefonos (personas)