¿Cómo se interpretan y ejecutan los scripts MeteorJS del lado del servidor y del lado del cliente cuando empaqueto mi aplicación Meteor como una aplicación de Android?

Las secuencias de comandos del servidor no participan en el proceso de empaquetado de la aplicación y permanecen en el servidor.

La parte del lado del cliente se empaquetará en la aplicación APK y se servirá a Cordova WebView a través de un mecanismo que asigna los recursos del cliente a una URL enraizada en http: //meteor.local para permitir que el cliente arranque sin un servidor. Incrustado también habrá una configuración ROOT_URL que permite al cliente buscar su contraparte del servidor lo antes posible. Una vez que se establece una conexión DDP, el servidor puede informarle al cliente sobre una nueva versión de código de cliente disponible, y el cliente comenzará un procedimiento de “inserción de código activo” que es ligeramente diferente al que vería en un cliente web normal.

Comienza por descargar todos los nuevos recursos del cliente en un nuevo contenedor local junto con el código que se está ejecutando actualmente. Una vez que todos los archivos se transportan correctamente, el resto de la inserción de código activo es el mismo que en el escenario web. La aplicación comienza a “migrar”, que es un proceso en el que se pide a todos los módulos en memoria que guarden su estado antes de que la ventana se actualice desde la nueva ubicación del contenedor. (en realidad, para el HTML que se está ejecutando, se seguirá cargando desde http: //meteor.local, pero ahora se resuelve en el nuevo contenedor). Una vez que el nuevo código arranca, cada componente que tiene el estado guardado vuelve a recibir ese estado, se elimina el contenedor de código anterior y el cliente continúa ejecutándose. En efecto, la aplicación móvil siempre tiene disponible todo el código del lado del cliente para cargar desde un sistema de archivos local, lo que hace que su aplicación se pueda arrancar sin conexión, sin usar el temido caché de la aplicación HTML5.

Cuidado. Si empuja a un cliente malo que arroja un error JS al principio del proceso de carga, el cliente nunca podrá cargar o aceptar una nueva inserción de código activo sin una reinstalación completa de la aplicación. Ni siquiera una actualización de APK ayudará, el usuario tendrá que desinstalar y volver a instalar.

Si en algún momento el usuario instala una actualización del APK desde la tienda, el último contenedor de código de cliente descargado seguirá vigente. El contenedor de código real del lado del cliente se habrá almacenado fuera del APK en una ubicación “caché” o similar, y no se sobrescribirá ni se verá afectado por la actualización del APK.

Por supuesto, si desea completar la historia fuera de línea, necesitará una forma de conservar los datos en sus colecciones, eche un vistazo al terreno: db.
https://atmospherejs.com/ground/db