How to use WebAppLocalServer.localFileSystemUrl() - documentation or example?


#1

From the Meteor mobile guide:

The file serving mechanism used in Meteor allows for local file access through URLs of the form http://localhost:/local-filesystem/) however. You can construct these file system URLs manually, or use WebAppLocalServer.localFileSystemUrl() to convert file:// URLs. You can use this to convert URLs received from plugins like cordova-plugin-file and cordova-plugin-camera for example.

Can anybody point me to anything at all that tells me where WebAppLocalServer.localFileSystemUrl() comes from? - code, documentation, an example? There is nothing in Google, I haven’t found the code base, it’s all very mysterious.

I asked this question in Stackoverflow, but unfortunately got no reply


#2

Found it with a GitHub search, where I suppose I should have looked right away

cordova-plugin-meteor-webapp.WebAppLocalServer

This plugin is an integral part of meteor-cordova code, and is installed when you run meteor create so you don’t have to do an import, you just use it as it is with calls like this:

WebAppLocalServer.localFileSystemUrl(fileUrl)

fileUrl is expected to begin with file://, if it doesn’t, the method just returns the fileUrl as it is.


#3

Hi @mwarren2,

I understand this topic has long been untouched, but I’m lost in trying to find a way to access local files in a mobile meteor app (or adding them in the first place).

I’m able to create an Android app now, but I’d like to load images among other things internally. So that means including the images in the build.

Here’s my recent SO question:

I hope you can help. :bowing_man:t2:‍♂️


#4

If you’re talking about static resources, simply accessing them vis “/myImage.jpg” will work, as Meteor
s cordova is served via localhost. If you’re talking about dynamic images, you need some code to access and write to the filesystem. Take a look at the filesystem API https://developer.mozilla.org/en-US/docs/Web/API/FileSystem while it is “non-standard” it is implemented in cordova.


#5

Try searching for the meteor static asset compiler. I haven’t tried it but it might work for your use case


#6

" simply accessing them vis “/myImage.jpg” "

That’s how I direct the src to my img tags now, and the thing is, it’ll load the images slowly (well not instantly), meaning it’s probably downloading the images off the server.


#7

Hi!

It’s the first time I’ve heard of this package, and I’ll give it a try, but from the looks of it, since the example shows that the files would be placed into the imports folder (imports/client), I’m guessing that this will still be served off the server, as opposed to being included in the apk when I try to build. :thinking:

But I’ll give it a shot. Thank you!


#8

Sorry, I assumed you were in cordova? Use the chrome inspector and watch the network tab - see what requests go out and to where, you should see requests to localhost:1234/myImage.jpg if you see requests to a remote URL - make sure you haven’t accidentally hardcoded an absolute URL into your images.


#9

I do use cordova for my mobile builds!

And after your message, I just had to try again, creating a build with an img with an src that’s from /public (effectively /imgs/myfile.jpg), and running the app while the device is offline.

And true enough, it showed the photo. I’m at a loss, I probably confused myself so much that I convinced myself it didn’t work… :joy:

Thank you for your answer!


#10

I’m checking my mongodb collection now (since that’s where I placed my url links), and that’s the culprit, it was still linking to an online link, versus a raw path that’s supposed to just point to my public folder.

But that said, is it ok to just put it in the public folder :cold_sweat:or is @rjdavid 's suggestion of using the meteor static asset compiler work with mobile builds too? (to keep it a bit more private?)

Also, please feel free to answer the same question on SO! I’d be glad to mark your answer as the solution! :bowing_man:t2:‍♂️


#11

If your resources are static, then static is the way to go (e.g., a user chooses one of X number of images), but if a user can upload arbitrary images, you’ll need a dynamic solution. In that case, I’m not even sure that @rjdavid’s solution will work (though I’m not familar with it) you’ll likely need something that behaves in a similar way to a service worker (e.g., you cache the URL when it’s first requested) - this is also necessary if you need offline support for dynamic resources.


#12

I see. For my (current) purposes, I can go with static. It’ll be an internal tool where admin roles will have full control of the database as well as app updates.

I’ve definitely looked into caching before, but it really is quite different from native Android or iOS. :joy:

Thank you again! I’ll be updating my database tomorrow! :sweat_smile: