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.
Related
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.
I'm just creating my first project in Cappuccino without a lot of success. Looking for examples and documentation, there isn't a lot out there...
The differences from real Objective-C and the lack of libraries mean you cannot easily convert code directly from say a OS X desktop app. to Cappuccino.
As an experienced PHP, and RoR developer (besides the Java, VB, VC.....) I can't quite see the logic of abstracting/wrapping JavaScript in another language.
Any comments or suggestions for a more efficient framework?
If you have specific questions that can't be answered in the IRC channel (it just depends who's in there) you should post the question to the mailing list and someone will help you.
As for why you would want objective-j I'll point you to this blog post which contains several reasons why objj exists. http://cappuccino.org/discuss/2008/12/08/on-leaky-abstractions-and-objective-j/
I have converted several Objective-C classes nearly line for line into Cappuccino. Mostly it's a matter of changing NS to CP and changing pointers to non-pointers. What differences between Objective-C are you thinking about?
Indeed you could even take your existing XIB files from your Cocoa desktop app and convert them to Cappuccino using nib2cib. Here's how to work with Interface Builder using XCode 4: http://groups.google.com/group/objectivej/browse_thread/thread/786331dbcbc9c7b1.
I also recently started a project in Cappuccino and what I could say is: definitely it worth it. I'm used with javascript as well as (but less) cocoa (which helps). In short, the javascript is very fine, probably one of my favorite language because of it's flexibility. But it does lack of structure. For example there is no class in javascript and you have to trick with object inheritances, prototyping and so on. By using the Cappuccino framework at first you have all those very convenient facilities but also you do not reinvent the wheel each time. This is cross browser standardized so that you only have to focus on your code and not on the IE whims. As it is based on cocoa, cappuccino also comes with the MCV scheme in mind which again let you structure your project in an efficient way.
Ok you probably already know all this. What I could tell now about the learning curve is that I had to find the right tools to really get in. i.e.Installing cappuccino (sudo Starter/bootstrap.sh), creating a simple nib application (capp gen -t NibApplication YourApplication) then using xcodecapp-cocoa to listen, convert and open the project into Xcode what probably the hardest part of this learning curve to me…
Now if you are still not satisfied with cappuccino, I can only suggest to look at another framework like http://javascriptmvc.com/ , www.grooveshark.com used it to do their amazing webapp-site but I personally would never go back to html for building a web application. (conversely I would not use cappuccino for a webpage neither, "The cobbler should stick to his last")
I began writing cappuccino a couple of months ago and had a lot of difficulty when it came to setting up the proper development environment. I also had numerous problems writing working client server code that worked well.
I eventually broke through and started doing better with Cappuccino and then I found these video tutorials that would have helped so much earlier on. They did cost me $30 but I really wished I had watched these at the start because they help you get set up properly as a developer and get you started on the right learning curve.
I actually discovered these videos when using Cappuccinos IRC which has helped me a couple of times when I couldn't find an answer.
Info on the videos here: http://cappuccino.org/discuss/2011/10/19/cappuccino-training-course-ideveloper-tv/
At my current job, it goes without question that if a new version of a technology that we use in our project is released, we upgrade it ASAP. At my previous job, that was not the case... we had to convince management that it was necessary. As such, we often had to do without features that could have been helpful and continue living with bugs that had long ago been fixed. At times, it was even hard to get support for the old versions we were using. I don't really see that point of view, especially after experiencing the opposite approach. Are there really 2 sides to this question?
Of the two approaches, I absolutely would prefer the one where you are now. Having applications falling behind can be painful for many reasons, some of which you noted.
The only caveats would be centered around time, really; it would usually take some non-trivial amount of time to update something for new frameworks/dependencies. It's nice when frameworks maintain backward-compatibility, but that does not always happen.
Breaking changes are usually obvious, and usually (we hope) exist for some very good reasons. More troublesome are the silent changes that do not prevent building, but cause subtle bugs; like a library function with the same signature, but which has slightly different behavior or return results.
But if an application is meant to be supported long-term, keeping it up-to-date is really a must, IMO.
There is a grey area that lies somewhere in the middle.
Your old place lived by a "don't rock the boat" approach. Yes the stuff might not be up to date but they knew what it could do (and maybe couldn't) and how to handle it. If theres an issue you hopefully know its not the kit as its been around the block (or you've been around the block find out all the bugs in it and how to handle them and keep your kit up and running).
Your new place puts all their faith in the fact that the newer kit must be better and can't possibly have been released without lots of checks and balances. Yes there might be some quirks but knowing some of those old bugs are no more (well the release docs say its fixed anyway) is worth the time spend finding new bugs in the latest release.
Its a fine line to tread and depends very much on what the tech is used for and how mission critical it is.
Yes, there certainly are two sides to this question. I'll weigh in on the side of not upgrading whenever a new version is released ...
If it ain't broke don't fix it. If your system is working then any
change is a risk, not all risks are
worth taking.
If you upgrade every time a new
release of any component pops up you
will find yourselves following other
people's schedules.
Change management is vital discipline for robust and reliable systems.
Are there any guidelines on pitfalls to avoid while developing iPhone applications?
Sure, thousands. The same is true for any software development. Unfortunately, the easiest way to enumerate them is to write them down on a sheet of paper while waiting for a friendly soul to release you from the one you just fell into.
However:
Don't try to reinvent the wheel. The iPhone API is very complete -- you just have to LOOK for the facility you need. Things are NOT always implemented the way you would expect. Read the guides, carefully. Look at the tutorials and analyze how they work. (Try changing a line here or there in the tutorial to see what difference the change makes.) The single biggest mistake I have made in 1 year of iPhone development is not trying hard enough to find the iPhone way of doing something.
Don't ignore memory management; master it early and often. Use the Object Allocation and Leaks tools in Instruments to check for memory leaks frequently. I'd recommend checking after you complete each feature or view; more often than that if you keep finding bugs. Eventually you may understand it so well you can stop doing this.
Don't just use the default build settings. Play around with them to understand what they do. Figure out certification and distribution. GET INTO THE DEVELOPER PROGRAM QUICKLY -- it can take a while to push through that pipeline. [ AND when you get that notification that you need to renew, get it on instantly -- there have been problems with that process. ]
Don't neglect to read the Human Interface Guidelines (HIG) carefully. If they say not to do something -- DON'T DO IT. Apple will reject applications that misuse their iconography.
Don't stint on marketing. Yes, the App Store puts your app in front of millions of people... In theory. But the odds of getting front-paged are slim. There are a lot of great apps on the App Store that haven't sold much because no one knows about them.
Don't rest on your laurels. If a new technology comes out, find out if it makes your job easier; if it does, take the time to learn it. Personal example: I'm just now trying to switch from SQLite-based data management to Core Data, because I was in a hurry at the time I started my most recent project; now I wish I had slowed down and thought about it.
Don't go into your design thinking (for example) "How do I implement my concept with a table view?" It's true that table views are natural for many informational and utility applications, but don't be constrained. Instead, think about what users will want to be able to do, how you can make it easier for them -- put things together that will be used together, etc. If you've never explored the concept of Use Cases, read up on them.
Don't hesitate to build composite views. Many of the questions I have seen here on Stack Overflow have to do with putting a toolbar at the top of a table, or having an image in the background of a text field. I understand the desire to do things the easy way, and as I state in #1 above, if there is an easy way, use it. But in many cases the solution is just to layer a couple of views with appropriate placement and transparency.
Think about what might be Apple-approved from the start.
App Rejected is one of several useful sites to help understand Apple's mostly undocumented standards. (One more.) (A previous question on app store rejection reasons.)
A few quick examples:
Using a UIWebView can get your app a 17+ rating.
Coding with an undocumented/private API = rejected
Version number < 1.0 might= rejected
Not enough feedback about network success/fail = rejected
Too much network use = rejected
Clearly limited free version vs full version = rejected
The word 'iPhone' in the app name = rejected
The above links contain many more examples, and more details about those examples.
Don't neglect the programming guides. While the documentation is quite extensive, the programming guides contains a veritable trove of useful tips and "insider" information that simply cannot be gleaned from reading method definitions. I spend just as much time reading the guides for a technology (say, Core Data) as I do actually implementing it.
Don't assume you know what a method does. If you have any degree of doubt about the functionality of a method, it is well worth your time to go look it up in the documentation to verify.
Wonderful examples from #Amagrammer above.
I would love to add that the first place to start is iPhone development is Photoshop. This is still the best advice I can give to anyone who is starting out. I now use OmniGraffle because it has awesome stencil templates.
What I find is that even for super simple app's, draw up your prototype and look for usability issues and work flow issues. It is 100x quicker to redraw your app than re-code it. I have fallen into this trap numerous times and now actually draw up some pretty simple functionality to see what it will look and feel like.
This advice will save you 10s maybe even 100s of hours in hopefully getting your app right first time and getting you to think through what the issues are. Throwing away code sucks and I have done it not because the code was bad but because it made the usability or solution worse. I think the best of us end up throwing code away and prototyping your design definitely will help in having to RTFM for something you did not have to build in the first place.
If you don't have an great designer, and can't do great design by yourself, then don't even start iPhone app development. This rule only applies if you want/need to make money with your apps.
By using somebody else's works you advertize the authors of those works (At least, among other programmers). Do you think it is cool?
This line of questioning could go up one more level and become "Programming Languages: Do you think it's cool to use those?" Because someone(s) wrote those too. I can continue this up to the types of computers, to the components, etc...
Monet did not make the brushes or the paint or the canvas (well maybe, not sure). But who creates those building blocks is not quite what stands out at the end.
Languages/Frameworks/etc were built and released to be utilized by the masses (or make money for the creators).
I think it's always cool. Be more efficient, reduce redundancy, promote other useful code.
If you're trying to learn though, reading and understanding the framework you're using is very helpful. There are always other things you can be programming and learning, not necessarily reinventing the wheel.
If using their work has saved you time reimplementing the same thing (but with more bugs) then don't they deserve credit?
Or put another way, stealing other peoples' work without credit (or paying them, depending on whether we're talking about free or commercial software here) isn't cool.
Of course, nobody's stopping you from writing your own framework, if that's what you want to do...
It depends on what kind of programming you're doing.
Are you doing it to achieve a finished program? Then a framework could save you a lot of time.
Are you doing it to create something truly original? Then a framework might simply tie you into an existing way of thinking.
Rembrandt made his own paints. Michelangelo selected his own marble from the quarry. Alan Kay said "People who are really serious about software should make their own hardware". The Excel team famously has their own compiler. The iPhone ain't just an alternate firmware for the Blackberry. ISTM if you want to be at the very top of your game, you've got to get down and dirty with the nitty gritty of it.
I don't know anything about advertising, other programmers, or what's "cool", so I can't respond to those parts of your question.