It would be nice if the Xamarin forms controls could be available via nuget and you set a key or something.
All the components in my forms app come from Nuget. Applying the two DLL's for Telerik mean a shared solution library or something as we share out projects in TFS. It's a real pain.
7 Answers, 1 is accepted
Thank you for your feedback.
Indeed, I agree that it will much easier if our assemblies are distributed via NuGet. At the moment, however, I can't give a precise time-frame in which we will be able to develop a NuGet mechanism that also involves protection of our assemblies. To help us prioritize better, please vote for that feature in our Feedback Portal.
As a first step, would you find it valuable if we release nupkg files that you can put on your own internal NuGet server? This will allow you to use our components via NuGet across your company.
Regards,
Nikolay
Telerik
See What's Next in App Development. Register for TelerikNEXT.
Rank 1
Hi Nikolay,
At present we can live with it as it's maybe only 2-3 people doing Xamarin. Integrating chart into our forms app is not proving easy though and the documentation seems to have a few mistakes (I'll feed those back via a ticket).
Also you sample code is code behind which is of no help to us as our mobile apps are full MVVM apps and it won't deploy to our test handsets (ARMv7 + ARMv7s). Our apps deploy fine.
It isn't going well.........
Rank 1
Is 64bit unified API supported? it only seems to work in i368 architecture?
Error 209 Native linking failed, undefined Objective-C class: _OBJC_CLASS_$_TKViewTransition. If '_OBJC_CLASS_$_TKViewTransition' is a protocol from a third-party binding, please check that it has the [Protocol] attribute in its api definition file, otherwise verify that all the necessary frameworks have been referenced and native libraries are properly linked in. VesselFinder.iOS
Error 210 Native linking failed, undefined symbol: _TKListViewElementKindSectionHeader. This symbol was referenced the managed member TelerikUI.TKListViewElementKindSectionKey.Header. Please verify that all the necessary frameworks have been referenced and native libraries linked. VesselFinder.iOS
Rank 1
Rank 1
Finally got your app to compile and run in ARMv7, ARMv7s, ARM64 setting and no it doesn't run on the hardware 5s (ARMv7s).
I'll create a repo project and open a ticket but I ain't happy.
Thank you for the feedback.
Regarding our Xamarin offering and the Unified API - yes, we support that API since the end of January (removing the support for the monotouch API) as noted in this blog article. It is strange that you experience issues regarding that matter. Please open a new support ticket and send a sample project, so that we can investigate the case accordingly.
Please also open a new ticket about the documentation issues you have encountered. Generally speaking, we are trying to cover the controls scenarios with both XAML and C# in the documentation. It is our demo app that currently uses code behind for the examples, and should we receive more feedback about the same, we will consider creating one more app which focuses on the XAML usage exclusively.
Regards,
Nikolay
Telerik
See What's Next in App Development. Register for TelerikNEXT.
Rank 1
Hi Nikolay,
I'll do that. It takes a bit of time so it'll be Monday before I can submit it. On the plus side it works really well in Android and we're happy with the control once I'd pieced together what to set from the sparse documentation and code behind samples.
Regarding samples, we do no code behind unless there is no alternative so XAML samples would be welcome, I think enterprise customers will use XAML defined pages in many cases.
We're looking forward to the SwipeDrawer and Listview especially.