I'm creating an app in which I do the same thing multiple times. I'm going for as little code as possible and I don't want to repeat myself.
I need the PHP equivalant of a reusable function, where I set an input, and the function will return the output.
The app is a URL shortener, so the input as you may assume is a URL, and the output is the short URL.
What's the best way to go about this? I know I can code the same thing twice, but I hate to repeat myself.
Hopefully I'm getting my point across. Any help is greatly appreciated.
-Giles
Apologies if I'm oversimplifying your question, but are you asking how to define an Objective-C method? If so, you're going to have to learn Objective-C, there's no way around it:
The Objective-C Programming Language - Object Messaging
You can do a lot of great things with no code on the iPhone and Mac platforms, but it's hard to imagine completing any useful application without writing some code.
Example
- (float)multiplyThisFloatByTwoPointFive:(float)numberToMultiply
{
return numberToMultiply * 2.5;
}
To call it:
[self multiplyThisFloatByTwoPointFive:3.7];
Libraries
If you mean "I want to put these non-class-specific methods somewhere I can access them universally", eg, a library, you can do this in two ways:
Create some sort of "library" class like "MySpecialMathClass" (not to be confused with "my special education math class") or "MyAppAnimationTricks" and put your methods there (you'd define them as +someMethod: not -someMethod:, class- not instance-method, per Objective-C).
If they only ever deal with primitives (such as int, float, double ...), consider just making them C functions, rather than Objective-C methods.
I am pretty much a newbie at this, but you can certainly write functions (as opposed to methods) in Objective C.
I wrote several utility functions recently. I created an NSObject file to place them in, but it has no ivars or methods declared, just the functions. Then implement the functions in the .m file, and import the .h file into any class file where you want the functions. You can obviously call these from anywhere in any .m file that has imported the function file.
John Doner
Related
I am learning Objective C and noticed this funky quirk while reading up on methods.
Like Java and C++, Obj.C can take in multiple parameters, which is fine, however it states that objective C methods can have multiple names which does not seem to register to well with me.
For instance:
-(NSArray *)shipsAtPoint:(CGPoint)bombLocation withDamage:(BOOL)damaged;
In the above example, there are two parameters, bombLocation (return type CGPoint) and damaged (return type BOOL) and alongside the method name seems to be split as shipsatpoint:withDamage
I don't understand what's up with this...
What does it signify when it states that a method can have multiple names?
Is this applicable only for methods that require multiple parameters? Alternately, say I want to name my method with a single name but provide it with multiple parameters, is that possible or I must provide it with multiple names each of which correspond to a parameter? If yes, then why?
Thanks for jumping in with my confusion!!! :)
The reason is to make it easier to understand.
With your example, the method would be something like this in C++:
int shipsAtPointWithDamage (CGPoint bomb, BOOL damage) //I don't really know C++
OK, so the first parameter is the ship's point, and the damage is the second. It's easy enough to figure out, but that's the thing, you have to FIGURE it out, you have to look at the method to try and figure out what each thing is.
In Objective-C you have
-(NSArray *)shipsAtPoint:(CGPoint)bombLocation withDamage:(BOOL)damaged;
Each parameter is clearly defined, the first is the ship's point, the second is damage. It reads like a sentence, whereas with C++ (and almost every other language) it doesn't.
If you want a method to have multiple parameters in Obj-C you have to write it this way:
-(returnType)paraOne:(type*)name paraTwo:(type*)name
It's something that just takes getting used to, every language is different. Once you get used to the way Objective-C does things, you'll think it's absolutely fantastic.
EDIT: and as filipe pointed out, because the method as multiple parameters it doesn't mean it has multiple names, in the example I gave above, the method name would be paraOne:paraTwo, NOT paraOne:
Objective-C uses a system of message passing based on selectors. This is not quite the same thing as method calling. When you see code like this:
[world shipsAtPoint:point withDamage:YES];
That is converted into the following C call (in the most common case):
objc_msgSend(world, #selector(shipsAtPoint:withDamage:), point, YES);
The #selector() construct returns a unique identifier. The exact format of that identifier is an internal implementation detail.
objc_msgSend includes quite a lot of logic in it's few dozen bytes of assembler. But in simplest case, it looks up the class for world, walks through a table of selectors until it finds the one that matches shipsAtPoint:withDamage: and then grabs the function pointer at that slot. It then jumps to that function pointer, leaving the rest of the parameters alone (in registers or on the stack as appropriate for the processor). The function at that location is your method, and it knows the order and types of its parameters based on your declaration.
What's important in all this for you is that the selector is shipsAtPoint:withDamage:. This is generally the one-and-only name of the method. There are not "multiple names" as you suggest. (Usually.... the Objective-C runtime is very powerful and it's possible to point multiple selectors to the same implementation.)
As Joe points out, a selector can be in the form foo::. This would represent a method that took two parameters and would be called like [world foo:point :YES]. You should never do this. It's incredibly confusing to read. But it's legal.
Here is the best explanation i've ever seen. It includes comparisons with C++/C as well as lots of other good info.
I think you are confused. A method cannot have multiple names, but the argument may be named differently in the header then they are in the implementation.
The name of that method is shipsAtPoint:withDamage:. This is also known as a selector.
This method returns an instance of NSArray, and accepts a CGPoint as the first argument, and a BOOL as the second argument.
The names of the arguments may differ, however. This is totally valid:
// .h file
-(NSArray *)shipsAtPoint:(CGPoint)bombLocation withDamage:(BOOL)damaged;
// .m file
-(NSArray *)shipsAtPoint:(CGPoint)loc withDamage:(BOOL)dmg {
// ...
}
Lastly, ObjC is mainly some nice syntax sugar. You should know that any method invocation really just boils down to some C that looks more or less like this:
objc_msgSend(receiverObj, #selector(shipsAtPoint:withDamage:), point, damage);
So at the end of the day, you have a receiver, a selector, and your arguments. But the ObjC syntax is much nicer than that.
It is possible provide a method without labeled parameters but it is obviously discouraged.
-(void)badmethod:(id)obj1:(id)obj2:(id)obj3
{
}
//...
//Usage
[self badmethod:nil :nil :nil];
SEL sel = #selector(badmethod:::);
I've been working with layers for MapKit on the iPhone, and one library that I came across was this one: https://github.com/mtigas/iOS-MapLayerDemo/. It's very helpful, and seems to work fine. However, I'm trying to go through and understand a bit how it works, but I'm having some trouble.
On this page, for example: https://github.com/mtigas/iOS-MapLayerDemo/blob/master/MapLayerDemo/Classes/CustomOverlayView.m,
at the top, there are 4 custom functions defined. I assume these functions are adding on to the normal features of MKOverlayView? The thing is, I can't find where any of these new functions are actually called from, and thus I'm having some trouble understanding how this page works. It doesn't seem to be from any of the other files within the project.
I appreciate any help, thanks.
After some extended discussion with you in comments:
The override-able functions of MKOverlayView, such as canDrawMapRect cannot easily be traced back to their calling code because that code is obfuscated somewhere in the MapKit.framework.
Instead, the typical approach is to re-read their documentation until you get a mental picture of what the framework is using the function for. (There is such a thing as decompiling binaries, although that is generally frowned upon and I do not recommend it.)
canDrawMapRect documentation: http://developer.apple.com/library/ios/documentation/MapKit/Reference/MKOverlayView_class/Reference/Reference.html#//apple_ref/doc/uid/TP40009715-CH1-SW10
After reading their documentation, I inferred this: Somewhere in the MapKit.framework, canDrawMapRect is being called prior to actually drawing the view. If you didn't override that function in your subclass, it calls the super-class's default implementation, which always returns YES and then calls drawMapRect: (Which MUST be overridden if you are subclassing MKOverlayView, or else nothing will draw!)
The class you linked above potentially returns NO. In that particular case, it appears the code in MapKit.framework skips calling drawMapRect: and nothing is displayed (or refreshed).
So, long story short: for this case, you have to play code-detective and hope the documentation is written clearly enough to figure it out without being able to see all of the code.
Edit: Just to further clarify - It appears MKOverlayView must be subclassed to actually generate something visible.
My original answer before getting to your underlying question --
Short answer: Those are private functions for use within that class.
Long answer: Functions declared in an empty-name category at the top
of implementation files are visible only to the class the category is
extending. Thus, those functions can only be called within that
class's implementation. (C++ equivalent would just be declaring the
functions private)
3 of those 4 functions are called within that same .m file. Without
digging around, I'm guessing they wrote the first function and then
later decided to not use it.
I'm trying to get to grips with how Lua works, and how it can be integrated into a project, like an Obj-C based iPhone game. I've got Lua's source integrated fine, and have managed to use a simple manager class to translate function calls written in a .lua file, to Obj-C methods in the project.
I'm now a little stuck; I'm not sure how to go about what I'd like to use Lua for, and having Googled a lot on it I haven't found an article which fills the little gaps in my understanding. What I'd like to do is use Lua to script simple game logic for levels in my game; for example, I might want to check that the player has moved to a certain part of the level, then once he does that I check if he picks up an object, then once he throws that object I check if it hits another object, etc, etc.
In the script, I'd like to have something like this:
if (objectsAreTouching(level.objects["objIndex1"], level.objects["objIndex2"]))
{
//Move to next win-condition.
}
So I know how to access a function, for example the one named above, objectsAreTouching, but I can't see how I would, from within the .lua file, access a Dictionary or Array from within one of the game's main classes. I assume this must be possible, am I right? If so, how do you do this? If you can, can you then have a method in your game engine which returns a BOOL pass that return value to the script, so that the if statement above would then execute the code within it?
I may well have asked this question badly, and so if I need to clarify anything let me know. Also, I'm aware of the issues surrounding Apple's ban of interpreted code, and it doesn't concern me for this little project.
Thanks for any help!
You have (at least) three options:
Create the Dictionary (using a Lua table) and Array (also using a Lua table) on the Lua side rather than on the C++ side; you can do this in C++ using Lua's C API, or in a Lua script that you load to construct the game environment.
Provide access functions to Lua to read the C++ based Dictionary and Array. These access functions are just like the objectsAreTouching function you described, but at the level of data accessors. Typically the results returned from the accessors would be lightuserdata.
Use Lua userdata objects to share the state of the Dictionary and Array between Lua and C++. In this case they would be C++ objects requiring accessors, just like (2), but would be managed by Lua and could have methods (a metatable) and an environment associated with them.
I want to create a big file for all cool functions I find somehow reusable and useful, and put them all into that single file. Well, for the beginning I don't have many, so it's not worth thinking much about making several files, I guess. I would use pragma marks to separate them visually.
But the question: Would those unused methods bother in any way? Would my application explode or have less performance? Or is the compiler / linker clever enough to know that function A and B are not needed, and thus does not copy their "code" into my resulting app?
This sounds like an absolute architectural and maintenance nightmare. As a matter of practice, you should never make a huge blob file with a random set of methods you find useful. Add the methods to the appropriate classes or categories. See here for information on the blob anti-pattern, which is what you are doing here.
To directly answer your question: no, methods that are never called will not affect the performance of your app.
No, they won't directly affect your app. Keep in mind though, all that unused code is going to make your functions file harder to read and maintain. Plus, writing functions you're not actually using at the moment makes it easy to introduce bugs that aren't going to become apparent until much later on when you start using those functions, which can be very confusing because you've forgotten how they're written and will probably assume they're correct because you haven't touched them in so long.
Also, in an object oriented language like Objective-C global functions should really only be used for exceptional, very reusable cases. In most instances, you should be writing methods in classes instead. I might have one or two global functions in my apps, usually related to debugging, but typically nothing else.
So no, it's not going to hurt anything, but I'd still avoid it and focus on writing the code you need now, at this very moment.
The code would still be compiled and linked into the project, it just wouldn't be used by your code, meaning your resultant executable will be larger.
I'd probably split the functions into seperate files, depending on the common areas they are to address, so I'd have a library of image functions separate from a library of string manipulation functions, then include whichever are pertinent to the project in hand.
I don't think having unused functions in the .h file will hurt you in any way. If you compile all the corresponding .m files containing the unused functions in your build target, then you will end up making a bigger executable than is required. Same goes for if you include the code via static libraries.
If you do use a function but you didn't include the right .m file or library, then you'll get a link error.
Currently I am making some decisions for my first objective-c API. Nothing big, just a little help for myself to get things done faster in the future.
After reading a few hours about different patterns like making categories, singletons, and so on, I came accross something that I like because it seems easy to maintain for me. I'm making a set of useful functions, that can be useful everywhere.
So what I did is:
1) I created two new files (.h, .m), and gave the "class" a name: SLUtilsMath, SLUtilsGraphics, SLUtilsSound, and so on. I think of that as kind of "namespace", so all those things will always be called SLUtils******. I added all of them into a Group SL, which contains a subgroup SLUtils.
2) Then I just put my functions signatures in the .h file, and the implementations of the functions in the .m file. And guess what: It works!! I'm happy with it, and it's easy to use. The only nasty thing about it is, that I have to include the appropriate header every time I need it. But that's okay, since that's normal. I could include it in the header prefix pch file, though.
But then, I went to toilet and a ghost came out there, saying: "Hey! Isn't it better to make real methods, instead of functions? Shouldn't you make class methods, so that you have to call a method rather than a function? Isn't that much cooler and doesn't it have a better performance?" Well, for readability I prefer the functions. On the other hand they don't have this kind of "named parameters" like methods, a.f.a.i.k..
So what would you prefer in that case?
Of course I dont want to allocate an object before using a useful method or function. That would be harrying.
Maybe the toilet ghost was right. There IS a cooler way. Well, for me, personally, this is great:
MYNAMESPACECoolMath.h
#import <Foundation/Foundation.h>
#interface MYNAMESPACECoolMath : NSObject {
}
+ (float)randomizeValue:(float)value byPercent:(float)percent;
+ (float)calculateHorizontalGravity:(CGPoint)p1 andPoint:(CGPoint)p2;
// and some more
#end
Then in code, I would just import that MYNAMESPACECoolMath.h and just call:
CGFloat myValue = [MYNAMESPACECoolMath randomizeValue:10.0f byPercent:5.0f];
with no nasty instantiation, initialization, allocation, what ever. For me that pattern looks like a static method in java, which is pretty nice and easy to use.
The advantage over a function, is, as far as I noticed, the better readability in code. When looking at a CGRectMake(10.0f, 42.5f, 44.2f, 99.11f) you'll may have to look up what those parameters stand for, if you're not so familiar with it. But when you have a method call with "named" parameters, then you see immediately what the parameter is.
I think I missed the point what makes a big difference to a singleton class when it comes to simple useful methods / functions that can be needed everywhere. Making special kind of random values don't belong to anything, it's global. Like grass. Like trees. Like air. Everyone needs it.
Performance-wise, a static method in a static class compile to almost the same thing as a function.
Any real performance hits you'd incur would be in object instantiation, which you said you'd want to avoid, so that should not be an issue.
As far as preference or readability, there is a trend to use static methods more than necessary because people are viewing Obj-C is an "OO-only" language, like Java or C#. In that paradigm, (almost) everything must belong to a class, so class methods are the norm. In fact, they may even call them functions. The two terms are interchangeable there. However, this is purely convention. Convention may even be too strong of a word. There is absolutely nothing wrong with using functions in their place and it is probably more appropriate if there are no class members (even static ones) that are needed to assist in the processing of those methods/functions.
The problem with your approach is the "util" nature of it. Almost anything with the word "util" it in suggests that you have created a dumping ground for things you don't know where to fit into your object model. That probably means that your object model is not in alignment with your problem space.
Rather than working out how to package up utility functions, you should be thinking about what model objects these functions should be acting upon and then put them on those classes (creating the classes if needed).
To Josh's point, while there is nothing wrong with functions in ObjC, it is a very strongly object-oriented language, based directly on the grand-daddy of object-oriented languages, Smalltalk. You should not abandon the OOP patterns lightly; they are the heart of Cocoa.
I create private helper functions all the time, and I create public convenience functions for some objects (NSLocalizedString() is a good example of this). But if you're creating public utility functions that aren't front-ends to methods, you should be rethinking your patterns. And the first warning sign is the desire to put the word "util" in a file name.
EDIT
Based on the particular methods you added to your question, what you should be looking at are Categories. For instance, +randomizeValue:byPercent: is a perfectly good NSNumber category:
// NSNumber+SLExtensions.h
- (double)randomizeByPercent:(CGFloat)percent;
+ (double)randomDoubleNear:(CGFloat)percent byPercent:(double)number;
+ (NSNumber *)randomNumberNear:(CGFloat)percent byPercent:(double)number;
// Some other file that wants to use this
#import "NSNumber+SLExtensions.h"
randomDouble = [aNumber randomizeByPercent:5.0];
randomDouble = [NSNumber randomDoubleNear:5.0 byPercent:7.0];
If you get a lot of these, then you may want to split them up into categories like NSNumber+Random. Doing it with Categories makes it transparently part of the existing object model, though, rather than creating classes whose only purpose is to work on other objects.
You can use a singleton instance instead if you want to avoid instantiating a bunch of utility objects.
There's nothing wrong with using plain C functions, though. Just know that you won't be able to pass them around using #selector for things like performSelectorOnMainThread.
When it comes to performance of methods vs. functions, Mike Ash has some great numbers in his post "Performance Comparisons of Common Operations". Objective-C message send operations are extremely fast, so much so that you'd have to have a really tight computational loop to even see the difference. I think that using functions vs. methods in your approach will come down to the stylistic design issues that others have described.
Optimise the system, not the function calls.
Implement what is easiest to understand and then when the whole system works, profile it and speed up what's slow. I doubt very much that the objective-c runtime overhead of a static class is going to matter one bit to your whole app.