[Discussion] .NET MAUI Single Project #70
Replies: 34 comments 2 replies
-
|
I think it is nice to group by functionality when we are talking about code files. But we still need a platform folder for info.plist, AndroidManifest.etc. The platform folder can also be a good place for platform-specific resources, a CoreML model for iOS for example. |
Beta Was this translation helpful? Give feedback.
-
|
I don't understand the motivation here. The current project structure makes sense to me. For example: we create a UWP project. It makes sense by itself and displays a blank window. We edit settings, icons, as normal for UWP projects. We create a netstandard project, put a Xamarin Forms page in, and reference it from the UWP project. It shows up there. Then we customize the UWP titlebar, put back and forward buttons there, all using UWP classes. How does all this work with a single project shared by many platforms? Do we install uwp/ios/android/mac nuget packages into the same project? Who maintains the uniproject? Currently there are simple separated platform projects. Putting things in one place wouldn't make things simpler except from the most superficial perspective. It's not as if there would be a reduction in files or settings: exactly the same ones would be needed surely (except for a few shared resources). |
Beta Was this translation helpful? Give feedback.
-
And then you have to do that all again for Android, all again for iOS, all again for WPF, all again for GTK, all again for macOS, all again for .... The idea with single project is that you can configure as much as possible once which will use the most rational defaults.
There's only one nuget and then in the IDE you can just indicate what platforms you want to support. The Application class becomes a native implementation so there is only one Application and then when you operate under the context of a specific platform you get those benefits. If as a user you want to add UWP you don't have to go look up in our docs about adding a uwp project, changing a base class, installing nugets, etc... You just check a box that says.. Hey also build UWP please. With single project you get all the things you mentioned in your comment but things are just arranged better, and more organized. The majority of modern 3rd party library has moved to multi targeting using SDK Extras because it's just easier. |
Beta Was this translation helpful? Give feedback.
-
|
For code, if not using shared projects, my preference is grouping by functionality with per platform icons in the solution window implemented by a naming convention — ClassName.TFM.cs — that's included via a globbing pattern. No special or extra csproj metadata.
|
Beta Was this translation helpful? Give feedback.
-
|
I love the idea of Grouping by Functionality, however it's not as practical in the scenario where one platform will require a number of supporting classes to achieve the functionality required. I think a hybrid approach would be fantastic, whereby a Also, I second @ghuntley's sentiment about shared projects 😄 they are definitely useful. |
Beta Was this translation helpful? Give feedback.
-
|
I personally think that a mix of both grouping concepts may actually be the best solution here. What:
Why:
|
Beta Was this translation helpful? Give feedback.
-
|
Amazing to see how open this project is! I'll be sure to help out and give feedback where I can, as I've definitely been waiting for something like this for a long time! Long time Xamarin.Forms user here :) Here are some of my thoughts on all of these things. Grouping Concepts Launch Screens Altho, there should still be a possibility to choose a "Custom" option if you want to createa launch screen for each platform individually. Localization Platform Configuration In terms of common or shared properties (Like App name, Package Name, Version, etc.), that might make sense to keep in the main info of the project itself (when you right-click the project to see it's properties). Just thinking out loud here, maybe there's another way to do that. Resource Management Idea of how that could look: MAUI.Resources.Images.MyCoolCatImage
MAUI.iOS.Resources.Images.MyCoolCatImage
MAUI.Android.Resources.Images.MyCoolCatImageI'm really excited for MAUI, and I hope these thoughts help a little bit :) |
Beta Was this translation helpful? Give feedback.
-
How does this compare to embedded resources? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @PureWeen,
All of those platforms have different icon requirements, so you are going to have to do 'all again' for each platform you want to support anyway, right? Just in a single definition project rather than platform specific? I don't see any advantage in that. We currently target 4 platforms (ok not quite MacOS but we prototyped a solution for that). We have a separate startup project for each platform, and set up the launch icons and splash screens in each because they are platform specific. How does this suggestion improve that? Seperately, I DO see a massive advantage of having fonts etc in a shared project. But for shared images there are still the platform differences, x1 x2 x3 for iOS, dpi's for Droid etc. How will you address those? |
Beta Was this translation helpful? Give feedback.
-
|
@PureWeen Thanks for clarifying the purpose of single projects. I think we should measure how much sharing there is to assess the benefits of single-project for app developers. Fonts: I think this is covered already in the current Xamarin.Forms. Images: Yes currently annoying since overuse of bitmaps creates more images than needed per platform, and there is extra work to adjust fullscreen/orientation etc.. If would be conveninent if we could specify a few svgs in a single project and generate all the bitmaps and create the appropriate Android Settings: I don't see a lot of commonality between settings across uwp/android/ios/mac currently so don't see a large benefit from single-project here. (Edit: post below has verison numbers. That seems useful to make common.) |
Beta Was this translation helpful? Give feedback.
-
|
I think that "settings solution" will be creating another way to group common properties (like permissions, version and etc) and give some editable "file" to specific properties. Maybe eg: {
"global": {
"version":1,
"version-name":"1.0.0",
"permissions":[
"use-gps"
]
},
"android": {
"install-location": "auto",
"some-platform-specific": "somevalue"
},
"ios": {
"some-platform-specific": "somevalue"
}
}Another way is using the hosting/dependency injection such as aspnet core (yeah, too) eg Host.CreateDefaultBuilder()
.Android(settings =>
{
settings.Version = 1,
settings.VersionName = "1.0.0",
settings.SomePlatformSpecific = "somevalue"
})
.Ios(settings =>
{
settings.Version = 1,
settings.VersionName = "1.0.0",
settings.SomePlatformSpecific = "somevalue"
})
.... |
Beta Was this translation helpful? Give feedback.
-
|
I’ve seen a few people talking about the generally point and why the need of having a single project instead of the normal 4. These are my personally opinions. For once, there is tremendous value in ease and simplicity having to just worry about ONE project over 4. I understand the concerns about different image formats, sizes, etc. but we’re in 2020 so I honestly don’t think that’s a technical challenge we can’t overcome. Now a days, anything is possible. Imagine if Unity had a separate project for each platform. Wouldn’t you be mad AF? Yes, yes you would 😁 |
Beta Was this translation helpful? Give feedback.
-
|
What @felipebaltazar said!! Let's see android I have to annotate with these attributes or update this manifest, UWP has these checkboxes, iOS has these plist things that I have to add these various settings to. How much of this can we normalize? Let's look at deeplinking What if we could just provide one setting for deeplinking and then that auto sets the plist/intent/uwp things needed for that. How much can we normalize the settings so users can focus on a common API to achieve what they need to? |
Beta Was this translation helpful? Give feedback.
-
|
I am voting for Grouping by Platform: if we choose Grouping by Functionality, we will see something like this: from this structure I understand that this button will work only for WPF, because I see WPF file. but I originally this may work with all other platforms. |
Beta Was this translation helpful? Give feedback.
-
|
Seems this is going to be a tooling feature in Visual Studio...why not both with a toggle in the solution explorer? I could see times both would be useful. |
Beta Was this translation helpful? Give feedback.
-
|
I prefer Grouping by Functionality, we can do it already in sdk-style projects with multitargeting. It's much more useful if you have project structured by features and not by layers. Let's say you have directory:
In grouping by platform you have
To be honest it's not very different from having that in separate projects, you still have to jump between folders. |
Beta Was this translation helpful? Give feedback.
-
|
So here's a question. What if I want to keep my Bluetooth code in a separate project from my XAML? I assume I could make another .NET 6 project that has |
Beta Was this translation helpful? Give feedback.
-
|
@jcmanke They already confirmed that MAUI will be backwards compatible with Xamarin.Forms, meaning if you want to, you can still have the 3 different projects like you have now. However they want to make MAUI more simple and streamline for people, so that people can get started more quickly without having to do a lot of complicated setup stuff and have to worry about multiple projects. |
Beta Was this translation helpful? Give feedback.
-
Please no! There are already a bunch of issues that greatly enhance the app development experience but are backwards incompatible changes. |
Beta Was this translation helpful? Give feedback.
-
|
The plan is for backwards compatibility as @kevinjpetersen mentioned. To that point, if that might lead you to forego using a single project and stick with doing things the same way you do now (potentially even for new projects), please do discuss your reasoning because it's just as valuable for us to know. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for giving us a voice. @pauldipietro As you asked, I would like to explain why I would do things the same way as I do now. I like the way my platforms are logically separated under one roof. I have to address a lot of platform specific functionalities. As an example, I need to start a service for Android that I do not need for iOS. I appreciate that I can do this completely independent of the other implementations. When I'm done, I minimize the project and go back to the shared project without having to deal with the platform specific implementations. I find this especially important for larger projects, where my shared project already contains enough files. I understand that the market share should be increased and the entry for new developers should be simplified. Not on the project level but in an abstract way compared to Xamarin.Forms this simplification was called Xamarin.Forms-Shell. Maybe there should be a similar abstraction for MAUI, MAUI-Shell to adress new developers. For me, I don't see any advantages in restructuring my current or future projects. |
Beta Was this translation helpful? Give feedback.
-
App ManifestsI think @felipebaltazar is largely on the right track here... though I think a name like {
"global": {
"id": "com.contoso.awesomeapp",
"displayName": "Awesome App",
"version": 1,
"version-name":"1.0.0",
"permissions":[
"location"
]
},
"android": {
"install-location": "auto",
"some-platform-specific": "somevalue"
},
"ios": {
"some-platform-specific": "somevalue"
}
}There are a number of things that could be abstracted rather easily like the app name, and version. Assuming we just kept a name like Manifest.json, we could support localization for certain values like the display name in an Manifest.es.json, etc. Where I think things get a little more involved is with permissions. While Android for example we might simply add the permission for the Coarse, Fine or Mock GPS location, on iOS we may potentially need to provide 4 different descriptions for why we need the permission. There are 3 ways I think this could and should be supported...
{
"permissions":[
{
"permission": "location",
"description": "Big brother is watching..."
}
]
}NOTE: the description would be used for each location description on iOS
ImagesWhile I'm very much for simplified Image handling, it is worth remembering that there are times that images may be localized, or platform specific (as I recall the TabbedPage project template for Xamarin.Forms currently has images for the Tabs that are only used on iOS). This sort of begs the question if we're grouping by feature which I like for things like Fonts/Images (which I wholeheartedly love), do we now introduce a Platforms directory under images if we need something only for iOS/Android. Native BindingsI fully admit for probably 95+% of people this isn't going to ever be an issue... but this would be a potential headache for some developers... There is the occasional case where you need to bind native drivers or other native libraries. Platform Specific Project / NuGet ReferencesOn a similar, however much more common and easier to deal with issue are platform specific references say basically anything Android. While MSBuild is able to easily tackle this, and those of us who are already experienced with Multi-Targeting with MSBuild.Sdk.Extras, this isn't even something that we'd blink for... but this is an area in Visual Studio/Visual Studio for Mac that is going to need some love. |
Beta Was this translation helpful? Give feedback.
-
|
I have one question in their demo video they showed us demo app on Iphone in which they didn't paired their windows visual studio to mac and ran the app on Iphone from windows visual studio. the thing i want to confirm how did they build the solution for Iphone without mac is it new functionality which i don't think is possible or did i miss the connection part with mac. |
Beta Was this translation helpful? Give feedback.
-
|
@haideralicspak they were using Hot Restart (not to be confused with XAML Hot Reload). You need to enable it in the Preview Features in Visual Studio and you can use it right now today!
|
Beta Was this translation helpful? Give feedback.
-
|
I would actually like to be able to see MSBuild/CSProj properties that can be applied to the Info.plist and AndroidManifest.xml as build tasks. It would definitely make the experience smoother, especially for cases such as automatically incrementing versions. Having to run an external command or script to pull this off isn't the best. |
Beta Was this translation helpful? Give feedback.
-
|
Glad I found this issue! (I had added a comment over here in a discussion.) Also related to this issue in the Reunion repo. Definitely would prefer the Grouping by Functionality as @mgierlasinski called out as well here. I definitely just see things being more useful to be displayed underneath the file as part of my normal project structure: Clicking on the root file itself would just take you to whatever current platform you have selected for debugging, but you could still drill-in to pull up the alternates (and they'd show up in search of course still). |
Beta Was this translation helpful? Give feedback.
-
|
I would prefer the Grouping by Functionality on all common classes and Please also add Blazor , Winui3.0 Desktop and UWP to the list of supported projects. |
Beta Was this translation helpful? Give feedback.
-
|
I agree:
|
Beta Was this translation helpful? Give feedback.
-
|
MAUI, maybe merge with the blazor project |
Beta Was this translation helpful? Give feedback.
-
|
With the single project approach, how do we handle these situations
Both situations are supported using the platform-specific project approach in Xamarin.Forms. |
Beta Was this translation helpful? Give feedback.
-
|
use conditions. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot @VladislavAntonyuk. However, I sense (at the moment at least) that handling dependencies in the platform-specific approach is easier and more clean in situations like this. |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
-
.NET MAUI Single Project
This is an evolving discussion and will be updated as new questions/subjects arise.
During our Build session about .NET MAUI we discussed plans to provide a single project structure for developing apps. Presently, Xamarin.Forms apps utilize a project for shared code and a platform-specific project head for each specific target platform supported, e.g.:
A couple high level goals of the single project are to make developing apps with .NET MAUI more immediately digestible for those new developers and simplify the current structure for those migrating existing Xamarin.Forms apps, along with reducing the burdens that come with maintaining multiple project heads. We hope this helps provide an amazing experience for developers in the future.
During the session we presented a structure of how a single project might look; we can call this Grouping by Platform. We also have a second concept that we'd like to present to the community to receive feedback on, which we'll call Grouping by Functionality.
Grouping Concepts
Grouping by Platform
As discussed during the Build session, grouping by platform uses a structure where all targeted platforms are represented inside of a
Platformsdirectory, and within each of those nested platform-specific subdirectry will be all of the necessary functionality. Here is a visualized mockup from the session:In this scenario, the
BluetoothAdapter.android.cs,BluetoothAdapter.ios.cs, andBluetoothAdapter.windows.cslive inside of the Android, iOS, and Windows subdirectories, respectively.Grouping by Functionality
Grouping by functionality is another concept we have discussed and would like to present here for discussion. In this structure, a
Platformsdirectory is not used, but rather the specific functionality is contained within the various elements of an app. To better illustrate this is another mockup:In this scenario, our app happens to require a custom control which inherits from a
Button. Inside of theControlsfolder we use is aCustomButton.csfile; this functions similarly to if you currently defined such a control and its properties in the shared project of your Xamarin.Forms app. In this structure, however, the platform-specific code is nested beneathCustomButton.csusing theCustomButton.platform.csnaming.It should be noted that in this scenario, the
Resourcesfunctionality remains the same.What are your thoughts on each of the above?
Questions & Topics for Discussion
Launch Screens
Both Android and iOS require developers to add a launch screen and Windows requires a splash screen to be added to applications; how could we provide a way to provide a single definition of such a screen in a single project that provides an easy way for developers to create such screens?
Localization
How can we improve the developer experience with regards to localizing apps? Both text as well as localized images must be considered.
Platform Configuration
Where would the platform-specific configurations such as
AndroidManifest.xml,Info.plist, orPackage.appxmanifestreside? Also, how and where might common properties across all three platforms be set?Resource Management
If for some reason a user needs a specific image resource for a given platform, where and how would that resource be identified and utilized?
We need your feedback!
Your feedback is extremely important here. What are your expectations for this single project structure? Do you have any concerns in a scenario where you would migrate an existing Xamarin.Forms app? If we missed something, let us know!
Beta Was this translation helpful? Give feedback.
All reactions