When deploying an android/cordova app, how do you specify the production database that the app uses? I want to use an existing one deployed on one of my servers instead of a local one running on the phone
For development purposes, I have tried starting the app with
meteor run android-device --mobile-server user:pass@host:port/dbname
However that continues to use the local database (no errors) and doesnt connect to the remote one
It seems you are a little confused about the way this works. The database doesn’t run on the device, but on a server (either the same one Meteor runs on or another one). The app connects to the Meteor server over DDP, and the server is where you configure which database to connect to.
--mobile-server is used to specify the address of the DDP server, not the database.
So meteor apps have both a client and server aspect to them. Does this mean that within my
Meteor.isServer block I can specify the remote database to be connected to? What would be the code for that?
I dont really understand how the database doesnt run on the device. Because during development, sure, the database can be on the computer that the android device is connected to. But once you ship the app to the play store, surely they all have to be independent of any external/remote server/database. So wouldn’t the database have to run on the device in that case? I don’t have a separate meteor server for this project, everything is designed to be solely on the device
Meteor apps currently always require a server to connect to, both for the data and the hot code push. They will be able to survive a temporary loss of connection, and there are some client-side caching solutions that enable a form of offline behavior. But even then they still need to connect to a server to load the initial data, and they never connect to a database directly.
You can use the
MONGO_URL environment variable on the server to specify what database to connect to.
So in the case of an android app, the client side of the app (on the device) will connect to the server (on the device), which then connects to the database. Does/can both the server and database exist on the device?
No, and the Meteor server does not live on the device either. Both the server and the database are remote.
Where can I read more about how meteor structures the client/server/db for android apps?
From the sounds of it, if I were to push an app to the play store, I also require some machine set up somewhere else that runs meteor server (and DB). This is a heavy requirement for an android app designed to only be used local to the device, so I’d like to gain a better understanding of how everything plays together specifically for android apps
There is no documentation about this specific to Android apps, but the basic architecture is the same as it is for browser apps. You are correct in that Meteor currently always require a server to be set up.
Thanks, I will take a look
So with the app that I’m currently developing, I test it with
meteor run android-device, and after I shut everything down and unplug my phone, the app remains on the device. It is still useable, even with no hard connection to the computer. How is it still functioning in this case? And how stable is that app that is still on the device?
I have a very specific use case. I’m doing this for research purposes. This is going to be a single app on a single device that we will use to collect participant data in the lab. For the time being, there will be no widespread distribution of this app. However, the data needs to be stable and not get wiped due it to being a “development app”. It is for this reason that setting up an entire meteor server is overkill. We already have a mongodb server set up to house data for other research projects, so I just wanted to hook this one app up to the existing database
Unplugging the phone doesn’t make a difference. The app connects to the local development server (the one on the computer you run
meteor run android-device on) over WiFi. Even if you shut down the server however, the app will keep running using the data that it has already loaded. But it won’t be able to load new data and it won’t survive an app restart. Data modifications will be reflected on the device and sent to the server when a connection is reestablished, but these will also be lost if the app gets killed. So this is only meant to survive short term loss of connectivity (e.g. going through a tunnel) and not true offline behavior.