So I've had to subclass NSURLProtocol because I am using a UIWebView and want to intercept ajax calls which works fine as per this example. I have to get the data from the request from + (BOOL)canInitWithRequest:(NSURLRequest *)request which causes a problem, I now need to call instance methods to do things with the data, but I can't because it's a class method.
How could I call an instance method based on the contents of what is in the request?
You cannot call instance methods from a class method without having an instance first. This is true for all object-oriented systems, AFAIK. After all, the instance methods (usually) use data that the class method cannot have. Imagine an object with a property name, and you now have one thousand objects with different names. How should the class method know which name to use?
So you need to find a way to somehow query instances of your class based on your request, or find a way to get at the information in a way that does not involve instance variables (if a method doesn't use instance variable you can turn it into a class method or even C function). There are many different ways to solve the "query problem", which to chose is highly dependent on your design and even taste.
canInitWithRequest: shouldn't do any work whatsoever, it should just respond with "YES" or "NO". "startLoading" is where you do the work.
Related
I'm currently learning Kotlin through the Kotlin Android Developer program from Udacity. There's two sample apps using DiffUtil.ItemCallback, but declare it in different ways. Both sample apps use a ListAdapter, however one declares the DiffUtil like this: companion object DiffCallback : DiffUtil.ItemCallback<MarsProperty>()
while the other like this: class SleepNightDiffCallback: DiffUtil.ItemCallback<SleepNight>()
Both DiffUtils are passed as parameters to the ListAdapter, with the only difference being that in the case of the class implementation, it has to be initialised:
class PhotoGridAdapter : ListAdapter<MarsProperty, PhotoGridAdapter.ViewHolder>(DiffCallback)
class SleepNightAdapter : ListAdapter<SleepNight, SleepNightAdapter.ViewHolder>(SleepNightDiffCallback())
The only difference between those sample apps is that one downloads and shows images from the internet (the one with the PhotoGridAdapter), while the other shows data from a database, so
my question is: Is one implementation preferred compared to the other? Are there any performance differences between them?
This is probably a matter of opinion. Mine is that the callback should be an object, or anonymous object, but not a companion object.
All it's doing is comparing properties of two objects. It doesn't have to hold any state. So it makes sense for it to be a singleton object rather than a class that you have to instantiate. Whether you define it as a named singleton object or define in place as an anonymous object assigned to a property doesn't make much different in communicating intent.
But it doesn't make sense to me to make it a companion. It's already nested and has a name. All companion does is suggest that you should need to call its functions directly and that the name PhotoGridAdapter should also be thought of as a callback. For instance, it enables you to pass the name PhotoGridAdapter to some other adapter as its DiffUtil callback, which is nonsensical. The only reason it might possibly make sense is if you also want to use it as a utility for comparing items, so you could call functions like PhotoGridAdapter.areContentsTheSame directly. However, I don't think this is likely. Usually, the contents of the callback's functions are either very trivial like passing through equals() or they are very specific to the nature of updating the displayed list.
I have a handful of classes that manage some data. They all sync with a server, and the sync is started by one method called startSync. I want the super method to do some checking if the sync is even necessary, and if it isn't to stop the sync before the child method kicks off the sync.
I have thought of a few options, but not sure which one is the best way to implement it. I'm working in Objective-C so that adds a few variables to consider.
A) Make the method return a boolean value and have the child implementation call the super implementation and check the boolean, returning false if it is false. But someone writing a subclass and implementing the method won't always know what to do with that.
B) Make a doSync abstract method that the super class calls from the startSync method that one would call from outside the class. This has the side effect of not knowing which method to call and accidentially overriding the wrong method.
C) Same as B but the "doSync" method is protected by using an "internal" header. This has the side effect of accidentally overriding the wrong method because they don't know about the internal header, but outside classes don't know about the doCall method to skip the check.
What I'm looking for is input on if one of these is the most appropriate or if there is a better option.
there is a conceptional question:
I want to have a wrapper class which forwarding all called selectors to a given object. How do I do this?
And here is why:
I have a library for synchronizing data with a service. And I use Core Data.
For the library I have to create classes of a specific protocol. But I can not use the same protocol for the Core Data subclasses.
My idea is to create a subclass of the specific protocol and forwarding the protocol calls to the Core Data Object.
But there are many subclasses and many properties per subclass and without changing the Core Data subclasses (project specific requirement!)
Is there a way to do this without overwriting every method?
Thanks for your time =)
Implement -forwardingTargetForSelector:. You can return another object to forward unknown messages to. If that is most of what your class will do, you may want to just subclass from NSProxy rather than NSObject. (NSProxy has the advantage that it doesn't implement all of the standard NSObject methods, so you can forward those as well.)
One common problem with this approach is that the compiler will complain that your class does not respond to the selectors you're sending it. The usual way to address this is by requiring that users of your object declare it as id. This can often be inconvenient as well, so this is a bit of a last resort if other approaches are not possible.
But usually the better approach is to make your class a subclass of the target and add the additional methods required for your protocol. Or you can add the additional methods to the Core Data class via a category.
The answer to your specific question is yes. Message Forwarding contains everything you need.
I think you might want to step back and evaluate other options. For example, can you add this functionality to a base class instead of a proxy class.
Which is better of the two
Creating properties and passing it within methods in class or passing objects as parameters to a method?
I have a datamodel object instance returned by a handler class, which i want to pass it to two different methods, so what is the best approach, assing it to a property in the class and then use it into these two methods, or pass the instance as a parameter to the method?
If an object is only needed temporarily by a class to extract data from for example, then pass it as an method argument.
You should take a step back from the code details and have a more abstract look: If the object has no direct purpose, or does not meaningfully belong with the class, then passing it as a method argument is fine. If the object could be seen as a part of the class (i.e. something the class needs all the time, or relies on a lot), then it might be an option to make it part of the class using a property.
Something else to consider is that setting a property, and then call a method that uses that property, separates the data from the operation. I mean, this obscures what the method does, and on what data it works. Of course this could be overcome by correct naming of those methods. Again look at things at a bit more abstract level to find the most meaningful way (i.e. what is closest to the purpose of the class and what the methods are actually doing) of structuring things.
In other cases these object may belong to underlying/other classes, which means that your current class is only passing them on. In those cases it's clear that you should literally pass them on with methods.
I've been trying to implement a simple component-based game object architecture using Objective-C, much along the lines of the article 'Evolve Your Hierarchy' by Mick West. To this end, I've successfully used a some ideas as outlined in the article 'Objective-C Message Forwarding' by Mike Ash, that is to say using the -(id)forwardingTargetForSelector: method.
The basic setup is I have a container GameObject class, that contains three instances of component classes as instance variables: GCPositioning, GCRigidBody, and GCRendering. The -(id)forwardingTargetForSelector: method returns whichever component will respond to the relevant selector, determined using the -(BOOL)respondsToSelector: method.
All this, in a way, works like a charm: I can call a method on the GameObject instance of which the implementation is found in one of the components, and it works. Of course, the problem is that the compiler gives 'may not respond to ...' warnings for each call. Now, my question is, how do I avoid this? And specifically regarding the fact that the point is that each instance of GameObject will have a different set of components? Maybe a way to register methods with the container objects, on a object per object basis? Such as, can I create some kind of -(void)registerMethodWithGameObject: method, and how would I do that?
Now, it may or may not be obvious that I'm fairly new to Cocoa and Objective-C, and just horsing around, basically, and this whole thing may be very alien here. Of course, though I would very much like to know of a solution to my specific issue, anyone who would care to explain a more elegant way of doing this would additionally be very welcome.
Much appreciated, -Bastiaan
I don't think that sending the container object all of its components' messages is what Mick West was suggesting--that doesn't help to remove the idea of a "monolithic game entity object".
The eventual goal is to have the components communicate directly with one another, with no container object at all. Until then, the container object acts as glue between old code that expects a single object for each game entity and the new component-to-component system.
That is, you shouldn't need to use message forwarding at all in the final product, so ignoring the warnings, or declaring variables as id for now to quiet them, isn't all that ugly. (The plan as laid out by the article is to eventually remove the very code that is causing your warnings!)
A simple way to have those warnings disappear would be to declare the instance variables of type id
That way the compiler assumes you know what you're doing regarding the type of the object and that the object will respond to whatever messages you send to it, or if it doesn't you don't care.
Override your GameObject's -respondsToSelector: method. Your implementation should in turn send a respondsToSelector: message to each of its instances, and return YES if any one of them returns YES.
You can use type of id - or you could invoke the methods using performSelector methods, or create an NSInvocation if the arguments are complex. This is all just a way of getting around compiler warnings, however. If your objects respond to several methods, then possibly declaring a protocol might help, although the same caveat applies.
Another option if I understand the problem correctly is to implement a protocol. This is link an interface in java and variables can be declared like this:
id anObjectRef
That way the compiler understands that the object referred to by anObjectRef conforms to the protocol.
There are also methods that can tell you if an particular object conforms to a specific protocol before you cast or assign it.