In Blackberry Runtime Store, when sharing objects between applications. How can we call methods of the shared object in another application, if the object itself is not recognized in the other application ? i am getting a runtime error when object gets typecasted, as that object is not defined in the calling applicatoin .
If i typecast it to super interface and have the interface in another application. When i call getClass() on the object returned from the runtimestore. It shows as concrete class instance stored in the RunTimeStore.
How can a share a object in runtimestore and use it across different applications ?
The referenced question seems to answer what you're asking.
If you're putting com.foo.bar.MyClass which implements the com.foo.bar.MyInterface in app1, you need to also have it in app2. The package that your class and interface appears to make a difference.
How is your question different?
You seem to have answered your own question - you can typecast to an interface that the calling app is aware of. If you want to cast to a class/interface that's not defined in the calling app though, you're out of luck - it can't be done.
BlackBerry is based on Java ME (formerly J2ME) which has very limited support for runtime reflection - essentially just class names, which you're already seeing when you get the name of the class from the Runtime Store. Unlike Java SE/EE you can't call methods on classes using the String names of the methods - it would be very handy to have sometimes, but unfortunately not supported.
So to summarize, if you can't include the class definition in your calling app, derive an interface (or superclass) with the methods the calling app wants to call, make the class implement that interface, and include that interface/superclass in both the calling app and the other app.
Related
I am trying to incorporate Microsoft.Extensions.DependencyInjection into an existing ASP.NET 4.6.1 app.
I know that while .NET Core has it built-in, for 4.6.1 you need to create some initial classes as outlined in http://scottdorman.github.io/2016/03/17/integrating-asp.net-core-dependency-injection-in-mvc-4/. (The article seems to be out of date since the sample code does not show implementation of BeginScope() and Dispose() for IDependencyResolver. If anybody has more updated examples that would be appreciated.)
"Services" accessed by controllers where you are creating instances via constructors is fairly simple but my problem is when I need an instance of "something" that is from a property or method of an existing object.
For example, I have a inherited DbContext that needs an instance of System.Security.Principal.IIdentity that comes from the logged in user.
Another example is an instance of ApplicationUser. ApplicationUser inherits IdentityUser and the current user can be found by calling FindById() method of AppUserManager.
While AppUserManager can easily be instantiated using DI, how can I use DI the inject the output of the FindById() method? I cannot seem to find any documentation or sample code about this for Microsoft based framework. Other frameworks like Unity seem to support Property-based injection.
In essence, can DI be used with all existing classes or do you specifically need to code out the classes to support DI from the beginning? (i.e. only expect parameters to be passed in via constructors and make sure those instances themselves are created via constructors).
The very simple and short answer to your question "Does Microsoft DependencyInjection support non-constructor injection?" is, no.
Out-the-box Microsoft DI does not currently support property injection like other frameworks such as Ninject. If you need that feature, I suggest using those frameworks instead (I cant imagine MS has any plans to add property injection any time soon).
Your other option is to consider how you can refactor your code to use constructor injection instead which is the preferred method
I built a framework myself, and in the framework, I have a http request
that needs to use dynamic parameters.
The whole implementation does not need the framework's user to implement anything but the dynamic parameters.
So, my question is: How can I get the parameters?
Depending on the framework design, you might either
need a Singleton object that holds the framework's configuration and a configuration-method must be called by the user before any other API use.
Thus, the methods using the data can access it when they need it throughout the framework.
Pass the arguments as actual arguments to the methods that actually need this data.
Have the objects using the data store the data for object lifetime and have the user use a factory that configures the objects accordingly.
I want to use introspection to modify an object. However, I need a way of knowing if I created that object class, or if it is something in Foundation, etc...
Is there a property I can access (even in objcruntime.h) to see this?
This may be a silly question, so sorry for asking this, and fyi I'm new to this kind of stuff.
After reading the documentation about mirrors, I can only grasp that the mirrors API is just like copying some instance plus access to some method that I don't know when/why to use.
Anybody care to give me some pointers, some example would be nice.
Mirror API allows you to retrieve metadata about objects and types programmatically (during execution) and to execute methods on objects . It is similar to reflection in .NET or Java.
A typical example is implementing plugin support:
Let's say that you define an IPlugin interface and want to automatically register with your PluginManager an instance of each type that implements it, without need to explicitly register each new implementation. Sometimes you even don't know all the plugins in advance, e.g. if users can deploy their own plugins.
You could do it like this (WARNING: I have never used Mirror API, so this is a high level description based on API documentation, not a proper implementation):
You first use MirrorSystem.libraries to get LibraryMirror instance for each library in that MirrorSystem
Then for each LibraryMirror you use classes property to get ClassMirror for each class in the library
For each ClassMirror use superinterfaces to get all implemented interfaces
If any of the implemented interfaces is IPlugin you can create an instance of that class (ClassMirror.newInstance) and register it with plugin manager.
Without mirror API, you would not be able to enumerate all the types, find what interfaces they implement (without creating an object) or create an instance of a type that you don't know about in advance.
To be honest I am not sure what is the current state of mirror API in Dart, I believe that it is still not finished, but I might be wrong.
is it possible to access a static property of a COM object without creating an instance of the object?
my situation is this:
i have an unmanaged application (written in delphi). this application exposes a COM-based plugininterface. until now i only wrote managed plugins in c#. plugins provide their info (name, author, ..) via a static property that returns an instance of PluginInfo (which implements IPluginInfo). this static property i can access on the managed plugins using http://managedvcl.com.
now i want to write unmanaged plugins on the same interface. i can load them using:
plug := CreateComObject(TGuid) as IMyPlugInterface;
and they run, but i don't know how to read out their PluginInfo.
so the question again is: is there another way than implementing IPluginInfo in the plugin-class and only accessing the info after i have created an instance of the plugin?
It may not be as "elegant" as the static property provided by the C# plug-in architectures you are used to, but you could provide an exported function in the COM DLL that returns an IPluginInfo. By convention this exported function would have the same name in every plug-in DLL designed to operate in your architecture.
The host application would obtain the proc address for the exported function dynamically at runtime then call it to obtain the IPluginInfo interfaced object for that specific plug-in DLL. The mechanics for this could all be encapsulated in a class for your plug-in architecture, hiding the implementation details.
It would take very little work to reach a point where your plug-in architecture would be just as convenient to use and code against as the C# infrastructure you are more used to.
No. Delphi's interfaces are implemented as virtual methods (basically) on an object instance, and AFAIK can't accept static members. That would probably make a useful enhancement, though.