Related
I've recently read the news on http://allseeing-i.com that ASIHTTP is being discontinued. I have much respect for the makers of the library. However, I am now looking for a substitute that also supports queued download (multithreaded) on iOS, that also supports a progress bar with appropriate information.
Is there any (hopefully lightweight) library, that is in an active development livecycle? ARC support would also be much appreciated.
Many thanks for your thoughts.
You may want to look at MKNetworkKit. In its words:
MKNetworkKit's goal was to make it as feature rich as ASIHTTPRequest yet simple and elegant to use like AFNetworking
It has a number of very nice features for queuing and managing offline situations.
AFNetworking is being lauded as a successor to ASIHTTPRequest. It is based on operation queues, and in my experience it works reasonably well. You could probably do what you want to do without a third-party library, but if you want to make it a little easier on yourself, a combination of AFURLConnectionOperation subclasses and the AFHTTPClient class will do nicely.
I wrote one recently. It's fully ARC compliant and fairly lightweight:
https://github.com/nicklockwood/RequestQueue
As of version 1.2 it supports download and upload progress bars (see the included ProgressLoader example).
Rather than make a monolithic framework like ASI, I've tried to keep this as simple as possible. That means you are free to mix and match it with other libraries for stuff like POST parameter generation, JSON parsing, etc.
How do I implement activesync protocol in iphone app?
Any advice, any docs and tutorials are well come.
I have read the Exchange ActiveSync and iOS 4 Devices from apple.
Is there any real docs for this?
Despite having asked a question in the comment, you might be looking for the Microsoft documentation of the Exchange Server Protocols.
If you're thinking of implementing your own client though, I would strongly advise you to pause and consider whether it's really worth it. As someone who's worked on a server-side implementation of these protocols, I can tell you they can get pretty complicated - and the documentation doesn't always give you enough information. (In some areas it's flat out wrong, too.)
It is hard, but not impossible to write an app which communicates via exchange active sync. The link to the Exchange Server Protocols in Jons answer contains a document named MS-ASWBXML. You have to write an encoder for wbxml on your own and the document describes clearly the needs. Additionaly I recommend strongly this document: http://www.w3.org/TR/wbxml/
If the low level is working, you have to implement the EAS-protocol on top ob wbxml, which is not trivial, because of bugs in the documentation, different behaviour of different protocol versions. It will be a lot of trial an error to examine, why the exchange server does not understand your requests ;-)
Using Apple's built in support just means using Apple's APIs for writing to the Address Book and Calendar Store on the phone. Your app isn't supposed to know anything about the way that data is synchronised: it just happens in the background.
If you want direct control over the synchronisation process, then Apple's APIs cannot help you. Jon Skeet's answer contains a link to Microsoft's protocol documentation, but as he mentioned you'll be setting yourself up for a world of pain.
EAS is really meant for device makers to implement and not normal application development. You should look over the ActiveSync Protocol documentation and look into licensing the protocol (yeah its a pay-for license) and then ask yourself if its worth all the trouble to write all the business logic, ecoding logic, intensive testing and the licensing. An alternative is to use Exchange Web Services (EWS), which might be a much better fit - more rhobust in many areas and no licensing needed.
You should also look at this: http://blogs.msdn.com/b/webdav_101/archive/2011/09/29/new-to-exchange-activesync-development.aspx
What are some of the less-known and interesting public APIs and frameworks that I can use for iPhone? In OS 3.0 they're supposed to be 1000 new APIs more than in 2.2, so which one of these are the most interesting and not so well-known?
There is the screen capture function that the newly approved streaming video iPhone apps are using. Though, normally its use would be prohibited (private API policy), Apple changed its stance on this one in particular.
CGImageRef UIGetScreenImage();
Link to devforums.apple.com
Although PDFKit is not available on iPhone, much of the Core Graphics level CGPDF stuff is. You can draw PDFs with a CGPDFContext, or parse existing PDFs with a CGPDFDocument.
There is the UIDataDetectors API. Not much documentation. But you asked for obscure ;-)
There is an API for the copy, cut and paste too. Not seen too many apps use this yet.
To be honest, I've tinkered with most of the new APIs. While they state a 1000 new APIs it's more like they've added 1000 new methods distributed across fewer what we'd call APIs.
There is the ExternalAccessory API. Not widely used as you need, well, external accessories. Maybe you can have some fun with this API and video goggles.
All the big ones I'm sure you already know about. CoreData is the biggest one for me. But the highlight for me in 3.0 were the huge number of small changes:
[UIApplication canOpenURL:] is great, as it means that you can only offer options if certain applications are loaded
Methods such as [UIViewController willAnimateRotationToInterfaceOrientation:duration:] make certain animations significantly easier
It's easier to work with toolbars (now part of UIViewController)
[UIViewController viewDidUnload] make certain memory management tasks simpler
Changes to table views and cells... it's not so much a single method as how they all interact that makes it much easier to work with than in OS 2.x
The copy/paste functionality is nice, though not terribly well documented
Since my main app still needs to build for OS 2.x I've not used all of these in anger.
A few years ago I did a lot of work with CGI.pm. I'm evaluating using it again for a quick project. Can someone bring me up to speed on the current state of developing with CGI.pm in the "Web 2.0" world? What are the best libraries on CPAN to use with it? Are there clean ways to include jQuery, YUI, other CSS libs, etc, and do some AJAX. There are of course lots of libraries on CPAN but what works and what is commonly used?
We aren't still doing this?
$JSCRIPT<<EOF;
...
EOF
I realize people are going to offer Catalyst as an answer. However, many people may have legacy CGI.pm apps they simply want to enhance. Is starting over really the best answer?
Personally, I'm no fan of Catalyst (too heavy for my taste) or Mason (mixing code and HTML is bad ju-ju), but I do quite well using CGI.pm for input[1], HTML::Template for output, and CGI::Ajax to provide AJAX functionality where called for.
If you're looking at frameworks, you may also want to consider CGI::Application, which is a widely-used and lighter-weight alternative to Catalyst/Mason.
[1] I can't recall the last time I called anything other than $q->param or $q->cookie from CGI.pm. There are still a lot of tutorials out there saying to use its HTML-generation functions, but that's still mixing code and HTML in a way that's just as bad as using here docs, if not worse.
Consider using something more modern, for example Catalyst. It will make your life much easier and you won't have to reinvent the wheel. I understand that it is just a small project, but from my experience many small projects in time become large ones :)
The "web 2.0" apps that I've worked with usually use client-side JavaScript to request JSON data from the server, then use that data to update the page in-place via DOM.
The JSON module is useful for returning structured data to a browser.
As far as including JavaScript, HTML, or whatever in a here doc - that was never a good idea, and still isn't. Instead, use one of the plethora of template modules to be found on CPAN. For a CGI, I'd avoid "heavy" modules like Mason or Template Toolkit, and use a lighter module for quicker startup, such as Text::Template, or Template::Simple.
Yes, you can write perfect web2.0 web applications WITHOUT using any framework on the server side in any language Perl, Python, Java, etc and WITHOUT using any JavaScript libraries/framework on the client side. The definition of web 2.0 is kind of a loose definition, and I'm guessing by web2.0, you mean Ajax or partial page refresh, then all you would really need is to focus on the following:
Know about the XmlHttpRequest object.
Know how to return JSON object from the server to the client.
Know how to safely evaluate/parse the JSON object using JavaScript and know to manipulate the DOM. Also, at least know about innerHTML. InnerHTML is helpful occasioanally.
Know CSS.
Having said that, it's a lot easier to use some framework on the server side, but not because it's required by web2.0 and it's a lot easier to use some JavaScript on the client like jQuery, mootools, YUI. And you can mix-and-match depends on your needs and your tastes. Most JavaScript provides wrapper around the XmlHttpRequest so that it works across all browsers. No one write "naked" XmlHttpRequest anymore, unless you want to show some samples.
It's perfectly possible to write "Web 2.0" apps using CGI.pm, but you'll have to do the work yourself. From what I've seen, the focus in the Perl development community has been on developing successor frameworks to CGI, not on writing helper modules to let legacy apps get bootstrapped into modern paradigms. So you're somewhat on your own.
As to whether to start over, what are you really trying to accomplish? Everyone's definition of "Web 2.0" is somewhat different.
If you're trying to introduce a few modern features (like AJAX) to a legacy app, then there's no reason you need to start over.
On the other hand if you're trying to write something that truly looks, feels, and works like a modern web app (for example, moving away from the page-load is app-state model), you should probably consider starting from the ground up. Trying to make that much of a transformation happen after the fact is going to be more trouble than it's worth for anything but the most trivial of apps.
I agree with Adam's answer, you probably want to use Catalyst. That being said, if you really don't want to, there's nothing preventing you from using only CGI.pm. The thing is, Catalyst is a collection of packages that do the things you want to make Web 2.0 easy. It combines the various templating engines such as Template Toolkit or Mason with the various ORM interfaces like DBIx::Class and Class::DBI.
Certainly you don't have to use these things to write Web 2.0 apps, it's just a good idea. Part of your question is wondering if javascript and CSS frameworks like jQuery, or prototype require anything from the server-side code. They don't, you can use them with any kind of server-side code you want.
For new apps, if you don't find Catalyst to your taste, Dancer is another lightweight framework you may like. There are also plenty of others, including CGI::Simple, Mojo/Mojolicious, Squatting...
Any of these lightweight frameworks can take care of the boring parts of web programming for you, and let you get on with writing the fun parts the way you want to.
If the jump from CGI.pm to Catalyst seems too daunting then perhaps something like Squatting might be more appropriate?
Squatting is a web microframework and I have found it ideal for quick prototyping and for replacing/upgrading my old CGI scripts.
I have recently built a small "web 2.0" app with Squatting using jQuery with no issues at all. Inside the CPAN distribution there is an example directory which contains some programs using jQuery and AJAX including a very interesting [COMET](http://en.wikipedia.org/wiki/Comet_(programming)) example which makes use of Continuity (which Squatting "squats" on by default).
NB. If required then you can later "squat" your app onto Catalyst with Squatting::On::Catalyst
There is also CGI::Ajax.
Every time I see Ruby or Python discussed in the context of web development, it's always with a framework (Rails for Ruby, Django for Python). Are these frameworks necessary? If not, is there a reason why these languages are often used within a framework, while Perl and PHP are not?
I can only speak towards Ruby - but, no, you don't need a framework to run Ruby based pages on the web. You do need a ruby enabled server, such as Apache running eruby/erb. But, once you do, you can create .rhtml files just like RoR, where it processes the inline ruby code.
The short answer is no, they are not necessary. In ruby you have .erb templates that can be used in a similar way as you use PHP pages. You can write a site in ruby or Python using several technologies (Rails-like frameworks, Templates or even talking directly with the HTTP library and building the page CGI-style).
Web frameworks like Python's Django or Ruby's Rails (there are many) just raise the level of abstraction from the PHP's or ASP's, and automate several process (like login, database interaction, REST API's) which is always a good thing.
"Need" is a strong word. You can certainly write Python without one, but I wouldn't want to.
Python wasn't designed (like PHP was, for example) as a direct web scripting language, so common web-ish things like connecting to databases isn't native, and frameworks are handy.
EDIT: mod_python exists for Apache, so if you're merely looking to write some scripts, then Python doesn't need a framework. If you want to build an entire site, I'd recommend using one.
From a Pythonic point of view, you'd absolutely want to use one of the frameworks. Yes, it might be possible to write a web app without them, but it's not going to be pretty. Here's a few things you'll (probably) end up writing from scratch:
Templating: unless you're writing a really really quick hack, you don't want to be generating all of your HTML within your Python code -- this is a really poor design that becomes a maintainability nightmare.
URL Processing: splitting a URL and identifying which code to run isn't a trivial task. Django (for example) provides a fantastic mechanism to map from a set of regular expressions to a set of view functions.
Authentication: rolling your own login/logout/session management code is a pain, especially when there's already pre-written (and tested) code available
Error handling: frameworks already have a good mechanism in place to a) help you debug your app, and b) help redirect to proper 404 and 500 pages.
To add to this, all of the framework libraries are all heavily tested (and fire tested). Additionally, there are communities of people who are developing using the same code base, so if you have any questions, you can probably find help.
In summary, you don't have to, but unless your project is "a new web framework", you're probably better off using one of the existing ones instead.
Framework? Heck, you don't even need a web server if you're using Python, you can make one in around three lines of code.
As to the why:
The most plausible thing I can think of is that Perl and PHP were developed before the notion of using frameworks for web apps became popular. Hence, the "old" way of doing things has stuck around in those cultures. Ruby and Python became popular after frameworks became popular, hence they developed together. If your language has a good framework (or more than one) that's well supported by the community, there's not much reason to try to write a Web App without one.
A framework isn't necessary per se, but it can certainly speed development and help you write "better" code. In PHP, there are definitely frameworks that get used like CakePHP, and in Perl there are many as well like Mason and Catalyst.
The frameworks aren't necessary. However, a lot of developers think frameworks ease development by automating a lot of things. For example, Django will create a production-ready backend for you based on your database structure. It also has lets you incorporate various plugins if you choose. I don't know too much about Rails or Perl frameworks, but PHP frameworks such as Zend, Symfony, Code Igniter, CakePHP, etc are used widely.
Where I work at we rolled our own PHP framework.
Are these frameworks necessary?
No. They, like any 'framework', are simply for speeding up development time and making the programmer's job easier.
If not, is there a reason why these languages are often used within a framework, while Perl and PHP are not?
PHP and Perl were popular languages for building web sites well before the idea of using frameworks was. Frameworks like Rails are what gave Ruby it's following. I'm not sure that Python or Ruby were that common as web languages before they were backed by frameworks.
These days, even PHP/Perl web developement should be backed by a framework (of which there are now many).
By no means are those development frameworks required. But as with most development environments, your productivity will increase exponentially if you have a supported framework to reference and build your applications on. It also decreases the training needed to bring others up to speed on your applications if they already have a core understanding of the framework that you use.
For python, the answer is No you don't have to. You can write python directly behind your web server very easily, take a look at mod_python for how to do it.
A lot of people like frameworks because they supply a lot of the boilerplate code in a reliable form so you don't have to write it yourself. But, like any code project, you should choose the tools and frameworks on their merit for your problem.
You can certainly write CGI scripts in either language and do things "raw".
The frameworks (ideally) save the trouble of writing a pile of code for things that other people have already handled (session handling, etc.).
The decision probably comes down to what you need to do. If the framework has the features you need, why not use it. If the framework is going to require extensive modifications, it might be easier to roll your own stuff. Or check out a different framework.
The python library has numerous modules for doing cgi, parsing html, cookies, WSGI, etc:
http://docs.python.org/library/index.html
PHP has a lot of frameworks. Probably more then most. In Ruby most use Rails so thats what you hear, and Django for Python is mentioned more then not.
But with PHP you have many to choose from.
List of web application frameworks
Any language that can "print" can be used to generate web pages, but frameworks handle a lot of the HTML generation for you. They let you concentrate more on the content and less on the details of coding the raw HTML.