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.
Related
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.
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/
I'm planning on starting a new project, and am evaluating various web frameworks. There is one that I'm seriously considering, but I worry about its lasting power.
When choosing a web framework, what should I look for when deciding what to go with?
Here's what I have noticed with the framework I'm looking at:
Small community. There are only a few messages on the users list each day
No news on the "news" page since the previous release, over 6 months ago
No svn commits in the last 30 days
Good documentation, but wiki not updated since previous release
Most recent release still not in a maven repository
It is not the officially sanctioned Java EE framework, but I've seen several people mention it as a good solution in answers to various questions on Stack Overflow.
I'm not going to say which framework I'm looking at, because I don't want this to get into a framework war. I want to know what other aspects of the project I should look at in my evaluation of risk. This should apply to other areas besides just Java EE web, like ORM, etc.
I'll say that so-called "dead" projects are not that great a danger as long as the project itself is solid and you like it. The thing is that if the library or framework already does everything you can think you want, then it's not such a big deal. If you get a stable project up and running then you should be done thinking about the framework (done!) and focus only on your webapp. You shouldn't be required to update the framework itself with the latest release every month.
Personally, I think the most important point is that you find one that is intuitive to your project. What makes the most sense? MVC? Should each element in the URL be a separate object? How would interactivity (AJAX) work? It makes no sense to pick something just because it's an "industry standard" or because it's used by a lot of big-name sites. Maybe they chose it for needs entirely different from yours. Read the tutorials for each framework and be critical. If it doesn't gel with your way of thinking, or you have seen it done more elegantly, then move on. What you are considering here is the design and good design is tantamount for staying flexible and scalable. There's hundreds of web frameworks out there, old and new, in every language. You're bound to find half a dozen that works just the way you want to think in your project.
Points I consider mandatory:
Extensible through plug-ins: check if there's already plug-ins for various middleware tasks such as memcache, gzip, OpenID, AJAX goodness, etc.
Simplicity and modularity: the more complex, the steeper the learning curve and the less you can trust its stability; the more "locked" to specific technologies, the higher the chances that you'll end up with a chain around your ankle.
Database agnostic: can you use sqlite3 for development and then switch to your production DB by changing a single line of code or configuration?
Platform agnostic: can you run it on Apache, lighttpd, etc.? Could you port it to run in a cloud?
Template agnostic: can you switch out the template system? Let's say you hire dedicated designers and they really want to go with something else.
Documentation: I am not that strict if it's open-source, but there would need to be enough official documentation to enable me to fully understand how to write my own plug-ins, for example. Also look to see if there's source code of working sites using the same framework.
License and source code: do you have access to the source code and are you allowed to modify it? Consider if you can use it commercially! (Even if you have no current plans to do that currently.)
All in all: flexibility. If I am satisfied with all four points, I'm pretty much done. Notice how I didn't have anything about "deadness" in there? If the core design is good and there's easily installable plug-ins for doing every web-dev 3.0-beta buzzword thing you want to do, then I don't care if the last SVN commit was in 2006.
Here are the things I look for in a framework before I decide to use it for a production environment project:
Plenty of well laid out and written documentation. Bad documentation just means I'm wasting time trying to find how everything works. This is OK if I am playing around with some cool new micro framework or something else, but not when it's for a client.
A decently sized community so that you can ask questions, etc. A fun and active IRC channel is a big plus.
Constant iteration of the product. Are bugs being closed or opened on a daily/weekly basis? Probably a good sign.
I can go through the code of the framework and understand what's going on. Good framework code means that the projects longterm life has a better chance of success.
I enjoy working with it. If I play with it for a few hours and it's the worst time of my life, I sure as hell won't be using it for a client.
I can go on, but those are some primary ones off the top of my head.
Besides looking at the framework, you also need to consider a lot of things about yourself (and any other team members) when evaluating the risks:
If the framework is a new, immature, "bleeding-edge" framework, are you going to be willing and able to debug it and fix or work around whatever problems you encounter?
If there is a small community, you'll have to do a lot of this debugging and diagnosis yourself. Will you have time to do that and still meet whatever deadlines you may have?
Have you looked at the framework yourself to determine how good it is, or are you willing to rely on what others say about it? Why do you trust their judgment?
Why do you want to use this rather than the "officially sanctioned Java EE framework"? Is it a pragmatic reason, or just a desire to try something new?
If problems with the framework cause you to miss deadlines or deliver a poor product, how will you talk about it with your boss or customer?
All the signs you've cited could be bad news for your framework choice.
Another thing that I look for are books available at Amazon and such. If there's good documentation available, it means that authors believe it has traction and you'll be able to find users that know it.
The only saving grace I can think of is relative maturity. If the framework or open source component is mature, there's a chance that it does the job as written and doesn't require further extension.
There should still be a bug tracker with some evidence of activity, because no software is without bugs (except for mine). But it need not be a gusher of requests in that case.
Are there any other database engines that could be used on the iPhone, besides sqlite3? Something like textDb is for PHP, single-file and no server.
There are a slew of alternatives to SQLite, but there is little point to using them as others have pointed out.
Before pointing out some alternatives, some points:
First, SQLite is an excellent single-file, non-client-server, small-footprint SQL database. The performance is excellent, it is a relatively tiny runtime, and it is thoroughly fast. There isn't an embeddable SQL-interpreting alternative that is either all around technically superior or anywhere near as popular.
Secondly, if you are doing persistency in an iPhone application, you should very likely be using CoreData. There are certainly reasons not to, but they are pretty uncommon. Beyond being a higher level mapping to a relational store that is quite adeptly integrated with Cocoa Touch, Core Data solves a number of very difficult problems above and beyond persistency; object graph management, efficient memory use (i.e. push stuff out of memory when no longer needed), and undo support, to name a few.
Finally, if you do decide to use some other database persistency layer, keep in mind that the iPhone 3G and prior is an extremely memory constrained runtime environment. The very presence of any kind of additional library can significantly reduce the working memory available to your app. Whatever solution you choose, make sure it is optimized to use as little memory as possible.
So, seriously, if you are looking to not use SQLite or CoreData it is either because you have a very rare case where they aren't appropriate or because you are being curious. If curious, well... good for you!
If you are looking for alternatives, the SQLite documentation includes a set of links to similar products.
Pretty sparse list and it isn't because the author is hiding anything. There simply isn't a lot of motivation in the industry to try and re-invent this particular wheel because SQLite does a really good job. There is a reason why Google, Adobe, GE, FireFox, Microsoft, Sun, REALBasic, Skype, Symbian, Apple, and others have pretty much standardized on SQLite to solve their non-client/server relational persistency needs; it just works.
If you're looking for an alternative, I would say Core Data.
I had the same question for a long time and even used SQLite in some projects. After speaking with an Apple Engineer though, he pointed out that Core Data could do everything that I was using SQLite for (mainly just storing information and accessing it in a few different ways).
I would start with the with Core Data Programming Guide and see how it works for what you're looking to do.
I think your problem is that you are thinking of a software library more like a software product. People want choice between Internet browsers for all sorts of reasons. But when you have a software library, it's pretty much set up for one purpose. If it doesn't fulfill that purpose well enough, it shouldn't be a library.
Do you not like NSObject? Do you not like the Core Foundation library? Then write your own. However, to drag up an unfortunately overused analogy, don't reinvent the wheel, unless your job is making new and innovative wheels.
SQLite does perform acceptably, and so it is supplied as a library on the iPhone platform. SQLite works for what I need it to do. If it doesn't work for you, then maybe you have some reason you'd like to share?
Freedom of choice is fine if you want to choose between Internet browsers, but I would think that as a programmer, one should have a very specific reason for going out of their way, spending valuable time to fix something that already works. Even with my choice of Internet browser, I have specific reasons I choose one over another.
No. Everyone seems to be happy with SQLite.
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.