Topic
  • 1 reply
  • Latest Post - ‏2012-11-18T04:51:52Z by SystemAdmin
SystemAdmin
SystemAdmin
2327 Posts

Pinned topic Looking for optimal way for handling a variable <worklightServerRootURL>

‏2012-11-18T00:17:19Z |
Hello,

  • I develop, test, and demo on a Macbook Pro w OSX v10.8.2 using WDE v5003 and MySQL v5.x
  • I do Ad-hoc app installation on to my iOS devices for untethered testing, and the embedded WL Server in WDE and MySQL db on my Mac becomes my surrogate server environment
  • I bypass my home router's DHCP IP assignments by creating a separate Network Location on my Mac so that I have a fixed IP address for my <worklightServerRootURL>

What I need to do...
  • I need to deliver iOS device-based demos on other networks where I cannot control the IP address assignments
  • I will connect to either a customer's or conference's guest WiFi, or create a personal hotspot on my iPhone so that my device and Mac are on the same network

Question...
What is the most effective way of solving this situation?

I'm thinking that since the .ipa that's already installed on my device is currently pointing to my fixed home-based network, I believe that I'm forced into the full WDE - Xcode - iTunes Ad-hoc deployment model whereby I supply the app's URL during the final step of the Xcode Archive Distribution process using "http://<new Macbook IP address>:8080/" each and every time I find myself in this situation. Interestingly enough, I accidentally left the <worklightServerRootURL>http://${local.IPAddress}:8080</worklightServerRootURL> in it's default form, so the URL I supplied in the Xcode distribution actually controlled the access.

Thank you in advance for your expertise!
  • SystemAdmin
    SystemAdmin
    2327 Posts

    Re: Looking for optimal way for handling a variable &lt;worklightServerRootURL&gt;

    ‏2012-11-18T04:51:52Z  
    It appears that I overlooked the obvious...

    Settings > General > theApplicationName

    that's where the Custom Server URL is located.

    Unless I'm overlooking something (again), I'm marking this closed...