The data is not a problem. I’ve confirmed that ground:db works as required for my app. Only part I need help with is storing all the assets locally. I just want to compile an apk and send that to someone who doesnt need to connect to my server.
Ah interesting. What about referring to them like src="/images/logo.png" though? Then you could have the same link for mobile and web, and not have to remember weird ports. Does that not work?
Oh yeah that works as well actually. I thought in cases where you have routes like this: /in/too/deep/ that you would need the absolute path from the start.
I don’t understand why you want to do that. The :12560 may change over time, since this is a random id Meteor uses, and it might change once you do another build. However, images in the public folder are always available and packaged with the app. Meteor itself cares about pointing the app to the right port (like 12560), all you have to do is use absolute links and omit the public folder: /images/my.image.png This will work just fine.
If you won’t provide a server via --mobile-server, your app will complain on the console that it can’t reach a server backend. But unless you don’t actually need one (since you don’t want to use methods or save something in Mongo), this should just work.
I don’t think it’s possible to run a full-fledged server on the device anyways. The local server on your device is used for starting up the client code and for serving static assets (like those in the /public folder). It also handles Hot Code Push. But if you don’t require a backend, this would be just what you need.
We have been using a offline versie of a Meteor Cordova app sinds June 2015, in combo with GroundDB and all assets in the resource folder. We access the images (an odd 150 items) like previously mentioned by Herteby (src="/images/logo.png"). All resources are bundled in the App (is 40MB plus)
We run do have a server running online just in case we need to update data and the client has a working internet connection. The app is a geo caching game where users are running round in a internet dead zone.
So instead we now pick a port from a predetermined range (12000-13000), calculated based on the appId, a unique identifier that is part of every Meteor project.
Could the media bundling approach above work without ‘server=localhost’ still? So that an app can still be bundled with it’s media resources and also connect to a central server when a wifi connection is available for resyncing?
This is how Meteor mobile apps actually work. They setup a local host server inside the app and try to sync it with the central server once a connection can be established.
Great!
How about a case where I need the user to download/sync up to a gig of video/audio media in order for the app to be fully functional offline? It sounds like that would still be possible and that is what I am hoping. Would it simply be a matter of whatever the size limit is with the app stores themselves then? Thank you for the feedback!