Xamarin forms что это
Что такое Xamarin?
Благодаря Xamarin в среднем 90 % кода приложения может использоваться без изменений на разных платформах. С помощью этого шаблона разработчик может написать всю бизнес-логику на одном языке (или использовать существующий код приложения), но при этом получить характеристики производительности, оформление и поведение, характерные для каждой соответствующей платформы.
Приложения Xamarin можно писать на ПК или Mac и компилировать в собственные пакеты приложений, например в файлы с расширением .apk для Android или .ipa для iOS.
Для компиляции и развертывания приложений для iOS на данный момент требуется компьютер с MacOS. Сведения о требованиях к разработке см. в разделе Требования к системе.
На кого ориентирована платформа Xamarin
Платформа Xamarin ориентирована на разработчиков, перед которыми стоят следующие задачи:
Как работает платформа Xamarin
На этой схеме показана общая архитектура кроссплатформенного приложения Xamarin. С помощью Xamarin вы можете создавать собственный пользовательский интерфейс для каждой платформы и писать на языке C# общую бизнес-логику, которая будет использоваться на различных платформах. В большинстве случаев Xamarin позволяет использовать на разных платформах 80 % кода приложения.
Дополнительные сведения об архитектуре для конкретных платформ см. в разделах Xamarin.Android и Xamarin.iOS.
Добавленные компоненты
Xamarin сочетает в себе возможности собственных платформ с добавлением возможностей, к которым относятся:
Xamarin.Android
Дополнительные сведения см. в разделе Архитектура Xamarin.Android.
Xamarin.iOS
Дополнительные сведения см. в разделе Архитектура Xamarin.iOS.
Xamarin.Essentials
Xamarin.Essentials — это библиотека, которая предоставляет кроссплатформенные API для собственных функций устройства. Как и сама платформа Xamarin, библиотека Xamarin.Essentials представляет собой абстракцию, которая упрощает процесс доступа к собственным функциям. Ниже приведены некоторые примеры функциональных возможностей, предоставляемых Xamarin.Essentials:
Для получения дополнительной информации см. Xamarin.Essentials.
Xamarin.Forms
Xamarin.Forms — это платформа пользовательского интерфейса с открытым кодом. С помощью Xamarin.Forms разработчики могут создавать приложения для Xamarin.iOS, Xamarin.Android и Windows на основе общей базы кода. Xamarin.Forms позволяет разработчикам создавать пользовательские интерфейсы в XAML с помощью кода программной части в C#. Эти пользовательские интерфейсы на каждой платформе подготавливаются к просмотру как собственные элементы управления. Ниже приведены некоторые примеры функций, предоставляемых Xamarin.Forms:
Для получения дополнительной информации см. Xamarin.Forms.
Начало работы
Ниже представлены руководства, которые помогут вам в создании первого приложения с использованием Xamarin:
Связанные видео
Другие видео о Xamarin см. на Channel 9 и YouTube.
Что такое Xamarin.Forms?
Xamarin.Forms — это платформа пользовательского интерфейса с открытым кодом. С помощью Xamarin.Forms разработчики могут создавать приложения для Xamarin.Android, Xamarin.iOS и Windows на основе общей базы кода.
Xamarin.Forms позволяет разработчикам создавать пользовательские интерфейсы в XAML с помощью кода программной части в C#. Эти интерфейсы на каждой платформе подготавливаются к просмотру как собственные элементы управления.
Для кого предназначена платформа Xamarin.Forms
Платформа Xamarin.Forms ориентирована на разработчиков, перед которыми стоят следующие задачи:
Как работает Xamarin.Forms
Схема архитектуры Xamarin. Forms «Data-ссылок =» относительный путь «/>
Xamarin.Forms предоставляет согласованный API для создания элементов пользовательского интерфейса на разных платформах. Этот API может быть реализован в XAML либо C# и поддерживает привязку данных для шаблонов, таких как «Модель — представление — модель представления» (MVVM).
Во время выполнения Xamarin.Forms использует отрисовщики платформы для преобразования кроссплатформенных элементов пользовательского интерфейса в собственные элементы управления в Xamarin.Android, Xamarin.iOS и UWP. Позволяет разработчикам добиться привычного внешнего вида, поведения и уровня производительности, а также реализовать преимущества совместного использования кода на разных платформах.
Дополнительные функциональные возможности
Xamarin.Forms имеет большую экосистему библиотек, которые добавляют разнообразные функциональные возможности для приложений. В этом разделе описываются некоторые из этих дополнительных функций.
Xamarin.Essentials
Xamarin.Essentials — это библиотека, которая предоставляет кроссплатформенные API для собственных функций устройства. Как и сама платформа Xamarin, библиотека Xamarin.Essentials представляет собой абстракцию, которая упрощает процесс доступа к собственным служебным программам. Ниже приведены некоторые примеры служебных программ, предоставляемых Xamarin.Essentials:
Для получения дополнительной информации см. Xamarin.Essentials.
Оболочка
Оболочка Xamarin.Forms упрощает разработку мобильных приложений, предоставляя основные возможности, которые необходимы для большинства приложений. Ниже приведены некоторые примеры функций, предоставляемых этой оболочкой:
Xamarin.Forms. Личный опыт использования
В статье речь пойдет о Xamarin.Forms на примере живого проекта. Кратко поговорим о том, что такое Xamarin.Forms, сравним с похожей технологией WPF, увидим, как достигается кроссплатформенность. Также разберём узкие места, с которыми мы столкнулись в процессе разработки, и добавим немного реактивного программирования с ReactiveUI.
Кроссплатформа — что выбрать?
В современном мире, в век огромного количества различных устройств и операционных систем, более конкурентноспособными являются приложения, способные работать сразу на нескольких платформах. Для реализации кроссплатформенности существуют разные подходы: написание нативного кода для каждой целевой платформы (по сути, нескольких различных приложений) или использование специальных фреймворков, позволяющих разрабатывать единый код для всех случаев. Есть еще кроссплатформенные языки программирования или же среды исполнения, например, Java Virtual Machine, но здесь я их касаться не буду.
Нативный подход обеспечивает более высокое качество и скорость работы готовых приложений, позволяет более эффективно использовать ресурсы платформы. Однако, сроки разработки значительно больше, чем при написании единого кода. Увеличивается также и стоимость поддержки таких продуктов. Использование сторонних фреймворков для написания единой кодовой базы, напротив, позволяет писать приложения быстрее, используя более распространённые языки программирования, но может добавить накладных расходов при работе уже готового программного обеспечения, ведь любой инструмент, обеспечивающий кроссплатформенность, является своего рода обёрткой, транслирующей вызовы к системе и от неё. Никто не отменял и банальных погрешностей в работе самой этой обёртки.
Какое решение использовать на конкретном проекте – выбор сугубо индивидуальный и зависит от многих параметров, таких как сроки, квалификация разработчиков, требования к приложению и т.д.
А теперь к сути
Не так давно нашей команде пришлось лицом к лицу столкнуться с кроссплатформенной разработкой. Задача от заказчика звучала так:
Xamarin.Forms и WPF
Еще одной известной xaml-подобной технологией является WPF (Windows Presentation Foundation). Это потрясающий инструмент для создания красивых интерактивных пользовательских интерфейсов. На мой взгляд, это один из лучших инструментов, созданных Microsoft, имеющий, правда, серьезный недостаток – такие приложения можно разрабатывать только под Windows.
Xamarin.Forms включает в себя урезанную версию WPF, агрегируя лишь те компоненты, которые имеют аналоги на других платформах. С одной стороны, это даёт разработчикам, имеющим опыт работы с WPF, неплохую фору для входа в Xamarin.Forms. С другой же, познав всю прелесть и возможности WPF, программисту будет трудно то тут, то там натыкаться на отсутствие всех этих преимуществ в Xamarin.Forms. Мне было крайне грустно осознать, что я не могу использовать шаблоны для элементов управления, которыми так привыкла жонглировать в WPF, в Xamarin.Forms их попросту нет. Или удобный и мощный ItemControl – компонент WPF, позволяющий разместить на форме список элементов, задавая каким угодно образом их внешний вид и расположение. С помощью одного только этого компонента как основного можно написать, например, простенький прототип игры в бильярд. В Xamarin.Forms существуют аналоги ItemControl, но все они имеют конкретную реализацию внешнего вида списка, что лишает их необходимой гибкости и вынуждает разработчиков идти на GitHub за «велосипедами».
Кроссплатформенность в Xamarin.Forms
Однако не бывает худа без добра. Своими ограничениями Xamarin.Forms платит за кроссплатформенность, которая действительно легко и удобно достигается средствами этого инструмента. Вы пишете общий код для iOS, Android и Windows, а Xamarin сам разбирается, как связать ваш код с родным для каждой платформы API. Кроме того, есть возможность писать не только общий, но и платформозависимый код, и Xamarin тоже поймет, что и где вызывать. Одним из главных механизмов достижения кроссплатформенности является наличие «умных» сервисов, способных осуществлять кросс-зависимые вызовы, то есть обращаться к той или иной реализации определённого функционала в зависимости от платформы. Платформозависимый код можно писать не только на C#, но и добавлять его в xaml-разметку. В нашем случае iOS версия была урезанной и часть графического интерфейса нужно было скрыть, размеры некоторых элементов также зависели от платформы.
Для большей наглядности приведу небольшой пример. В нашем проекте мы использовали библиотеку классов, предоставленную заказчиком, которая была написана на C++. Назовём её MedicalLib. MedicalLib собиралась в две разные сборки в зависимости от платформы (статическая MedicalLib.a для iOS и динамическая MedicalLib.dll для Windows). Кроме того, она имела различные wrapper-классы (классы-переходники) для вызова неуправляемого кода. Основной проект (общая кодовая база) содержал описание API MedicalLib (интерфейс), а платформозависимые проекты для iOS и Windows – конкретные реализации этого интерфейса и ссылки на сборки MedicalLib.a и MedicalLib.dll соответственно. Из основного кода мы вызывали те или иные функции абстракции, не задумываясь, как именно они реализованы, а механизмы Xamarin.Forms, понимая, на какой платформе запущено приложение, вызывали необходимую реализацию и подгружали конкретную сборку.
Примерно так это можно изобразить схематично:
Среда разработки
Для написания программ с Xamarin.Forms используется Visual Studio. На MacOS – Visual Studio for Mac. Многие разработчики считают это больше недостатком, ссылаясь на тяжеловесность этой IDE. Для меня Visual Studio является привычной средой разработки и на высокопроизводительных компьютерах не доставляет каких-либо неудобств. Хотя Mac-версия этой IDE пока еще далека от идеала и имеет на порядок больше недочетов, чем её Windows-собрат. Для мобильной разработки имеется целый ряд встроенных эмуляторов мобильных устройств, а также возможность подключить реальный девайс для отладки.
Reactive UI и реактивная модель
В основу любого проекта Xamarin.Forms отлично ложится паттерн проектирования MVVM (Model – View – View Model), главным принципом которого является отделение внешнего вида пользовательского интерфейса от бизнес-логики. В нашем случае мы использовали MVVM, что действительно оказалось удобно. Важным моментом реализации MVVM является механизм оповещений View о том, что какие-то данные изменились и это необходимо отобразить на интерфейсе. Думаю, многие разработчики на WPF слышали об интерфейсе INotifyPropertyChanged, реализуя который во вью-моделях, мы получаем возможность оповещать интерфейс об изменениях. Этот способ имеет свои плюсы и минусы, но главным недостатком является запутанность и громоздкость кода в случаях, когда во вью-моделях есть вычисляемые свойства (например, Name, Surname и вычисляемое FullName). Мы выбрали более удобный фреймворк ReactiveUI. Он уже содержит реализацию INotifyPropertyChanged, а также много других преимуществ – например, IObservable.
IObservable – это реактивные push-based провайдеры уведомлений о наличии обновлений для подписчиков. Очень похоже на события и подписки на них, но с рядом дополнительных встроенных фич. Например, мы можем реагировать не на все обновления, а с какими-нибудь фильтрами (допустим, наш IObservable – «поток» целых чисел, и мы хотим принимать во внимание только четные). Или одним подписчиком можно подписаться на комбинацию из двух IObservable, первый из которых типа bool, и реагировать или не реагировать на обновления второго в зависимости от того, что пришло в первый. IObservable можно представить как поток данных, хотя по сути это коллекция.
Если коротко и не вдаваясь в подробности описывать предметную область нашего приложения, то это симулятор реального медицинского оборудования. На экране бегут графики якобы снимаемых с пациента данных, а пользователь, то есть врач, может менять настройки девайса и смотреть, как это влияет на медицинские характеристики пациента. Интерфейс в нашем случае – это отображение в реальном времени данных, которые с большой частотой (раз в 40 миллисекунд) приходят из недр приложения.
Реализовано это было следующим образом: на бэкэнде постоянно крутился некий генератор данных, которые поступали в несколько IObservable. На каждый IObservable во вью-моделях были подписаны соответствующие свойства, которые с помощью механизмов ReactiveUI выводили данные на интерфейс в нужном виде.
Взаимодействие с интерфейсом в обратном направлении (т.е. обработка действий пользователя), было реализовано с помощью так называемых Interaction – взаимодействий, которые инициировались при работе пользователя с UI (например, при нажатии на кнопку), а обрабатывались в любом месте приложения. Что-то наподобие интерфейса ICommand и команд в WPF, только интеракции в нашем случае назначались на интерфейсные элементы не декларативно (как с командами в WPF), а программно, что показалось не очень удобным.
Выше я уже проводила аналогию с WPF. Для наглядности покажу, как выглядит наша архитектура в сравнении со стандартным WPF-приложением:
Весь набор инструментов, описанных на этой схеме, мы получили, используя Reactive UI.
Сложности в процессе разработки
А теперь я перейду от красивой теории к практическим проблемам, с которыми пришлось столкнуться, ведь ни один живой проект без этого не обходится.
Наиболее сложные моменты были связаны с разработкой UWP приложения, Windows добавила немало головной боли из-за некоторых особенностей и ограничений в отношении этих программ.
При сворачивании окна приложение переходит в состояние Suspended, и Windows выделяет ему меньше ресурсов. Это было критично, так как в одной из вариаций наш Data Generator работал, интегрируясь с внешними источниками и получая данные через сокеты. При сворачивании окна сокеты продолжали получать данные, заполняя свой внутренний буфер пакетами. А при выходе из режима Suspended все эти пакеты тут же помещались в буфер приложения, начиная обрабатываться только в этот момент. Из-за этого происходила задержка в отображении данных после развертывания окна, которая была пропорциональна времени, проведенному в свёрнутом виде. Всё решилось грамотной обработкой событий Suspending и Resuming, при наступлении которых мы сохраняли состояние приложения и закрывали сокеты, открывая их снова при восстановлении штатного режима работы.
Ещё одной непростой задачей стало добавление второго окна приложения (это было необходимо в рамках технического задания). Сейчас я не могу сказать, были ли это ограничения UWP, Xamarin.Forms или же наша собственная ошибка – краш происходил в конструкторе одного из представлений из-за UI-потоков. Позже выяснилось, что библиотека, предоставленная заказчиком и являющаяся ядром обработки данных, – однопользовательская и хранит в себе состояние. Таким образом, два независимых окна требовали двух независимых экземпляров библиотеки, что добавило нам одну большую низкоуровневую задачу, решение которой не было бы тривиальным. Мы решили, что овчинка выделки не стоит и проще не открывать отдельное окно, а создавать новый экземпляр приложения со своими настройками и адресным пространством. В итоге со стороны пользователя это выглядело в точности как второе окно (даже при закрытии главного окна второе тоже завершало свою деятельность), и разницу можно было заметить, только заглянув в диспетчер задач и увидев второй процесс.
Ну, и главный недостаток UWP, с которым пришло немало повозиться, – это политика его распространения. Чтобы установить приложение, его либо необходимо загрузить в Microsoft Store и скачивать оттуда, либо поставлять дистрибутив другим способом с одним ограничением – тогда при его установке необходимо дать операционной системе соответствующие разрешения («Sideloaded Apps» в настройках Windows). Техническое задание требовало реализации второго подхода, однако политика безопасности заказчика запрещала сотрудникам компании менять подобные настройки. В итоге нам пришлось написать инсталлер, который перед установкой включал «Sideloaded Apps», устанавливал пакет и в конце выключал эту настройку (естественно, по согласованию с заказчиком).
Отдельно стоит отметить, что сама кроссплатформенная разработка обязует программиста быть более дисциплинированным и проверять свой код на всех целевых платформах, что, конечно, добавляет монотонности.
Что касается архитектуры и каких ошибок можно было бы избежать?
Выше я уже писала об использовании для взаимодействия с пользователем Interaction от ReactiveUI. Такие интеракции можно обработать в любом месте приложения, что является не только их достоинством, но и недостатком, так как может внести большую путаницу. Чтобы понять, почему при нажатии на кнопку она окрашивается в красный цвет, а не в зелёный, вам нужно найти все обработчики интеракции и проверить код в них. Договоренность внутри команды обрабатывать интеракции унифицированно может помочь снизить негативное влияние этого фактора, но избежать его совсем вряд ли удастся.
Не меньшим по значимости недостатком описанных выше интеракций является то, что управлять порядком вызовов обработчиков практически невозможно. Мы наступили еще на одни грабли и использовали их не только для взаимодействия с пользователем, но и для общения вью-моделей друг с другом. Это часто играло против нас, так как из-за неконтролируемости вызовов обработчиков мы получали много плавающих багов. Поэтому использовать Interaction я рекомендую с большой осторожностью, а при реализации MVVM прорабатывать иные подходы к взаимодействию вью-моделей.
Еще стоит отметить, что достаточно много времени наша команда потратила на адаптацию визуальной части пользовательского интерфейса под Windows-приложение. Сжатые сроки и приоритеты заказчика поставили разработку iOS-версии на первое место, поэтому к UWP мы приступили, имея уже наполовину готовый проект, работающий на iOS. Изначально не предполагалось изменение разрешения, и приложение оказалось не готовым к свободному масштабированию окна, не имея достаточной гибкости в расположении элементов, что привело нас к довольно объемному рефакторингу всех визуальных компонентов. Поэтому не могу не отметить, что разработка кроссплатформенного проекта всё-таки должна вестись параллельно на всех предполагаемых платформах.
Краткое руководство по созданию приложения Xamarin.Forms
В этом кратком руководстве рассматриваются следующие темы:
В этом кратком руководстве приводятся инструкции по созданию кроссплатформенного приложения Оболочки в Xamarin.Forms, которое позволяет ввести заметку и сохранить ее в хранилище устройства. Ниже показано итоговое приложение:
Заметки о примечания
Предварительные требования
Дополнительные сведения об этих предварительных требованиях см. в разделе Установка Xamarin. Сведения о подключении Visual Studio 2019 к узлу сборки Mac см. в статье Связывание с Mac при разработке для Xamarin.iOS.
Начало работы с Visual Studio 2019
Запустите Visual Studio 2019 и в начальном окне щелкните Создать проект, чтобы создать новый проект:
В окне Создать проект в раскрывающемся списке Тип проекта щелкните Мобильное приложение, а затем выберите шаблон Мобильное приложение ( ) и нажмите кнопку Далее:
В диалоговом окне Настроить новый проект в поле Имя проекта укажите Notes, выберите подходящее расположение для проекта и нажмите кнопку Создать:
Фрагменты кода на C# и XAML из этого краткого руководства предполагают, что решение и проект называются Notes. Выбор другого имени приведет к ошибкам сборки при копировании кода из этого краткого руководства в проект.
В диалоговом окне Новое мобильное приложение выберите шаблон С вкладками и нажмите кнопку Создать:
После создания проекта закройте файл GettingStarted.txt.
В обозревателе решений в проекте Notes удалите следующие папки (и их содержимое):
В обозревателе решений в проекте Notes удалите GettingStarted.txt.
В обозревателе решений в проект Notes добавьте новую папку с именем Views.
В результате этого в папку Views будет добавлена новая страница с именем NotesPage. Эта страница будет основной страницей в приложении.
В обозревателе решений дважды щелкните файл NotesPage.xaml в проекте Notes, чтобы открыть его:
Удалите из NotesPage.xaml весь шаблонный код и замените его приведенным ниже.
Сохраните изменения в файле NotesPage.xaml, нажав клавиши CTRL+S.
В обозревателе решений дважды щелкните файл NotesPage.xaml.cs в проекте Notes, чтобы открыть его:
Удалите из NotesPage.xaml.cs весь шаблонный код и замените его приведенным ниже.
Сохраните изменения в файле NotesPage.xaml.cs, нажав клавиши CTRL+S.
В результате этого в папку Views будет добавлена новая страница с именем AboutPage.
В обозревателе решений дважды щелкните файл AboutPage.xaml в проекте Notes, чтобы открыть его:
Удалите из AboutPage.xaml весь шаблонный код и замените его приведенным ниже.
Сохраните изменения в файле AboutPage.xaml, нажав клавиши CTRL+S.
В обозревателе решений дважды щелкните файл AboutPage.xaml.cs в проекте Notes, чтобы открыть его:
Удалите из AboutPage.xaml.cs весь шаблонный код и замените его приведенным ниже.
Сохраните изменения в файле AboutPage.xaml.cs, нажав клавиши CTRL+S.
В обозревателе решений дважды щелкните файл AppShell.xaml в проекте Notes, чтобы открыть его:
Удалите из AppShell.xaml весь шаблонный код и замените его приведенным ниже.
Сохраните изменения в файле AppShell.xaml, нажав клавиши CTRL+S.
В обозревателе решений в проекте Notes разверните AppShell.xaml и дважды щелкните файл AppShell.xaml.cs, чтобы открыть его:
Удалите из AppShell.xaml.cs весь шаблонный код и замените его приведенным ниже.
Сохраните изменения в файле AppShell.xaml.cs, нажав клавиши CTRL+S.
В обозревателе решений дважды щелкните файл App.xaml в проекте Notes, чтобы открыть его:
Удалите из App.xaml весь шаблонный код и замените его приведенным ниже.
Сохраните изменения в файле App.xaml, нажав клавиши CTRL+S.
В обозревателе решений в проекте Notes разверните App.xaml и дважды щелкните файл App.xaml.cs, чтобы открыть его:
Удалите из App.xaml.cs весь шаблонный код и замените его приведенным ниже.
Сохраните изменения в файле App.xaml.cs, нажав клавиши CTRL+S.
Сборка примера из краткого руководства
в Visual Studio выберите элемент меню build build Solution (или нажмите клавишу F6). Выполняется сборка решения, а в строке состояния Visual Studio отображается сообщение об успешном выполнении:
При наличии ошибок повторите предыдущие шаги и исправьте все ошибки, пока сборка проектов не будет проходить успешно.
На панели инструментов Visual Studio нажмите клавишу Запустить (треугольная кнопка, похожая на кнопку воспроизведения), чтобы запустить приложение в выбранном эмуляторе Android.
Введите примечание и нажмите кнопку Сохранить. Закройте приложение и повторно запустите его, чтобы убедиться, что введенные заметки перезагружены.
Нажмите значок » о программе » для перехода к :
Нажмите кнопку Подробнее, чтобы запустить веб-страницу кратких руководств.
На панели инструментов Visual Studio щелкните правой кнопкой мыши проект Notes.iOS, а затем выберите команду Назначить запускаемым проектом.
На панели инструментов Visual Studio нажмите клавишу Запустить (треугольная кнопка, похожая на кнопку воспроизведения), чтобы запустить приложение в выбранном удаленном эмуляторе для iOS.
Введите примечание и нажмите кнопку Сохранить. Закройте приложение и повторно запустите его, чтобы убедиться, что введенные заметки перезагружены.
Нажмите значок » о программе » для перехода к :
Нажмите кнопку Подробнее, чтобы запустить веб-страницу кратких руководств.
Предварительные требования
Дополнительные сведения об этих предварительных требованиях см. в разделе Установка Xamarin.
Начало работы с Visual Studio для Mac
Запустите Visual Studio для Mac и в начальном окне щелкните Создать, чтобы создать новый проект:
В диалоговом окне Выбор шаблона для нового проекта щелкните многоплатформенное приложение, выберите шаблон приложения оболочки и нажмите кнопку Далее :
В диалоговом окне Configure your Shell Forms app (Настройка приложения Shell Forms) присвойте новому приложению имя Notes, а затем нажмите кнопку Далее:
В диалоговом окне Configure your new Shell Forms app (Настройка нового приложения Shell Forms) сохраните для проекта и решения имя Notes, выберите подходящее расположение для проекта и нажмите кнопку Создать для создания проекта:
Фрагменты кода на C# и XAML из этого краткого руководства предполагают, что решение и проект называются Notes. Выбор другого имени приведет к ошибкам сборки при копировании кода из этого краткого руководства в проект.
На Панели решения в проекте Notes удалите следующие папки (и их содержимое):
На Панели решения в проекте Notes удалите GettingStarted.txt.
На Панели решения в проект Notes добавьте новую папку с именем Views.
В результате этого в папку Views будет добавлена новая страница с именем NotesPage. Эта страница будет основной страницей в приложении.
На Панели решения дважды щелкните файл NotesPage.xaml в проекте Notes, чтобы открыть его:
Удалите из NotesPage.xaml весь шаблонный код и замените его приведенным ниже.
На Панели решения дважды щелкните файл NotesPage.xaml.cs в проекте Notes, чтобы открыть его:
Удалите из NotesPage.xaml.cs весь шаблонный код и замените его приведенным ниже.
На Панели решения дважды щелкните файл AboutPage.xaml в проекте Notes, чтобы открыть его:
В результате этого в папку Views будет добавлена новая страница с именем AboutPage.
Удалите из AboutPage.xaml весь шаблонный код и замените его приведенным ниже.
На Панели решения дважды щелкните файл AboutPage.xaml.cs в проекте Notes, чтобы открыть его:
Удалите из AboutPage.xaml.cs весь шаблонный код и замените его приведенным ниже.
На Панели решения дважды щелкните файл AppShell.xaml в проекте Notes, чтобы открыть его:
Удалите из AppShell.xaml весь шаблонный код и замените его приведенным ниже.
На Панели решения в проекте Notes разверните AppShell.xaml и дважды щелкните файл AppShell.xaml.cs, чтобы открыть его:
Удалите из AppShell.xaml.cs весь шаблонный код и замените его приведенным ниже.
На Панели решения дважды щелкните файл App.xaml в проекте Notes, чтобы открыть его.
Удалите из App.xaml весь шаблонный код и замените его приведенным ниже.
На Панели решения в проекте Notes разверните App.xaml и дважды щелкните файл App.xaml.cs, чтобы открыть его:
Удалите из App.xaml.cs весь шаблонный код и замените его приведенным ниже.
Сборка примера из краткого руководства
в Visual Studio для Mac выберите пункт меню построить сборку все (или нажмите ⌘ + B). Будет выполнена сборка проектов, а на панели инструментов Visual Studio для Mac отобразится сообщение об успешном выполнении:
При наличии ошибок повторите предыдущие шаги и исправьте все ошибки, пока сборка проектов не будет проходить успешно.
В панели решения щелкните правой кнопкой мыши проект Notes.iOS и выберите команду Назначить запускаемым проектом:
На панели инструментов Visual Studio для Mac нажмите клавишу Запустить (треугольная кнопка, похожая на кнопку воспроизведения) для запуска приложения в выбранном симуляторе iOS:
Введите примечание и нажмите кнопку Сохранить. Закройте приложение и повторно запустите его, чтобы убедиться, что введенные заметки перезагружены.
Нажмите значок » о программе » для перехода к :
Нажмите кнопку Подробнее, чтобы запустить веб-страницу кратких руководств.
В панели решения щелкните правой кнопкой мыши проект Notes.Droid и выберите команду Назначить запускаемым проектом:
На панели инструментов Visual Studio для Mac нажмите клавишу Запустить (треугольная кнопка, похожая на кнопку воспроизведения) для запуска приложения в выбранном эмуляторе Android:
Введите примечание и нажмите кнопку Сохранить. Закройте приложение и повторно запустите его, чтобы убедиться, что введенные заметки перезагружены.
Нажмите значок » о программе » для перехода к :
Нажмите кнопку Подробнее, чтобы запустить веб-страницу кратких руководств.
Дальнейшие действия
В этом кратком руководстве рассматривались следующие темы: