[SOLVED] Exclusive offline app: without mobile-server

[SkyRooms]

ground:db

ground:db looks like a solid place to start by the looks.

“GroundDB is a fast and thin layer providing Meteor offline database - Taking cloud data to the ground.”

Maybe raise an issue on GitHub with more detailed questions about how permanent the data is.

[fullhdpixel]

@ericl Nope, reactive-native is not the solution. I have an existing app that’s too large to rewrite in a weekend.

@SkyRooms How do you suggest to handle the images? Where do you put them instead of the public folder?

@herteby I will have to find out more about the resources folder. A solution would probably be in this direction…

[fullhdpixel]

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.

[SkyRooms]

Well if you build the app as server=localhost, the images would still go in /public.

So a full path being locahost/images/logo.png for example, which would have a Meteor structure of /public/images/logo.png

Right? Give that a whirl and see what happens.

[XTA]

Yep, you can save images and other assets into your /public folder. They will be bundled with your app and served locally.

[fullhdpixel]

I tried:

meteor run android-device --settings settings.json --server="localhost"

but the images are not there when restarting without internet connection.

[fullhdpixel]

So if I put images in the resources folder how should one inline them in HTML?

[fullhdpixel]

fixed the images now!

The absolute path is http://localhost:12560/, so anything you have saved in public/images should be reffered to as http://localhost:12560/images/logo.png

[herteby]

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?

[fullhdpixel]

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.

[herteby]

Starting the url with / means “from root”, just like in a file system

[waldgeist]

The absolute path is http://localhost:12560/, so anything you have saved in public/images should be reffered to as http://localhost:12560/images/logo.png

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.

[waldgeist]

Here’s another thread about this topic, especially on local storage options:
https://forums.meteor.com/t/cordova-best-way-to-store-persistent-data-on-client-side?source_topic_id=38855

From the discussion there I learnt that some of these options are risky as the devices may purge your data if they need disk space.

[SkyRooms]

From the discussion there I learnt that some of these options are risky as the devices may purge your data if they need disk space.

This is correct. I’m sure you could build something to export data to another part of the device, and/or send it to cloud for storage.

But looks like this has been solved. You can indeed build offline applications with Meteor.

[noblestreet]

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.

If you need more info how we do it, send me a pm

[meonkeys]

The :12560 may change over time, since this is a random id Meteor uses, and it might change once you do another build.

This port number is not random, it will persist for a given app. From https://guide.meteor.com/mobile.html#cordova-integration-in-meteor :

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.

. This may be a new change since Aug 2017.

[pauln]

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?

[waldgeist]

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.

[pauln]

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!

[waldgeist]

You could just download these assets via a REST API call (or a simple HTTP GET) and then store them on the device via cordova-plugin-file:

https://cordova.apache.org/docs/en/9.x/reference/cordova-plugin-file/index.html#page-toc-source

Haven’t tried this approach, though, since I never needed that much of local data.