stringWithContentsOfURL different result with wifi - iphone

I have the following code:
NSString *url = [NSString stringWithContentsOfURL:myURL encoding:NSStringEncodingConversionAllowLossy error:&error];
and I get a different string using Wifi than with my mobile network.. Basically it's the same, but I get it without the spaces.. just like this in wifi:
<html> hello </html>
would be this with my mobile network:
<html>hello</html>
how can this be?
I am using iPhone SDK 6.0 and Xcode 4.5.

I think this is because, when you try to get data using mobile data, the information in the header is sent that the request has been with mobile data, so it tries to minimize the response, and thats not the case with wifi, it doesn't try to minimize the response while using wifi.

Related

iOS stringWithContentsOfURL gives HTML error

I am trying to Parse Google Maps api with SBJSon but before parsing when I use the below code gives me the Access Denied errors in the HTML this error comes only when I run on the Device and If I run the same in the simulator ..it gives me the google maps api string..what should be the error for Device running.
NSString *String = [NSString stringWithContentsOfURL:url
encoding:NSUTF8StringEncoding
error:nil];
NSLog(#"string %#",string);
error
<HTML><HEAD>
<TITLE>Access Denied</TITLE>
</HEAD>....
full Html error is similar of
Setting Proxy Username & password using Objective-C - iPhone
The network your device is connected to does not allow access to the URL. Since you are able to access the URL from your MAC, connect your device to the same network as your MAC. It should work.
Alternate solution, first access some URL from the device Safari browser. If asked for authentication, provide correct username and password. Once connected, do not close the tab or Safari app. Run your application and the URL should now work.
EDIT
If you still face authentication problem, may be you are better off implementing asynchronous downloader which implements NSURLConnectionDelegate. Provide the authentication parameters in method,
- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;
The API you are using stringWithContentsOfURL:encoding:error: will not give you much flexibility.
Hope that helps!

ASIHTTPRequest problem with parameters using 3G conneciton (Fine with Wifi)

I have one user of my iPhone application who is complaining it does not work when using his mobile data connection (but works fine via Wifi). My application make a request to a third party REST API and I use the ASIHTTPRequest library for this.
One parameter of my HTTP request is a username (which is an email address), so I encode the username using the following code:
-(NSString *) encodeString:(NSString *) string
{
NSString * returnString = (NSString *)CFURLCreateStringByAddingPercentEscapes(
NULL,
(CFStringRef) string,
NULL,
(CFStringRef)#"!*'();:#&=+$,/?%#[]",
kCFStringEncodingUTF8 );
return [returnString autorelease];
}
This then gets built into a URL as follows:
// Setup the url we need to make the request to the sharkscope API
NSString * urlString = [NSString stringWithFormat: #"%SERVICEADDRESSHERE?Username=%#&Password=%#",
encodedUserName, m_md5Key];
NSURL * url = [NSURL URLWithString:urlString];
request = [[ASIHTTPRequest requestWithURL:url] retain];
What get's sent out of my application is a request with the following Username:
Username=Fred.Bloggs%40wanadoo.fr
For this one user, what is received at the server when using his mobile data connection is:
Username=Fred.Bloogs%2540wanadoo.fr
So clearly the % character is being encoded somewhere between me making the call to requestWithURL and it arriving at the server. I can't understand the reason because I have hundreds of other users who can run the requests fine via their data connection.
Do I even need to encode the values passed into requestWithURL?
Does anyone have any idea at what stage the % character is being re-encoded. I'm guessing it must be in ASIHTTP library, but can't work out what circumstances would trigger it in this case.
The corruption is probably happening because of a proxy or transparent proxy on the 3G connection, put in place by the carrier.
Possibly workounds:
Use POST instead of GET
Use https instead of http
Use http on a non-standard port
To prove this theory, you could try asking him to enter the same / similar request in Safari on iOS when he's using the 3g connection.

Cannot get the MPMoviePlayerViewController to play my media file

Having some issues getting this MPMoviePlayerViewController to work. I have two sample URLs pointing to the same Quicktime movie. The commented out URL doesn't work; the other one works fine.
I've monitored both via Fiddler and I can't see any issues in headers/etc.
Basically I'm trying to figure out a way to play an Azure hosted media file with some sort of security; either via pass through WCF service. Any one have this figured out? I'm pulling my hair out.
//NSString *moviePath = [[NSString alloc] initWithString:#"http://www.nov8rix.com/Services/CPipeline.svc/Media/42"];
NSString *moviePath = [[NSString alloc] initWithString:#"http://nov8rixstorage.blob.core.windows.net/searchpad/tutorial_portrait.mov"];
NSURL *url = [NSURL URLWithString:moviePath];
[url retain];
MPMoviePlayerViewController *mp = [[MPMoviePlayerViewController alloc] initWithContentURL:url];
[self presentMoviePlayerViewControllerAnimated:mp];
[mp release];
[url release];
Update: This is the error I'm receiving:
NSConcreteNotification 0x892e540 {name = MPMoviePlayerPlaybackDidFinishNotification; object = <MPMoviePlayerController: 0x8921570>; userInfo = {
MPMoviePlayerPlaybackDidFinishReasonUserInfoKey = 1;
error = "Error Domain=MediaPlayerErrorDomain Code=-12939 \"The server is not correctly configured.\" UserInfo=0x892ecb0 {NSLocalizedDescription=The server is not correctly configured.}";
A brief search on the web mentions that my problem may be that my media connection doesn't support byte Range Requests. This is probably true. Is there a way to allow Range Requests with WCF?
Yay I finally got this to work! The reason it was not working was because my WCF services didn't support Range Requests. Apparently iPhone Movie streaming requires range requests.
I changed my implementation to make direct requests to the Azure blob storage via SAS URLs. Works so far!
Thanks for posting your answer. I had the same error with my MPMoviePlayerViewController, and my problem was fixed too when I added support for Range Requests to my php mp4 file streamer. Streaming media to the iPHone requires some specific headers, else you get the "The server is not correctly configured" error.
I found some great hints for php Range Requests support here:
fread, (PHP 4, PHP 5), fread — Binary-safe file read

Tracking iPhone on Yahoo Web Analytics using ASIHTTPRequest

I'm trying to track an event in my app using Yahoo Web Analytics. The code I am using looks like
ASIHTTPRequest *yahooTrack = [ASIHTTPRequest requestWithURL:
[NSURL URLWithString:#"http://s.analytics.yahoo.com/p.pl?a=xxxxxxxxxxxxx&js=no&b=yyyyyyyyyyyy&cf6=zzzzzzzzzzz"]];
yahooTrack.didFinishSelector = #selector(statisticsFinished:);
yahooTrack.delegate = self;
[yahooTrack startAsynchronous];
Then the statisticsFinished looks like:
NSLog(#"Cookies: %#", request.requestCookies);
NSLog(#"Redircount: %d", [request redirectCount]);
NSLog(#"Responsecode %d %#\nMsg: %#", request.responseStatusCode,
request.responseStatusMessage, [request responseString]);
And all the information I get back looks correct. Cookies are set, redirectcount is 1 the first time (as it redirects to s.analytics.yahoo.com/itr.pl?.... a normal browser does). Then the redirectcount is 0 for subsequent request until the app is restarted and session cleared. The responseString returns GIF89a.
Even if the data looks correct, Yahoo still won't track. As soon as I call the tracking url directly in my browser it works as expected.
I realize Flurry is a better option, but I'm forced to use Yahoo in this case. Also, using a UIWebView probably would work, but I'm against putting in a webview just for tracking purposes.
Is there any difference in how ASIHTTPRequest and Safari would handle a call to a simple URL as this? Or do you see anything else that could explain why the tracking isn't working?
I finally found the problem. ASIHTTPRequest creates a user-agent based on your applications name, and requests from this user agent is ignored by Yahoo somehow (bug?). As stated in the documentation, you can override the user-agent as follows:
[request addRequestHeader:#"User-Agent" value:#"My-User-Agent-1.0"];
I used the user-agent string of Safari on iPhone, and it worked immediately! BTW; the same problem applies for Android, and the same fix works.

How to use iPhone Custom URL schemes

I've got an app that I want to be able to use Custom URL schemes for. I want users to be able to open Tweetie using the Custom URL protocol however I need to populate the tweet with dynamic website link which I get using currentItem.link.
I found this code which launches Tweetie and populates a message with static information:
NSString *shortened_url = #"http://your.url.com";
NSString *stringURL = [NSString stringWithFormat:#"tweetie://%#", shortened_url];
NSURL *url = [NSURL URLWithString:stringURL];
[[UIApplication sharedApplication] openURL:url];
So using the above code how would I populate the message with currentItem.link information?
Thanks.
It depends entirely on the application on the receiving end. You have to find out how their protocol works, then you can use their protocol as it is designed.
Adding a http:// protocol URL to the end of a tweetie:// protocol URL is not the correct method, and searching for how the Tweetie URL protocol works would be suggested.
The Tweetie protocol is documented, but it's not clear how much of this still applies since the client was converted to the official Twitter one. I believe that the format you want is:
NSString *stringURL = [NSString stringWithFormat:#"tweetie://post?message=%#", shortened_url];
I have already tried this to get the account selection parameter to work. The basic method works, but account selection does not for me.