I know you can have #private member variables but is there someway to prevent code from calling the default init: method of your class and forcing code that creates and uses your objects to only use another initializer such as initWithOptions:
I have had a flick through some Objective-C books and didn't immediately see anything.
I have seen the stack overflow topic suggesting to throw exception, or assert/abort/whatever in how to prevent usage of other init methods other than my custom method in objective-c
and the use of the depreciated keyword
How do I flag a function as being deprecated in an iPhone Objective C header file?
Both of these seem somewhat less than elegant solutions, there is really no language orientated elegant way to say doesNotImplmentSelector in Objective-C...?
I come from a C++ background and just kind of expected something like the ability to hide the default constructor...
R.
I think the standard thing to do is to have an implementation of init which calls initWithOptions: with a default set of options.
Related
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.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
List selectors for obj-c object
Does anybody know how to get all selectors that a instance respond to during runtime in objective C?
As answered here, #import < objc/runtime.h > and use class_copyMethodList().
In general, this is not possible. "The selectors an instance responds to" may be an infinite set. For example, it is possible to implement a class that is sent Roman numerals as messages and returns the corresponding integer value. If you want to know the precise set of instance methods implemented by a class at a given time (which is a different question), you can just use the Objective-C runtime functions to get a class's instance method list and walk up the class tree to find the ones it inherits from superclasses. Again, though, these are two totally different things. A class might have a method for a message that it chooses not to respond to and it might respond to messages for which it does not have a directly corresponding method.
dapptrace (Dtrace) is your friend.
on the man page (man dapptrace):
dapptrace prints details on user and
library function calls
dapptrace is written for the Dtrace scripting language (D). This means you can adjust dapptrace or pull ideas from it's script file to do many things. For instance:
wait for myFunctionWhichCreatesSpecialObject to be called. Store the object address that it returns (the special object). Print out any selectors invoked on that object.
You can also invoke dtrace directly to write simple single-line spells. I'll let you go search for those.
During runtime you would use
the class method "+ (BOOL)instancesRespondToSelector:(SEL)aSelector"
provided you know the selectors you want to check on.
When I work with UITableViewControllers - especially when using NSFetchedResultsController - I find myself repeating a lot of base functionality on every controller. Which I hate. I'd much rather love to write these methods once and keep it all neat and tidy.
So I was wondering: What do you guys do to not repeat yourself writing UIViewControllers. How do you DRY up your code. Inheritance, protocols, whatever.
Thanks! Looking forward to your answers.
(Since this question doesn't have a definitive answer, I will accept the one I find the best.
Is that the way to do it?)
You can write your own controllers with the basic functionality and then subclass and reuse them. Check the CoreDataTableViewController class that was built for the Stanford iPhone Application Development course -> http://www.stanford.edu/class/cs193p/cgi-bin/drupal/node/167
One technique is to subclass your own subclass. This, modularizes and isolates the differences nicely, however it generates a lot of classes and files, which some find harder to read.
Another technique, which you can use when you want to create a bunch of almost identical controllers with just slight differences, is to give one class a "type" parameter or instance variable. Set the controller's type when you init a controller, and use the controller's type in "if" or switch statements (etc.) to select between slight differences in controller behaviors at run-time. This can help keep all the differences more compactly located in source code.
I made this new Core Data wrapper for iOS in Swift - https://github.com/tadija/AERecord
It has Swift version of CoreDataTableViewController, and CoreDataCollectionViewController also.
Beside that you can use it to setup Core Data stack like this:
AERecord.setupCoreDataStack()
Access context for current thread like this:
AERecord.defaultContext
Save context like this:
AERecord.saveContext()
Create fetch requests like this:
NSManagedObject.create()
NSManagedObject.firstOrCreateWithAttribute("city", value: "Belgrade")
NSManagedObject.deleteAll()
let predicate = ...
NSManagedObject.firstWithPredicate(predicate)
NSManagedObject.allWithAttribute("year", value: 1984)
And much more... I hope it will be useful for someone.
As far as I understand, in Scala we can define a function with no parameters either by using empty parentheses after its name, or no parentheses at all, and these two definitions are not synonyms. What is the purpose of distinguishing these 2 syntaxes and when should I better use one instead of another?
It's mostly a question of convention. Methods with empty parameter lists are, by convention, evaluated for their side-effects. Methods without parameters are assumed to be side-effect free. That's the convention.
Scala Style Guide says to omit parentheses only when the method being called has no side-effects:
http://docs.scala-lang.org/style/method-invocation.html
Other answers are great, but I also think it's worth mentioning that no-param methods allow for nice access to a classes fields, like so:
person.name
Because of parameterless methods, you could easily write a method to intercept reads (or writes) to the 'name' field without breaking calling code, like so
def name = { log("Accessing name!"); _name }
This is called the Uniform Access Principal
I have another light to bring to the usefulness of the convention encouraging an empty parentheses block in the declaration of functions (and thus later in calls to them) with side effects.
It is with the debugger.
If one add a watch in a debugger, such as, say, process referring for the example to a boolean in the focused debug context, either as a variable view, or as a pure side-effect free function evaluation, it creates a nasty risk for your later troubleshooting.
Indeed, if the debugger keeps that watch as a try-to-evaluate thing whenever you change the context (change thread, move in the call stack, reach another breakpoint...), which I found to be at least the case with IntelliJ IDEA, or Visual Studio for other languages, then the side-effects of any other process function possibly found in any browsed scope would be triggered...
Just imagine the kind of puzzling troubleshooting this could lead to if you do not have that warning just in mind, because of some innocent regular naming. If the convention were enforced, with my example, the process boolean evaluation would never fall back to a process() function call in the debugger watches; it might just be allowed in your debugger to explicitly access the () function putting process() in the watches, but then it would be clear you are not directly accessing any attribute or local variables, and fallbacks to other process() functions in other browsed scopes, if maybe unlucky, would at the very least be very less surprising.
When we should use global variable and when class variable and why?
I hope your experiences and ideas to share with us who are novice in this platform.
Example:
Let, i need to trace timestamp and position of touch events (eg. touch start, end) on a layer. I can trace it using global variable or class variable of the class which implements touch event. What should I do?
Regards,
-Sadat
This isn't a problem specific to Objective C or the iPad family of devices.
Variables should have the minimum "visibility" and "duration" that they need, and no more.
You would have to come up with some very convincing reasons for trying to get a global variable through our code review processes. They're almost always able to be replaced with something a little more appropriate.
In response to your comment:
I don't know how global/class variable affects on memory.
There's a nice snippet over here which details how to do class level variables. These are normal C file-scoped variables so they're not visible outside the file but you only get one for the class, not one for every object that you instantiate.
In that sense, they have the advantages of a global (minimal storage and the value is still accessible for reading) without the disadvantages (polluting the global name-space and making it possible for code outside of the class to change it).
And, if it doesn't need to be read outside of the file, just don't provide the initCount method.
It's kind of a flip answer, but don't use global variables at all - stick with class methods and expected encapsulation. Anything else and you'll be fighting the cocoa libraries from dusk to dawn. If you follow their patterns, which include class methods, encapsulation, delegation, etc - you'll be making huge headway with relatively little effort.
The only place where I might think to call something a "global variable" in my efforts are project-wide constants - so not variables at all, but sometimes there's a good need for a constant across your project (TableViewCell identifiers comes to mind)