Name already in use
azure-docs.ru-ru / articles / active-directory / develop / msal-net-use-brokers-with-xamarin-apps.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Использование Microsoft Authenticator или Корпоративный портал Intune в приложениях Xamarin
В Android и iOS такие брокеры, как Microsoft Authenticator и Microsoft Intune Корпоративный портал для Android, включают:
- Единый вход (SSO). пользователям не нужно входить в каждое приложение.
- Идентификация устройства. брокер обращается к сертификату устройства. Этот сертификат создается на устройстве при его присоединении к рабочей области.
- Проверка идентификации приложения. когда приложение вызывает брокер, ему передается URL-адрес перенаправления. Брокер проверяет URL-адрес.
Чтобы включить одну из этих функций, используйте WithBroker() параметр при вызове PublicClientApplicationBuilder.CreateApplication метода. По .WithBroker() умолчанию параметр имеет значение true.
Настройка проверки подлинности через посредника в библиотеке проверки подлинности Майкрософт для .NET (MSAL.NET) зависит от платформы:
Аутентификация через посредника для iOS
Чтобы включить взаимодействие приложения Xamarin. iOS с приложением Microsoft Authenticator , выполните следующие действия. Если вы намерены ориентироваться на iOS 13, рекомендуем ознакомиться с изменениями в API нарушения Apple.
Шаг 1. Включение поддержки брокера
Необходимо включить поддержку брокера для отдельных экземпляров PublicClientApplication . По умолчанию поддержка отключена. При создании PublicClientApplication с помощью PublicClientApplicationBuilder используйте параметр, WithBroker() как показано в следующем примере. По WithBroker() умолчанию параметр имеет значение true.
Шаг 2. Включение доступа к цепочке ключей
Чтобы включить доступ к цепочке ключей, необходимо иметь группу доступа к цепочке ключей для приложения. Вы можете использовать WithIosKeychainSecurityGroup() API для настройки группы доступа к цепочке ключей при создании приложения:
Дополнительные сведения см. в разделе Включение доступа к цепочке ключей.
Шаг 3. обновление AppDelegate для обработки обратного вызова
Когда MSAL.NET вызывает брокер, брокер выполняет обратный вызов к приложению через OpenUrl метод AppDelegate класса. Так как MSAL ожидает ответа брокера, приложение должно взаимодействовать для вызова MSAL.NET назад. Чтобы обеспечить взаимодействие, обновите файл AppDelegate. CS , чтобы переопределить следующий метод.
Этот метод вызывается при каждом запуске приложения. Он используется как возможность обработки ответа от брокера и завершения процесса проверки подлинности, MSAL.NET запущен.
Шаг 4. Настройка UIViewController ()
Находясь в файле AppDelegate. CS , задайте окно объекта. Обычно вам не нужно задавать окно объекта для Xamarin iOS, но для отправки и получения ответов от брокера необходимо окно объекта.
Чтобы настроить окно объекта, выполните следующие действия.
В файле AppDelegate. CS задайте новое значение App.RootViewController UIViewController() . Это назначение гарантирует, что вызов брокера включает UIViewController . Если этот параметр назначен неправильно, может появиться следующее сообщение об ошибке:
«uiviewcontroller_required_for_ios_broker»:»UIViewController is null, so MSAL.NET cannot invoke the iOS broker. See https://aka.ms/msal-net-ios-broker»
В AcquireTokenInteractive вызове используйте, .WithParentActivityOrWindow(App.RootViewController) а затем передайте ссылку на окно объекта, которое вы будете использовать.
В AppDelegate. CS:
В AcquireToken вызове:
Шаг 5. Регистрация схемы URL-адреса
MSAL.NET использует URL-адреса для вызова брокера, а затем возвращает ответ брокера в приложение. Чтобы завершить цикл обработки, зарегистрируйте схему URL-адресов для своего приложения в файле info. plist .
CFBundleURLSchemes Имя должно включать в msauth. качестве префикса. После префикса используйте CFBundleURLName .
В схеме URL-адресов BundleId уникальным образом идентифицирует приложение: $»msauth.(BundleId)» . Поэтому BundleId , если имеет значение, используется com.yourcompany.xforms Схема URL-адресов msauth.com.yourcompany.xforms .
[!NOTE] Эта схема URL-адреса преобразуется в URI перенаправления, который уникальным образом идентифицирует ваше приложение при получении ответа от брокера.
Шаг 6. Добавление идентификатора брокера в раздел Лсаппликатионкуериессчемес
MSAL использует, –canOpenURL: чтобы проверить, установлен ли брокер на устройстве. В iOS 9 Компания Apple заблокировала схемы, которые может запрашивать приложение.
Добавьте msauthv2 в LSApplicationQueriesSchemes раздел файла info. plist , как показано в следующем примере:
Шаг 7. Добавление URI перенаправления в регистрацию приложения
При использовании брокера URI перенаправления имеет дополнительное требование. URI перенаправления должен иметь следующий формат:
Обратите внимание, что URI перенаправления соответствует CFBundleURLSchemes имени, которое вы включили в файл info. plist .
Добавьте URI перенаправления в регистрацию приложения в портал Azure. Чтобы создать правильно отформатированный URI перенаправления, используйте Регистрация приложений в портал Azure для создания URI перенаправления с брокером из идентификатора пакета.
Создание URI перенаправления:
Выберите Azure Active Directory > Регистрация приложений > зарегистрированное приложение
Выбор проверки подлинности > Добавление платформы > iOS/macOS
Введите идентификатор пакета и нажмите кнопку настроить.
Скопируйте созданный URI перенаправления, который отображается в текстовом поле URI перенаправления для включения в код:
. image type=»content» source=»media/msal-net-use-brokers-with-xamarin-apps/portal-01-ios-platform-settings.png» alt-text=»параметры платформы iOS с созданным URI перенаправления в портал Azure».
Выберите Готово , чтобы завершить создание URI перенаправления.
Аутентификация через посредника для Android
Шаг 1. Включение поддержки брокера
Поддержка брокера включается отдельно для каждого компонента PublicClientApplication . Она отключена по умолчанию. Используйте WithBroker() параметр (по умолчанию задано значение true) при создании с IPublicClientApplication помощью PublicClientApplicationBuilder .
Шаг 2. обновление AppDelegate для обработки обратного вызова
Когда MSAL.NET вызывает брокер, брокер, в свою очередь, выполняет обратный вызов к приложению с помощью OnActivityResult() метода. Так как MSAL будет ждать ответа от брокера, приложению нужно направить результат в MSAL.NET.
Направьте результат в SetAuthenticationContinuationEventArgs(int requestCode, Result resultCode, Intent data) метод, переопределив метод, OnActivityResult() как показано ниже:
Этот метод вызывается каждый раз при запуске приложения брокера и используется как возможность обработки ответа от брокера и завершения процесса проверки подлинности, запущенного MSAL.NET.
Шаг 3. Задание действия
Чтобы включить проверку подлинности через посредника, настройте действие таким образом, чтобы MSAL мог отправлять и получать ответ от брокера. Для этого укажите действие (обычно MainActivity ) для WithParentActivityOrWindow(object parent) родительского объекта.
Например, в вызове AcquireTokenInteractive() :
Шаг 4. Добавление URI перенаправления в регистрацию приложения
MSAL использует URL-адреса для вызова брокера, а затем возвращается в приложение. Чтобы завершить цикл обработки, зарегистрируйте URI перенаправления для приложения с помощью портал Azure.
Формат URI перенаправления для приложения зависит от сертификата, используемого для подписи APK. Пример:
Последняя часть URI — hgbUYHVBYUTvuvT&Y6tr554365466= это версия сигнатуры в кодировке Base64, с которой подписывается apk. При разработке приложения в Visual Studio при отладке кода без подписи APK с помощью определенного сертификата Visual Studio подписывает APK для вас в целях отладки. Когда Visual Studio подписывает APK для вас таким образом, он предоставляет ей уникальную подпись для компьютера, на котором она создана. Таким же, каждый раз при сборке приложения на другом компьютере необходимо обновить URI перенаправления в коде приложения и регистрацию приложения в портал Azure для проверки подлинности с помощью MSAL.
При отладке может возникнуть исключение MSAL (или сообщение журнала), сообщающее, что указанный URI перенаправления неверен. Исключение или сообщение журнала также указывает URI перенаправления, который следует использовать с текущим компьютером, на котором выполняется отладка. Вы можете использовать указанный универсальный код ресурса (URI) перенаправления, чтобы продолжить разработку приложения при условии обновления URI перенаправления в коде и добавления предоставленного URI перенаправления в регистрацию приложения в портал Azure.
Когда вы будете готовы завершить код, обновите URI перенаправления в коде и регистрацию приложения в портал Azure, чтобы использовать подпись сертификата, с помощью которого вы подписаны APK.
На практике это означает, что следует добавить URI перенаправления для каждого члена команды разработчиков, а также URI перенаправления для версии APK, подписанной в рабочей среде.
Вы можете вычислить подпись самостоятельно, как это делает MSAL:
Вы также можете получить подпись для пакета, используя keytool с помощью следующих команд:
Шаг 5 (необязательно). Возврат к обозревателю системы
Если MSAL настроен для использования брокера, но брокер не установлен, MSAL будет использовать веб-представление (браузер). MSAL попытается пройти проверку подлинности с помощью системного браузера по умолчанию на устройстве, что приведет к сбою, так как универсальный код ресурса (URI) перенаправления настроен для брокера, а системный браузер не знает, как использовать его для перехода к MSAL. Чтобы избежать сбоя, можно настроить Фильтр намерения с помощью URI перенаправления брокера, который использовался на шаге 4.
Измените манифест приложения, чтобы добавить фильтр намерения:
Например, если у вас есть URI перенаправления для msauth://com.microsoft.xforms.testApp/hgbUYHVBYUTvuvT&Y6tr554365466= , манифест должен выглядеть как следующий фрагмент кода XML.
Требуется прямая косая черта ( / ) перед сигнатурой в android:path значении.
Дополнительные сведения о настройке приложения для браузера системы и поддержки Android 11 см. в статье обновление манифеста Android для поддержки системных браузеров.
В качестве альтернативы можно настроить MSAL для возврата к встроенному браузеру, который не полагается на URI перенаправления:
Советы по устранению неполадок при проверке подлинности через брокер Android
Вот несколько советов по предотвращению проблем при реализации проверки подлинности через посредника в Android:
URI перенаправления — Добавьте URI перенаправления в регистрацию приложения в портал Azure. Отсутствующий или неверный URI перенаправления является распространенной проблемой, возникшей разработчиками.
Версия компонента Service Broker — установите минимальную требуемую версию приложений брокера. Одно из этих двух приложений можно использовать для проверки подлинности через посредника в Android.
-
(версия 5.0.4689.0 или более поздняя) (версия 6.2001.0140 или более поздняя).
Приоритет компонента Service Broker . MSAL взаимодействует с первым брокером, установленным на устройстве при установке нескольких брокеров.
Пример. Если сначала установить Microsoft Authenticator, а затем установить Корпоративный портал Intune, то проверка подлинности через посредник будет выполняться только в Microsoft Authenticator.
Журналы . при возникновении проблемы с проверкой подлинности через посредника Просмотр журналов брокера может помочь в диагностике причины.
Получение журналов Microsoft Authenticator:
- Нажмите кнопку меню в правом верхнем углу приложения.
- Выберите Отправить отзыв о > проблемах?.
- В разделе что вы пытаетесь сделать? выберите вариант и добавьте описание.
- Чтобы отправить журналы, щелкните стрелку в правом верхнем углу приложения.
После отправки журналов в диалоговом окне отображается идентификатор инцидента. Запишите идентификатор инцидента и включите его при запросе помощи.
Получение журналов Корпоративный портал Intune:
- Нажмите кнопку меню в левом верхнем углу приложения.
- Выберите Справка > Электронная почта поддержка.
- Чтобы отправить журналы, выберите отправить только журналы.
После отправки журналов в диалоговом окне отображается идентификатор инцидента. Запишите идентификатор инцидента и включите его при запросе помощи.
Xamarin.Messaging.Broker wants firewall access
After installing VS2019 16.5.1 and 16.5.2 I receive a message that Windows Defender has locked some features of Xamarin.Messaging.Broker and asking if I should allow it.
Normally I would as it seems to be part of Visual Studio but this executable is located in my appdata\local\temp file, which I would not expect it to be. Searching the net for info about this yields little in the way of good information.
Does anyoe know what it does and why on earth would you put an exe in the local user temp?
3 Answers 3
My message appear exactly after upgrade 16.5.0 to 16.5.3, We all see this message in 16.5.2 version and above.
So as far as we know this happened because microsoft add something new in 16.5.2 and above, It can’t be anything except microsoft work since we all have seen this firewall message.
My file was in C:\users\username\appdata\local\temp\xamarin\xma\broker.local\16.5.000.533\broker.exe
This access will add a record in firewall advanced «Inbound Rules» Which means grant an access from outside to our PCs on UDP/TCP.
Conclusion :
Personaly i allowd this file in firewall because i have tons of problems in xamarin (special to connect to Mac) and i don’t want to add more, I suggest you all do the same.
leveraging brokers on Android and iOS — AzureAD/azure-activedirectory-library-for-dotnet GitHub Wiki
If you are just getting started with brokers, or already using brokers for authentication, please look into migrating to, or directly starting with, MSAL.NET. Learn how to migrate from ADAL to MSAL here.
ADAL.NET has been deprecated and will only receive security fixes. MSAL.NET can be used for Intune integration.
MSAL.NET Android broker integration has been designed so that no longer requires the «Contacts» permission, which can be a big deterrent for users adopting your app, nor does it require to show an account picker.
Why use brokers on Xamarin.iOS and Xamarin.Android applications?
On Android and iOS, brokers enable:
- Single Sign On (SSO). Your users won’t need to sign-in to each application
- Device identification (by accessing the device certificate which was created on the device when it was workplace joined)
- Application identification verification (is it really outlook which calls me?). The way it works is when an application calls the broker, it passes its redirect url, and the broker verifies it:
- On iOS, the redirect URL is, for instance, ms-word://com.msft.com , the broker parses and gets the appId (after the //) and verifies it’s the same as the appId of the calling app, which it knows (by the OS).
- On Android the redirect URLs have the following shape msauth://com.msft.word/<base64URL encoded hash> .
To enable one of these features, the application developers need to set the UseBroker Boolean to true in the platform parameters. They also need to implement a delegate to react to the broker calling back the application as described in Platform parameters properties specific to brokers on Android and iOS
Things are slightly different on iOS and Android. here are the details:
Brokered Authentication for iOS
If your Xamarin.iOS app requires conditional access or certificate authentication (currently in preview) support, you must set up your AuthenticationContext and redirectURI to be able to talk to the Microsoft Authenticator app. Make sure that your Redirect URI and application’s bundle id is all in lower case.
Enable Broker support on your AuthenticationContext
Broker support is enabled on a per-authentication-context basis. It is disabled by default. You must set the useBroker flag to true in the PlatformParameters constructor if you wish ADAL.NET to call the broker:
Update AppDelegate to ensure that the broker calls back ADAL.NET
When ADAL.NET calls the broker, it will call back to your application, through the OpenUrl method of AppDelegate. Since ADAL waits for the token from the broker, your application needs to cooperate to call ADAL.NET back. You will do this by updating the AppDelegate.cs file to override the method below.
This method is invoked every time the application is launched and is used as an opportunity to process the response from the Broker and complete the authentication process initiated by ADAL.Net.
Register a URL Scheme
ADAL.Net uses URLs to invoke the broker and then return back to your app. To finish that round trip you need to register a URL scheme for your app. We recommend making the URL scheme fairly unique to minimize the chances of another app using the same URL scheme.
ADAL uses –canOpenURL: to check if the broker is installed on the device. In iOS 9, Apple locked down what schemes an application can query for. You will need to add “msauth” to the LSApplicationQueriesSchemes section of your info.plist file.
Register your Redirect URI in the application portal
This adds extra requirements on your redirect URI. Your redirect URI must be in the proper form.
This Redirect URI needs to be registered on the app registration portal (https://portal.azure.com) as a valid redirect URI for your application. Additionally a second «msauth» form needs to be registered to handle certificate authentication in Azure Authenticator.
Note: If you are seeing a «Something went wrong» message, please verify that your Redirect URI and application’s bundle id is all in lower case.
Brokered Authentication for Android
If your Xamarin.Android app or your app users requires conditional access or certificate authentication support, you must set up your AuthenticationContext and redirectURI to be able to talk to the Microsoft Authenticator app OR the Company Portal app. Both are brokers on Android. Make sure that your Redirect URI and application’s bundle id is all in lower case.
Enable support for Broker on Your AuthencationContext
Leveraging a broker is enabled on a per-authentication-context basis. It is disabled by default. You must set the useBroker flag to true in PlatformParameters constructor if you wish ADAL to call to broker:
Ensure your app has access to the Broker accounts
Google has introduced an extra security measure for apps wanting to access accounts. ADAL needs to list all the «Microsoft» accounts, i.e. all the accounts created by the broker app. Currently, it is your responsibility to ensure your app has access to this — by invoking the Android Account Picker.
If you do not do this, silent calls to the broker (e.g. when the access token expires in 1h) will fail and the broker will have to invoked explicitly, degrading the user experience because they have to login again.
As far as we have tested, it is sufficient to perform this call only once for your app.
Update the application manifest
If you target Android versions lower than 23, calling app requires having the following permissions declared in the application manifest(http://developer.android.com/reference/android/accounts/AccountManager.html):
- GET_ACCOUNTS
- USE_CREDENTIALS
- MANAGE_ACCOUNTS
If your application targets Android 23 or above, the USE_CREDENTIALS and MANAGE_ACCOUNTS permissions have been deprecated and GET_ACCOUNTS is under protection level «dangerous». Your app is responsible for requesting the permission for GET_ACCOUNTS. You can reference permission request for API 23.
Register a Redirect URI for your application
ADAL uses URLs to invoke the broker and then return back to your app. To finish that round trip you need to register a URL scheme for your app. This Redirect URI needs to be registered on the Azure AAD app registration portal as a valid redirect URI for your application.
The redirect URI needed for your application is dependent on the certificate used to sign the APK.
The last part of the URI, hgbUYHVBYUTvuvT&Y6tr554365466=, is the signature that the APK is signed with, base64 encoded. However, during the development phase of your application using Visual Studio, if you are debugging your code without signing the apk with a specific certificate, Visual Studio will sign the apk for you for debugging purposes, giving the APK a unique signature for the machine that it is built on. Thus, each time you build your app on a different machine, you will need to update the redirect URI in the application’s code and the application’s registration in the azure portal in order to authenticate with MSAL.
While debugging, you may encounter an MSAL exception (or log message) stating the redirect URI provided is incorrect. This exception will also provide you with the redirect URI that you should be using with the current machine you are debugging on. You can use this redirect URI to continue developing for the time being.
Once you are ready to finalize your code, be sure to update the redirect URI in the code and on the application’s registration in the azure portal to use the signature of the certificate you will be signing the APK with.
In practice this means that you have to register a redirect URI for each member of the team, plus a redirect URI for the production signed version of the APK.
You can also compute this signature yourself, similar to how MSAL does it:
You also have the option of acquiring the signature for your package by using the keytool with the following commands:
For Windows: keytool.exe -list -v -keystore «%LocalAppData%\Xamarin\Mono for Android\debug.keystore» -alias androiddebugkey -storepass android -keypass android
For Mac: keytool -exportcert -alias androiddebugkey -keystore
/.android/debug.keystore | openssl sha1 -binary | openssl base64
Update MainActivity.cs to call back ADAL.NET
When ADAL.NET calls the broker, it will call back your application, through the OnActivityResult method of your Android application MainActivity class. Since ADAL waits for the token from the broker, your application needs to cooperate to call ADAL.NET back. You will do this by updating the MainActivity.cs file to the override method below.
This method is invoked when the activity receives a callback from the webview or the broker application. This code snippet is required to complete the authentication process initiated by ADAL.NET
In Silent calls, make sure the UserIdentifier matches the entry in the Broker
When performing a silent call to fetch a token, ADAL must communicate with the Broker to find out which broker account to fetch a token for. ADAL uses the information you pass in as UserIdentifier to locate the account.
Known issue with Xamarin Android Acquire Token Silent and Intune Company Portal
First reported in this issue, and first noticed in ADAL 5.1 and Intune Company Portal 5.0.4464.0, there can be a cache miss on the acquire token silent call which results in the Company Portal appearing on every acquire token silent call.
Use the tenant GUID version of the authority instead of the string representation. If the string version is used, ADAL will fail during LoadFromCacheCommon because there is a comparison of the authority with the cache key authority. Pass in the GUID value for the authority to resolve the issue.
Xamarin: что это такое, кому стоит использовать и ответы на другие важные вопросы о фреймворке
При кроссплатформенной разработке код и элементы дизайна для одной платформы используются при работе над следующей, и это обещает неплохую экономию. Xamarin позиционируется как лучший инструмент для таких решений. Рассказываем, как он работает и для кого.
Кто выигрывает с Xamarin?
Бизнес-логика приложения редко меняется при смене платформы. Ваш любимый интернет-банкинг проводит платежи и сообщает баланс вне зависимости от того, работаете вы на смартфоне или ноутбуке. Подобные приложения со сложной бизнес-логикой и стандартным интерфейсом — прерогатива Xamarin.
Алгоритмы, разработанные на C# для одной платформы, программисты используют и для всех остальных платформ. Например, при работе на Xamarin.Android и Xamarin.iOS, до 75% кода можно переиспользовать: приложение работает одинаково и на iPhone, и на Android-смартфоне.
Если в приложении главное — функциональность, а из дизайна всего пара кнопок и красивый график — вам повезло, Xamarin подходит. На проектах со сложным интерфейсом стоимость доработки иногда сопоставима с разработкой двух-трёх нативных решений. Но бизнес-логика равно не меняется и с каждой новой версией приложения разрабатывать ещё будет проще — все нюансы требований заказчика уже известны. В сухом остатке затраты на доработку зависят от команды и сложности дизайна.
Какие плюсы?
Экономия ресурсов, переиспользование кода и простота добавления версий для новых платформ. Код на C# доступен всей команде и при достаточной квалификации может быть использован на любой другой платформе: как мобильной, так и десктопной.
Ваша команда подходит?
Для программистов, уже работающих с несколькими платформами отдельно, переход на кроссплатформенные решения покажется рутиной. Разобраться в Xamarin легко, а вот изучить документацию, гайдлайны, SDK и API каждой платформы с нуля — гораздо сложнее.
Для тех же Xamarin.Android и Xamarin.iOS требуется знание iOS Storyboards и синтаксис Android XML. Конечно, обучать сотрудников всегда полезно, но готовы ли вы делать эти вложения прямо сейчас? В любом случае, лучше иметь на проекте пару iOS-Android разработчиков, которые ускорят процесс обучения коллег. В команде одни десктоп-специалисты, а приложение должно работать и на смартфонах? Без дополнительной помощи мобильных разработчиков вы вряд ли почувствуете экономию от Xamarin.
Сколько это стоит?
Ещё в начале 2016 года разработчики тратили на лицензию Xamarin до $999 в год. Но после поглощения компанией Microsoft большая часть продуктов Xamarin стала доступна по лицензии Visual Studio 2013 или Visual Studio 2015. Скачивайте всё необходимое с официального сайта Xamarin или прямо в Visual Studio 2015 (Update 2) и начинайте работу.
Доплачивать надо, например, за Xamarin Test Cloud. Но будем честны: без этого сервиса может обойтись подавляющее большинство проектов.
Стоит учитывать стоимость оборудования. Вам понадобятся устройства с macOS для разработки на iOS SDK и Windows для Windows Phone SDK, а Android SDK работает и там, и там.
О чем стоит беспокоиться?
Xamarin сравнительно молодой — на специфические вопросы не всегда удаётся найти ответы в документации или на форуме. Но можно спросить у разработчиков на конкретных платформах. В Xamarin используются нативные SDK, даже название методов и классов в Xamarin наследуется, так что проблем с поиском возникнуть не должно.
Раздел для разработчиков на сайте Xamarin содержит детальную документацию, API и примеры всех методов и процедур — этого достаточно, чтобы начать разработку. Для всего остального есть Stackoverflow с ответами на любые вопросы по Xamarin, iOS, Android.
Первые Xamarin-специалисты жаловались на проблемы при работе со сторонними библиотеками. Сегодня SQLite.NET, loC фреймворки Autofac, MVVC фреймворки и другие популярные библиотеки поддерживают кроссплатформенную разработку. Если вы не собираетесь использовать на проекте исключительно редкие инструменты, то волноваться не о чем.
Xamarin.Forms или Xamarin.IOS + Xamarin.Android?
Зависит от возможностей и желаний. Xamarin.Forms — это инструмент для разработки единого интерфейса для всех платформ. Дизайн описывается в XML-файле, используя синтаксис XAML. Это оценят .NET-разработчики, которые обычно уверенно работают с XAML.
Проблема в том, что программисту будет доступен всего лишь небольшой набор стандартных элементов управления, внешняя оболочка, связанная с нативными кнопками, чекбоксами и прочим. Теоритически, в Xamarin.Forms используется до 100% общего кода, но только для приложений с совсем уж простым интерфейсом, вроде «Hello world». Если вам захочется что-то, чего нет в наборе, то придётся перерабатывать и сами элементы на каждой платформе по-отдельности. Выбирайте Xamarin.Forms для проектов, где вы готовы сэкономить на гибкости настройки интерфейса.
Чаще «схалявить» не получается и нужно использовать Xamarin.iOS и Xamarin.Android. Так у вас будет прямой доступ к API платформ и полный набор элементов управления, а каждая платформа будет представлена отдельным решением.
Так подойдет мне Xamarin или нет?
Ответьте на три вопроса и станет ясно, подходит ли вам Xamarin:
- Интерфейс приложения без сложной логики взаимодействия и нестандартных элементов управления?
- У вас в команде есть мобильные разработчики?
- Вы планируете другие кроссплатформенные проекты (пусть даже не на Xamarin) в ближайшее время?
Если вы ответили «да» на все вопросы, тогда Xamarin — хорошее вложение для вашей команды и проекта в долгосрочной перспективе.
Автор: Мария Куликовская, веб-разработчик, Itransition
Мария работает в Itransition более трех лет, отвечая за планирование проектов, выбор технологий под бизнес-требования заказчика, управление развертыванием и пост-проектной поддержкой и т.п. Участвовала в разработке самых разных систем, как мобильных, так и десктопных. Сфера особого интереса — базы данных.