01-18-2010 12:19 PM - edited 01-18-2010 12:21 PM
I'm running into a scenario where a user is connected to a specific transport gateway (lets say WAP2, but it could be any) and is able to make a data request fine. But once they connect to WIFI they are no longer able to make a data connection via WAP2.
Question: Is this because WIFI overrides all other gateway transports and only a WIFI connection can be made?
I ask because in this other forum thread pete_strange hints at this is what's going on
"if your choices are WiFi or Direct TCP, you are going to have to check WiFi first and fall back to Direct TCP if WiFi isn't there or doesn't work. The system will not do that for you."
Thanks in advance.
01-18-2010 01:18 PM
If you are using a BIS or BES mode, the "system" will switch from WiFI to cellular etc as needed - but unless you have coded for this in your application the application will pick one path at a time.
Also, WiFI is a deviceside=true mode connection . WAP is not. Not sure if you are trying to specify a WAP connection uid with interface=wifi. That is not expected to work.
01-18-2010 02:29 PM
I can confirm that the 'fallback' is only meant to highlight that the change from wifi to direct tcp will not happen automatically, unlike with BIS and BES connections where the application in fact does not even know or care if WiFi or wireless is being used.
Note that the ";deviceside=true" is not required for WiFi connections but doesn't seem to hurt - there is a debate about whether you should code it for 'readability' or leave it out because it is not needed. I fall into the later camp.
01-18-2010 02:38 PM
1. What's the connection URL used for connecting via WAP 2.0? In particular, what connection UID is used and how is it obtained?
2. Does the above connection URL change when the device connects to a WiFi network?
3. Is the cellular interface still up and running when the device is connected to a WiFi network (it has to be, otherwise the device can't connect via WAP 2.0).