This Xamarin.Android TwoPage example (TwoPage) is not up-to-date with the latest UX in the Kotlin repo.

Should be possible to bring the resources (images, XML layouts) over to update the Xamarin.Android project. README/screenshots should be updated to match.

Xamarin.Android

Kotlin

hi , guys .
I cannot see any Surface Duo Emulator in Visual Studio 2019 .

My dev environment :
OS : Windows 10(19555.0)
Hardware : Surface Book 2

The screenshots as bellow

so , does any solutions for this issue ?

Hi,

I'm trying to run the Xamarin.Forms sample on my Android Surface Duo emulator running in the background. When I go to make the selection for the emulator, after I select it, it default back to the other AVD device I have saved instead. It doesn't like it when I select the emulator. I haven't tested it where if I delete the other AVD, if it just default onto itself but this is a bug.

EDIT: After exiting VS and playing around with the selector, I got it to correctly default to the right one and it works. Idk if this still considered a bug worth an investigation into or not however? Looks like maybe that happens on first time trying to default to the emulator?

The Kotlin Qualifiers example shows how to load resources specifically for Surface Duo using resource qualifier folders.

Add the equivalent project to the Xamarin.Android samples in this repo. Should be possible to bring images and XML from the source project.

Kotlin example

This Xamarin.Android List Detail example (ListDetail) is not up-to-date with the latest UX in the Kotlin repo.

It should be possible to bring the resources (images, XML layouts) over to update the Xamarin.Android version to match. README/screenshots should be updated to match.

Xamarin

Kotlin

beta02 released on 1-Sep-21.

Update samples using test binding to verify, and merge once Xamarin.AndroidX.Window beta02 binding is available on NuGet

With this issue, I want to propose changes to the README.me file of the Surface Duo Xamarin samples.

Motivation

In my opinion, the current readme does not show all the effort the team puts into the SDK and the samples for Xamarin apps.
With just some wording changes or re-structuring of the Readme-filemaybe more interested developers could be motivated to try out the samples.

In comparison to the Readme files of its sister repositories, the Xamarin one lacks different kinds of information.

Ideas for enhancements

Extend Getting Started

It seems to be standard that sample projects list what’s required to get started in a simple bullet point list without the need of reading documentation first.
The modern Microsoft does not longer require Windows or paied apps to get started. This could be too “beginner”-ish but I would not harm.

With the release of the beta versions of Visual Studio 2022 it would maybe more helpful to state that the samples best work currently in Visual Studio 2019 – if this is true.

Sample content and structure

Furthermore, the great quality of the sample app could be highlighted by providing a detailed list of explanations about the different included view samples. This could be done by simply linking the Readme-file of each project or in addition to this with further information in which use case which view project could be used as inspiration. This could be achieved by simple linking the related Microsoft Docs article (design) introduction to dual-screen devices.

Personal note:
It was a bit irritating what the actual difference between is between “Dual View” and “Dual Page”.
This kind of information are already available at the GitHub compose sample.

Xamarin.Forms & Xamarin.Android

At the beginning it was a little bit hard to understand that this is a Xamarin.Android and Xamarin.Forms sample repository. I know that the current Readme contains a section that describes this circumstance. Nevertheless, it could be more obvious that both “worlds” are included in this sample app. I would go that far that the very first headline could be changed to “Surface Duo – Xamarin.Forms & Xamarin.Android SDK samples”.

Add links to streams, blogs, and social media

The Surface Duo SDK team does a really good job in spreading out the word and trying to engage new developers to join the dual screen side of app development.

To support this effort the Readme could also include:

• Surface Duo Dev Twitch account with timetable
• Surface Duo Dev blog
• Surface Duo Getting Started Docs page
• Surface Duo Dev Twitter account

Additional ideas:

• Team member’s Twitter account with information why to follow (Cesar = Kotlin expert)
• Well-known dual screen app Xamarin developers Twitter or GitHub accounts
• YouTube links BUILD sessions or DroidCon talks

All I want to show with such section is, that the dual screen developer community is small but striving and growing.

Unify “Related links” across all Surface Duo sample repositories

Add more information that are already included in other sample repositories. One of the missing sections are “CI build status badges” or for example the “Related links” section.

Other small details

As everywhere else there is room for improvement outside the suggest ideas of enhancements. For example, to align the screenshots all the same. Another low hanging fruit would be (outside of the readme but visible to the repositories’ visitor) to enable or disable GitHub features. The Wiki button just redirects to the Readme and other sample repos use the “Release” feature of GitHub, the Xamarin’s one seems not to facilitate this feature.

Hi team,
Are community contributions to this repository is welcomed? Or will the source change dramatically in the near future?

Ideas
I have the following enhancements in mind:

• Unify code formatting
  • Removing unused imports
  • Removing duplicated line spaces
  • This would help to „read“ the lib classes
• Add documentation to the Surface Duo related library classes like TwoPaneView, both of the services, etc.
  • E.g what does the height or witch configuration enum values mean in detail (which value is related to which pane configuration?)
  • Add relationship diagram how the lib classes works together
  • DuoPage has FormsWindow which contains the LayoutService that relies on a working dependency injected member
• Add „how to get started“ section which classes you have to use for your own project
  • Platform specific dependency classes and unit of them (MainActivity.cs changes)
• Improve services to work in other apps
  • E.g. Make isDuo property public accessible

Contact
If anyone wants to chat wit me about this topic, tweet me @tobonaut on Twitter. :)

This Xamarin Companion Pane example (CompanionPane) is not up-to-date with the latest UX in the Kotlin repo.

It should be possible to bring the resources (images, XML layouts) over to update the Xamarin version to match. README/screenshots should be updated to match.

Xamarin

Kotlin

Window Manager is an API that provides information about dual-screen and foldable display features, that work not just for Surface Duo but also devices from other OEMs.

There is a pre-release binding available on NuGet - Xamarin.AndroidX.Window - which has been implemented in the Xamarin.Android samples in this repo.

We've our updated docs and blog.

Pre-requisites

This issue relies on Google releasing the stable version of Jetpack Window Manager.

Google reference

There is documentation, a blog post, and a codelab on how to use it in Kotlin.

Xamarin.Forms

This applies to the Xamarin.Android samples in this repo. The Xamarin.Forms samples will require Window Manager to be incorporated into the Xamarin.Forms.DualScreen NuGet package, which is a separate task.

This Xamarin.Forms Companion Pane example (XamarinForms/DualScreenDemos/CompanionPane) is not up-to-date with the latest UX in the Kotlin repo.

Some work will be required to bring the resources (images, XML layouts) over to the Xamarin.Forms version and convert to XAML. README/screenshots should be updated to match.

Xamarin.Forms

Kotlin

Window Manager is an API that provides information about dual-screen and foldable display features, that work not just for Surface Duo but also devices from other OEMs.

There is a pre-release binding available on NuGet - Xamarin.AndroidX.Window - that exposes the functionality in the alpha versions of Window Manager on Android. There is documentation, a blog post, and a codelab on how to use it in Kotlin.

This applies to the Xamarin.Android samples in this repo. The Xamarin.Forms samples will require Window Manager to be incorporated into the Xamarin.Forms.DualScreen NuGet package, which is a separate task.

Idea

The large screens of the Duo are able to present more information than any other "single" screen Android device.
That's why I need to know if the app is running on a Surface Duo or not. In my optionen, please correct me if this feature already exists, a simple member provided by the SDK that indicatates if it is running on a Duo would be great.

Example extension

public static class DualScreenInfoExtensions
{
    public static bool IsDuo(this DualScreenInfo dualScreenInfo)
    {
        return DualScreenInfo.Current.HingeBounds.Width != 0;
     }
}
 

Example usage

For example to show a multi column layout for "is a Duo" and a single column layout for "is not a Duo"

if(DualScreenInfo.Current.IsDuo())
{
    SecondColumnWidth = new GridLength(1, GridUnitType.Star);
}
else
{
    SecondColumnWidth = new GridLength(0, GridUnitType.Absolute);
}

TechCommunity
I also opened a post in the official Surface Duo SDK TechCommunity forum.

There are 50,000 flutter apps in both the iOS and Android store. What you saw was your own ignorance (not meant as an insult) of the technology. It works VERY well for iOS, Android and now macOS (with the majority of those apps getting ported to macOS almost immediately giving macOS the major win that Windows needs right now)

Web is about to go mainline and works very well too. As of June 25th you can write for iOS, Android, macOS and Web from one environment by simply learning Dart. (And yes, it supports essentially everything that Xamarin Forms does but with a pixel perfect renderer on all platforms)

The weaknesses of flutter are:

Some plugins haven't yet been ported to Web. They're coming quickly however.
Dart is not nearly the language that C# is.
Flutter doesn't have the Xamarin eco-system for Simulators, and compile to store etc. that Xamarin does.
Windows support is still lacking.
Linux support is still lacking.
There literally are no other downsides. I've built the same app in Xamarin and flutter and the flutter app looks way better, functions way better and is more stable. The development environment though limited is also way more stable.

#1 is just a time thing.
#2 The flutter rendering engine is C++ code and ANY language can be hooked to it. @SteveSandersonMS did a POC of Blazor running against flutter. That work needs to be taken seriously and made into a full project. There's 0 reason why C# can't be used with flutter and it would give flutter a vastly better development experience.
#3 All of Xamarin tools could come over easily with the remote simulators etc. This is just a decision by MS. If you recall they had these working for Cordova before they dumped cordova support in VS.net. So it's already there and could easily be extended and publish to the stores is already there and just needs the blazor tooling.
#4 This is on MS. Google has asked in a blog post for help from Microsoft. Microsoft has provided support for Duo in Flutter recently. If MS added Windows support and the ability to write plugins in C# UWP instead of having to use win32 and C++ Flutter's Windows ecosystem would flurish quickly because of the massively larger developer pool.
#5. Not sure this even matters.

I'm a Microsoft guy. I love C#. It's by far the best development language made. XAML is another story but I'm going to ignore it for now. I would much rather never have touched Dart. It's a lame language that google created to compete with C# and Typescript and prove that they could make it more simple and in the process made most things more difficult.

I would very much love to see Microsoft succeed. But their current approach of project reunion is a fool's errand. With the exception of games and some highly specialized tools that require realtime responsiveness/low level hardware, Windows development on its current track is an ever shrinking market and reunion doesn't change that or give MS any new opportunities to expand that. Windows has quickly become a web browser with Office. Office is literally the only reason why most companies haven't switched to chromebooks or linux on desktops. Maui is just more of the same Xamarin that has proven to be a complete flop. Xamarin forms in specific is a mess. It's so bad that in 2019 they went 3 months without a build of visual studio that could
compile to all 3 stores at the same time because of bugs. Exactly 3 people even watched the bug reports. Changing the name and providing a syntax more similar to Flutter without the rendering engine that flutter provides is a pointless waste of resources because it still won't be used.

By adopting the flutter rendering engine and bolting on C# like dart is right now and then providing all of the tools necessary so that a dev never needs to own a Mac Microsoft has the opportunity to win BIGLY. And they have the opportunity to have their competitor do work for them. That means Duo and Neo get an app ecosystem and become relevant, and it means that Windows app development has a chance again.

This Xamarin.Forms List Detail example (ListDetail) is not up-to-date with the latest UX in the Kotlin repo.

Some effort is required to bring the resources (images, XML layouts) over to update the Xamarin.Forms project and convert to XAML. README/screenshots should be updated to match.

Xamarin.Forms

Kotlin

This Xamarin.Forms TwoPage example (TwoPage) is not up-to-date with the latest UX in the Kotlin repo.

Some work is required to bring the resources (images, XML layouts) over to update the Xamarin.Forms project and convert to XAML/C#. README/screenshots should be updated to match.

Xamarin.Forms

Kotlin

When you span CompanionPane, DualView, MasterDetail, TwoPage they don't adapt to both screens 😟

For example, this view takes up both screens when it should adapt to being spanned: