Im really new to iOS Programming. Although I read lots of books and material I cant really find out an answer to a simple question.
I know C++ language, and I understand how variables are handled through the functions. What I really dont understand in iOS programming is how this thing is done.
For example, in C++ I create a class instance in the main function. When I call another function and I want to share this class instance all you need to do is:
myFunction(&myClassInstance);
When I switch views in iOS programming (and therefore classes) I dont know how to send a class instance that was created before. For example, if I am on the firstView of my program, and I switch to the secondView, how can I send the variables that I was currently using?
If I need to create an instance of a class that is going to be used though ALL the program, where I should create it? In C++ I would create it in the main function, in iOS Programming, where should I create it?
Thanks!
First of all what I understand from your question is
"In C++ when we have to pass instance of some other class we use reference argument. What is option in Objective C?"
So, Objective C is build up on C. So you can pass instance using pointer. like...
-(void)myFunction:(MyClass*)myClassInstance;
Other question is
"If I need some instance in all the program then where should I create?"
You can use AppDelegate class to hold that instance. Because instance of AppDelegate it accessible from all your program.
And you can create instance in "didFinishLaunchingWithOption"
Related
I'm new to PLC programming and we need to create a library for a project. We need dynamically created function block instances during the runtime. There is a concept described on the codesys homepage:
https://help.codesys.com/webapp/fb_factory;product=LibDevSummary;version=3.5.15.0
We tried to implement the example but without success. Unfortunately, there is no further information about the concept on the codesys homepage.
Has anybody some advice how to dynamically create fb instances during the runtime on a plc?
When you want to create an instance of an FB dynamically you need first to put the following attribute above the FB-Declaration:
{attribute 'enable_dynamic_creation'}
Then you must make sure you are not calling __NEW(FB_NAME) cyclically.
Then you assign the result of __NEW(FB_NAME) to a pointer:
//Put this is the declaration section
pfbName : POINTER TO FB_NAME;
//Your call to create a dynamic instance
pfbName := __NEW(FB_NAME);
If your pointer = 0 after __NEW returns, it means __NEW failed to allocate memory.
I made a simple classic OOP Person, Teacher, Student example here.
Basically, changing the value of numberOfTeachers inside PLC_PRG will cause the reinitializarion of the array people with the first numberOfTeachers entries being Teachers, and the rest being Students. You can look at the Device Logs where I write messages for creation/destruction of Teacher/Studemt.
PS. I am myself still exploring the possibilities of the Factory Design in CODESYS, so excuse me if I made any mistakes!
This is a question about implementing a scriptable application using Cocoa Scripting.
My app's scriptable application object contains elements of a custom class, let call it flower.
In the .sdef file, the Cocoa class for flower is specified as ScriptableFlower.
In Applescript, one can now write:
tell app "myapp"
get flowers
end tell
My code provides an accessor function for retrieving flowers: -(NSArray*)flowers.
Now, I like to implement a way to add new flowers, so that one can write:
tell app "myapp"
make new flower
end tell
The default behavior for this, with the default Core suite handler for "make" using NSCreateCommand, is as follows:
The scripting engine will fetch the current array of flowers by calling my flowers function, then instantiate a new Cocoa object of class ScriptableFlower, and then call setFlowers:(NSArray*) with an array that contains my original objects plus the newly created one.
However, this is not good for my application: I cannot allow the scripting engine to create objects of my scriptable classes at will.
Instead, I need to be the one instantiating them.
A half-way solution would be to implement the default -(id)init method and then detect if it's called by me - if not, I can take the extra steps. But that's not clean. I rather do not let the scripting engine create new objects at all but rather provide them myself as I may have the object "somewhere" already prepared.
Is there some provision in Cocoa Scripting that leads to it calling me whenever it wants me to create a new scriptable object?
Update
To clarify: The Cocoa Scripting docs explains that one can implement special insertion handlers (insertObject:in<Key>AtIndex:)so that one doesn't have to take the entire NSArray, but that still leads to the scripting engine to create the object. I need to be asked to create the object instead, though.
The file NSObjectScripting.h provides a function for this:
- (id)newScriptingObjectOfClass:(Class)objectClass forValueForKey:(NSString *)key withContentsValue:(id)contentsValue properties:(NSDictionary *)properties;
It's available since OS X 10.5 and documented as follow:
Create a new instance of a scriptable class to be inserted into the relationship identified by the key, set the contentsValue and properties of it, and return it. Or return nil for failure. The contentsValue and properties are derived from the "with contents" and "with properties" parameters of a Make command. The contentsValue may be nil. When this method is invoked by Cocoa neither the contentsValue nor the properties will have yet been coerced using scripting key-value coding's -coerceValue:forKey: method. In .sdef-declared scriptability the types of the passed-in objects reliably match the relevant .sdef declarations however.
One option is to subclass NSCreateCommand and implement your own logic.
I left the original, so people can understand the context for the comments. Hopefully, this example will better help explain what I am after.
Can I create a class in Obj-C that has file-scope visibility?
For example, I have written a method-sqizzling category on NSNotificationCenter which will automatically remove any observer when it deallocs.
I use a helper class in the implementation, and to prevent name collision, I have devised a naming scheme. The category is NSNotificationCenter (WJHAutoRemoval), so the private helper class that is used in this code is named...
WJH_NSNotification_WJHAutoRemoval__Private__BlockObserver
That's a mouthful, and currently I just do this...
#define BlockObserver WJH_NSNotification_WJHAutoRemoval__Private__BlockObserver
and just use BlockObserver in the code.
However, I don't like that solution.
I want to tell the compiler, "Hey, this class is named Bar. My code will access it as Bar, but I'm really the only one that needs to know. Generate a funky name yourself, or better yet, don't even export the symbol since I'm the only one who should care."
For plain C, I would is "static" and for C++ "namespace { }"
What is the preferred/best/only way to do this in Obj-C?
Original Question
I want to use a helper class inside the implementation of another. However, I do not want external linkage. Right now, I'm just making the helper class name painfully unique so I will not get duplicate linker symbols.
I can use static C functions, but I want to write a helper class, with linker visibility only inside the compilation unit.
For example, I'd like to have something like the following in multiple .m files, with each "Helper" unique to that file, and no other compilation unit having linker access. If I had this in 10 different files, I'd have 10 separate classes.
#interface Helper : NSObject
...
#end
#implementation Helper : NSObject
...
#end
I have been unable to find even a hint of this anywhere, and my feeble attempts at prepending "static" to the interface/implementation were wrought with errors.
Thanks!
I don't believe you will be able to do what you want because of the Objective-C Runtime. All of your classes are loaded into the runtime and multiple classes with the same name will conflict with each other.
Objective-C is a dynamic language. Unlike other languages which bind method calls at compile time, Objective-C does method resolution at invocation (every invocation). The runtime finds the class in the runtime and then finds the method in the class. The runtime can't support distinct classes with the same name and Objective-C doesn't support namespaces to seperate your classes.
If your Helper classes are different in each case they will need distinct class names (multiple classes with the same name sounds like a bad idea to me, in any language). If they are the same then why do you want to declare them separately.
I think you need to rethink your strategy as what you are trying to do doesn't sound very Objective-C or Cocoa.
There's no way to make a class "hidden." As mttrb notes, classes are accessible by name through the runtime. This isn't like C and C++ where class are just symbols that are resolved to addresses by the linker. Every class is injected into the class hierarchy.
But I'm unclear why you need this anyway. If you have a private class WJHAutoRemovalHelper or whatever, it seems very unlikely to collide with anyone else any more than private Apple classes or private 3rdparty framework classes collide. There's no reason to go to heroic lengths to make it obscure; prefixing with WJHAutoRemoval should be plenty to make it unique. Is there some deeper problem you're trying to fix?
BTW as an aside: How are you implementing the rest of this? Are you ISA-swizzling the observer to override its dealloc? This seems a lot of tricky code to make a very small thing slightly more convenient.
Regarding the question of "private" classes, what you're suggesting is possible if you do it by hand, but there really is no reason for it. You can generate a random, unique classname, call objc_allocateClassPair() and objc_registerClassPair on it, and then assign that to a Class variable at runtime. (And then call class_addMethod and class_addIvar to build it up. You can then always refer to it by that variable when you need it. It's still accessible of course at runtime by calling objc_getClassList, but there won't be a symbol for the classname in the system.
But this is a lot of work and complexity for no benefit. ObjC does not spend much time worrying about protecting the program from itself the way C++ does. It uses naming conventions and compiler warning to tell you when you're doing things wrong, and expects that as a good programmer you're going to avoid doing things wrong.
Is there a way to make one (1) instance of an object and share that instance between different files?
For instance, I have Class "A" (created in fileA.m), and I create an instance of it in a different file (fileB.m). Now, I want to use that same instance created in fileB.m in several other files (fileC.m and fileD.m) so I can share ivar's (such as a database).
How do I do that?
You would want Class A to be a singleton. Here's a great guide to help you out with that.
You need to use a static class method as a constructor which will return a singleton instance of the object you're looking for.
What is the standard way of incorporating helper/utility functions in Obj-C classes?
I.e. General purpose functions which are used throughout the application and called by more than 1 class.
Can an Obj-C method exist outside of a class, or does it need to be a C function for it to have this kind of behaviour?
I would group similar functions as static methods in a helper class. These can then be called using the classname rather the instance name. Static methods are defined with a + instead of the usual -.
like so:
#interface HelperClass: superclassname {
// instance variables - none if all methods are static.
}
+ (void) helperMethod: (int) parameter_varName;
#end
This would be called like so.
[HelperClass helperMethod: 10 ];
As this is static you do not init/alloc the class. This has the advantage of clearly grouping like Helper functions. You could use standalone C functions but as your Application gets larger it can become a right mess! Hope this helps.
Tony
I don't see why people are avoiding creating functions. Objective-C is a superset of C, which means that C is part of it. Moreover, it's completely integrated—there's no wall between them.
Create functions! It's fine! Foundation does it. Application Kit does it. Core Animation does it. Core Media does it.
I see no reason not to.
There are a number of options for this in Objective-C. First, since Obj-C is a strict superset of C, you can define all your library functions in a separate module (source file) and happily call them from any Obj-C object/code you already have. If you create an obj-c source file (.m file) you can then call back into/use objects.
If your generic functions are logically manipulating other, established objects (for instances, operates on an NSString), you can use categories to graph your functions on already existing classes (where that makes sense).
Finally, as Tony points out, you can create classes with static methods (although I like this option the least, personally). I tend to use a mix of one an two... adding categories where appropriate and using standard functions for others. I generally only make a new class where it makes sense to design a class.