#BeanProperty generates simple get/set methods. Is there a way to automatically generate such methods with support for firing property change events (e.g. I want to use it with JFace Databinding?)
I've had the same question, and have been keeping a close eye out for possible answers. I think I've just stumbled across one (although I haven't tried it yet). Scala 2.9 has a feature for handling dynamic calls (meant for integration with dynamic languages, I suspect). Essentially, calls to methods which don't exist are routed to a method called applyDynamic. An implementation of that method could use reflection to check that the method signature matches a property (possibly one with an annotation similar to #BeanProperty). If there is a match, it could handle firing the event.
Maybe that's something where a custom compiler plugin can do the trick.
Sadly I have no idea about how to write such a plugin. But at least thought I give you this pointer.
I would be very interested, if you'd come up with something along that line.
Related
I recently discovered the convenience of using Refit, but after reading through its documentation I was unable to find a way to replace/override an implementation of an interface method that RestService would normally generate.
Does Refit provide a way to do this? Or is there a way to solve such a problem without getting too hacky?
I'm just worried about using Refit all over the place and then half way into a project realizing I can't modify the implementation of a method. It's inevitable that I'll have to break coding standards to meet a requirement and I'd like to know what would be the solution if a situation like this occurs?
Its not exectly what you want, but you can create extension where you call Refit implementation, but before and after call you can add any customization you want.
For example, I have use it to reformat response.
We are currently using PostSharp for its standard functionality (logging, caching, transactions, and so on).
We also generate dynamically, at runtime, some custom classes, using Reflection.Emit. This obviously slows startup, and as we need to add more dynamic type generation, I am wondering, since all the information for the dynamic types is known at build time, whether we can use PostSharp to do this.
So, the question itself is, can I use PostSharp to achieve what I can do with Reflection.Emit, but at build time?
Regards
The PostSharp itself is using PostSharp.Sdk to manipulate the binary code, but this API is not publicly documented and supported at the moment. So, it's not future-proof to rely on it in your project.
The closest you can get with the documented API is probably by introducing interfaces, methods and properties: http://doc.postsharp.net/content/code-injections
I'm thinking about a platform-neutral (i.e. not .NET MEF) technique of implementing chain-of-responsibliity pattern using web services as the handlers. I want to be able to add more CoR handlers by deploying new services and not compiling new CoR code, just change configuration info. It seems the challenge will be managing the metadata about available handlers and ensuring the handlers are conforming to the interface.
My question: any ideas on how I can safely ensure:
1. The web services are implementing the interface
2. The web services are implementing the base class behavior, like calling the successor
Because, in compiled code, I can have type-safety and therefore know that any handlers have derived from the abstract base class that ensures the interface and behavior I want. That seems to be missing in the world of services.
This seems like a valid question, but a rather simple one.
You are still afforded the protection of the typing system, even if you are loading code later, at runtime, that the original code never saw before.
I would think the preferred approach here would be to have something like a properties file with a list of implementers (your chain). Then in the code, you are going to have to have a way to instantiate an instance of each handler at runtime to construct the chain. When you construct the instance, you will have to check its type. In Java, for instance, that would take the form of instanceof (abomination ordinarily, but you get a pass for loading scenarios), or isAssignableFrom. In Objective C, it's conformsToProtocol.
If it doesn't, it can't be used and you can spit an error out to the console.
I recently read about Dynamic Creation as one of the design pattern in Cocoa. However, I don't really understand how it works. So I need clarification from you who have implemented in your design.
What is it? Why and when would you use this design pattern?
I have read that you use NSClassFromString() to access the class. I assume that I use this when I want to use class that doesn't exist within the project I'm working on. Usually when I want to use certain class, I imported them in header. Does using this approach skip the #import process?
Class JavaArrayList = NSClassFromString(#"java.util.ArrayList");
I quote the code above as example. If do according to the code above, that means I can create a new JavaArrayList class and use the methods in it right?
JavaArrayList *foo = [[JavaArrayList alloc] init];
[foo useMethodBelongJava:doWhateverTask];
What are the benefits of using this design pattern? Especially in iPhone Development.
Your example appears to be using that pattern to instantiate a Java class. In the old days (up to about MacOS 10.4 I think), Apple had some technology called the Cocoa-Java Bridge, which let you use Java classes within Objective-C code. You had to instantiate them in the manner specified, because they didn't have Objective-C header files to import.
However, as of Snow Leopard, the Java Bridge no longer exists, so the code in your question won't work any more.
The recommended solution for calling a Java class from Objective-C is now JNI. Take a look at this question if that is what you're trying to do.
What is it? Why and when would you use this design pattern?
Coming back to NSClassFromString, it has other uses besides instantiating Java classes (which, as I mentioned, it doesn't do any more!). For an example, recently I wrote a library for parsing the response from a web service. In order to make it work with different web services, I had it read in a configuration file that described the data format it was expecting. For each field in the web service, my configuration file specified which Cocoa class to instantiate. Thus, in my code, I had a Cocoa class name as a string. To instantiate the object I wanted, I used NSClassFromString to turn it into a Class object.
Usually when I want to use certain class, I imported them in header. Does using this approach skip the #import process?
It can do. NSClassFromString will instantiate any class that is present at run time, so you don't need the header to be able to use it. If you don't have the header, you'll get a bunch of warnings of "may not respond to selector" whenever you try and use your newly instantiated class, as the compiler doesn't have enough information to be helpful. However, in many circumstances where NSClassFromString is useful, the header files aren't available.
See this link:
need advise about NSClassFromString
The only real benefit for iPhone was being able to reference classes from newer APIs and still target the old APIs. Since 4.0 you can do this anyway by setting the deployment target of your project. I can't really see any reason you would use it for iPhone programming any more.
This would only work for objective-C classes. You can't import java objects into your iphone app.
Is there anyway to add more fields (e.g. location and etc) to TTPhoto protocol?
I know that one way is to create my own protocol but that would require me to change a lot of stuffs in my view controllers. Is there any simpler way to achieve this?
Formal protocols are primarily a compile time conceit, to help you be more clear about your intentions. They're a relatively recent invention, before which all protocols were informal — they were part of the class documentation but not declared in the code. They have a runtime effect in that you can use some of the Objective-C runtime methods to query whether a particular class responds to a particular protocol (just as you can query whether a particular class responds to a particular selector), but no such testing will occur at runtime when you pass objects about.
Protocols are just a contract defining communications and don't specify behaviour. So there's no concept of inheritance. And there's no runtime list of the selectors included in a protocol, so the idea isn't particularly helpful.
Your best shot is to define an additional protocol that includes the extra functionality you want. Write your new objects to implement both protocols. Extend classes you don't want or have access to using category methods.
If you need additional storage to handle the new fields, then it's safest to subclass. You can actually add instance variables at runtime nowadays, but you'd need to drop down to the C interface to the Objective-C runtime and finding an opportunity to do so would require some hoop jumping.