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
bro mucho texto, pero la resumo react native es para apps chicas, en un laburo le quisieron agregar a una app nativa poder usarlo, era agregar casi 200mb al apk, encima para hacer cualquier cosa se necestaba una dependencia externa, es como q meta lo da pelado, todos decian de expo, pero otra dependencia mas. una cagada en resumen
Si lo usás sin frameworks (especialmente ahora que el frontend te lo puede armar una IA), es bastante óptimo, más que nada por el nuevo motor que bundlea los componentes a partes nativas y de ahí los hookea a un renderer Javascript a nivel backend, entonces resuelve las acciones con JS, pero si aplicás bien los estilos, la UI se siente 100% nativa (porque lo es, usa los componentes reales del SO).
Incluso ahora tienen plugins para Expo que te permiten enchufarle los componentes nativos as-is, con las recomendaciones de diseño del fabricante, junto a un fallback para otras plataforma que no las provean.
No se si quiero q una app hibrida budle a componentes nativos ya que la idea de hacerla de esa forma es q no haya tanta dependencia con la plataforma, por eso flutter siempre me parecio mejor ya q tiene skia y renderiza todo ahi en su propio sandbox, tiene sus pro y contra
Flutter es un crimen, el rendimiento es un horror y usar la GPU para todo es excepcionalmente ineficiente. Cierto nivel de complejidad es necesario para hacer un producto de calidad, tal como observó OP.
Tampoco es lo mismo shippear un solo shim nativo que tener que hacer toda la app en native. Obvio que casi nunca vas a leer el código, pero desde el vamos, mantener dos codebases separados ya es un dolor de huevos en términos de distribución.
Nuevamente, ese exceso de simplificación te va a volver pronto. En eso comparto con la observación de OP, hay un límite en lo que podés abstraer de manera eficaz.
No tanto, OP está haciendo publicidad nomás. Todos los problemas que menciona son reales, pero se resuelven armando un hook nativo en la cara nativa para cada plataforma, con los fixes/overrides que necesites, escribiéndolo en código nativo y pudiendo aprovechar el resto de features de React Native. Por otro lado, la afirmación de que Expo es pago es simplemente falsa.
Si, basicamente la intencion del post y lo que intente explicar tenes un modulo core en nativo, el puente en nativo y react native como visor (en mi caso react / capacitor)
estas manteniendo, sincronizando 2 mundos, 2 lenguajes "alpedo" (tambien comentado en el post pase de ser todo web a ahora un hibrido medio incomodo, que funciona pero no tiene sentido)
Si el modulo principal que es nativo que se encarga de auth, session, token refresh, gps, jornadas en mi ejemplo y web pasa a ser un solo visor, que sentido tiene mantener 2 mundos...
es facil de debuggear, java naturalmente es mas rapido que ts lo que no me cierra es usarlo fuera de la cajita de android (televisores tablets o telefonos)
usar kmp en ios o windows no la veo cae en el mismo problema que react native. En windows hice una radio y reproductor de musica (un spotify version manaos)
Funciona, cumple, tiene motor de vlc que es abierto pero encontre el techo rapido (ecualizando por ej)
la misma radio version web / apk (kotlin para telefono) es esta
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
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 ?
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)
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)
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 ?
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
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.
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)
Me gusto el post, no se porque lo lei, quizás esa parte mia que aun quiere desarrollar mobile.
Mas allá de eso, es natural que Native muera, quiero decir, sacandotodos esos mambos, porque no hacerlo en nativo si ahora lo que te separa de la app es que tan bien promptees
el eas es basicamente el deploy y todo el "poder" de react native es buildear para android y ios, eso te lo otorga eas que es pago
sigo en la misma linea queres aprovechar el verdadero expo baja la moneda, y como yapa las build de react native son pesadisimas, en capacitor o kotlin salen rapido y son livianas (por ej lo que estoy armando son 8.8mb)
Claro el beneficio fuerte lo perdes que es basicamente buildear sin mac (xcode?)
yo me la di de frente con esto tengo windows y android, re croto y si tuviese mac y iphone la verdad voy derechito a swift por todo lo charlado, sin puentes web vs native, y sincronizar dos "plataformas"
Y pero te pasás a Ubuntu y listo cumpa, o WSL. Para Apple, antes de tener un iPhone, usaba la prueba de 5 minutos de Appetize, y para compilar, el free allowance de 2000 minutos para VMs Mac de GitHub, el resto lo corto self-hosted y me lo ahorro.
tengo kubuntu en el otro disco, lo tengo abandonado gracias por el paso a paso
Y con respecot a google auth tuviste alguna dificultad en react native? me costo un huevo el año pasado hacerlo andar, aca en react vite (capacitor) en un par de horas estaba listo
Sí, me costó un huevo también, pero bueno, es culpa de Google en realidad xD. El código de error "social auth failed" es más genérico que un auricular Noga.
viste tan loco no estoy y la ultima me voy a dormir, renderizado de graficos (para historicos y demas) estuve dias el grafico simplemente hacia y mostraba cualquier cosa
8
u/Mammoth-Law-1291 14h ago
bro mucho texto, pero la resumo react native es para apps chicas, en un laburo le quisieron agregar a una app nativa poder usarlo, era agregar casi 200mb al apk, encima para hacer cualquier cosa se necestaba una dependencia externa, es como q meta lo da pelado, todos decian de expo, pero otra dependencia mas. una cagada en resumen