I am currently facing an issue about Xamarin Forms Android Bindings library.
I've put a .jar library inside my bindings project and I realize that the library is not fully loaded.
When I build my bindings project it compiles properly but I still have some warnings in my output.
1>BINDINGSGENERATOR : warning BG8102: Class Java.Util.LinkedHashMap has unknown base type Java.Util.HashMap.
1>BINDINGSGENERATOR : warning BG8103: Class Com.MyParams has invalid base type java.util.LinkedHashMap.
1>BINDINGSGENERATOR : warning BG8701: Invalid return type com.MyParams in method GetParams in managed type Com.TagOp.
1>BINDINGSGENERATOR : warning BG8801: Invalid parameter type com.MyParams in method TagOps in managed type Com.TagOp.
1>BINDINGSGENERATOR : warning BG8801: Invalid parameter type com.MyParams in method TagOps in managed type Com.TagOp.
1>BINDINGSGENERATOR : warning BG8801: Invalid parameter type com.MyParams in method TagPage in managed type Com.Tag.
In my Android code I can't use the Com.MyParams class because it's not loaded.
This problem occurs since the update of Xamarin for Visual Studio 2017.
Do you have any leads to solve this problem ? Thanks in advance.
HashMap & LinkedHashMap are not known ...therefore nothing based upon them can be instanced.
When the data-binding does not know a class, then it either lacks the annotations, it might not extend class BaseObservable and/or has wrongful get / set method names (which need to match the name of the field); there are quite a few conditions to meet, depending if one-way or two-way data-binding is required. Reviewing the generated code often gives a clue what one has to change.
However, directly data-binding the JAR classes does not even appear possible, unless adding the required annotations into them and then building the JAR, in order to have them bind-able. The documentation of the Android Data Binding Library and Xamarin Java Bindings Metadata explains it (replicating the required Java classes from scratch, perfectly bind-able, might be the most fast-forward, if not the only way).
One can only work around it, by substituting the classes to be bound to the GUI - which is possible with rather simple classes, or when using a Java decompiler (in order to know the fields to use).
Related
Up until now, I had been using the following libraries:
kotlin("jvm")
kotlin("plugin.serialization") version "1.7.10"
implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.3.2")
Since until now, there is no serializer for the type kotlin.time.Duration, I had my own custom serializer. So far so good.
Now I want to update the kotlinx serialization libraries to 1.4.0, which has a DurationSerializer.
When I do this, the compiler naturally protests the following:
Caused by: java.lang.IllegalArgumentException: The name of serial descriptor should uniquely identify associated serializer. For serial name Duration there already exist DurationSerializer.
So I delete my custom DurationSerializer in order to use the new one included in the library, clean and attempt to recompile. However, when I do that, the following happens:
Serializer has not been found for type 'Duration'. To use context serializer as fallback, explicitly annotate type or property with #Contextual
Basically, the new library version can tell that my custome DurationSerializer is conflicting with its own, but then can't actually use its own. How do I get around this?
Got the answer from the kotlinx.serialization github repository here.
Turns out the library version of the serializer will only be added in a future compiler update.
In the meantime, our serial name for the custom serializer was too similar to the libraries', causing a conflict. Changed it from kotlin.time.Duration to CustomDurationSerializer and the issue went away.
I have a class library which includes a custom MVC model binder to instantiate various concrete types which derive from an abstract class. The model binder is almost identical to the one described in this post.
It works fine when using it from within the same Visual Studio Solution that also includes an MVC web application for testing.
My problem is that having created a nuget package from the assembly and included it in a totally separate MVC application the model binder no longer works, despite having configured it correctly in Global.asax.cs.
After some hair pulling I recreated the model binder directly in the separate MVC app, and as I was doing so I noticed that the overridden CreateModel() method in the binder is protected. It now gets executed and I suspect the protected keyword has something to do with it but I would like someone to explain why exactly.
Even with the 'local' modelbinder there are more problems. When it executes, and tries to instantiate the concrete object, I get an exception Could not load type XXXX from assembly { separate MVC project assembly name} so it seems the model binder is unable to load types from outside its own assembly.
Can anyone give me more information on why this happens and what I can do to work around it? Bearing in mind I need the model binder and models to reside in the class library not in the MVC assembly.
I had the same problem as you did, binding to models in a different assembly, but I needed a different solution. I used the same model binding example that you linked to, and I also got the same exception: Could not load type XXXX from assembly
I ended up needing to use the AssemblyQualifiedName for each concrete type. So my views contain this:
#Html.Hidden("ModelType", Model.GetType().AssemblyQualifiedName)
Instead of this:
#Html.Hidden("ModelType", Model.GetType())
I'm still wondering why this was necessary, since the default model binder can load types from the assembly in question.
OK so I was being stupid. It turns out that a few assumptions led me on a wild goose chase.
The ModelBinder was executing correctly to start with. My viewmodel had nested properties which were also abstract base types and required the model binder but I hadn't put the hidden fields in the view to identify their concrete type, nor had I added them to the Global.asax configuration. Once I did this everything started to work as expected.
I'm in the process of upgrading my application the latest release of Eclipse Equinox 3.7 and associated libraries. I'm excited to have the generic support in OSGi 4.3 and digging the new Bundle.adapt() concepts. I've run into one stumbling block.
Previously, I've used PackageAdmin.getBundle(Class) to find out which bundle loaded which classes. I have to do this due to some RMI object serialization usage.
QUESTION: Is there an way to accomplish the same result, mapping Class to Bundle, using the new BundleWiring API?
I realize that PackageAdmin is probably not going away anytime soon, but I hate deprecation warnings.
Kinda embarrassed that I didn't find this the first time I looked through the document. Answering my own question for completeness.
From the core specification PDF ...
Section 3.9.9 - Finding an Object’s Bundle
There are scenarios where a bundle is required in code that has no access to a Bundle Context. For this
reason, the framework provides the following methods:
Framework Util – Through the FrameworkUtil class with the getBundle(Class) method. The
framework provides this method to allow code to find the bundle of an object without having the
permission to get the class loader. The method returns null when the class does not originate from
a bundle.
Class Loader – An OSGi framework must ensure that the class loader of a class that comes from a
bundle implements the BundleReference interface. This allows legacy code to find an object’s
bundle by getting its class loader and casting it to a BundleReference object, which provides
access to the Bundle. However, this requires the code to have the permission to access the class
loader. The following code fragment shows how to obtain a Bundle object from any object.
ClassLoader cl = target.getClassLoader();
if ( cl instanceof BundleReference ) {
BundleReference ref = (BundleReference) cl;
Bundle b = ref.getBundle();
...
}
In an OSGi system, not all objects belong to the framework. It is therefore possible to get hold of a
class loader that does not implement the BundleReference interface, for example the boot class path
loader.
How would I get a hold of a singleton in the main application from a SIMBL plugin? When I try to call something like [ProcessControl sharedInstance], I get an error that ProcessControl is undefined (even though it is declared in a header file).
Use NSClassFromString to look up the class at run time, then send it the sharedInstance message as normal.
Be prepared for NSClassFromString to return Nil or for the message to the class to fail. Either one will happen if the application developer removes or renames the class or its singleton method. You assume this risk whenever you write a plug-in for an application that doesn't have a documented, supported plug-in API.
Your “plug-in” will be most robust if all of your code that interacts with the application's classes and instances thereof looks thoroughly paranoid.
I'm using Workshop for Weblogic and I'm testing an XQuery Transformation.
Both MFL and XSD are valid. But the XQuery doesn't seem to work... it gives me this error:
Error occurred while executing XQuery: loader constraint violation: when resolving method "javax.xml.stream.XMLInputFactory.createXMLStreamReader(Ljava/io/Reader;)Ljavax/xml/stream/XMLStreamReader;" the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current class, weblogic/xml/query/parsers/StAXCursorAdaptor, and the class loader (instance of ) for resolved class, javax/xml/stream/XMLInputFactory, have different Class objects for the type javax/xml/stream/XMLStreamReader used in the signature
Have you ever seen this before? How can I solve this please?
You need to reinstall workshop with default JRockit, or what is much faster just edit workshop.ini and change -vm parameter value from Sun/Oracle JDK to JRockit SDK which can be found in weblogic directory.