Thanks, this is really easy to do as right now cocoadocs generates a jsonp file of every cocoapod: http://cocoadocs.org/documents.jsonp - so whilst ATM I'm not planning on doing this, someone can do it very easily.
Hey guys & gals, I created cocoadocs to try and fill a gap in the iOS ecosystem.
It's a site that acts similar to rubydocs in that it gets the latest cocoapods libraries and documents them using a custom flavour of appledoc. I'm planning on adding support for Xcode and Dash over the next few weeks to make it even easier to use!
I'd love to but ATM its a static site hosted on s3, so no API at all. Moving to something which is API / Client is within my next major move, at that point it will be super easy.
Looks great! Only one thing, how often is it updated? I pushed a new Podspec to the master repo about 5 days ago for one of my projects (http://cocoadocs.org/docsets/Colours/0.0.1/) and it should be v1.0.1. Just wondering if you are doing live grabbing of the data or have it cached somewhere?
AVFoundation is an apple library, which isn't on cocoapods meaning cocoadocs doesn't support it. Apple do their own documentation pretty well and I don't really see a need to duplicate that to be honest.
But if you're solving a find-ability the drop down list could either include those results or provide a redirect. This would just be an easy workflow thing.
Also, you're attempting to reflect the rubydocs ecosystem. An ecosystem which includes (core and stdlib) and gems. If you're reflecting that system accurately, you should include apple docs, and pods accordingly.
I agree, I think redirecting to apple's libraries is a great idea! When the grand-parent said a lack of AVFoundation was a problem, I interpreted that as "you should document that" but I think linking to all of Cocoa/UIKit is a real useful feature. Thanks 1qaz2wsx3edc.
Ah I see. It wasn't clear (to me at least) that this wasn't meant to be globally inclusive. My initial take was that you were trying to make a better overall docs system for Obj-c. Having links back to the current definitive Apple docs would be great.
Fantastic! I can see this being incredibly useful for cases where you have multiple versions of a framework used in different projects. Right now you can install documentation into Xcode if the project uses appledoc[1], but there's no way to switch between versions.
On the subject of appledoc, are you using a custom template here? It seems to improve on the default one in a few places.
If you use Cocoapods, when you install with Appledoc it names the documentation based on versions, e.g. TTTAttributedLabel 1.6.2 so you can keep multiple sets.
Of course, that gets messy real fast, so it's good that CocoaDocs is an option.
I should, I just closed the issue an hour ago about this after looking through the repository and only finding your library and 2-3 others as a spec with meaningful appledoc options. I'll re-open it for my next deploy.
30 comments
[ 4.8 ms ] story [ 88.7 ms ] threadSuggestion: I would love to see the full list of available pods (not just search) with short description next to them somewhere.
IE have http://cocoadocs.org/docsets/NUI/ Redirects to: http://cocoadocs.org/docsets/NUI/0.2.7/
This would enable http://cocoadocs.org/docsets/%s shortcuts
I like how you pull the github README to use at the documentation landing page.
But if you're solving a find-ability the drop down list could either include those results or provide a redirect. This would just be an easy workflow thing.
Also, you're attempting to reflect the rubydocs ecosystem. An ecosystem which includes (core and stdlib) and gems. If you're reflecting that system accurately, you should include apple docs, and pods accordingly.
Just my two cents.
On the subject of appledoc, are you using a custom template here? It seems to improve on the default one in a few places.
[1]: http://gentlebytes.com/appledoc/
Of course, that gets messy real fast, so it's good that CocoaDocs is an option.
https://github.com/mapbox/mapbox-ios-sdk/blob/release/MapBox...