I am using currently ASIHTTPRequest for communicating with the server, however it's causing crashes. The bug is known for a long time, but is still an issue.
Therefore: Are there good alternatives to ASIHTTPRequest? I am flexible on the server side, i could also use sockets or using something else.
What would you recommenend for server client communication?
Here is the link to the topic where the author is giving some ASIHTTPRequest alternatives.
List of them with links from topic:
AFNetworking
LRResty
RestKit
AWS SDK for iOS
ShareKit
NSURLRequest/NSURLConnection
I know it's probably not the answer you are looking for, but if ASIHTTPRequest is crashing then it's at least 90% likely that there's an error in your code - the most common problems all relate around request vs delegate lifetime issues. NSURLConnection might well just give you a different set of problems (though it might just work well). NSURLConnection also has a lot fewer features (no caching etc).
Generally, you need to remove the delegate from ASIHTTPRequest before the delegate is destroyed (ie. at the very start of the delegate's dealloc method). So long as this is done, there is no way for ASIHTTPRequest to call a deallocated delegate. You must do this for every request, including ones that have been cancelled.
The bug you link to seems to relate to one very particular circumstance, and at least a one reason it's not been fixed is that it appears no one else has been able to reproduce it.
(I'll caveat this with the statement that their have been problems with ASIHTTPRequest in the past - in particular the release of v1.7 contained some race conditions that could cause crashes, but these were later fixed in the git tree. I've not personally tried v1.8, but v1.7 with the fixes is working very well for me.)
It might be worth posting a new question detailing the crash you're seeing and sharing some of your code / how you use ASIHTTPRequest.
ASIHTTPRequest is pretty popular and used by a good number of applications so, as JosephH suggests, it's more likely that there's a bug in your code.
Having said that, if it is in ASIHTTPRequest then it's open source -- you can fix it. I'm sure the maintainers would appreciate a patch. A BAD_ACCESS is likely over-releasing memory.
It's difficult to suggest an alternative since you don't say which features you're using. You could just use the native NSURLConnection if you're just using the basics (I wrote a thin wrapper around it and I'm sure there are a bunch of others out there). At the other end of the spectrum, there are REST libraries that integrate with Core Data too (RESTKit).
Related
I know this question has been asked a lot of time and a lot of suggestions exist on the net. But i am still not able to conclude what is the right way.
After ASIHTTPRequest becoming obsolete, i think it is not advisable to use any third party libraries(though AFNetworking is really good), hence i am trying to build a one on my own.
I want to have following features in it Asynchronous concurrent
connections
Support of delegate methods to track connection progress
Support of doing authentication
Ability to cancel any connection and restart
I did came across multiple recipes using NSOperation, GCD, NSBlockOperation, NSRunLoop, etc. Also i did check the code of AFURLConnectionOperation but it is hell lot of a code which i think can be over kill in many situations.
Can anyone suggest me the optimum and minimalist way to achieve my requirements?
I have been using ASIHTTPRequest for quite a while now and i quite satisfied with it. However since it has been deprecated, I am considering replacing it. My first though was to go with the NSURLConnection, but I found out that ASIHTTPRequest actually does quite a lot. For example I like its queue handling.
The iPhone application that I am working on uses a REST API, so I have been considering RESTKit. Is is possible to use RESTKit without Core Data? As it is know I have pure dataobjects and I do not want to use Core Data, not right now anyway.
Are there any other good alternatives to ASIHTTPRequest?
BTW I know that there is a similar question but this is more specific.
I think that AFNetworking is a good solution.
Pros:
Small
Well documented
Simple to install, only copy the source code into your project.
Simple to use.
An excellent category for UIImageView for loading icons in the background.
Cons:
No way of setting the timeout for requests. (Applies to v0.9.0)
I can definitely recommend RestKit, I make use of it a lot! It handles common stuff for you and no, you don't have to use Core Data. RestKit can work with it, but that is just a nice feature.
A good starting point for using RestKit is the wiki on github.
RestKit relies on AFNetworking as a networking framework. If RestKit seems to be an overkill, you may want to try only this one.
Try the BYRequest:
BYRequest based on MKNetowrkKit, but it works like ASIHttpRequest, so you can easily migrate your project from ASIHttpRequest to BYRequest and also enjoy ARC.
https://github.com/BoydYang/BYRequest
I am about to develop an application for iPad and it has enormous amount of background thread network calls.
I would like to know which one will be better? ASIHTTPRequest still works but not maintained. However few sources says AFNetworking framework creates lots of complications.
Update (September 2013)
It's been nearly two years since I originally wrote this answer, and quite a lot has changed. AFNetworking is about to go into version 2.0 and has a thriving developer community, whereas ASIHTTPRequest is pretty much dead. Additionally, AFNetworking has dozens of great helper libraries and classes available for handling things like OAuth, Amazon S3, and the like. It's so popular that there's several books available on it.
Given this, there's no reason at all to keep using ASIHTTPRequest. My original answer is below, so if you're still interested do read on - just bear in mind I would now recommend without a doubt not using ASIHTTPRequest and going with something more modern (namely, AFNetworking, but other options are available).
Original Answer (December 2011)
How much time have you got? Here's my thoughts, although as a subjective question I don't think there's a right or wrong answer.
I lead a development team that works on commercial apps for sizeable clients, and some of my colleagues are always on the look-out for new libraries that can make things easier. Currently I guess the vast majority of our networking uses ASIHTTP. We took a look at AFNetworking about six months ago, and decided at the time we'd stick with what we know. ASI has been around for a while, and there is far more documentation and helpful advice available online for it. It is a solid codebase, and been around long enough to have gained a lot of traction and respect.
That said (and hopefully people who disagree with everything I've said above will read on!), I think if you're starting afresh now is the time to move on to something else. Even the developer of ASI thinks so. Given all of the changes that have come with iOS 5, I think a modern actively maintained framework like AFNetworking (and there are other options, like RestKit) is a good choice.
Now, you're right to say some people have trouble using AFNetworking in their application. But equally, a quick google reveals many people who had problems with ASI (valid or not)! I think whatever framework you go with, someone somewhere will have had trouble with it, either through something genuine wrong with the framework or their own limitations.
So with all this in mind I think I'd dive in to AFNetworking, and see how you get on! One of my new year resolutions will be to migrate over to a new networking library, and I think it will probably be AFNetworking.
From Author's Comment:
A little update: I've actually really enjoyed using AFNetworking, and in many ways it's considerably better (probably not the right word: 'refined', maybe) than ASI. That said, you shouldn't go into it expecting a 'like for like' replacement, and there are certain things you may want to consider other options for (Amazon S3, which ASI supported out of the box for example). But I'm generally really pleased, and find it a clear, well documented library. So if you're looking to move from ASI to something else, you really can't go wrong with AFNetworking...
https://github.com/BoydYang/BYRequest
BYRequest based on MKNetowrkKit, but it works like ASIHttpRequest, so you can easily migrate your project from ASIHttpRequest to BYRequest and also enjoy ARC.
Ben Copsey has abandoned ASIHTTPRequest. It has been announced almost two months ago but I just realized it.
I'm in the middle of a project using it. It wouldn't be an huge problem for me to replace it with something else at this stage (everyone is talking about AFNetworking right now), but:
If I can avoid replacing it it's better. I'd rather spend that time working on other things
I'd like to support iOS < 4, but AFNetworking and LRResty are 4> only
I also have a few other apps that heavily depend on it
I'm pretty sure other folks are in my situation. So my question is: is it safe to continue using it?
If it works for you already, there is no point replacing it. Ben has only stopped development of it himself, that doesn't mean others are not free to continue developing it.
It just means that it won't get updated.
On the blog post he has provided other options that you can use.
I would continue using it. He probably quit working on it because it had all the functionality possible and was complete for all time (jk). Seriously though, it's a great library and your only fear would maybe be something that might break in a new version of iOS, but I guarantee someone will develop a fix for something like that.
There's a really old thread from 2008 that mentioned NSUrlConnection is quite buggy and leaks a lot. Is this still the case?
Is there any Cocoa Touch class that already implements the chunked upload or am I better off using the CF classes?
NSURLConnection doesn't leak, but you DO need to know when and where to release your references to it. Bear in mind that on a mobile device, streaming upload is a bad plan, because you're keeping the radio on fairly consistently, and probably overriding whatever power management is designed to keep it inactive where possible.
In the mobile space, if it is at all possible to upload the file all at once, I would suggest going that way.