Objective-C method description (doc comments) - objective-c

I'm currently learning Objective-C and need to know how to write a method description. I'm having a lot of difficulty learning how to do this in Objective-C.
In Jave we have this
/**
< h2 >MethodName</ h2 >
< p >Various Description, can use html with images etc.</ p >
*/
private void methodName(args[]..)
{
}
In objective-c where do I place the description? Also does this to be in the header file or the implementation file?
//Within Implementation?
- (float)gteHeightPercentage:(float)percentageToGet
{
return self.view.bounds.size.height * percentageToGet;
}
//Within Header?
- (float)getWidthPercentage:(float)percentageToGet;

Update: The format below works for Objc. If you want to document swift code, refer to NSHipster's blog about Swift Documentation
The Xcode 5 can do what you want. Thanks to Wonil Kim, in the .h file:
/**
* Add new message between source to destination timeline as empty name string
* #author Wonil Kim
*
* #param sourceId Source timeline entity ID
* #param destId Destination timeline entity ID
* #return A newly created message instance
*/
- (ISMessage*)messageFromTimeline:(NSInteger)sourceId toTimeline:(NSInteger)destId;
Once this is done, you can alt+click on the method name, and.. voilà!
Of course, as you can see on Kim's blog, this is not the only way:
/*! Some description of the method....
* \returns The result
*/
Alternatively,
/// Some description to show up, done by:
/// #author Olly Dixon
You got the point...
As many already have mentioned, Objective-C does not show you your documentation; in fact, neither does java (javadoc, may be). It's your IDE, in this case, the un-crashable Xcode :)
UPDATE2: Complete list of "Special Commands" in comments.
UPDATE3: Use VVDocumenter-Xcode if you'd like to enable auto-generation of documentation by ///.
UPDATE4:: VVDocumenter has be integrated in to Xcode:
Use the shortcut (⌥ Option + ⌘ Command + /) to add a documentation
comment to your code if you are using Xcode 8 or above

What you are describing are called “documentation comments”, or “doc comments” for short.
Xcode, as of version 4.6.3, does not display your own doc comments in a pop-up window or its quick help inspector. You have to compile your comments into a “docset” to get Xcode to display them. There are tools to do that, but there is no way to get Xcode to reload a docset except by quitting and restarting it, so I don't recommend bothering.
Xcode 5 (which is currently available as a developer preview for paid members of the OS X and iOS developer programs) does display the doc comments for your own code; see “Quick Help” on the Developer Tools Features page. You must write the doc comments in the header file. You may use either doxygen or headerdoc format.

In objective-c where do I place the description?
Objective-C compilers like gcc and llvm don't care how you document your code. There are several different documentation generators such as Doxygen and HeaderDoc that can build documentation from appropriately formatted comments, usually in your header files. Additionally, Xcode makes it easy to jump to the definition of symbols defined in your code, and it's "quick help" inspector can show you definitions, both without any special annotations in your code.

Related

Comments removed from swift files when make a framework

I have built up framework files of swift.
In general,if we built up framework with objective c files with comments,show up in header files but when i added comment in swift file and when import framework and access that class it will not show up any comment and also not editable to put comment.
For objective it have header file so we can add comment and can display comment.
How to do same for swift file?
Any one have idea?Please share.
Documentation comments (with /** ... */ or /// ...) will be retained in Swift generated interface files. There are several additional features you can use like - Returns: and - Parameter:. More information is in the Markup Formatting Reference.

How to document the return value of a method in Objective C and Oxygen with Xcode 6?

I am currently trying to document some pieces of code. I am using Xcode version 6 and tried to document a method with a return value.
/**
#brief TODO
#param url TODO
#param interval TODO
#return id TODO.
*/
-(id) initWithUrl: (NSString*) url andInterval: (int) interval;
Without the line with #return Xcode shows the documentation of the method correctly in the Quick Help, when I drag my cursor above or combine the options key with a mouse click.
Can someone tell me whats wrong with it? How does the correct documentation with oxygen have to look like?
Thanks a lot.
Sometimes doing nothing helps. Additionally I read an article that says:
If your popover didn’t contain your comment, you may not have waited long enough for the project to build. If it has finished, try restarting Xcode, just to make sure.
Source: Ray Wenderlich

How to create Apple mail plugin

I'm going to create a mail plugin for the OS X Mail.app application for some additional features.
I have no idea where to start as there is no official documentation for plugins.
Can anyone please help me, how can I start the project.
Is there any initial link or tutorial, please suggest?
As noted, writing Apple Mail plugins is not straightforward, since it only has a private plugin API, which is entirely undocumented and can change with any new version of Mail.app. The best code example is GPGMail, which is open source & still active (already working on Yosemite support). Here is what I successfully did to get started (will put it up on github once finished):
How to build a minimal Apple Mail plugin (as of Mavericks & Xcode 6.0.1)
you need to create an OSX "Bundle" project in XCode
wrapper extension is mailbundle (under Packaging in the project Build settings)
a bundle needs to be stored under ~/Library/Mail/Bundles (as Build Phase add a Copy Files action with that as absolute path destination and the *.mailbundle from your build/ folder as item to copy)
for development, I have set up /Applications/Mail.app as executable in my run scheme, so that Run in XCode will build it, copy the bundle and start mail; note that at this point you'll get an error from Mail that your plugin cannot be started and was disabled
you need to provide a list of SupportedPluginCompatibilityUUIDs in the Info.plist, I stole it from GPGMail, these change with new Mail/OSX versions
use class-dump to generate the header files from Mail.app's private API
starting point is MVMailBundle, which you have to inherit from and which has a registerBundle method to hook you in
I extracted that from the huge generated header file in a small MVMailBundle.h header to include where needed (as done by GPGMail)
create a new class MyMailBundle, inheriting from NSObject
it needs an initialize method
and set it as "Principle class" in the Info.plist so that it gets run when the bundle is loaded by Mail.app
#import <Cocoa/Cocoa.h>
#interface MyMailBundle : NSObject
+ (void)initialize;
#end
initialize implementation: previously, you could use the simple way and directly inherit as done in Letterbox, however, since 64-bit runtimes of Objective-C you have to use the dynamic way as done by GPGMail:
using NSClassFromString to dynamically get the MVMailBundle class
and class_setSuperclass from <objc/runtime.h> to have your own class inherit from it
and then call registerBundle on it casted as MVMailBundle (requires include of MVMailBundle.h)
#import <objc/runtime.h>
#import "MVMailBundle.h"
#import "MyMailBundle.h"
#implementation MyMailBundle
+ (void)initialize
{
NSLog(#"Loading MyMail plugin...");
// since 64-bit objective-c runtimes, you apparently can't load
// symbols directly (i.e. through class inheritance) and have to
// resort to NSClassFromString
Class mvMailBundleClass = NSClassFromString(#"MVMailBundle");
// If this class is not available that means Mail.app
// doesn't allow plugins anymore or has changed the API
if (!mvMailBundleClass)
return;
// dynamically change super class hierarchy
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated"
class_setSuperclass([self class], mvMailBundleClass);
#pragma GCC diagnostic pop
// register our plugin bundle in mail
[[((MyMailBundle *)self) class] registerBundle];
NSLog(#"Done registering MyMail plugin.");
}
#end
add some NSLog logging calls to verify the right thing is happening, they'll be visible in XCode's console when running/debugging Mail.app from within XCode or alternatively in the system logs of Console.app
This should successfully run the plugin in Mail with no error!
The next steps involve crazy things like MethodSwizzling and ClassPosing to modify Mail's behavior, where GPGMail can be a helpful example. (Haven't been there myself yet)
For reference, here are some of the resources that helped me:
GPGMail
Adam Nash: Getting Ready to Write an Apple Mail.app Plug-in for Mac OS X - some good links, but apparently he never finished the project, so no code
James R. Eagan: Demystifying Mail.app Plugins on Leopard - using PyObjC to write a plugin in Python, explains the basic mechansims, very useful
Aaron Harnly: Mail Plugin Template - for XCode 2 I think, unfortunately the template (download a zip) doesn't work as template in Xcode anymore, but the code is still useful to look at
Aaron Harnly: Letterbox sources - from the same guy, but also from 2007, very outdated; contains a readme from the template, though it doesn't really help if you can't use the template.
There is no official supported way to build such a tool - you need to start trying to hook in to Mail.app without any official support.
If you want to persist on this sort of thing, then you'll need to understand how Mail.app internals work, which is a bunch of using the debugger and class dump to inspect libraries in other apps:
https://github.com/nygard/class-dump
You'll probably also want a way to inject code into other applications, for example:
https://github.com/rentzsch/mach_inject
And every time Apple update Mail.app you'll potentially need to redo everything :)

How do I get Doxygen to link to a method of an Objective-C class?

I'm using Doxygen to document my Objective-C code, and so far it's working fine.
However, I've been searching for hours and I have not been able to find any way to link to a method. For example:
#interface Example : NSObject {
}
/** This is an example method I want to link to. */
- (void)methodWithArgument:(NSString*)one andArgument:(NSString*)two;
/** I want a link to methodWithArgument:andArgument: but Doxygen
* doesn't seem to link the two.
*/
- (void)someOtherMethod;
#end
My expectation is for methodWithArgument:andArgument: to become a link to the appropriate method, but in the generated documentation, it is just plain text.
I have tried lots of other forms:
methodWithArgument:andArgument:
-methodWithArgument:andArgument:
::methodWithArgument:andArgument:
Example::methodWithArgument:andArgument:
But none of them seem to work. Is it possible to link Objective-C methods in Doxygen, and if so, how? Also, how do I link to a method of another class? I know how to do this for C, C++ and Java, but for Objective-C the answer eludes me. Could it be that Doxygen simply doesn't support linking methods in Objective-C? This seems like quite a shortcoming...
You said you tried this one, but it works for me in Doxygen 1.7.2:
/** I want a link to Example::methodWithArgument:andArgument: but Doxygen
* doesn't seem to link the two.
*/
This might depend on your configuration file; I was using a default configuration file generated by doxygen -s -g Doxyfile.

Doxygen and Objective-C Protocols

I'm using the Doxygen Wizard on the Mac (GUI for Doxygen 1.7.3).
I found out that If, in the header for my class, I #import a header file in which a protocol is defined, the first member of my class appears in the docs as pre-appended with the path to the class' header file, something like this:
(Doxygen HTML Output)
Protected Attributes:
Users [username] Desktop DirectoryName ClassName h NSString* myStringMember
(Further attributes display OK)
If I remove the #import, the problem goes away (But I need the protocol).
I read somewhere that Doxygen used to 'choke' on Obj-C protocols in the past, but that bug should be fixed by now. Anyone else experiencing something similar?
You may want to consider appledoc, its targeted at Cocoa developers and produces really good output.