Preview: Xamarin.Forms Embedding

2»

Posts

  • rseostarrseostar USUniversity ✭✭

    @Xavios Need the stack trace from the exception to help you out.

  • XaviosXavios BEMember

    @rseostar

    pastebin.com/H5xaZ7h0

    Thank you

  • rseostarrseostar USUniversity ✭✭

    @Xavios Try turning your output detail up, and run through it again to see if it gives any more info.
    (Options -> Projects and Solutions -> Build and Run -> selected detailed under the "MSBuild project build output verbosity" dropdown.)

    As you probably noticed, the output you are getting isn't helpful at all by just saying an exception occurred with no indication as to why. PM me if you find anything :smile:

  • AlexanderGnauckAlexanderGnauck DEMember
    edited October 2017

    is it already possible to embed Xamarin.Froms 3.0 in WPF Desktop (not UWP) or Winforms applications?
    If yes, is there an example?

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    No. WinForms is long dead and not XAML compatible.
    Nor are you going to put Xamarin XAML into a WPF application

    While all the concepts are interchangable, there are enough differences to make this not a good path to even try.

    Just make a new Xamarin.Forms application - then import the models, ViewModels and other CSharp logic classes. If you created a good, well-architected WPF application then you don't really have a lot of work to import those classes. If you didn't, then you needed to go back and make a better version 2 of it anyway.

  • rseostarrseostar USUniversity ✭✭

    @ClintStLaurent @AlexanderGnauck Looks like @jsuarezruiz has an example of embedding forms in wpf up on github. https://github.com/jsuarezruiz/forms-embedding-wpf

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @rseostar @AlexanderGnauck
    I'm sure if you look enough on the internet you can find examples of just about anything.
    I have no doubt that I can find a video on how to convert my '68 VW Beetle into an 18 Wheeler. But does that make it a good idea?

    You do what you like - it doesn't effect anyone but you. But I'll tell ya right now - if someone interviewed with me that had done something like that their resume would go to the bottom of the stack.

    Personal advice

    WinForms is F'ing dead - let it die. Bring your skillset forward 15 years and just make a new decent app using modern principals and designs. Trying to hang on to that old crap is not doing you any favors.

  • CosminStirbuCosminStirbu ROMember ✭✭

    Hi guys,

    I've been following this thread and even though I've noticed people asking about this, it's not quite clear how you suggest handling navigation from an embedded XF Page to a native UIViewController or Activity / Fragment (Android).

    Can you maybe reference any sample code that does this?

    You could probably leverage the Messaging infrastructure for this :-?, but I wonder what other options do you guys thing about.

    Thank you,
    Cosmin

  • csumantacsumanta Member

    There are issues with native XF embedding as it does not support multiple windows with multiple dispatchers at least from my test in UWP. Multi window scenarios include main window and share target window in UWP (Desktop family) which have two separate dispatchers. It was frustrating to see that XF binding framework applies binding using BeginInvokeOnMainThread() which immediately crashes the app if embedding on different windows i.e. separate dispatchers. Another problem is that Forms.Init initializes on the first dispatcher and retains a initialized flag throughout its life even if XF is being initialized on a new dispatcher later on. So, how about considering the following fixes?

    1. Maintain a Dispatcher in BindableObject itself. It would be straight forward to abstract CoreDispatcher / Looper / NSRunLoop in a new class rather than maintaining on a single IPlatformServices instance in Device class. If that sounds to be too much work, as a tactical fix in PlatformServices.BeginInvokeOnMainThread() check if current thread has a dispatcher and then post to that, else post to the main dispatcher.

    2. In Forms.Init(), check if Xamarin Forms have been initialized in the current Dispatcher, if not do the dispatcher specific initialization. eg. In UWP, load native ResourceDictionary in the platform Application object.

  • EZHartEZHart USXamarin Team Xamurai

    @csumanta said:
    There are issues with native XF embedding as it does not support multiple windows with multiple dispatchers at least from my test in UWP. Multi window scenarios include main window and share target window in UWP (Desktop family) which have two separate dispatchers. It was frustrating to see that XF binding framework applies binding using BeginInvokeOnMainThread() which immediately crashes the app if embedding on different windows i.e. separate dispatchers. Another problem is that Forms.Init initializes on the first dispatcher and retains a initialized flag throughout its life even if XF is being initialized on a new dispatcher later on. So, how about considering the following fixes?

    1. Maintain a Dispatcher in BindableObject itself. It would be straight forward to abstract CoreDispatcher / Looper / NSRunLoop in a new class rather than maintaining on a single IPlatformServices instance in Device class. If that sounds to be too much work, as a tactical fix in PlatformServices.BeginInvokeOnMainThread() check if current thread has a dispatcher and then post to that, else post to the main dispatcher.

    2. In Forms.Init(), check if Xamarin Forms have been initialized in the current Dispatcher, if not do the dispatcher specific initialization. eg. In UWP, load native ResourceDictionary in the platform Application object.

    If you could post this as a bug to https://github.com/xamarin/Xamarin.Forms/issues (with a small repro demonstrating the crash you see when using multiple windows), we'll take a look and see what we can do*. TBH, multiple windows on UWP is a scenario we didn't think all that much about.

    *(We'll eventually look anyway, but if you post it to issues with a repro we'll look much, much sooner :smile: )

2»
Sign In or Register to comment.