Sugar ExecuteRequest do not works

Elements C#
1

Hello

Here is my code:

Url _url = new Url("http://www.cnn.com");
        HttpRequest httpr = new HttpRequest(_url);
        Sugar.Http.ExecuteRequest(httpr, (response) => 
        {
               if (response.Success)
             {
                 //response.Code
                response.GetContentAsString(null, (content) => {
                    if (content.Success)
                    NSLog("Response was: " + content.Content);
                });
             }
        });

if callback block code (response.Success) is never reached. I have wrote code without Sugar which works:

NSString urlAsString = "http://www.cnn.com";
NSURL url = NSURL.URLWithString(urlAsString);
NSURLRequest urlRequest = NSURLRequest.requestWithURL(url);
NSURLConnection.sendAsynchronousRequest(urlRequest) queue(NSOperationQueue.alloc().init()) completionHandler(delegate(NSURLResponse response, NSData data, NSError error)
    {
        if ((data.length() > 0) && (error == null))
        {
        }
        else
            if ((data.length() == 0) && (error == null))
            {
                NSLog("Nothing was downloaded.");
            }
            else
                if (error != null)
                {
                    NSLog("Error = %@", error);
                }
    });

Checked Sugar code and problem is with sendAsynchronousRequest and queue. When is null then there is no callback block code executed. When queue is NSOperationQueue then is working. Can You check if my Sugar code is correct (Sugar tutorial is outdated http://docs.elementscompiler.com/Tutorials/Sugar/Http/).

b.r.

2

Thanks, logged as bugs://72701

3

Ah, yes So passing NSOperationQueue.mainQueue instead of nil should fix this. Will fix own our end, as a workaround, can you just replace the call and rebuild Sugar — does that solve the issue for you?

i’ll review. what part, specifically?

thanx,
marc

4

I created http calls without Sugar but based on Sugar code and yes, it works when NSOperationQueue.mainQueue is passed instead nil (null).

This one is outdated:

Http.ExecuteRequest(new Url("http://www.elementscompiler.com"), (response) => {
  // handle the response
});

ExecuteRequest with Url as first parameter is commented in Sugar Http.pas sources.

Small tip. Please consider to use NSURLSession and dataTaskWithRequest if any changes You will made in Sugar, because NSURLConnection.sendAsynchronousRequest is deprecated in iOS 9 :slight_smile: NSURLSession It’s already available in past iOS versions, so no problem with compatibilty and also Apple resign from use any sync HTTP methods too from iOS 9. NSURLSession is simple to adapt and almost same as NSURLConnection

Here is info about NSURLConnection

https://developer.apple.com/library/prerelease/ios/documentation/Cocoa/Reference/Foundation/Classes/NSURLConnection_Class/index.html#//apple_ref/occ/clm/NSURLConnection/connectionWithRequest:delegate:

b.r.

5

Yeah, on my list to migrate to NSURLSession. ;). That said, NSURLConnection will continue to worrkfine in iOS9, and pro baby 10 and beyond. but we will make the switch of course.

6

Ah yes, but there’s

operator Implicit(aUrl: not nullable Url): HttpRequest;

which will auto-cast a Url to a HttpRequest. So the call will still work, even w/o the explicit overload.

7

Okay thanks for info :slight_smile: Anway I used NSURLConnection already for future compatibility.
What exactly do this operator Implicit? Any docs about it?

b.r

8

It just means that you can assign a Url where HttpRequest is expected,and the compiler will convert it for you.

Hmm, that’s a shame :(. You shod use Sugar.Http, and it will eventually switch to NSURLSession w/o any change needed from you.

9

Thanks for explanation :smile:
No worry about Sugar, I’ll use it for other things because IT’S AMAZING idea :slight_smile: I had to use NSURLConnection becuase I must add mutexes (blocking method).

b.r.

1 Like
10

I’d love to hear more about what you needed there, so i can see if i can expose the necessary functionality in Sugar.Http.

11

Okay so, from iOS 9 only asynchronous HTTP connections will be possible. This is good, but in some cases is hard to adopt or will be hard to redesign actual project is somone used blocking HTTP calls. I choose [EDIT] semaphores, but I believe exists more elegant way. I had to use blocking calls, beacuse of nature of connection way where I need session ID and in cases when is invalid, need to be acquired again. So it need some kind of serialization. It will be nice if You will adopt blocking calls too in Sugar with NSURLConnection. :smile:

b.r.

12

Define possible. You mean when using NSURLSession? or in general?

13

By possible I mean “only” way. From iOS9 ONLY async HTTP connections are available in system. To make them sync (blocking), user must do self with for example semaphores or use dispatch_sync. So in general =>iOS9 do not have sync HTTP connections.

b.r.

14

So NSURLConnection.sendSynchronousRequest() returningResponse() error() will just start failing for apps that run on iOS 9? I have a hard time believing that, and don’t see in any exiting apps.

15

Is deprecated in iOS 9 > https://developer.apple.com/library/prerelease/ios/documentation/Cocoa/Reference/Foundation/Classes/NSURLConnection_Class/index.html#//apple_ref/occ/clm/NSURLConnection/connectionWithRequest:delegate:

I didn’t update to iOS 9 to give You response, but if is already deprecated, then maybe will work in iOS 9, but in newer OS releases will cause app crash if will be removed definitely :smile: I’m not iOS expert, but I assume that.

b.r.

16

right. deprecated != “will no longer work”

1 Like
17

Yea they will work :slight_smile: I have read some info on Apple page:
…
Deprecated FrameworksFrom time to time, Apple
adds deprecation macros to APIs to indicate that those APIs should no
longer be used in active development. When a deprecation occurs, it is
not an immediate end of life to the specified API. Instead, it is the
beginning of a grace period for transitioning off that API and onto
newer and more modern replacements. Deprecated APIs typically remain
present and usable in the system for some reasonable amount of time past
the release in which they were deprecated. However, active development
on them ceases, and the APIs receive only minor changes to accommodate
security patches or to fix other critical bugs. Deprecated APIs may be
removed entirely from a future version of the operating system.

That’s it’s good practice to leave deprecated API’s :slight_smile: :slight_smile: :slight_smile:

b.r.

18

No argument there. But that’s not the same as “asynchronous HTTP connections will be possible in iOS 9” :wink:

19

Hehe okay :smile: