Meteor "--mobile-settings" being overriden by server values?

Question

I'm trying to provide some per-build configuration for a Meteor mobile app. The --mobile-settings option looked to be ideal for this task - it allows you to pass configuration (JSON) to mobile clients at build time - in the same way that the --settings option does for the server.

However, I'm seeing some unexpected behaviour... anything passed to the mobile clients via --mobile-settings looks to be being overridden when the client refreshes from the server.

Here's what I did....

1. Wrote a very simple app which reads a settings value from Meteor.settings.public.blah and displays it on-screen.
2. Deployed this app to the meteor servers (without any mobile-settings file).
3. Built the same app for android, pointing to the server above and with the --mobile-settings option set - pointing to a settings file which declared the 'blah' property. Installed it on a device.
4. When I ran the app on the device, the app started and the screen correctly displayed the blah setting.
5. However, after a couple of seconds the app refreshed and the setting disappeared.

On refresh, why would a mobile-specific, build-time value be overridden from the server? Does the mobile-settings file need to exist on the server too?

Thanks in advance.

Update

Ok, going by a discussion below, I think I need to clarify my question a little...

What I've described above is the behaviour I'm seeing. However, I find this behaviour confusing and I'm struggling to find any documentation on this feature to detail what the expected behaviour is.

The best I could find was a thread where one of the original devs commented (https://groups.google.com/forum/#!msg/meteor-talk/Jbfnk5kCvW4/6qvccun2dQ0J). He said...

You just build your mobile apps twice with different json passed to --mobile-settings.

This does not seem to support the behaviour I'm seeing - where the json passed to --mobile-settings would be overwritten by whatever was deployed to the server. Hence my confusion.

I would appreciate it if anyone could point me to any documentation or confirm this behaviour either way.

Answer 1

In short

Let's look at

meteor build --help

It reads:

--mobile-settings   Set optional data for the initial value of Meteor.settings
                    in your mobile application. A new value for
                    Meteor.settings can be set later by the server as part of
                    hot code push.

So it looks like the settings you provide for the server with the METEOR_SETTINGS environment variable always takes precedence. The "mobile settings" are only there as a fallback/defaults values if there are no server setting yet.

Let's look at Meteor source code :)

Still, it may not be clear what's the purpose of having another settings object for a mobile device. I am not an expert on Cordova, but I guess the problem here is how the application gets bootstrapped.

Normally, when you request the initial page from meteor server the Meteor.settings object is - of course - up-to-date with your server config. This is taken care of by the webapp package here:

https://github.com/meteor/meteor/blob/devel/packages/webapp/webapp_server.js#L352

Note that it becomes a bit more complicated when you install the application on your mobile device. Of course the installation process has nothing to do with your server current state, hence there's no way to get the initial values for settings unless they're know in advance during the mobile build process. That's the only reason you need that --mobile-settings option. They're not there to alter your settings for a mobile device but to provide initial values before the up-to-date settings object can be loaded from your server during the hot-code-push.

And it will always happen if the two settings objects are different, because as you can see in the code here the PUBLIC_SETTINGS value is taken into account while computing the hash which is used to tell if the the client code is up-to-date.

Conclusion

So the conclusion is: your "mobile settings" - or at least the public part of it - should reflect the current server configuration as close as possible. Every time you change your public settings you should also rebuild your mobile application and publish the update to make sure your new customers have the up-to-date version of settings out-of-the-box.

Ideally, the client application should not depend on Meteor.settings to startup properly. Even if the object is empty there should be some default behavior that does not break the user experience.