I've seen in a lot of places that in order to use an External Mongodb in Meteor applications, you should use an Environment Variable MONGO_URL. However, I'm building my application to work both as web app and mobile app (by generating an apk).
The problem is that when I start meteor as MONGO_URL='mongodb://user:pwd#path.mlab.com:9999/db' meteor it works well in my computer. But, it's not possible (I haven't found any way of doing so yet) to do this in mobile.
So, anyone has any idea of how I could use an external mongodb in mobile applications?
Thanks!
It seems to me that you are confused about how Meteor works, and more generally the client-server architecture.
Only your server has access to your database (whether on the same machine or at a third party provider), so that you keep control of exactly what your Client has access to.
By "Client", we mean what your visitor uses to access your app, whether a web app through a browser, or a mobile app through a Cordova wrapper.
So your mobile app only needs to know the URL of the server it has to connect to. That is specified by the --server option when you do your meteor build.
Then your server needs to know how to access the external MongoDB. This is your MONGO_URL environment variable. In production, you would set this variable on your server host. Each provider offers a different method to configure those environment variables, most of the time there is a graphical administration panel.
Note that the way Meteor works, you can use the same server to support both your web app and mobile app at the same time.
Finally, you can also test on mobile using meteor run android instead of just meteor (or with ios instead of Android, but you need a Mac). Of course you can still specify your MONGO_URL variable in the CLI when testing, exactly like you have done when testing on browser.
For mobile (cordova) meteor applications think of the app as just a web view with the ability to access native device features (camera, bluetooth ...). Since the application is basically a web view, the underlying mongodb associated with it is the same. If you want mobile device specific storage take a look at GroundDB
For your situation, if sounds like your mobile app is having problems connecting to your server, ultimately not allowing it to pull data from the mongoDB. Make sure that when you build the mobile application you have server specifed '--mobile-server'. Also if you are running it locally, make sure your mobile device is on the same network as your computer and any firewalls that might not allow connections are disabled.
Related
I have been working on a NativeScript project that uses an API. The API project is on my MacBook and haven't deployed to anywhere yet. It's based on Laravel and I use Laravel Valet as development environment.
I can't test the mobile app on iPhone because the app can't connect to local API URL. I know Valet has "share" command, but because the API consumes another API -which has IP restrictions-, it doesn't work for me. Sharing a local domain via Valet's share command is something like a proxy as I understand, so the consumed API doesn't work on that proxy.
I also checked articles about how to share Macbook's network with iPhone, but it only shares the same network. I can't access the local API still.
Is there any other way that can resolve my issue? Maybe a Docker based solution? I am not that good at Docker, but I can give a try if it is possible with it.
https://ngrok.com/ will happily expose your local Laravel Valet server.
Looks like there's a bit of a walk through on that here too https://mannyisles.com/using-laravel-valet-and-ngrok/ which may help?
I've run into issues when running a web server in an app that is embedded using the AppView approach.
The background is that we need to run two applications in Kiosk mode (digital signage implementation).
There is a primary app and a supporting application running, the support application needs to run a local web server for configuration and control purposes.
The web server needs to be accessible from external browsers.
I have had some success embedding the app with the web server and being able to access from a browser running on the same device, but not remotely.
These tests have only been done in desktop rather than kiosk mode.
From what I can tell the Manifest for both the embedded and host apps are correct, in that the apps run in single app mode ok.
The apps will embed using the AppView tag.
as per... https://developer.chrome.com/apps/tags/appview
1 - Is it possible to embed a web server as per the above senario?
2 - Are there any additional properties needed in the manifest
Any assistance would be greatly appreciated.
Thanks
P.S.
There are a few additional undocumented requirements for the embedding to work in Kiosk mode.
Such as listing the apps ID in the in the manifest for the container app.
i.e. you need to include "kiosk_secondary_apps" with a list of kiosk mode apps that you want to embed.
I am looking at the features of 1password app which allows us to save a password and access the same data via its mac osx app.
If I was to create an chrome extension for my OSX app - how could it share data with a chrome extension and the Mac App?
Two broad possibilities:
Native Messaging. That's the more secure mechanism, but has only-one-way-to-use-it that essentially means you'll need some "proxy" application that Chrome can start, and that can communicate with your application - it cannot connect to an already-running process.
Local Web(Socket) server. Your native application can open a local port and the extension would try to connect to it and talk this way. Makes it hard to authenticate parties: your extension and your app has no warranties they are not talking to something hostile. Include your own authentication.
See also this question.
FWIW, 1password uses a local WebSocket port.
Is it possible to develop facebook apps locally on my system so that the callback URL need not be a public URL like http://abc.com and instead can be an internal IP address like localhost http://127.0.0.1?
It is now possible to develop Facebook apps locally.
I believe this is true especially if you're developing in an iframe, which is now the standard way of developing facebook apps (FBML is deprecated).
In case this does not work, there are still some ways to make working more convenient.
Take a look at this answer:
Testing FB apps is still a rather primitive process.
I generally setup a test application that is a complete copy of the production settings inside the FB development environment that uses an SSH tunnel to point to my development server. You can setup as many applications as you need inside FB - I generally have a development application, a staging app and production. Staging and Production are both on "live" servers rather than an SSH tunnel.
The rest of the answers to this question detail different workflows that people have utilized to make it more convenient to develop on a remote host.
you can use http://127.0.0.1/ProjectName as the callback url, or your ip address itself
I was thinking about creating an iPhone app "front end" for one of our internal systems.
I suspect this will need to run via a Cisco VPN (connecting with a key code).
What are the options to do this on the iPhone?
Do you need to manually connect to a VPN somehow using the iPhone and then start the iPhone app?
Or can the app prompt users to enter their key code and then start the VPN session?
No, (as of iPhone SDK 3.1.2) there's no API provided by the SDK to manipulate VPN connections. The user will have to manually connect to the network.
While there may not be an API available to manipulate the VPN itself, as of iOS 3.0 enterprises can at least enforce hosts within particular domains be accessed via a VPN, and "VPN On Demand" can be used to turn on the VPN when a given resource is being accessed. Without the enterprise deployment tools though, I suspect you're out of luck.
It doesn't sound like the application will be able to have any insight in to any of this happening, though.
Ref: http://support.apple.com/kb/HT1424
Try iSimplyConnect - it support Dial-On-Demand.