Xamarin.forms: Uwp Xamarin.Forms.Shell

В настоящее время поддержка оболочки предоставляется только для Android и iOS. Мы постоянно оцениваем отзывы о возможной будущей поддержке UWP и предоставим дополнительную информацию в будущем, когда она станет доступной.

Обычно я использую iOS и Android для пользователей своих телефонов и UWP для пользователей планшетов и компьютеров. Поэтому поддержка UWP будет очень важна для вовлечения пользователей Windows.

Что?? MS действительно отказывается от собственной платформы. Это грустно слышать!

Разве нет информации о том, когда будет предоставлена ​​поддержка UWP? Или решение уже принято?

Поддержка оболочки для UWP - пожалуйста!

Я также хотел бы видеть поддержку UWP для оболочки.

Для моей компании UWP очень важен, потому что наши клиенты используют планшеты Windows в сочетании с некоторыми телефонами Android для выполнения своей работы. Мы не сможем перейти на Shell, если поддержка UWP отсутствует.

Согласовано - совместимость с UWP позволяет мне использовать возможности планшета Windows с моей мобильной реализацией. Без него мне пришлось бы кодировать это полностью отдельно. Фу! Совместимость с UWP обязательна!

Я не знаю, имеет ли это смысл, потому что я еще не использовал Shell. Но, возможно, есть способ использовать все другие элементы приложения (кроме Shell) для реализации UWP. В конце концов, похоже, что использование TabbedPage и MasterDetailPage приведет к тому же результату.

Я бы также проголосовал за возможность использовать UWP с Shell.

UWP, пожалуйста ... или, по крайней мере, какой-то вкус Microsoft UX API, на который мы можем положиться в течение нескольких лет. Такой подход «мы сообщим вам, можем ли мы поддержать это позже» просто подлый.

Итак, да, UWP или что-то еще будет его поддерживать, но, что более важно: ОБЯЗАТЕЛЬСТВО, КОГДА МЫ ЗНАЕМ, ЕСЛИ ИЛИ КОГДА.

Не могу перейти в Shell без этой уверенности.

Не только UWP, но и MacOS, пожалуйста.

Не знаю, осознали ли вы, что UWP - это не только платформа, которая до сих пор широко используется разработчиками, но и самый быстрый способ запустить и запустить приложения XF на базе Android и iOS. Потому что - для сравнения - эмуляторы, предоставляемые как для Android, так и для Mac, чертовски медленны, подвержены проблемам, и давайте не будем говорить об ужасных впечатлениях от сертификации или о том, что все еще вынуждены иметь настоящий Mac, не так ли? Таким образом, несмотря на то, что оно не может заменить реальную разработку, приложение UWP увеличивает продуктивность разработчика, предлагая быстрый, простой и комплексный способ выполнения ... задач ... выполнения. А затем: сделайте все возможное, чтобы ваше приложение заработало и на iOS, и на Android.

Не могли бы вы добавить поддержку оболочки для UWP?

https://github.com/xamarin/Xamarin.Forms/pull/6015

Согласитесь с @Mephisztoe, это действительно отличный инструмент для

Пожалуйста, не относите Xamarin.Forms только к мобильным платформам. Я бы хотел, чтобы продолжалась поддержка UWP, особенно, но также WPF и GTK #.

Таким образом, практически любой, у кого есть приложение, которое является кроссплатформенным для всех трех платформ в Xamarin Forms, прямо сейчас не может обновлять и использовать эти функции. Если в будущем разработка Xamarin Forms для UWP не состоится, почему бы просто не удалить UWP из списка кросс-платформенных?

У разных платформ всегда будут разные приоритеты. В конце концов, вы сказали «все три платформы», а не «все семь платформ».

@GalaxiaGuy , правильно, я сказал все три платформы, учитывая, что если бы я сказал семь платформ, я бы создал воображаемые платформы. Согласно документации Xamarin.Forms:

Xamarin.Forms
Xamarin.Forms предоставляет полный набор кроссплатформенных инструментов пользовательского интерфейса для разработчиков .NET. Создавайте полностью собственные приложения для Android, iOS и универсальной платформы Windows с помощью C # в Visual Studio.

А в ридми написано:

Xamarin.Forms позволяет быстро создавать собственные приложения для iOS, Android, Windows и macOS полностью на C #.

Это не значит, что он также не поддерживает GTK, WPF и Tizen.

Я согласен с тем, что эти платформы, вероятно, менее важны, чем UWP, но многие люди думают, что UWP менее важен, чем iOS и Android.

Я в целом согласен с этим мнением и мне самому приходится игнорировать новые функции, потому что они не включены в UWP.

К вашему сведению, если я не читаю примечания к выпуску неправильно, похоже, что в превью 4.1 есть реализация ShellRenderer для Tizen. Никакого упоминания о UWP.

Если для слияния запроса на вытягивание от @dotMorten требуется время, возможно, кто-то сможет перенести эту реализацию в отдельный «предварительный» пакет NuGet, управляемый сообществом, до тех пор, пока мы не получим официальную поддержку. Таким образом, мы можем использовать его, не используя полную предварительную версию или настраиваемую сборку Xamarin.Forms. Если мы не получим официальную поддержку, репозиторий уже будет настроен, и сообщество сможет его взять на себя.

Мне жаль, что это не пошло быстрее. Я столкнулся с некоторыми регрессами при синхронизации с мастером, и я был полностью завален работой и семейными вещами, так что у меня просто не было много времени, чтобы по-настоящему сесть и попытаться решить эту проблему. Однако я более чем счастлив принимать PR для своего филиала.

Мы также будем использовать оболочку, как только она будет доступна в UWP. У нас та же проблема, что и выше. У нас есть разные планшеты, телефоны и ноутбуки как с Android, так и с Windows. И мы также считаем, что лучшая среда разработки - это UWP.

Эта проблема - одна из основных причин, по которой я отказался от XF. Для наших клиентов настольные и мобильные устройства имеют одинаковый приоритет.

Что я могу сказать, что еще не было сказано ..

так что давай!
Поддержка UWP не является обязательной для Microsoft - действительно ли вам нужно об этом говорить?

@papiermache, обратите внимание, что кодекс поведения применяется ко всем сообщениям, проблемам и комментариям по этому проекту.

Также рассматриваем это как проверку приверженности MS Xamarin разработчикам. Кто-нибудь на стороне MS готов взвесить?

Извините всех, сдержу дальнейшие мысли ... но я был просто потрясен, обнаружив отсутствие поддержки UWP - мне даже не приходило в голову, что UWP не будет включенной платформой с самого начала. Рик.

От: Джереми [email protected]
Отправлено: 16 августа 2019 г., 14:28
Кому: xamarin / Xamarin.Forms [email protected]
Копия: Рик Пиовесан [email protected] ; Упомяните упоминание@noreply.github.com
Тема: Re: [xamarin / Xamarin.Forms] Uwp Xamarin.Forms.Shell (# 5593)

@papiermache https://github.com/papiermache обратите внимание, что кодекс поведения применяется ко всем сообщениям, проблемам и комментариям по этому проекту.

-
Вы получаете это, потому что вас упомянули.
Ответить на это сообщение непосредственно, просматривать его на GitHub https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=ABJC5GJKYHEGIOR3P2UIKX3QE4EVLA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PT3PQ#issuecomment-522141118 или приглушить нить https://github.com/ уведомления / отписаться-авторизация / ABJC5GKCHSPBRJ5JNNEVD5LQE4EVLANCNFSM4G7ANE7A .

Привет @dotMorten , можешь дать какое-нибудь обновление? Вы все еще планируете попробовать заставить UPW + Shell работать? Поймите, это проявление доброты и общности :) Просто интересно, ведь ваши усилия кажутся наиболее близкими к тому, чтобы заставить работать Shell + UWP. По-прежнему полностью озадаченный тем, что похоже на отказ Microsoft от поддержки Windows с помощью Xamarin. Благодарен за все остальные добрые дела, но все еще сбит с толку и разочарован.

Прости. Прямо сейчас вроде как выгорело, так что я еще не возвращался к этому. Я помню, как слияние с последним вызывало множество регрессов, и у меня просто не было ни времени, ни энергии, чтобы вернуть его в норму. Также было определено несколько вещей, которые необходимо изменить и которые потребуют более широкой поддержки со стороны команды XF, но не получили особой поддержки, кроме «конечно, давайте рассмотрим это», а затем исчезли. В целом поддержка и отзывы, которые я получил от команды XF, были только воодушевлением, но с некоторым отсутствием доводов до конца. Все еще жду отзывов о проделанной мной работе, но на данный момент она, вероятно, слишком устарела. Надеюсь, у меня скоро появится время и силы, чтобы вернуться к этому.

В настоящее время эта проблема входит в десятку наиболее часто комментируемых открытых вопросов, но не входит в план действий.

@pauldipietro, мы можем получить поводу ? Мне кажется, это сигнал о том, что поддержка UWP больше не является приоритетом для команды XF. Если это правда, сообщите нам, чтобы мы могли строить планы на этот счет.

Спасибо

Согласен, я просто хочу знать, не будет ли XF включать поддержку Windows. Если нет, то я тоже хочу знать, почему бы и нет? Знают ли они, каким будет «следующий» стек Windows UX, кроме UWP, и не хотят ли тратить циклы? Будет ли следующей частью Blazor / HTML? Если так, просто дайте мне (нам) знать, чтобы я мог перейти ... Может быть, на платформу uno?

От: Скотт Кул [email protected]
Отправлено: четверг, 22 августа 2019 г., 13:21:22
Кому: xamarin / Xamarin.Forms [email protected]
Копия: Дэвид Гердинг [email protected] ; Комментарий [email protected]
Тема: Re: [xamarin / Xamarin.Forms] Uwp Xamarin.Forms.Shell (# 5593)

В настоящее время эта проблема входит в десятку наиболее часто комментируемых открытых вопросов, но не входит в план действий.

@pauldipietro https://github.com/pauldipietro можем ли мы получить обновленную информацию по этому поводу? Мне кажется, это сигнал о том, что поддержка UWP больше не является приоритетом для команды XF. Если это правда, сообщите нам, чтобы мы могли строить планы на этот счет.

Спасибо

-
Вы получили это, потому что прокомментировали.
Ответить на это сообщение непосредственно, просматривать его на GitHub https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=AAD7YD4EYE5XBBSXIR6MGV3QF3KKFA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD456VUI#issuecomment-524020433 или приглушить нить https://github.com/ уведомления / отписаться-auth / AAD7YD42CJSV4KS5ZFWWJU3QF3KKFANCNFSM4G7ANE7A .

Откровенно говоря, мне кажется, что лучше всего было бы заменить XF платформой Uno ...

Xamarin ясно дал понять, что их цель - в основном мобильные устройства (телефоны, планшеты, часы), а не настольные компьютеры или ноутбуки.

Они не заинтересованы в поддержке и обслуживании UWP, поэтому я не могу рекомендовать их своим клиентам.

Я хочу уточнить, что мне нужно: мне не нужен _UWP_ для Xamarin Forms. Мне нужна _некая цель Windows_ для Xamarin Forms. UWP кажется наиболее подходящим кандидатом. Если бы мне пришлось предположить, что Microsoft в конечном итоге перейдет к клиенту HTML и Blazor для настольных компьютеров, поскольку это может дать им самый широкий охват UX в мире после Windows. Это также может лучше подходить для пути к составной оболочке (а не к оболочке xf). Ввиду отсутствия какой-либо последовательной дорожной карты для Windows-стороны UX я не могу представить, что еще они могут планировать.

Но для ясности, отказ от поддержки Xamarin в Windows без объявления большими жирными буквами «МЫ НЕ И НЕ ДЕЛАЕМ WINDOWS», как минимум, действительно, очень недоброжелателен. Это звенит «старый Майкрософт».

@davidortinau et al: Пожалуйста, сделайте что-нибудь большее, чем указание на теперь фактически мертвую (см. последний пост @dotMorten ) «поддержка сообщества XF Shell + Windows».

Я очень благодарен за все новое и интересное в Xamarin. Но мне нужен более честный ответ о будущей жизнеспособности, если таковая имеется, целевых объектов Windows с использованием Xamarin.

несколько вещей, которые необходимо изменить и которые потребуют более широкой поддержки со стороны команды XF

Я знаю, что один из них был связан с WinUI, который мы надеемся использовать в качестве зависимости от этого PR.
https://github.com/xamarin/Xamarin.Forms/pull/7214

Этот PR поддерживает совместимость 16299 и, судя по моим тестам, отлично работает, когда он включен в nuget, и не требует от пользователя установки WinUI. Мне все еще нужно развернуть 16299 в виртуальной машине, чтобы убедиться, но я сохраняю оптимизм. Я знаю, что @dotMorten вы выразили некоторые опасения по поводу использования WinUI, поэтому, если я полностью их проигнорировал, дайте мне знать :-)

Вот этот нюджет.

Xamarin.Forms.4.3.0.1853.zip

Если кто-то еще захочет протестировать это для нас и сообщить нам, если у вас возникнут какие-либо проблемы, это будет действительно полезно. Я протестировал его с базовым шаблоном UWP, и он отлично работает без сбоев.

Путь, который я вижу для этого в настоящее время,

• get # 7214 объединено, чтобы мы позаботились о зависимости WinUI
• получить переустановку PR Shell UWP (у нас это запланировано на будущий спринт, поэтому мы либо сделаем это тогда, либо если кто-то другой нас опередит)
• У Мортена он уже работает с Gastropods, поэтому мы просто хотим протестировать его с еще несколькими образцами (в основном Xaminals), как только он заработает и мы внесем любые необходимые изменения очистки кода, мы объединим

Если мне что-то не хватает в этом пути, дайте мне знать, и мы постараемся решить эту проблему, поэтому все, что нужно сделать, - это перебазирование и проверка на Xaminals.

@PureWeen ,
Я могу запустить App132.zip с предоставленным вами Xamarin Nuget. Кажется, что приложение работает нормально ... при условии, что оно должно добавлять элементы с отметкой времени в элемент управления списком. И кнопка вверху, и поведение «Потяните для обновления» добавляют элементы.

Не уверен, что ищу, но ценю ваши усилия и постараюсь помочь, чем смогу.

Дэйв Джи

@PureWeen Приятно видеть, что вы продвигаетесь вперед с WinUI. Зависимость от WinUI создавала для меня нарушение поведения, поскольку WinUI добавлял зависимость, которая не была добавлена ​​транзитивно. Это поправимо, если вы используете VS2019, но я не уверен, воспользовался ли WinUI этой функцией (и это по-прежнему повлияет на пользователей VS2017, но, по крайней мере, есть обходной путь).
Вдобавок в WinUI были ошибки, которые вызвали у меня много головной боли, но недавно я заметил, что некоторые из тех, что я зарегистрировал, были исправлены, так что это все обнадеживает. Пингуйте меня, как только войдет 7214, и я постараюсь начать эту работу.
Также хотелось бы помочь с перебазированием. В прошлый раз я напортачил с пиаром :-)

@dotMorten Звучит хорошо !!

Я тестировал приложение, которое я включил выше, на VS 2017, и оно сработало для меня, поэтому я думаю, что с этим все в порядке.

Не уверен, что ищу, но ценю ваши усилия и постараюсь помочь, чем смогу.

Главное - добавить nuget в ваш основной проект UWP и просто убедиться, что все они компилируются и работают нормально.

Просто пытаюсь проверить, что добавление зависимости WINUI не вызовет головной боли :-)

Я тестировал приложение, которое я включил выше, на VS 2017

Без добавления WinUI в шапку проекта? Это проблема, которую я обнаружил: если люди будут обновляться до версии XF, которая зависит от WinUI, это не сработает без ручного добавления зависимости к WinUI. ИМХО, это критическое изменение. WinUI может изменить свой пакет, чтобы он работал неявно, но для этого потребуется VS2019, поскольку он полагается на функцию NuGet 5.0 (и, кстати, они не внесли этого изменения, поэтому он не будет работать ни в одном из них прямо сейчас).

Вот проблема, с которой я вошел в WinUI: https://github.com/microsoft/microsoft-ui-xaml/issues/596#issuecomment -524187369

Я мог бы просто сделать быстрый пиар, чтобы хотя бы решить эту проблему, чтобы пользователям VS2019 не пришлось вручную добавлять дополнительную зависимость.

Просто добавлю, что когда я тестировал app123, это было с VS2019.

Без добавления WinUI в шапку проекта?

Да, проект, который я связал выше, я могу открыть внутри VS2017, и он компилируется и работает нормально. У меня нет Nuget WinUI, добавленного в заголовок UWP, он указан только как зависимость внутри nuspec

Я действительно не понимаю, как это работает. Есть стиль, который нужно добавить, и дополнительный пакет фреймворка appx, который необходимо установить вместе с пакетом, и все это делается с помощью .targets. Пакет фреймворка уже установлен на вашем компьютере?

Журнал Visual Studio Magazine как раз рассмотрел эту проблему, в частности. Microsoft, время официального ответа.

https://visualstudiomagazine.com/articles/2019/08/23/xamarin-forms-4-2.aspx

@dotMorten Меня нет на пару дней, но я разберусь с этим, когда вернусь. Я также обратился к команде WinUI, чтобы проверить

Эта цель работает нормально транзитивно, когда я тестировал VS 2017
https://github.com/microsoft/microsoft-ui-xaml/blob/8f8cd0fe32754cfcd83dafb2fc8539703b6aec26/build/NuSpecs/MUXControls-Nuget-Common.targets#L6

Вот обновленный nuget, который позволяет вам переопределить настройку в вашем проекте локальных форм.
Xamarin.Forms.4.3.0.1853.zip

<SkipMicrosoftUIXamlCheckTargetPlatformVersion>false</SkipMicrosoftUIXamlCheckTargetPlatformVersion>

В проекте форм мы сделали это так, чтобы это не удивило людей.

https://github.com/xamarin/Xamarin.Forms/pull/7214/files#diff -5e6292d5925c776aa9aa6d6f8c63ddf6R19

@PureWeen Это бит, который должен работать без явного добавления этих строк (поскольку всем пользователям также придется обновлять

Я думаю, вы говорите, что это работает, но просто убедитесь, что мы на одной волне.

Возможно, вы считаете это приемлемым критическим изменением, но я помню, что это произошло недавно с другой зависимостью и отбросило многих людей, поскольку путь обновления не такой чистый, как простой выбор новой версии XF.

Re: необходимость в целевом компьютере / ноутбуке / планшете для Xamarin Forms

Для тех из нас, кто создает мобильные приложения в корпоративной среде, очень важна возможность создания исполняемого файла для настольных компьютеров и ноутбуков, «похожего на работу», на основе той же базовой кодовой базы, что и для Android / iOS. Это не обязательно должна быть только Windows (целевой объект на основе браузера, такой как HTML / JS, будет столь же хорош), но у подавляющего большинства наших пользователей есть настольный компьютер / ноутбук с Windows + телефон iPhone / Android, поэтому исполняемый файл Windows является нормально по большей части.

Мы обнаружили, что когда мы делаем мобильное приложение доступным внутри организации, большинство наших пользователей хотят сначала опробовать его на своих ноутбуках / настольных компьютерах - и только если они сочтут его полезным или соответствующим их потребностям, они соизволят поставить это на их телефонах. Кроме того, получение поддержки (и обратной связи) пользователей работает значительно лучше, если они могут вводить данные или запрашивать результаты либо с настольного компьютера, либо с устройства, в зависимости от того, где они работают в данный конкретный момент.

Xamarin Forms хорошо работает для этих сценариев, и мы действительно хотели бы использовать Shell и CollectionView, но они являются для нас готовым продуктом, пока их нельзя будет использовать для создания рабочих столов или ноутбуков ...

@dotMorten, поэтому причина, по которой я не вижу исключения, заключается в том, что у меня WinUI является зависимостью от nuget, поэтому, если вы устанавливаете XF на головку UWP, WinUI приходит на помощь и применяет свои цели.

Это делает так, что сам пакет XF должен быть установлен в головном проекте UWP для работы. Я протестировал свой пример выше, когда XF был установлен только в проекте netstandard, и смог воссоздать ваше исключение.

Мы немного об этом поговорили в этом выпуске
https://github.com/xamarin/Xamarin.Forms/issues/4126

Это нарушает правила, если у людей установлен только XF в общую библиотеку, а не в головной проект UWP. Поэтому нам нужно немного обсудить это, чтобы увидеть, что мы хотим с этим делать.

@pureween хорошо, хорошо. Рад, что тогда мы видим то же самое. Несколько вещей, которые следует учитывать при обсуждениях:

• Если мой PR в WinUI будет объединен, это повлияет только на пользователей VS2017 (что, однако, может стать странным, если команда использует оба, и это влияет только на некоторых пользователей).
• Вы можете обнаружить это во время Init () и выдать ошибку, которая сообщает пользователям, что именно делать, чтобы боль не была такой ужасной.
• Я играл с идеей, что у XF есть целевой файл, который добавляет зависимость к ссылающемуся проекту, если она еще не присутствует, но может
  создать странный опыт разработки.
• Все проекты UWP всегда будут использовать эту зависимость после отделения WinUI от платформы (но к тому времени VS2017, вероятно, все равно не будет поддерживаться).
  
  
  
  • Вы сможете поддерживать более ранние версии Win10 с этим изменением, создавая добавленную стоимость, которая могла бы его оправдать.
  
  
  • Никто не заметит, потому что, по мнению вашей команды, никто на самом деле не использует UWP 😜 j / k
  
  

Еще один возможный подход: определить, есть ли ссылка на WinUI во время инициализации, но позволить приложению работать. Любой модуль рендеринга, который полагается на WinUI, вместо этого выбрасывает, поэтому он будет влиять только на пользователей этих новых функций. Таким образом, история становится такой: «Если вы хотите использовать Shell или PullToRefresh, вы также должны добавить ссылку на WinUI (если вы используете VS2017)».

@dotMorten Благодарим вас за все ваши усилия по внедрению Shell в UWP! Это очень необходимо, и основная группа разработчиков Xamarin должна решить эту проблему.

Вот пример работы Xaminals на UWP с CV и Shell !!!

Отличная работа!

Отличная работа. Мы включим его в нашу структуру для создания приложений корпоративного уровня, как только он выйдет.

Отличная работа, попробую в следующем выпуске своего приложения ;)

Да, Xamarin сделал это! Я читал, что один парень сказал, что мы переезжаем в Уно. Нет!!!! Xamarin отлично нам подошел и сэкономил нам много времени на изучение Swift + java. Будем терпеливы с командой и поддерживать их

закрыто # 6015

Отличная работа, спасибо за всю команду <3, переверну 💃

Отличная работа, большое спасибо!

Хорошо, что-то странное происходит, я обновил свой проект, чтобы использовать 4.3.0.947036, теперь проект не работает при вызове forms.init с помощью
«Не удалось найти тип среды выполнения Windows» Microsoft.UI.Xaml.Controls.XamlControlsResources

Что очень странно, так это объем кода, который теперь находится в XamlTypeInfo.g.cs, в предыдущей версии Xamarin у нас было только 13 записей, теперь у нас их более 43. Я установил Win.UI Nuget в проект, и все еще нет помощи. Любые идеи

@ abrantie1z - (хотя и не по теме, я подумал, что упомянул) Uno и Xamarin Forms больше не должны быть взаимоисключающим выбором - см. https://platform.uno/xamarin-forms/ и https: / /visualstudiomagazine.com/articles/2019/09/19/uno-platform-2.aspx Предостережение: я не использовал Uno, поэтому понятия не имею, насколько надежна эта поддержка. Но все, что привлекает больше людей к XF в браузерах, - это хорошо.