Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't start local server when using option --mobile-server #3727

Closed
dirkpostma opened this issue Feb 14, 2015 · 4 comments
Closed

Don't start local server when using option --mobile-server #3727

dirkpostma opened this issue Feb 14, 2015 · 4 comments

Comments

@dirkpostma
Copy link

When I want to run my app on iOS (or other platform), using remote server on meteor.com, I run the command:

$ meteor run ios-device --mobile-server example.meteor.com

It works almost fine, except for the fact that this command also tries to run a local server. This is not necessary at this point because the app is using the server on example.meteor.com.

When the local server is already running from another terminal instance, an error is generated. Plus, I think the app should be deployed to example.meteor.com before it is run on mobile device in order to prevent app version conflicts.

So my suggestions:

  • Don't start local server when using --mobile-server option
  • Make sure --mobile-server is deployed with same app version

I'm pretty new to the meteor environment, so please excuse me & correct me if I'm wrong...

@Slava
Copy link
Contributor

Slava commented Mar 24, 2015

@dirkpostma

This looks like a valid case when you want to run a mobile app and local server from different code bases. When we built the meteor run ios/android command, the main use-case we supported was running the mobile app and the site on the same port from the same code base.

So it is clear that it can work inconveniently for you. But it looks like there is a clear workaround of killing servers and running them in the "correct" order. At some point it would be nice to straighten out all of these cases by providing more fine-grained commands that do less work ("just run the mobile app", "just run the server", etc). For now it probably doesn't stop you from getting the app up and running.

@woniesong92
Copy link

@Slava Is it possible for you to explain what exactly happens when you pass in --mobile-server param? Accounts package doesn't seem to work on Android, and I saw it here that Accounts package doesn't work on the phone if you don't pass in the param. When I open the console, I see this:

screen shot 2015-08-06 at 6 19 18 pm

Does it mean that my mobile device is still trying to connect to local server even when I specified the --mobile-server to be a remote server?

@yagudaev
Copy link

I also find this behaviour very confusing. I don't quite understand what it means when it says:

=> App running at: http://localhost:3000/

And there is no mention at all of example.meteor.com anywhere. It looks like the command is completely ignored, but it is not.

@Slava not sure what you meant by "mobile app and the site on the same port from the same code base". There is the client portion of meteor code which I can run locally and it should talk to the example.meteor.com server at all times (especially when published to one of the stores). Right now it is not entirely clear to me what happens where. Everything seems to mention localhost and local urls and there is no mention of the remote url anywhere.

Maybe it is because I have autopublish on and the Cardova meteor build process doesn't allow that to be used. I do know that the web-app version (i.e. loading the site using mobile safari rather than the cardovda app) works perfect.

@hwillson
Copy link
Contributor

To help provide a more clear separation between feature requests and bugs, and to help clean up the feature request backlog, Meteor feature requests are now being managed under the https://github.com/meteor/meteor-feature-requests repository.

This feature request will be closed here, but anyone interested in migrating this feature request to the new repository (to make sure it stays active), can click here to start the feature request migration process. This manual migration process is intended to help identify which of the older feature requests are still considered to be of value to the community. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants