One thing I didn’t grasp from this guide: is it possible to build a completely offline, local mobile app using Meteor, and if so, can it use MongoDB? I.e. when you build a Meteor app with Cordova, is the app running both client and server code, or does it assume there’s a sever somewhere else in the network?
1 reply
@kueda: You can build offline apps, because all assets are available locally. But that won’t give you access to your data. For data loading, you would still need a connection to a DDP server. There are community packages like GroundDB that may help you use local storage instead however.
Very useful this guide, thanks guys!
One item that could use a bit more explaining is the section on mobile-config.js. Is there a one to one mapping from the Config.xml to mobile-config.js?
These two specifications have a few things in common, but a lot is unclear to me: http://docs.meteor.com/#/full/mobileconfigjs vs https://cordova.apache.org/docs/en/latest/config_ref/index.html and https://cordova.apache.org/docs/en/latest/config_ref/images.html.
@aspin: Cordova plugins don’t really support modules (neither CommonJS or ES6). Cordova has its own module system for loading, but plugins then add themselves to the global scope depending on settings in their plugin.xml. So you should just keep using them as before.
Well I feel silly. Errors are gone after taking out the import statements hahaha. Thanks.
After struggling for a couple of days with a seemingly elusive bug, I’d like to share what happened and suggest a couple of small improvements in the guide that would have made finding the issue much easier:
What I experienced was very weird: When running on android with meteor run everything was fine. But when building an apk with meteor build and installing it (via adb or the play store) the app had extremely long load times for the first run, sometimes ending with complete stuckness. When reloading the app the second time was usually working fine - but sometimes not.
For a while I believed that this has to do with the launch screen package and tried some manipulations there. But after a while I realized it’s not that.
The first real smart thing I did was to build a debug apk and inspect it on my device with chrome. And here is my first suggestion: Explain in the guide how to do exactly this. Creating a debug apk (which is the only way to later debug an apk with the chrome devtools) is not documented anywhere in the mobile guide and yet it’s an incredibly powerful tool which I’m super glad I found out about.
Actually, the --debug flag is also not documented in the build tool guide. If searching for “meteor build” or “meteor build --debug” on google you get either to the above-linked guide or to this page which are not useful for this at all. So the only place you can learn about it is in command line help meteor build --help.
In short, what I’m trying to say here is that there’s a very powerful tool for mobile development in hiding 
.
After successfully building debug.apk (took me a bit also to realize it’s not release-unsigned.apk when using the --debug flag, this isn’t documented in the command line --help) and installing it, the rest was easy: my Meteor.settings was undefined, which caused errors where in the first pages of my app I’m using Meteor.settings.public.
It was undefined because I was building my app using this line:
meteor build ~/build-output-directory --server <host>:<port>
Which is the canonical example in the guide. I did not add a --mobile-settings flag. This caused the first run of the app to throw errors, and the second run to work ok since it was already after a hot code push with the settings on the server. Once I realized that this was the problem everything was fixed.
And here is my second suggestion:
the --mobile-settings flag isn’t even mentioned in the mobile guide. It should definitely be there.
That’s it. Sorry for the long rant and thanks a lot for a wonderful platform!!
2 replies
I have secrets I want my (android-only) mobile Meteor app to be able to use at runtime. I don’t want to store these in the APK. Based on https://docs.meteor.com/#/full/mobileconfigjs I think I want to use App.setPreference()or App.configurePlugin(), I’m just not sure where to go from there. How do I get/set my secrets while the app is running?
I can’t find a specific example for storing and retrieving secrets, but perhaps one of these links leads down the right path…
Hello,
If I only want to create an APK, and test it without using the Play store (I want to send it to me and my friend for apha use and debug), do I need to sign the apk ? For now I tried to send the unsigned-release.apk to my phone, but it failed the phone do not recognize the apk. (I enabled installation of ext app). The correct apk is unsigned-release.apk right ?
Last thing, do I need to explicit the settings (env variable) if they are all defined on the heroku app and I build with --server my_app_on_heroku:3000 ?
1 reply
@voyag3r in regards to signing, the apk needs to be signed regardless. If you’re using debug, the build process/android studio should sign with its own keystore automatically (you’ll end up with a something-debug.apk). But the release version is not automatically signed. If you want to test the release version you need to generate a signed version from android studio using your keystore. You can also sign using android studio’s debug keystore from the command line using something like this:
jarsigner -verbose -keystore ~/.android/debug.keystore -storepass android -keypass android path/to/some-release-unsigned.apk androiddebugkey