I'm interested in binding to iOS Foundation functions as seen in the iOS documentation but there aren't any handles or instances to send a message to invoke them. How would I do this with MonoTouch? I would think that it would involve something within the MonoTouch.ObjCRuntime namespace.
All of MonoTouch's NS* objects implement the MonoTouch.ObjCRuntime.INativeObject interface which has a property getter called "Handle". This accessor is public on NSObject and all subclasses.
Edit: code to bind NSSetUncaughtExceptionHandler() will be something like this:
public delegate void NSUncaughtExceptionHandler (IntPtr exception);
[DllImport ("/System/Library/Frameworks/Foundation.framework/Foundation")]
extern static void NSSetUncaughtExceptionHandler (IntPtr handler);
Then you could use it like this:
static void MyUncaughtExceptionHandler (IntPtr exception)
{
// Got an exception...
}
static void Main (string[] args)
{
NSSetMyUncaughtExceptionHandler (Marshal.GetFunctionPointerForDelegate(
new NSUncaughtExceptionHandler(
MyUncaughtExceptionHandler
)
);
}
Related
Why I cannot do that? I get compilation error.
public interface A {
void update(Object a);
}
public class B implements A{
void update(Long a) {
}
}
That is Java 8
I do not see here violating any OO principle.
That's really make my time difficult to implement a generic API...
(I try to get Generics out of the play because the generic API gets counter-intuitive)
You get a compilation error because void update(Long a) does not implement void update(Object a).
You can implement it as follows:
public class B implements A {
void update(Object o) {
if (!(o instanceof Long)) {
// possibly throw an exception
}
Long a = (Long) o;
...
}
}
A class that implements an interface must implement all the methods declared in the interface. The methods must have the exact same signature (name + parameters) as declared in the interface. The class does not need to implement (declare) the variables of an interface. Only the methods.
Source:
http://tutorials.jenkov.com/java/interfaces.html#:~:text=A%20class%20that%20implements%20an,Only%20the%20methods.
Using the following example, I am not able to intercept the methods call when I have #Advice.Origin Method method as an argument in my method.
public static void premain(String arguments, Instrumentation instrumentation) throws IOException {
new AgentBuilder.Default()
.type(ElementMatchers.nameEndsWith("Controller"))
.transform((builder, type, classLoader, module) -> {
return builder.method(ElementMatchers.any()).intercept(MethodDelegation.to(AccessInterceptor.class));
}
).installOn(instrumentation);
}
#RuntimeType
public static Object intercept(#Advice.Origin Method method, #SuperCall Callable<?> callable) throws Exception {
System.out.println("intercept");
return callable.call();
}
If I remove #Advice.Origin Method method, the code starts working
#RuntimeType
public static Object intercept(#SuperCall Callable<?> callable) throws Exception {
System.out.println("intercept");
return callable.call();
}
There is a difference between #Advice.Origin and #Origin. Advice can do less then delegation but inlines its code. You need to adjust your imports.
I'm developing an application which is using a library and I would like to wrap this library so that it does not goes to deep into my application code. Thanks to that I could change the library I'm using just by re-implementing my wrapper classes.
Suppose that I have a library LibA. It gives me 2 objects to work with, LibAObj1 and LibAObj2. LibAObj2 has a method using LibAObj1.
Here can be a simple definition of their declaration
class LibAObj1 {};
class LibAObj2
{
void action(LibAObj1 &obj);
};
Now I would like to define an interface that my application can use to wrap those objects in my application code
For instance:
class ItfLibAObj1 {};
class ItfLibAObj2
{
public:
void action(ItfLibAObj1 &obj) = 0;
};
The problem comes whenever I want to implement my interface ItfLibAObj2.
class ImplLibAObj2 : public ItfLibAObj2
{
public:
void action(ItfLibAObj1 &itfObj)
{
<how to get my LibAObj1 from itfObj>?
obj.action(LibAObj1);
}
private:
LibObj2 obj;
}
The question is actually in the pseudo code. How to get my LibAObj1 contained in my ItfLibAObj1 reference? I could add a getter function in LibAObj1 interface to return a void pointer that I would cast but I don't find that elegant in C++.
Is there any kind of design pattern I could use to solve my problem? Or do I just have a design issue?
Note that I'm not wishing to select which library to use at run time.
Thanks a lot for your help.
Kind regards
You problem perfectly explains why in Proxy Pattern, both the Real and Proxy must implement the same interface:
And your code should look like this:
// interfaces
class ItfLibAObj1 {};
class ItfLibAObj2
{
public:
void action(ItfLibAObj1 &obj) = 0;
};
// real
class RealLibAObj1 : public ItfLibAObj1 {};
class RealLibAObj2 : public ItfLibAObj2
{
void action(ItfLibAObj1 &obj)
{
...
}
};
// proxy
class ProxyLibAObj1 : public ItfLibAObj1
{
private:
RealLibAObj1 real;
};
class ProxyLibAObj2 : public ItfLibAObj2
{
private:
RealLibAObj2 real;
void action(ItfLibAObj1 &obj)
{
// do something
real.action(obj); // delegate to the real
// do something
}
};
However, if the whole purpose of your "wrapping" is adding a new layer between your core/real and the outside (client), please consider the Facade Pattern which provides a simpler interface to the client, instead of merely mimic the classes/methods of the core.
if I have the interface interfaceA
public interface IInterfaceA
{
void MethodA();
void MethodB();
}
and I have the classA
class ClassA:IInterfaceA
{
public void MethodA()
{
}
public void MethodB()
{
}
}
it's ok that I use ninject's bind,but when it comes that I have a method that called MethodC,I think the method should only exists in classA(just for classA) and should not be defined in InterfaceA,so how to use ninject'bind when just calling like this:
var a = _kernel.get<IInterfaceA>()
should I convert the result into ClassA ? (is that a bad habbit?) or there are another solution
Usually this is needed when you want interface separation but need both interfaces to be implemented by the same object since it holds data relevant to both interfaces. If that is not the case you would be able to separate interfaces and implementation completely - and then you should do so.
For simplicitys sake i'm going to asume Singleton Scope, but you could also use any other scope.
Create two interfaces instead:
public interface IInterfaceA {
{
void MethodA();
}
public interface IInterfaceC {
void MethodC();
}
public class SomeClass : IInterfaceA, IInterfaceC {
....
}
IBindingRoot.Bind<IInterfaceA, IInterfaceB>().To<SomeClass>()
.InSingletonScope();
var instanceOfA = IResolutionRoot.Get<IInterfaceA>();
var instanceOfB = IResolutionRoot.Get<IInterfaceB>();
instanceOfA.Should().Be(instanceOfB);
Does this answer your question?
I have the following interfaces that are part of an existing project. I'd like to make it possible to call the Store(..) function with dynamic objects. But I don't want to change the Interface hierarchy (if at all possible).
public interface IActualInterface
{
void Store(object entity);
}
public interface IExtendedInterface : IActualInterface
{
//Interface items not important
}
public class Test : IExtendedInterface
{
public void Store(object entity)
{
Console.WriteLine("Storing: " + entity.ToString());
}
}
and the following code:
IExtendedInterface extendedInterfaceTest = new Test();
IActualInterface actualInterfaceTest = new Test();
Test directTest = new Test();
dynamic employee = new ExpandoObject();
employee.Name = "John Smith";
employee.Age = 33;
employee.Phones = new ExpandoObject();
employee.Phones.Home = "0111 123123";
employee.Phones.Office = "027 321123";
employee.Tags = new List<dynamic>() { 123.4D, 99.54D };
try
{
extendedInterfaceTest .Store(employee);
}
catch (RuntimeBinderException rbEx)
{
Console.WriteLine(rbEx.Message);
}
//Casting as (object) works okay as it's not resolved at runtime
extendedInterfaceTest.Store((object)employee);
//this works because IActualInterface implements 'Store'
actualInterfaceTest.Store(employee);
//this also works okay (directTest : IProxyTest)
directTest.Store(employee);
When I call extendedInterfaceTest.Store(employee), it raises a runtime binder exception. Why does the interface type make a difference when it's the same underlying type? I can call it on IActualInterface and Type, but not IExtendedInterface?
I understand that when calling a function with a dynamic parameter, the resolution happens at runtime, but why the different behaviours?
What you need to remember is that dynamic resolution basically does the same process as static resolution, but at runtime. Anything that couldn't be resolved by the CLR won't be resolved by the DLR.
Let's take this small program, inspired by yours, and that doesn't use dynamic at all:
namespace ConsoleApplication38 {
public interface IActualInterface {
void Store(object entity);
}
public interface IExtendedInterface : IActualInterface {
}
public class TestInterface : IExtendedInterface {
public void Store(object entity) {
}
}
public abstract class ActualClass {
public abstract void Store(object entity);
}
public abstract class ExtendedClass : ActualClass {
}
public class TestClass : ExtendedClass {
public override void Store(object entity) {
}
}
class Program {
static void TestInterfaces() {
IActualInterface actualTest = new TestInterface();
IExtendedInterface extendedTest = new TestInterface();
TestInterface directTest = new TestInterface();
actualTest.Store(null);
extendedTest.Store(null);
directTest.Store(null);
}
static void TestClasses() {
ActualClass actualTest = new TestClass();
ExtendedClass extendedTest = new TestClass();
TestClass directTest = new TestClass();
actualTest.Store(null);
extendedTest.Store(null);
directTest.Store(null);
}
static void Main(string[] args) {
TestInterfaces();
TestClasses();
}
}
}
Everything compiles fine. But what did the compiler really generate? Let's see using ILdasm.
For the interfaces:
// actualTest.Store
IL_0015: callvirt instance void ConsoleApplication38.IActualInterface::Store(object)
// extendedTest.Store
IL_001d: callvirt instance void ConsoleApplication38.IActualInterface::Store(object)
// directTest.Store
IL_0025: callvirt instance void ConsoleApplication38.TestInterface::Store(object)
We can see here that the C# compiler always generates calls for the interface or class where the method is defined. IActualInterface has a method slot for Store so it's used for actualTest.Store. IExtendedInterface doesn't, so IActualInterface is used for the call. TestInterface defines a new method Store, using the newslot IL modifier, effectively assigning a new slot in the vtable for that method, so it's directly used since directTest is of type TestInterface.
For the classes:
// actualTest.Store
IL_0015: callvirt instance void ConsoleApplication38.ActualClass::Store(object)
// extendedTest.Store
IL_001d: callvirt instance void ConsoleApplication38.ActualClass::Store(object)
// directTest.Store
IL_0025: callvirt instance void ConsoleApplication38.ActualClass::Store(object)
For the 3 different types, the same call is generated because the method slot is defined on ActualClass.
Let's now see what we get if we write the IL ourselves, using the type we want rather than letting the C# compiler choosing it for us. I've modified the IL to look like this:
For interfaces:
// actualTest.Store
IL_0015: callvirt instance void ConsoleApplication38.IActualInterface::Store(object)
// extendedTest.Store
IL_001d: callvirt instance void ConsoleApplication38.IExtendedInterface::Store(object)
// directTest.Store
IL_0025: callvirt instance void ConsoleApplication38.TestInterface::Store(object)
For classes:
// actualTest.Store
IL_0015: callvirt instance void ConsoleApplication38.ActualClass::Store(object)
// extendedTest.Store
IL_001d: callvirt instance void ConsoleApplication38.ExtendedClass::Store(object)
// directTest.Store
IL_0025: callvirt instance void ConsoleApplication38.TestClass::Store(object)
The program compiles fine with ILasm. However it fails to pass peverify and crashes at runtime with the following error:
Unhandled Exception:
System.MissingMethodException: Method
not found: 'Void
ConsoleApplication38.IExtendedInterface.Store(System.Object)'.
at
ConsoleApplication38.Program.TestInterfaces()
at
ConsoleApplication38.Program.Main(String[]
args)
If you remove this invalid call, the derived classes calls work fine without any error. The CLR is able to resolve the base method from the derived type call. However interfaces have no true representation in runtime, and the CLR isn't able to resolve the method call from the extended interface.
In theory, the C# compiler could emit the call directly to the correct class specified in the runtime. It would avoid problems about middle classes calls as seen on Eric Lippert's blog. However as demonstrated, this is not possible for interfaces.
Let's get back to the DLR. It resolves the method exactly the same way as the CLR. We've seen that IExtendedInterface.Store couldn't be resolved by the CLR. The DLR cannot either! This is totally hidden by the fact that the C# compiler will emit the right call, so always be careful when using dynamic unless you perfectly know how it works in the CLR.