03-02-2010 11:42 AM
I am making an app that makes an HttpConnection, and I find that some of my users are reporting IO errors.
What my app does is first tries to connect with interface=wifi and then without interface=wifi.
However, BOTH times it uses deviceside=true. I did this because on my devices and simulators, deviceside=true always worked.
Are there some situations where deviceside=true won't work? Like are some corporate users' phones locked down in such a way that would prevent that kind of use? I don't care to use BES or any kind of specialized network.
03-02-2010 11:53 AM
devices which are connected to a BES can have restrictions about the allowed connections, for example being forced to use mds.
03-02-2010 11:53 AM
"deviceside=true" is going to require some type of APN info, either in the device settings, or included in the URL.
You should be using CoverageInfo to determine if the devices is on a BES also - you do not append this parameter if the device is on a BES network.
See the Peter Strange sticky thread for tons of info (top of the forum).
03-02-2010 05:35 PM - edited 03-02-2010 05:58 PM
I'm thinking of implementing something like this to ensure that I have the correct parameters appended to my stream URL:
Does that make sense?
(I am not using the USE_MDS_IN_SIMULATOR because I don't want to import his UploaderThread class)
03-02-2010 06:21 PM
Okay, I implemented that guy's code, but how do I test the connectivity of the various scenarios outlined in that code? I have a Bold 9000 on AT&T and a Curve 8330 on Verizon.
How do I test MDS for example?
03-03-2010 01:11 PM - edited 03-03-2010 01:20 PM
My main question is this:
If I don't use 'public-MDS' (which is unofficial and i hear is buggy), do I have to either pass carrier-specific APN info parameters or rely on the user's phone to have that inputted correctly in their advanced settings?
03-03-2010 03:23 PM - edited 03-03-2010 03:24 PM
Relying on the device settings is problematic, in my experience. First, it is a constant support headache, since most phones do not have these settings correctly entered.
Second, when your customer monkey's with the settings to try to make somebody elses software work, he'll break yours.
BIS-B is not buggy - not sure where you got that info. However, you need to be an alliance partner and your app needs to be approved to utilize it.
I would try WAP2 first, then fall back on Direct TCP wiht the params encoded in the URL. If you are in a relatively small geographic market, you won't have to know 100's of APN's, just a few.
03-03-2010 06:02 PM
One user had an issue where he was on 3G, his web browser worked but my application did not work. Any idea why that would be the case?
I was using just ';deviceside=true.'
Was it because the web browser uses MDS, whereas my ';deviceside=true' connection just uses Direct TCP with automatic APN detection. And that user's APN must not have been configured correctly, alternatively his provider didn't allow connections)?
I think for my next build I will try:
Wi-fi (;interface=wifi) (<-- for this one this is all that I need to append, correct?)
WAP2 (;deviceside=true;ConnectionUID=*wap2 uid from servicebook*)
Direct TCP (;deviceside=true)
If ALL of those fail, then I will present a dialog box indicating that there is no available connection and that the user should resolve it with their device carrier. Does that make sense?
I do NOT want to reference an XML file containing all carriers' APN information because I am aiming for worldwide support in my app.
03-03-2010 08:01 PM
His web browser as using BIS-B - that's why it worked and your app did not.
If you are going global, you might want to consider joining the alliance program for BIS-B access.