You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But to be able to discuss this topic with the community, i'm opening this issue.
We use a paid security third party library that only has Android/iOS native support, but we maintain a Binding for both versions, so was not a problem so far. The problem started some time a go, because they start using DataBinding in their Android SDK, blocking us to receive any update for some time now.
Since i didn't find any workarounds for this, its a big problem for us for a security point of view.
Also, it looks like google will not drop this any time soon and more libraries will use this since there is already in stable version, blocking the use of this libraries in any xamarin project.
Supporting Java DataBinding is not currently on our roadmap.
It is rather complex to integrate into our build system, as we do not currently invoke gradle during builds. I think what would need to happen is the step that compiles the generated Java callable wrappers would need to be changed to invoke gradle instead of javac. Additionally there would need to be a mechanism to add arbitrary gradle commands to this invocation. I think there are also Java annotations that we would need to add to the JCWs.
We will continue to monitor the need for this (and other enhancements that require adding gradle to the build, potentially AndroidX.Room(?)) for future prioritization.
Supporting Java DataBinding is not currently on our roadmap.
It is rather complex to integrate into our build system, as we do not currently invoke gradle during builds. I think what would need to happen is the step that compiles the generated Java callable wrappers would need to be changed to invoke gradle instead of javac. Additionally there would need to be a mechanism to add arbitrary gradle commands to this invocation. I think there are also Java annotations that we would need to add to the JCWs.
We will continue to monitor the need for this (and other enhancements that require adding gradle to the build, potentially AndroidX.Room(?)) for future prioritization.
What are the current options to have UI binded to properties in code in native Android .NET then? And I don't want to explicitly set texts, images through code each time. MVVMCross seems like an overkill for me and completely overwhelming to start using. Bindings are so much easier in MAUI using XAML and INotifyPropertyChanged.
Activity
jpobst commentedon Jan 23, 2023
Supporting Java DataBinding is not currently on our roadmap.
It is rather complex to integrate into our build system, as we do not currently invoke
gradleduring builds. I think what would need to happen is the step that compiles the generated Java callable wrappers would need to be changed to invokegradleinstead ofjavac. Additionally there would need to be a mechanism to add arbitrarygradlecommands to this invocation. I think there are also Java annotations that we would need to add to the JCWs.We will continue to monitor the need for this (and other enhancements that require adding
gradleto the build, potentially AndroidX.Room(?)) for future prioritization.[-]Support for binding a library that uses DataBinding[/-][+]Java DataBinding support[/+]GalaxiaGuy commentedon Jan 27, 2023
For reference, here is another thing that would benefit from
gradlesupport:xamarin/GooglePlayServicesComponents#172
ziomek64 commentedon Aug 13, 2024
What are the current options to have UI binded to properties in code in native Android .NET then? And I don't want to explicitly set texts, images through code each time. MVVMCross seems like an overkill for me and completely overwhelming to start using. Bindings are so much easier in MAUI using XAML and INotifyPropertyChanged.