Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement] Regions in PRISM for Xamarin.Forms #1072

Open
juanperezADD opened this issue Jun 1, 2017 · 14 comments

Comments

@juanperezADD
Copy link

commented Jun 1, 2017

We are a company that has been using PRISM in multiple WPF projects for many years.

Now, we want to develop a new multiplatform application for mobile, tablet, desktop, etc. Following the TODO app (https://github.com/brianlagunas/TodoApp), we have started by creating a solution for each device. For example, the desktop solution is created with WPF and the mobile solution with Xamarin.Forms. We can reuse most of the code by sharing the view models which are .Net Standard libraries that use PRISM.Core.

However, Microsoft recently announced that Xamarin.Forms will support WPF in addition to Linux and MacOS.

Before this, we understood that Xamarin.Forms was only for mobile applications. However, after this announcement, Xamarin.Forms will also start to be used as a framework for desktop applications.

That is the reason why we are thinking to work with Xamarin.Forms as a main development framework for all our applications, both for mobile and desktop devices. We could have different solutions for each device, but all of them would work with Xamarin.Forms with all the advantages that it represents (only one xaml to learn, only one framework, etc.).

The problem is that PRISM for Xamarin.Forms does not have the concept of region. For us, in tablet or desktop solutions, this feature is essential to be able to create modular applications.

In this post (http://brianlagunas.com/first-look-at-the-prism-for-xamarin-forms-preview/#comment-17787), Brian explained that regions didn't make sense in Xamarin.Forms for mobile devices. But now, after this announcement, it makes sense for larger devices like a tablet or desktop. For example, there is a framework called Exrin (https://xamarinhelp.com/container-region-stack-navigation-exrin/) that already supports regions in Xamarin.Forms.

Is there any plan to include the concept of regions in PRISM for Xamarin.Forms? We think that both the community and us will be very interested.

@brianlagunas brianlagunas added the XF label Jun 1, 2017

@brianlagunas

This comment has been minimized.

Copy link
Member

commented Jun 2, 2017

I'm not 100% sold yet, but I'll let the community weigh in.

@dansiegel

This comment has been minimized.

Copy link
Member

commented Jun 5, 2017

@juanperezADD I suppose this could maybe make sense for the yet to arrive CarouselView, but I'm not sure how this would make sense to implement for Xamarin Forms at current.

Pointing to the fact that Xamarin Forms is "supporting WPF" doesn't change how Xamarin Forms is implemented or how it works. Before a discussion could really begin on should we support regions, I think it's important to define how (using the Xamarin Forms API) it would even work and be implemented.

@juanperezADD

This comment has been minimized.

Copy link
Author

commented Jun 6, 2017

Both, @brianlagunas and @dansiegel, talk about that if the regions were added, it would be a completely different API that what exists in WPF now. But, What limitations does XF because of it's nature? Are they possible to solve?

@juanperezADD

This comment has been minimized.

Copy link
Author

commented Jun 6, 2017

@dansiegel We think regions are definitely needed for larger devices like a tablet or desktop, maybe even for phones when using MasterDetailPage or TabbedPage for navigation. Regions allow us to compose a view with smaller views and it has it's own region navigation service.

@brianlagunas

This comment has been minimized.

Copy link
Member

commented Jun 6, 2017

To do regions properly is not a simple task and will require a ton of planning as well as feature scope. For example, do you expect regions to have their own navigation stack with GoForward and GoBack methods, manage object lifetimes, manage active states, support nested regions, custom region behaviors, customer region adapters, interact with the hardware/software back buttons just to name a few. Regions aren't as simple as show something in the area. A lot of thought needs to go into them and a ton of code will be added to Prism in order to support them. Also, the API will not match the WPF version for a number of reasons. We also have to consider native UWP in this feature.

@dansiegel

This comment has been minimized.

Copy link
Member

commented Jun 6, 2017

@juanperezADD changing the target platform from Phone to Desktop doesn't change the API or how Xamarin Forms works. As @brianlagunas mentioned it requires a lot of planning and more than simply saying you want Regions, you need to define how it will would work within the given API. Also if we were to share the interface between UWP & Xamarin Forms then it would need to be done in a way that makes sense for both API's.

@Suriman

This comment has been minimized.

Copy link

commented Jun 6, 2017

As I understand it, the problem is technical, or rather time and development effort to implement a suitable solution.

Regardless of this, what seems pretty obvious is that if XF is used in a future desktop option it will have to adapt to features that other frameworks like WPF, that were originally born on desktop, have.

Let's take another example, the development companies of controls should also include controls that are originally designed for desktop in their versions for XF, for example, the Ribbon.

As I see it, the future should have a single framework to develop for phone, tablet and desktop, and this framework should be XF. Both XF and PRISM as well as third party control companies will have to adapt to this new scenario if we really want to see the fulfillment of a single way of doing things.

@brianlagunas

This comment has been minimized.

Copy link
Member

commented Jun 6, 2017

The problem with writing a single API that works across multiple platforms is you MUST develop against the least common denominator. Not all controls that are WPF controls can exist in an XF app. They will have to be completely rewritten to fit the target platforms, which will be the least common set of functionality across all platforms.

You are over simplifying a broad concept. The devil is in the details. I will also boldly say that I would never write an app meant for WPF in XF. That would be ridiculous. If you have a simple mobile app that you want to port to WPF, sure why not.

Keep in mind that XF has tons of issues with Android, iOS, and UWP as it is. It's a real massive pain in the ass. Now add another platform on top of that and it's cluster fuck of problems. I really wish Xamarin would concentrate on stabilizing what they have now before trying to shove another platform into an unstable code base. Wow, I went way off topic there :)

@juanperezADD

This comment has been minimized.

Copy link
Author

commented Jan 19, 2018

@brianlagunas In December this issue was added as a "TO DO" in the Kanban board. Are there any plans to implement it this year? This is a feature that we are looking forward to get since XF supports WPF.

@brianlagunas

This comment has been minimized.

Copy link
Member

commented Jan 19, 2018

@juanperezADD This is not planned for implementation anytime soon. XF "sort of" supports WPF, so I would be careful placing all you eggs in that basket.

@dazinator

This comment has been minimized.

Copy link

commented Feb 13, 2018

Keep in mind that XF has tons of issues with Android, iOS, and UWP as it is. It's a real massive pain in the ass. Now add another platform on top of that and it's cluster fuck of problems. I really wish Xamarin would concentrate on stabilizing what they have now before trying to shove another platform into an unstable code base.

100% this :-)
Combine that with the general tooling instabilities that we are living through in the form of VS 2017, net.core, netstandard, msbuild sdk changes and it's amazing that any of us are managing to remain productive at all!

@dansiegel dansiegel added this to the Prism 7.3 milestone Jun 6, 2019

@dansiegel dansiegel changed the title Regions in PRISM for Xamarin.Forms [Enhancement] Regions in PRISM for Xamarin.Forms Jun 6, 2019

@urodolf

This comment has been minimized.

Copy link

commented Jul 19, 2019

I have seen that this issue has been included to resolve in version 7.3.
Do you know when this release is planned?
We are very interested in this funcionality.

@dansiegel

This comment has been minimized.

Copy link
Member

commented Jul 19, 2019

@urodolf well 7.2 was theoretically considered stable last week... now that I'm getting back I can actually address that it didn't deploy to NuGet... once that hits NuGet we'll be looking ahead to issues we want to address for 7.3

@mackayn

This comment has been minimized.

Copy link

commented Jul 22, 2019

Would have been awesome if it made it into 7.2 as it's something we're having to work round UX design wise but it will be great to see this added to Prism.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.