Behaviors let you add functionality to user interface controls without having to subclass them. Instead, the functionality is implemented in a behavior class and attached to the control as if it was part of the control itself. This article provides an introduction to behaviors.

Behaviors enable you to implement code that you would normally have to write as code-behind, because it directly interacts with the API of the control in such a way that it can be concisely attached to the control and packaged for reuse across more than one application. They can be used to provide a full range of functionality to controls, such as:

• Adding an email validator to an Entry.
• Creating a rating control using a tap gesture recognizer.
• Controlling an animation.
• Adding an effect to a control.

Behaviors also enable more advanced scenarios. In the context of commanding, behaviors are a useful approach for connecting a control to a command. In addition, they can be used to associate commands with controls that were not designed to interact with commands. For example, they can be used to invoke a command in response to an event firing.

Xamarin.Forms supports two different styles of behaviors:

• Xamarin.Forms behaviors – classes that derive from the Behavior or Behavior<T> class, where T is the type of the control to which the behavior should apply. For more information about Xamarin.Forms behaviors, see Xamarin.Forms Behaviors and Reusable Behaviors.
• Attached behaviors – static classes with one or more attached properties. For more information about attached behaviors, see Attached Behaviors.

This guide focuses on Xamarin.Forms behaviors because they are the preferred approach to behavior construction.

동작을 사용하면 서브클래스 없이도 사용자 인터페이스 컨트롤에 기능을 추가할 수 있습니다. 대신 기능은 동작 클래스에서 구현되고 컨트롤 자체의 일부였던 것처럼 컨트롤에 연결됩니다. 이 문서에서는 동작을 소개합니다.

동작을 사용하면 코드가 컨트롤에 간결하게 첨부되고 둘 이상의 애플리케이션에서 재사용하도록 패키지될 수 있도록 컨트롤의 API와 직접 상호 작용하기 때문에, 대개 코드 숨김으로 작성해야 하는 코드를 구현할 수 있습니다. 다음과 같은 컨트롤에 광범위한 기능을 제공하는 데 사용할 수 있습니다.

• 이메일 유효성 검사기를 Entry에 추가합니다.
• 탭 제스처 인식기를 사용하여 등급 컨트롤을 만듭니다.
• 애니메이션을 제어합니다.
• 컨트롤에 효과를 추가합니다.

또한 동작은 더 고급 시나리오를 사용하도록 설정합니다. 명령 컨텍스트에서 동작은 명령에 컨트롤을 연결하는 데 유용한 접근 방식입니다. 또한 동작은 명령과 상호 작용하도록 설계되지 않은 컨트롤과 명령을 연결하는 데 사용할 수 있습니다. 예를 들어, 발생하는 이벤트에 대한 응답에서 명령을 호출하는 데 사용할 수 있습니다.

Xamarin.Forms는 동작의 두 가지 다른 스타일을 지원합니다.

• Xamarin.Forms 동작 – Behavior 또는 Behavior<T> 클래스에서 파생된 클래스입니다. 여기서 T는 동작이 적용되어야 하는 컨트롤의 형식입니다. Xamarin.Forms 동작에 대한 자세한 내용은 Xamarin.Forms 동작 및 재사용 가능한 동작을 참조하세요.
• 연결된 동작 – 첨부된 속성이 하나 이상 있는 static 클래스입니다. 연결된 동작에 대한 자세한 내용은 연결된 동작을 참조하세요.

이 가이드는 Xamarin.Forms 동작에 집중합니다. 이는 동작 구성에 선호되는 접근 방식이기 때문입니다.

• 2017. 03. 23.
• 읽는 데 6분

• • 

   
  •  

Handling Platform Divergence & Features

Divergence isn’t just a ‘cross-platform’ problem; devices on the ‘same’ platform have different capabilities (especially the wide variety of Android devices that are available). The most obvious and basic is screen size, but other device attributes can vary and require an application to check for certain capabilities and behave differently based on their presence (or absence).

This means all applications need to deal with graceful degradation of functionality, or else present an unattractive, lowest-common-denominator feature set. Xamarin’s deep integration with the native SDKs of each platform allow applications to take advantage of platform-specific functionality, so it makes sense to design apps to use those features.

See the Platform Capabilities documentation for an overview of how the platforms differ in functionality.

Examples of Platform Divergence

Fundamental elements that exist across platforms

There are some characteristics of mobile applications that are universal. These are higher-level concepts that are generally true of all devices and can therefore form the basis of your application’s design:

• Feature selection via tabs or menus
• Lists of data and scrolling
• Single views of data
• Editing single views of data
• Navigating back

When designing your high-level screen flow you can base a common user experience on these concepts.

Platform-specific attributes

In addition to the basic elements that exist on all platforms, you will need to address key platform differences in your design. You may need to consider (and write code specifically to handle) these differences:

• Screen sizes – Some platforms (like iOS and earlier Windows Phone versions) have standardized screen sizes that are relatively simple to target. Android devices have a large variety of screen dimensions, which require more effort to support in your application.
• Navigation metaphors – Differ across platforms (eg. hardware ‘back’ button, Panorama UI control) and within platforms (Android 2 and 4, iPhone vs iPad).
• Keyboards – Some Android devices have physical keyboards while others only have a software keyboard. Code that detects when a soft-keyboard is obscuring part of the screen needs to be sensitive to these differences.
• Touch and gestures – Operating system support for gesture recognition varies, especially in older versions of each operating system. Earlier versions of Android have very limited support for touch operations, meaning that supporting older devices may require separate code
• Push notifications – There are different capabilities/implementations on each platform (eg. Live Tiles on Windows).

Device-specific features

Determine what the minimum features required for the application must be; or when decide what additional features to take advantage of on each platform. Code will be required to detect features and disable functionality or offer alternatives (eg. an alternative to geo-location could be to let the user type a location or choose from a map):

• Camera – Functionality differs across devices: some devices don’t have a camera, others have both front- and rear-facing cameras. Some cameras are capable of video recording.
• Geo-location & maps – Support for GPS or Wi-Fi location is not present on all devices. Apps also need to cater for the varying levels of accuracy that’s supported by each method.
• Accelerometer, gyroscope and compass – These features are often found in only a selection of devices on each platform, so apps almost always need to provide a fallback when the hardware isn’t supported.
• Twitter and Facebook – only ‘built-in’ on iOS5 and iOS6 respectively. On earlier versions and other platforms you will need to provide your own authentication functions and interface directly with each services’ API.
• Near Field Communications (NFC) – Only on (some) Android phones (at time of writing).

Dealing with Platform Divergence

There are two different approaches to supporting multiple platforms from the same code-base, each with its own set of benefits and disadvantages.

• Platform Abstraction – Business Façade pattern, provides a unified access across platforms and abstracts the particular platform implementations into a single, unified API.
• Divergent Implementation – Invocation of specific platform features via divergent implementations via architectural tools such as interfaces and inheritance or conditional compilation.

Platform Abstraction

Class Abstraction

Using either interfaces or base classes defined in the shared code and implemented or extended in platform-specific projects. Writing and extending shared code with class abstractions is particularly suited to Portable Class Libraries because they have a limited subset of the framework available to them and cannot contain compiler directives to support platform-specific code branches.

Interfaces

Using interfaces allows you to implement platform-specific classes that can still be passed into your shared libraries to take advantage of common code.

The interface is defined in the shared code, and passed into the shared library as a parameter or property.

The platform-specific applications can then implement the interface and still take advantage of shared code to ‘process’ it.

Advantages

The implementation can contain platform-specific code and even reference platform-specific external libraries.

Disadvantages

Having to create and pass implementations into the shared code. If the interface is used deep within the shared code then it ends up being passed through multiple method parameters or otherwise pushed down through the call chain. If the shared code uses lots of different interfaces then they must all be created and set in the shared code somewhere.

Inheritance

The shared code could implement abstract or virtual classes that could be extended in one or more platform-specific projects. This is similar to using interfaces but with some behavior already implemented. There are different viewpoints on whether interfaces or inheritance are a better design choice: in particular because C# only allows single inheritance it can dictate the way your APIs can be designed going forward. Use inheritance with caution.

The advantages and disadvantages of interfaces apply equally to inheritance, with the additional advantage that the base class can contain some implementation code (perhaps an entire platform agnostic implementation that can be optionally extended).

Xamarin.Forms

See the Xamarin.Forms documentation.

Other Cross-Platform Libraries

These libraries also offer cross-platform functionality for C# developers:

• Xamarin.Essentials – Cross-platform APIs for common features.
• SkiaSharp – Cross-platform 2D graphics.

Conditional Compilation

There are some situations where your shared code will still need to work differently on each platform, possibly accessing classes or features that behave differently. Conditional compilation works best with Shared Asset Projects, where the same source file is being referenced in multiple projects that have different symbols defined.

Xamarin projects always define __MOBILE__ which is true for both iOS and Android application projects (note the double-underscore pre- and post-fix on these symbols).

C#복사

#if __MOBILE__ // Xamarin iOS or Android-specific code #endif iOS

Xamarin.iOS defines __IOS__ which you can use to detect iOS devices.

C#복사

#if __IOS__ // iOS-specific code #endif

There are also Watch- and TV-specific symbols:

C#복사

#if __TVOS__ // tv-specific stuff #endif #if __WATCHOS__ // watch-specific stuff #endif Android

Code that should only be compiled into Xamarin.Android applications can use the following

C#복사

#if __ANDROID__ // Android-specific code #endif

Each API version also defines a new compiler directive, so code like this will let you add features if newer APIs are targeted. Each API level includes all the ‘lower’ level symbols. This feature is not really useful for supporting multiple platforms; typically the __ANDROID__ symbol will be sufficient.

C#복사

#if __ANDROID_11__ // code that should only run on Android 3.0 Honeycomb or newer #endif Mac

There is not currently a built-in symbol for Xamarin.Mac, but you can add your own in the Mac app project Options > Build > Compiler in the Define symbols box, or edit the .csproj file and add there (for example __MAC__)

XML복사

<PropertyGroup><DefineConstants>__MAC__;$(DefineConstants)</DefineConstants></PropertyGroup> Universal Windows Platform (UWP)

Use WINDOWS_UWP. There are no underscores surrounding the string like the Xamarin platform symbols.

C#복사

#if WINDOWS_UWP // UWP-specific code #endif Using Conditional Compilation

A simple case-study example of conditional compilation is setting the file location for the SQLite database file. The three platforms have slightly different requirements for specifying the file location:

• iOS – Apple prefers non-user data to be placed in a specific location (the Library directory), but there is no system constant for this directory. Platform-specific code is required to build the correct path.
• Android – The system path returned by Environment.SpecialFolder.Personal is an acceptable location to store the database file.
• Windows Phone – The isolated storage mechanism does not allow a full path to be specified, just a relative path and filename.
• Universal Windows Platform – Uses Windows.Storage APIs.

The following code uses conditional compilation to ensure the DatabaseFilePath is correct for each platform:

C#복사

public static string DatabaseFilePath { get { var filename = "TodoDatabase.db3"; #if SILVERLIGHT // Windows Phone 8 var path = filename; #else #if __ANDROID__ string libraryPath = Environment.GetFolderPath(Environment.SpecialFolder.Personal); ; #else #if __IOS__ // we need to put in /Library/ on iOS5.1 to meet Apple's iCloud terms // (they don't want non-user-generated data in Documents) string documentsPath = Environment.GetFolderPath (Environment.SpecialFolder.Personal); // Documents folder string libraryPath = Path.Combine (documentsPath, "..", "Library"); #else // UWP string libraryPath = Windows.Storage.ApplicationData.Current.LocalFolder.Path; #endif #endif var path = Path.Combine (libraryPath, filename); #endif return path; }

The result is a class that can be built and used on all platforms, placing the SQLite database file in a different location on each platform.

The Xamarin platform consists of a number of elements that allow you to develop applications for iOS and Android:

• C# language – Allows you to use a familiar syntax and sophisticated features like Generics, LINQ and the Parallel Task Library.
• Mono .NET framework – Provides a cross-platform implementation of the extensive features in Microsoft’s .NET framework.
• Compiler – Depending on the platform, produces a native app (eg. iOS) or an integrated .NET application and runtime (eg.Android). The compiler also performs many optimizations for mobile deployment such as linking away un-used code.
• IDE tools – The Visual Studio on Mac and Windows allows you to create, build, and deploy Xamarin projects.

In addition, because the underlying language is C# with the .NET framework, projects can be structured to share code that can also be deployed to Windows Phone.

Under the Hood

Although Xamarin allows you to write apps in C#, and share the same code across multiple platforms, the actual implementation on each system is very different.

Compilation

The C# source makes its way into a native app in very different ways on each platform:

• iOS – C# is ahead-of-time (AOT) compiled to ARM assembly language. The .NET framework is included, with unused classes being stripped out during linking to reduce the application size. Apple does not allow runtime code generation on iOS, so some language features are not available (see Xamarin.iOS Limitations ).
• Android – C# is compiled to IL and packaged with MonoVM + JIT’ing. Unused classes in the framework are stripped out during linking. The application runs side-by-side with Java/ART (Android runtime) and interacts with the native types via JNI (seeXamarin.Android Limitations ).
• Windows – C# is compiled to IL and executed by the built-in runtime, and does not require Xamarin tools. Designing Windows applications following Xamarin’s guidance makes it simpler to re-use the code on iOS and Android. Note that the Universal Windows Platform also has a .NET Native option which behaves similarly to Xamarin.iOS' AOT compilation.

The linker documentation for Xamarin.iOS and Xamarin.Android provides more information about this part of the compilation process.

Runtime 'compilation' – generating code dynamically with System.Reflection.Emit – should be avoided.

Apple’s kernel prevents dynamic code generation on iOS devices, therefore emitting code on-the-fly will not work in Xamarin.iOS.Likewise, the Dynamic Language Runtime features cannot be used with Xamarin tools.

Some reflection features do work (eg. MonoTouch.Dialog uses it for the Reflection API), just not code generation.

Platform SDK Access

Xamarin makes the features provided by the platform-specific SDK easily accessible with familiar C# syntax:

• iOS – Xamarin.iOS exposes Apple’s CocoaTouch SDK frameworks as namespaces that you can reference from C#. For example the UIKit framework that contains all the user interface controls can be included with a simple using UIKit; statement.
• Android – Xamarin.Android exposes Google’s Android SDK as namespaces, so you can reference any part of the supported SDK with a using statement, such as using Android.Views; to access the user interface controls.
• Windows – Windows apps are built using Visual Studio on Windows. Project types include Windows Forms, WPF, WinRT, and the Universal Windows Platform (UWP).

Seamless Integration for Developers

The beauty of Xamarin is that despite the differences under the hood, Xamarin.iOS and Xamarin.Android (coupled with Microsoft’s Windows SDKs) offer a seamless experience for writing C# code that can be re-used across all three platforms.

Business logic, database usage, network access, and other common functions can be written once and re-used on each platform, providing a foundation for platform-specific user interfaces that look and perform as native applications.

Integrated Development Environment (IDE) Availability

Xamarin development can be done in Visual Studio on either Mac or Windows. The IDE you choose will be determined by the platforms you wish to target.

Because Windows apps can only be developed on Windows, to build for iOS, Android, and Windows requires Visual Studio for Windows. However it's possible to share projects and files between Windows and Mac computers, so iOS and Android apps can be built on a Mac and shared code could later be added to a Windows project.

The development requirements for each platform are discussed in more detail in the Requirement guide.

iOS

Developing iOS applications requires a Mac computer, running macOS. You can also use Visual Studio to write and deploy iOS applications with Xamarin in Visual Studio. However, a Mac is still needed for build and licensing purposes.

Apple’s Xcode IDE must be installed to provide the compiler and simulator for testing. You can test on your own devices for free, but to build applications for distribution (eg. the App Store) you must join Apple’s Developer Program ($99 USD per year). Each time you submit or update an application, it must be reviewed and approved by Apple before it is made available for customers to download.

Code is written with the Visual Studio IDE and screen layouts can be built programmatically or edited with Xamarin's iOS Designer in either IDE.

Refer to the Xamarin.iOS Installation Guide for detailed instructions on getting set up.

Android

Android application development requires the Java and Android SDKs to be installed. These provide the compiler, emulator and other tools required for building, deployment and testing. Java, Google’s Android SDK and Xamarin’s tools can all be installed and run on Windows and macOS. The following configurations are recommended:

• Windows 10 with Visual Studio 2019
• macOS Mojave (10.11+) with Visual Studio 2019 for Mac

Xamarin provides a unified installer that will configure your system with the pre-requisite Java, Android and Xamarin tools (including a visual designer for screen layouts). Refer to the Xamarin.Android Installation Guide for detailed instructions.

You can build and test applications on a real device without any license from Google, however to distribute your application through a store (such as Google Play, Amazon or Barnes & Noble) a registration fee may be payable to the operator. Google Play will publish your app instantly, while the other stores have an approval process similar to Apple’s.

Windows

Windows apps (WinForms, WPF, or UWP) are built with Visual Studio. They do not use Xamarin directly. However, C# code can be shared across Windows, iOS and Android. Visit Microsoft’s Dev Center to learn about the tools required for Windows development.

Creating the User Interface (UI)

A key benefit of using Xamarin is that the application user interface uses native controls on each platform, creating apps that are indistinguishable from an application written in Objective-C or Java (for iOS and Android respectively).

When building screens in your app, you can either lay out the controls in code or create complete screens using the design tools available for each platform.

Create Controls Programmatically

Each platform allows user interface controls to be added to a screen using code. This can be very time-consuming as it can be difficult to visualize the finished design when hard-coding pixel coordinates for control positions and sizes.

Programmatically creating controls does have benefits though, particularly on iOS for building views that resize or render differently across the iPhone and iPad screen sizes.

Visual Designer

Each platform has a different method for visually laying out screens:

• iOS – Xamarin's iOS Designer facilitates building Views using drag-and-drop functionality and property fields. Collectively these Views make up a Storyboard, and can be accessed in the .Storyboard file that is included in your project.
• Android – Xamarin provides an Android drag-and-drop UI designer for Visual Studio. Android screen layouts are saved as .AXML files when using Xamarin tools.
• Windows – Microsoft provides a drag-and-drop UI designer in Visual Studio and Blend. The screen layouts are stored as .XAML files.

These screenshots show the visual screen designers available on each platform:

In all cases the elements that you create visually can be referenced in your code.

User Interface Considerations

A key benefit of using Xamarin to build cross platform applications is that they can take advantage of native UI toolkits to present a familiar interface to the user. The UI will also perform as fast as any other native application.

Some UI metaphors work across multiple platforms (for example, all three platforms use a similar scrolling-list control) but in order for your application to ‘feel’ right the UI should take advantage of platform-specific user interface elements when appropriate.Examples of platform-specific UI metaphors include:

• iOS – hierarchical navigation with soft back button, tabs on the bottom of the screen.
• Android – hardware/system-software back button, action menu, tabs on the top of the screen.
• Windows – Windows apps can run on desktops, tablets (such as Microsoft Surface) and phones. Windows 10 devices may have hardware back button and live tiles, for example.

It is recommended that you read the design guidelines relevant to the platforms you are targeting:

• iOS – Apple's Human Interface Guidelines
• Android – Google's User Interface Guidelines
• Windows – User Experience Design Guidelines for Windows

Library and Code Re-Use

The Xamarin platform allows re-use of existing C# code across all platforms as well as the integration of libraries written natively for each platform.

C# Source and Libraries

Because Xamarin products use C# and the .NET framework, lots of existing source code (both open source and in-house projects) can be re-used in Xamarin.iOS or Xamarin.Android projects. Often the source can simply be added to a Xamarin solution and it will work immediately. If an unsupported .NET framework feature has been used, some tweaks may be required.

Examples of C# source that can be used in Xamarin.iOS or Xamarin.Android include: SQLite-NET, NewtonSoft.JSON and SharpZipLib.

Objective-C Bindings + Binding Projects

Xamarin provides a tool called btouch that helps create bindings that allow Objective-C libraries to be used in Xamarin.iOS projects.Refer to the Binding Objective-C Types documentation for details on how this is done.

Examples of Objective-C libraries that can be used in Xamarin.iOS include: RedLaser barcode scanning, Google Analytics and PayPal integration. Open-source Xamarin.iOS bindings are available on github.

.jar Bindings + Binding Projects

Xamarin supports using existing Java libraries in Xamarin.Android. Refer to the Binding a Java Library documentation for details on how to use a .JAR file from Xamarin.Android.

Open-source Xamarin.Android bindings are available on github.

C via PInvoke

"Platform Invoke" technology (P/Invoke) allows managed code (C#) to call methods in native libraries as well as support for native libraries to call back into managed code.

For example, the SQLite-NET library uses statements like this:

C#복사

[DllImport("sqlite3", EntryPoint = "sqlite3_open", CallingConvention=CallingConvention.Cdecl)] public static extern Result Open (string filename, out IntPtr db);

This binds to the native C-language SQLite implementation in iOS and Android. Developers familiar with an existing C API can construct a set of C# classes to map to the native API and utilize the existing platform code. There is documentation for linking native libraries in Xamarin.iOS, similar principles apply to Xamarin.Android.

C++ via CppSharp

Miguel explains CXXI (now called CppSharp) on his blog. An alternative to binding to a C++ library directly is to create a C wrapper and bind to that via P/Invoke.

Xamarin 플랫폼은 iOS 및 Android 용 응용 프로그램을 개발 하는 데 사용할 수 있는 여러 요소로 구성 됩니다.

• language – 친숙 한 구문과 제네릭, LINQ 및 병렬 작업 라이브러리와 같은 고급 기능을 사용할 수 있습니다. C#
• Mono .net framework – Microsoft .net framework의 다양 한 기능에 대 한 플랫폼 간 구현을 제공 합니다.
• 컴파일러 – 플랫폼에 따라 네이티브 앱을 생성 합니다 (예: iOS) 또는 통합 된 .NET 응용 프로그램 및 런타임 (예: Android). 또한 컴파일러는 사용 되지 않은 코드를 연결 하는 것과 같은 모바일 배포에 대해 많은 최적화를 수행 합니다.
• IDE 도구 – Mac 및 Windows의 Visual Studio를 사용 하 여 Xamarin 프로젝트를 생성, 빌드 및 배포할 수 있습니다.

또한 기본 언어는 .NET framework를 C# 사용 하기 때문에 Windows Phone에 배포 될 수 있는 코드를 공유 하도록 프로젝트를 구조화 할 수 있습니다.

내부적으로

Xamarin을 사용 하 여에서 C#앱을 작성 하 고 동일한 코드를 여러 플랫폼에서 공유할 수 있지만 각 시스템의 실제 구현은 매우 다릅니다.

컴파일

소스 C# 는 각 플랫폼에서 매우 다양 한 방식으로 네이티브 앱에 사용 됩니다.

• iOS – C# ARM 어셈블리 언어로 AOT (사전)로 컴파일됩니다. 응용 프로그램 크기를 줄이기 위해 연결 하는 동안 사용 되지 않은 클래스를 제거 하는 .NET framework가 포함 되어 있습니다. Apple은 iOS에서 런타임 코드 생성을 허용 하지 않으므로 일부 언어 기능을 사용할 수 없습니다 ( Xamarin.ios 제한 사항 참조).
• Android – C# IL로 컴파일되고 MonoVM + JIT'ing로 패키지 됩니다. 프레임 워크에서 사용 되지 않는 클래스는 연결 중에 제거 됩니다. 응용 프로그램은 Java/ART (Android 런타임)와 나란히 실행 되며 JNI를 통해 네이티브 형식과 상호 작용 합니다 ( Xamarin.ios 제한 참조).
• Windows – C# IL로 컴파일되고 기본 제공 런타임에 의해 실행 되며 Xamarin 도구가 필요 하지 않습니다. Xamarin의 지침에 따라 Windows 응용 프로그램을 디자인 하면 iOS 및 Android에서 코드를 보다 간단 하 게 다시 사용할 수 있습니다. 또한 유니버설 Windows 플랫폼에는 Xamarin.ios ' AOT 컴파일과 유사 하 게 작동 하는 .NET 네이티브 옵션이 있습니다.

Xamarin.ios 및 xamarin.ios 에 대 한 링커 설명서는 컴파일 프로세스의이 부분에 대 한 자세한 정보를 제공 합니다.

런타임 ' 컴파일 ' –를 사용 하 여 System.Reflection.Emit 동적으로 코드를 생성 하는 것은 피해 야 합니다.

Apple 커널을 사용 하면 iOS 장치에서 동적 코드를 생성할 수 없으므로 Xamarin.ios에서는 코드를 즉시 내보낼 수 없습니다. 마찬가지로 동적 언어 런타임 기능은 Xamarin 도구와 함께 사용할 수 없습니다.

일부 리플렉션 기능이 작동 합니다 (예: Monotouch.dialog은 코드를 생성 하는 것이 아니라 리플렉션 API에 사용 됩니다.

플랫폼 SDK 액세스

Xamarin을 사용 하면 플랫폼별 SDK에서 제공 하는 기능을 친숙 C# 한 구문으로 쉽게 액세스할 수 있습니다.

• ios – Xamarin.ios는 Apple의 CocoaTouch SDK 프레임 워크를 참조할 수 있는 네임 스페이스로 노출 C#합니다. 예를 들어 모든 사용자 인터페이스 컨트롤을 포함 하는 uikit 프레임 워크를 간단한 using UIKit; 문에 포함할 수 있습니다.
• Android – Xamarin android는 Google의 Android SDK를 네임 스페이스로 노출 하므로 사용자 인터페이스 컨트롤에 액세스 using Android.Views; 하는 등의 using 문을 사용 하 여 지원 되는 SDK의 모든 부분을 참조할 수 있습니다.
• Windows – windows 응용 프로그램은 Windows에서 Visual Studio를 사용 하 여 빌드됩니다. 프로젝트 형식에는 Windows Forms, WPF, WinRT 및 UWP (유니버설 Windows 플랫폼)가 포함 됩니다.

개발자를 위한 원활한 통합

Xamarin의 장점에도 불구 하 고, Xamarin.ios 및 Xamarin.ios (Microsoft의 Windows Sdk와 함께 제공)의 차이점에도 불구 하 고, 세 플랫폼 모두에서 다시 C# 사용할 수 있는 코드를 작성 하기 위한 원활한 환경을 제공 합니다.

비즈니스 논리, 데이터베이스 사용, 네트워크 액세스 및 기타 일반 기능을 한 번 작성 하 여 각 플랫폼에서 다시 사용 하 여 네이티브 응용 프로그램으로 표시 하 고 수행 하는 플랫폼별 사용자 인터페이스에 대 한 기초를 제공할 수 있습니다.

IDE (통합 개발 환경) 가용성

Visual Studio의 Mac 또는 Windows에서 Xamarin 개발을 수행할 수 있습니다. 선택한 IDE는 대상 플랫폼에 따라 결정 됩니다.

Windows 앱은 windows 에서만 개발할 수 있으므로 iOS, Android 및 windows 용으로 빌드하려면 Windows 용 Visual Studio가 필요 합니다. 그러나 Windows 및 Mac 컴퓨터 간에 프로젝트와 파일을 공유할 수 있으므로 Mac에서 iOS 및 Android 앱을 빌드할 수 있으며 나중에 Windows 프로젝트에 공유 코드를 추가할 수 있습니다.

각 플랫폼에 대 한 개발 요구 사항은 요구 사항 가이드에 자세히 설명 되어 있습니다.

iOS

IOS 응용 프로그램을 개발 하려면 macOS를 실행 하는 Mac 컴퓨터가 필요 합니다. Visual Studio를 사용 하 여 Visual Studio에서 Xamarin을 사용 하 여 iOS 응용 프로그램을 작성 하 고 배포할 수도 있습니다. 그러나 Mac은 빌드 및 라이선스를 위해 여전히 필요 합니다.

테스트에 대 한 컴파일러 및 시뮬레이터를 제공 하려면 Apple의 Xcode IDE가 설치 되어 있어야 합니다. 자신의 장치에서 무료로테스트할 수 있지만 배포를 위해 응용 프로그램을 빌드할 수 있습니다 (예: 앱 스토어) Apple의 개발자 프로그램 (연간 $99 USD)에 가입 해야 합니다. 응용 프로그램을 제출 하거나 업데이트할 때마다 고객이 다운로드 하는 데 사용할 수 있도록 하려면 먼저 Apple에서 해당 응용 프로그램을 검토 하 고 승인 해야 합니다.

Visual Studio IDE를 사용 하 여 코드를 작성 하 고, 화면 레이아웃을 프로그래밍 방식으로 작성 하거나, 두 IDE에서 Xamarin의 iOS Designer를 사용 하 여 편집할 수 있습니다.

설정 하는 방법에 대 한 자세한 지침은 Xamarin.ios 설치 가이드 를 참조 하세요.

Android

Android 응용 프로그램을 개발 하려면 Java 및 Android Sdk를 설치 해야 합니다. 이는 빌드, 배포 및 테스트에 필요한 컴파일러, 에뮬레이터 및 기타 도구를 제공 합니다. Java, Google의 Android SDK 및 Xamarin 도구는 모두 Windows 및 macOS에 설치 하 고 실행할 수 있습니다. 권장 되는 구성은 다음과 같습니다.

• Visual Studio 2019을 사용 하는 Windows 10
• Mac 용 Visual Studio 2019을 사용 하는 macOS Mojave (10.11 +)

Xamarin은 필수 Java, Android 및 Xamarin 도구 (화면 레이아웃에 대 한 비주얼 디자이너 포함)를 사용 하 여 시스템을 구성 하는 통합 설치 관리자를 제공 합니다. 자세한 지침은 Xamarin Android 설치 가이드 를 참조 하세요.

Google의 라이선스 없이 실제 장치에서 응용 프로그램을 빌드 및 테스트할 수 있지만 스토어 (예: Google Play, Amazon 또는 barnes and & Noble)를 통해 응용 프로그램을 배포 하기 위해 등록 요금은 운영자에 게 지불 될 수 있습니다. Google Play는 앱을 즉시 게시 하 고, 다른 매장에는 Apple과 비슷한 승인 프로세스가 있습니다.

Windows

Windows 앱 (WinForms, WPF 또는 UWP)은 Visual Studio를 사용 하 여 빌드됩니다. Xamarin을 직접 사용 하지 않습니다. 그러나 Windows C# , IOS 및 Android에서 코드를 공유할 수 있습니다. Microsoft 개발자 센터 를 방문 하 여 Windows 개발에 필요한 도구에 대해 알아보세요.

UI(사용자 인터페이스) 만들기

Xamarin을 사용 하는 경우의 주요 혜택은 응용 프로그램 사용자 인터페이스가 각 플랫폼에서 네이티브 컨트롤을 사용 하 여 목표-C 또는 Java (각각 iOS 및 Android 용)로 작성 된 응용 프로그램에서 구별할 수 없는 앱을 만드는 것입니다.

앱에서 화면을 작성 하는 경우 각 플랫폼에 사용할 수 있는 디자인 도구를 사용 하 여 코드에서 컨트롤을 레이아웃 하거나 전체 화면을 만들 수 있습니다.

프로그래밍 방식으로 컨트롤 만들기

각 플랫폼에서 코드를 사용 하 여 사용자 인터페이스 컨트롤을 화면에 추가할 수 있습니다. 이는 컨트롤 위치 및 크기에 대 한 픽셀 좌표를 하드 코딩 하는 경우 완성 된 디자인을 시각화 하기 어려울 수 있기 때문에 시간이 많이 걸릴 수 있습니다.

특히 iPhone 및 iPad 화면 크기를 다르게 조정 하거나 크기를 조정 하는 보기를 빌드하기 위한 iOS의 경우 프로그래밍 방식으로 컨트롤을 만들면 이점이 있습니다.

비주얼 디자이너

각 플랫폼에는 화면 레이아웃을 시각적으로 레이아웃 하는 다른 방법이 있습니다.

• ios – Xamarin의 ios 디자이너는 끌어서 놓기 기능 및 속성 필드를 사용 하 여 뷰를 쉽게 작성할 있습니다. 전체적으로 이러한 뷰는 스토리 보드를 구성 하며에서 액세스할 수 있습니다 . 프로젝트에 포함 된 스토리 보드 파일입니다.
• Android – Xamarin은 Visual Studio 용 android 끌어서 놓기 UI 디자이너를 제공 합니다. Android 화면 레이아웃은로 저장 됩니다 . Xamarin tools를 사용 하는 경우 xml 파일
• Windows – Microsoft는 Visual Studio 및 Blend에서 끌어서 놓기 UI 디자이너를 제공 합니다. 화면 레이아웃은로 저장 됩니다. XAML 파일.

이러한 스크린샷에는 각 플랫폼에서 사용할 수 있는 시각적 화면 디자이너가 나와 있습니다.

모든 경우에서 시각적으로 만드는 요소를 코드에서 참조할 수 있습니다.

사용자 인터페이스 고려 사항

Xamarin을 사용 하 여 플랫폼 간 응용 프로그램을 빌드하는 주요 이점은 네이티브 UI 도구 키트를 활용 하 여 사용자에 게 친숙 한 인터페이스를 제공할 수 있다는 것입니다. 또한 UI는 다른 네이티브 응용 프로그램 만큼 빠르게 수행 됩니다.

일부 UI 메타포는 여러 플랫폼에서 작동 합니다. 예를 들어 세 플랫폼 모두 유사한 스크롤 목록 컨트롤을 사용 합니다. 그러나 응용 프로그램에서 ' 느낌 '이 되도록 하려면 적절 한 경우 UI에서 플랫폼별 사용자 인터페이스 요소를 활용 해야 합니다. 플랫폼별 UI 메타포의 예는 다음과 같습니다.

• iOS – 화면 아래쪽에 있는 탭, 소프트 뒤로 단추를 사용 하 여 계층적 탐색
• Android – 하드웨어/시스템-소프트웨어 뒤로 단추, 작업 메뉴, 화면 맨 위에 있는 탭
• Windows – windows 앱은 데스크톱, 태블릿 (예: Microsoft Surface) 및 휴대폰에서 실행할 수 있습니다. 예를 들어 Windows 10 장치에는 하드웨어 뒤로 단추와 라이브 타일이 있을 수 있습니다.

대상 플랫폼과 관련 된 디자인 지침을 확인 하는 것이 좋습니다.

• iOS – Apple의 휴먼 인터페이스 지침
• Android - Google의 사용자 인터페이스 지침
• Windows - windows에 대 한 사용자 환경 디자인 지침

라이브러리 및 코드 다시 사용

Xamarin 플랫폼을 사용 하면 모든 플랫폼에서 기존 C# 코드를 다시 사용할 수 있을 뿐만 아니라 각 플랫폼에 대해 기본적으로 작성 된 라이브러리를 통합할 수 있습니다.

C#원본 및 라이브러리

Xamarin 제품은 및 .NET C# framework를 사용 하기 때문에 많은 기존 소스 코드 (오픈 소스 및 사내 프로젝트 모두)를 Xamarin.ios 또는 xamarin Android 프로젝트에서 다시 사용할 수 있습니다. 일반적으로 소스는 Xamarin 솔루션에 추가 될 수 있으며 즉시 작동 합니다.지원 되지 않는 .NET framework 기능이 사용 된 경우 약간의 조정 기능이 필요할 수 있습니다.

Xamarin.ios 또는 C# xamarin에서 사용할 수 있는 원본의 예는 다음과 같습니다. SQLite-NET, Newtonsoft.json 및 SharpZipLib.

목표-C 바인딩 + 바인딩 프로젝트

Xamarin은 Xamarin.ios 프로젝트에서 목표 C 라이브러리를 사용할 수 있도록 하는 바인딩을 만드는 데 도움이 되는 btouch 라는 도구를 제공 합니다. 이 작업을 수행 하는 방법에 대 한 자세한 내용은 바인딩 목표-C 형식 설명서 를 참조 하세요.

Xamarin.ios에서 사용할 수 있는 목적-C 라이브러리의 예는 다음과 같습니다. RedLaser 바코드 스캔, Google 분석 및 PayPal 통합.Github에서 오픈 소스 xamarin.ios 바인딩을 사용할 수 있습니다.

.jar 바인딩 + 바인딩 프로젝트

Xamarin은 Xamarin.ios에서 기존 Java 라이브러리를 사용 하도록 지원 합니다. 을 사용 하는 방법에 대 한 자세한 내용은 Java 라이브러리 바인딩 설명서 를 참조 하세요. Xamarin Android의 JAR 파일입니다.

Github에서 오픈 소스 Xamarin Android 바인딩을 사용할 수 있습니다.

PInvoke를 통한 C

"플랫폼 호출" 기술 (P/Invoke)을 통해 관리 코드C#()는 네이티브 라이브러리의 메서드를 호출 하 고 네이티브 라이브러리에서 관리 코드로 다시 호출할 수 있도록 지원 합니다.

예를 들어 SQLite-NET library는 다음과 같은 문을 사용 합니다.

C#복사

[DllImport("sqlite3", EntryPoint = "sqlite3_open", CallingConvention=CallingConvention.Cdecl)] public static extern Result Open (string filename, out IntPtr db);

이는 iOS 및 Android의 네이티브 C 언어 SQLite 구현에 바인딩됩니다. 기존 C API에 익숙한 개발자는 C# 클래스 집합을 생성 하 여 네이티브 API에 매핑하고 기존 플랫폼 코드를 활용할 수 있습니다. Xamarin.ios에서 네이티브 라이브러리를 연결 하는 방법에 대 한 설명서가 있습니다. xamarin에도 유사한 원칙이 적용 됩니다.

C++via CppSharp

Miel el은 블로그의CXXI (현재 CppSharp)에 대해 설명 합니다. C++ 라이브러리에 직접 바인딩하는 대신 C 래퍼를 만들어 P/Invoke를 통해 바인딩할 수 있습니다.

The Application base class offers the following features, which are exposed in your projects default App subclass:

• A MainPage property, which is where to set the initial page for the app.
• A persistent Properties dictionary to store simple values across lifecycle state changes.
• A static Current property that contains a reference to the current application object.

It also exposes Lifecycle methods such as OnStart, OnSleep, and OnResume as well as modal navigation events.

Depending on which template you chose, the App class could be defined in one of two ways:

• C#, or
• XAML & C#

To create an App class using XAML, the default App class must be replaced with a XAML App class and associated code-behind, as shown in the following code example:

XAML복사

<Application xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" x:Class="Photos.App"> </Application>

The following code example shows the associated code-behind:

C#복사

public partial class App : Application { public App () { InitializeComponent (); MainPage = new HomePage (); } ... }

As well as setting the MainPage property, the code-behind must also call the InitializeComponent method to load and parse the associated XAML.

MainPage property

The MainPage property on the Application class sets the root page of the application.

For example, you can create logic in your App class to display a different page depending on whether the user is logged in or not.

The MainPage property should be set in the App constructor,

C#복사

public class App : Xamarin.Forms.Application { public App () { MainPage = new ContentPage { Title = "App Lifecycle Sample" }; // your page here } }

Properties dictionary

The Application subclass has a static Properties dictionary which can be used to store data, in particular for use in the OnStart, OnSleep, and OnResume methods. This can be accessed from anywhere in your Xamarin.Forms code using Application.Current.Properties.

The Properties dictionary uses a string key and stores an object value.

For example, you could set a persistent "id" property anywhere in your code (when an item is selected, in a page's OnDisappearingmethod, or in the OnSleep method) like this:

C#복사

Application.Current.Properties ["id"] = someClass.ID;

In the OnStart or OnResume methods you can then use this value to recreate the user's experience in some way. The Propertiesdictionary stores objects so you need to cast its value before using it.

C#복사

if (Application.Current.Properties.ContainsKey("id")) { var id = Application.Current.Properties ["id"] as int; // do something with id }

Always check for the presence of the key before accessing it to prevent unexpected errors.

 참고

The Properties dictionary can only serialize primitive types for storage. Attempting to store other types (such as List<string>) can fail silently.

Persistence

The Properties dictionary is saved to the device automatically. Data added to the dictionary will be available when the application returns from the background or even after it is restarted.

Xamarin.Forms 1.4 introduced an additional method on the Application class - SavePropertiesAsync() - which can be called to proactively persist the Properties dictionary. This is to allow you to save properties after important updates rather than risk them not getting serialized out due to a crash or being killed by the OS.

You can find references to using the Properties dictionary in the Creating Mobile Apps with Xamarin.Forms book chapters 6, 15, and 20, and in the associated samples.

The Application class

A complete Application class implementation is shown below for reference:

C#복사

public class App : Xamarin.Forms.Application { public App () { MainPage = new ContentPage { Title = "App Lifecycle Sample" }; // your page here } protected override void OnStart() { // Handle when your app starts Debug.WriteLine ("OnStart"); } protected override void OnSleep() { // Handle when your app sleeps Debug.WriteLine ("OnSleep"); } protected override void OnResume() { // Handle when your app resumes Debug.WriteLine ("OnResume"); } }

This class is then instantiated in each platform-specific project and passed to the LoadApplication method which is where the MainPage is loaded and displayed to the user. The code for each platform is shown in the following sections. The latest Xamarin.Forms solution templates already contain all this code, preconfigured for your app.

iOS project

The iOS AppDelegate class inherits from FormsApplicationDelegate. It should:

• Call LoadApplication with an instance of the App class.

• Always return base.FinishedLaunching (app, options);.

C#복사

[Register ("AppDelegate")] public partial class AppDelegate : global::Xamarin.Forms.Platform.iOS.FormsApplicationDelegate // superclass new in 1.3 { public override bool FinishedLaunching (UIApplication app, NSDictionary options) { global::Xamarin.Forms.Forms.Init (); LoadApplication (new App ()); // method is new in 1.3 return base.FinishedLaunching (app, options); } }

Android project

The Android MainActivity inherits from FormsAppCompatActivity. In the OnCreate override the LoadApplication method is called with an instance of the App class.

C#복사

[Activity (Label = "App Lifecycle Sample", Icon = "@drawable/icon", Theme = "@style/MainTheme", MainLauncher = true, ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation)] public class MainActivity : FormsAppCompatActivity { protected override void OnCreate (Bundle bundle) { base.OnCreate (bundle); global::Xamarin.Forms.Forms.Init (this, bundle); LoadApplication (new App ()); // method is new in 1.3 } }

Universal Windows project (UWP) for Windows 10

The main page in the UWP project should inherit from WindowsPage:

XAML복사

<forms:WindowsPage ... xmlns:forms="using:Xamarin.Forms.Platform.UWP" ...> </forms:WindowsPage>

The C# code behind construction must call LoadApplication to create an instance of your Xamarin.Forms App. Note that it is good practice to explicitly use the application namespace to qualify the App because UWP applications also have their own App class unrelated to Xamarin.Forms.

C#복사

public sealed partial class MainPage { public MainPage() { InitializeComponent(); LoadApplication(new YOUR_NAMESPACE.App()); } }

Note that Forms.Init() must be called from App.xaml.cs in the UWP project.

For more information, see Setup Windows Projects, which includes steps to add a UWP project to an existing Xamarin.Forms solution that doesn't target UWP.

Xamarin.Forms App 클래스

Application 기본 클래스에서 제공하여 프로젝트의 기본 App 하위 클래스에 공개되는 기능은 다음과 같습니다.

• MainPage 속성 - 앱의 초기 페이지를 설정할 위치입니다.
• 영구 Properties 사전 - 수명 주기 상태 변경 전반에 걸친 단순 값을 저장합니다.
• 정적 Current 속성 - 현재 애플리케이션 개체에 대한 참조를 포함합니다.

또한 수명 주기 메서드(예: OnStart, OnSleep, OnResume)와 모달 탐색 이벤트도 제공합니다.

선택한 템플릿에 따라 App 클래스는 다음 두 가지 방법 중 하나로 정의할 수 있습니다.

• C# 또는
• XAML 및 C#

XAML을 사용하여 App 클래스를 만들려면 다음 코드 예제와 같이 기본 App 클래스를 XAML App 클래스 및 연결된 코드 숨김으로 바꿔야 합니다.

XAML복사

<Application xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" x:Class="Photos.App"> </Application>

다음 코드 예제에서는 연결된 코드 숨김을 보여 줍니다.

C#복사

public partial class App : Application { public App () { InitializeComponent (); MainPage = new HomePage (); } ... }

MainPage 속성을 설정할 것뿐만 아니라 코드 숨김에서 InitializeComponent 메서드를 호출하여 연결된 XAML을 로드하고 구문 분석해야 합니다.

MainPage 속성

Application 클래스의 MainPage 속성은 애플리케이션의 루트 페이지를 설정합니다.

예를 들어 사용자가 로그인했는지 여부에 따라 다른 페이지를 표시하는 논리를 App 클래스에 만들 수 있습니다.

MainPage 속성은 App 생성자에 설정해야 합니다.

C#복사

public class App : Xamarin.Forms.Application { public App () { MainPage = new ContentPage { Title = "App Lifecycle Sample" }; // your page here } }

속성 사전

Application 하위 클래스에는 데이터를 저장하는 데 사용할 수 있는 정적 Properties 사전이 있으며, 특히 OnStart, OnSleep 및 OnResume 메서드에서 사용할 수 있습니다. 이 하위 클래스는 Application.Current.Properties를 사용하여 Xamarin.Forms 코드의 어느 곳에서나 액세스할 수 있습니다.

Properties 사전은 string 키를 사용하고 object 값을 저장합니다.

예를 들어 다음과 같이 코드의 아무 곳에서(항목이 선택된 경우 페이지의 OnDisappearing 메서드 또는 OnSleep 메서드에서) 영구 "id"속성을 설정할 수 있습니다.

C#복사

Application.Current.Properties ["id"] = someClass.ID;

그러면 OnStart 또는 OnResume 메서드에서 이 값을 사용하여 사용자의 환경을 어떤 방식으로든 다시 만들 수 있습니다. Properties 사전에는 object가 저장되므로 사용하기 전에 해당 값을 캐스팅해야 합니다.

C#복사

if (Application.Current.Properties.ContainsKey("id")) { var id = Application.Current.Properties ["id"] as int; // do something with id }

예기치 않은 오류를 방지하기 위해 키에 액세스하기 전에 키가 있는지 항상 확인하세요.

 참고

Properties 사전은 스토리지에 대한 기본 형식만 직렬화할 수 있습니다. 다른 형식(예: List<string>)을 저장하려고 하면 자동으로 실패할 수 있습니다.

지속성

Properties 사전은 자동으로 디바이스에 저장됩니다. 사전에 추가된 데이터는 애플리케이션이 백그라운드에서 반환되거나 다시 시작된 후에도 사용할 수 있습니다.

Xamarin.Forms 1.4는 Application 클래스에 SavePropertiesAsync() 추가 메서드를 도입했으며, 이 메서드는 Properties 사전을 사전에 유지하기 위해 호출할 수 있습니다. 이렇게 하면 중요한 업데이트 후에 충돌로 인해 직렬화되지 않거나 OS에서 종료하는 위험을 감수하지 않으면서 속성을 저장할 수 있습니다.

Xamarin.Forms를 사용하여 모바일 애플리케이션 만들기 서적의 6, 15 및 20 장과 관련 샘플에서 Properties 사전 사용에 대한 참조를 찾을 수 있습니다.

애플리케이션 클래스

참조에 대한 완전한 Application 클래스 구현은 아래와 같습니다.

C#복사

public class App : Xamarin.Forms.Application { public App () { MainPage = new ContentPage { Title = "App Lifecycle Sample" }; // your page here } protected override void OnStart() { // Handle when your app starts Debug.WriteLine ("OnStart"); } protected override void OnSleep() { // Handle when your app sleeps Debug.WriteLine ("OnSleep"); } protected override void OnResume() { // Handle when your app resumes Debug.WriteLine ("OnResume"); } }

그러면 이 클래스가 각 플랫폼별 프로젝트에서 인스턴스화되고, MainPage가 로드되어 사용자에게 표시되는 LoadApplication 메서드로 전달됩니다. 각 플랫폼에 대한 코드는 다음 섹션에서 보여 줍니다. 최신 Xamarin.Forms 솔루션 템플릿에는 이 코드가 모두 포함되어 있으며 애플리케이션에 맞게 미리 구성되어 있습니다.

iOS 프로젝트

iOS AppDelegate 클래스는 FormsApplicationDelegate에서 상속됩니다. 수행하는 작업은 다음과 같습니다.

• App 클래스의 인스턴스를 사용하여 LoadApplication을 호출합니다.

• 항상 base.FinishedLaunching (app, options);를 반환합니다.

C#복사

[Register ("AppDelegate")] public partial class AppDelegate : global::Xamarin.Forms.Platform.iOS.FormsApplicationDelegate // superclass new in 1.3 { public override bool FinishedLaunching (UIApplication app, NSDictionary options) { global::Xamarin.Forms.Forms.Init (); LoadApplication (new App ()); // method is new in 1.3 return base.FinishedLaunching (app, options); } }

Android 프로젝트

Android MainActivity는 FormsAppCompatActivity에서 상속됩니다. OnCreate 재정의에서 LoadApplication 메서드가 App 클래스의 인스턴스를 사용하여 호출됩니다.

C#복사

[Activity (Label = "App Lifecycle Sample", Icon = "@drawable/icon", Theme = "@style/MainTheme", MainLauncher = true, ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation)] public class MainActivity : FormsAppCompatActivity { protected override void OnCreate (Bundle bundle) { base.OnCreate (bundle); global::Xamarin.Forms.Forms.Init (this, bundle); LoadApplication (new App ()); // method is new in 1.3 } }

Windows 10용 UWP(유니버설 Windows 프로젝트)

UWP 프로젝트의 기본 페이지는 WindowsPage에서 상속됩니다.

XAML복사

<forms:WindowsPage ... xmlns:forms="using:Xamarin.Forms.Platform.UWP" ...> </forms:WindowsPage>

C# 코드 숨김 생성은 LoadApplication을 호출하여 Xamarin.Forms App의 인스턴스를 만들어야 합니다. UWP 애플리케이션에도 Xamarin.Forms와 관련이 없는 자체의 고유한 App 클래스가 있으므로 애플리케이션 네임스페이스를 사용하여 App을 한정하는 것이 좋습니다.

C#복사

public sealed partial class MainPage { public MainPage() { InitializeComponent(); LoadApplication(new YOUR_NAMESPACE.App()); } }

UWP 프로젝트의 App.xaml.cs에서 Forms.Init()가 호출되어야 합니다.

자세한 내용은 UWP를 대상으로 하지 않는 기존 Xamarin.Forms 솔루션에 UWP 프로젝트를 추가하는 단계가 포함된 Windows 프로젝트 설정을 참조하세요.

출처 - 마이크로 소프트

모바일 애플리케이션 빌드는 Visual Studio를 열고, 함께 준비하고, 신속히 테스트하며 앱 스토어에 제출하는 것처럼 손쉽게 수행할 수 있습니다. 모든 작업이 그 날 완료됩니다. 또는 엄격한 사전 설계, 유용성 테스트, 수천 대의 디바이스에서 QA 테스트, 전체 베타 주기 및 여러 가지 다른 방식의 배포가 포함된 매우 복잡한 프로세스일 수 있습니다.

이 문서에서는 다음을 포함하여 모바일 애플리케이션 빌드에 대한 소개를 자세히 살펴보겠습니다.

1. 프로세스 - 소프트웨어 개발 프로세스를 SDLC(소프트웨어 개발 수명 주기)라고합니다. 다음과 같은 모바일 애플리케이션 개발에 관한 SDLC의 모든 단계를 살펴보겠습니다. 개시, 디자인, 개발, 안정화, 배포 및 유지 관리.
2. 고려 사항 – 특히, 기존 웹 또는 데스크톱 애플리케이션과 달리, 모바일 애플리케이션을 빌드할 때는 여러 가지 고려 사항이 있습니다. 이러한 고려 사항과 이러한 고려 사항이 모바일 개발에 주는 영향에 대해 살펴 보겠습니다.

이 문서는 초급 및 고급 애플리케이션 개발자 모두를 대상으로 모바일 앱 개발에 대한 기본적인 질문에 답하기 위해 작성되었습니다.전체 SDLC(소프트웨어 개발 수명 주기) 중에 마주치는 대부분의 개념을 상당히 포괄적인 방식으로 소개합니다. 그러나 이 문서가 모든 사람에게 적절한 것은 아닙니다. 바로 애플리케이션 빌드를 시작하고 싶다면 모바일 개발 소개 가이드로 이동한 다음, 나중에 이 문서를 다시 살펴보는 것이 좋습니다.

모바일 개발 소프트웨어 수명 주기

모바일 개발의 수명 주기는 웹 또는 데스크톱 애플리케이션의 SDLC와 크게 다르지 않습니다. 마찬가지로, 5가지의 프로세스 주요 부분으로 구성됩니다.

1. 개시 – 모든 앱이 이 개념으로 시작됩니다. 이 개념은 일반적으로 애플리케이션의 견고한 기반으로 구체화됩니다.
2. 설계 – 설계 단계는 일반적인 레이아웃이 무엇인지, 어떻게 작동하는지 등과 같은 앱의 UX(사용자 경험)를 정의하고 일반적으로 그래픽 디자이너를 활용해 UX를 적절한 UI(사용자 인터페이스) 디자인으로 바꾸는 것으로 구성됩니다.
3. 개발 – 일반적으로 리소스를 가장 많이 사용하는 단계이며 애플리케이션을 실제 빌드합니다.
4. 안정화 – 개발이 충분히 진행되면 일반적으로 QA를 통해 애플리케이션을 테스트하고 버그를 수정합니다. 종종 애플리케이션은 제한된 베타 단계로 진행되며 이 단계에서 보다 광범위한 대상 사용자에게 애플리케이션을 사용하고 피드백을 제공하며 변경 내용을 알릴 기회가 주어집니다.
5. 배포

이러한 단계는 많은 부분이 겹칩니다. 예를 들어, UI가 완료되는 동안 개발이 진행되는 것이 일반적이며 UI 디자인에 정보를 제공할 수도 있습니다. 또한 애플리케이션은 새로운 기능이 새로운 버전에 추가되는 것과 동시에 안정화 단계에 들어갈 수 있습니다.

이러한 단계는 애자일(Agile), 나선형(Spiral), 폭포수(Waterfall) 등과 같은 다양한 SDLC 방법론에서도 사용할 수 있습니다.

각 단계는 다음 섹션에 서보다 자세히 설명합니다.

개시

모바일 디바이스를 보유하고 있는 사람의 보편화와 상호 작용 수준을 보면, 거의 모든 사람이 모바일 앱에 대한 개념이 있음을 알 수 있습니다. 모바일 디바이스는 컴퓨팅, 웹, 심지어 기업 인프라와도 상호 작용할 수 있는 완전히 새로운 방식입니다.

개시 단계는 앱에 대한 개념을 정의 및 구체화하는 것입니다. 성공적인 앱을 만들려면 몇 가지 기본적인 질문을 하는 것이 중요합니다.다음은 앱을 공개 앱 스토어 중 하나에 게시하기 전에 고려해야 할 몇 가지 사항입니다.

• 경쟁 우위 – 유사한 앱이 이미 있나요? 있다면 이 애플리케이션을 어떻게 차별화할 것인가요?

엔터프라이즈에 배포할 앱의 경우:

• 인프라 통합 – 어떤 기존 인프라와 통합 또는 확장할 계획인가요?

또한 모바일 폼 팩터와 관련해서 앱을 평가해야 합니다.

• 가치 – 이 앱이 사용자에게 어떤 가치를 제공하나요? 사용자는 이 가치를 어떻게 활용하나요?
• 폼/이동성 – 이 앱이 모바일 폼 팩터에서 어떻게 작동하나요? 위치 인식, 카메라 등 모바일 기술을 사용하여 어떻게 가치를 부여할 수 있나요?

앱 기능 설계를 돕기 위해 행위자 및 사용 사례를 정의하는 것이 유용할 수 있습니다. 행위자는 애플리케이션 내에서 역할이며 보통 사용자입니다. 사용 사례는 일반적으로 작업 또는 인텐트입니다.

예를 들어, 애플리케이션을 추적하는 작업은 다음 두 행위자를 포함할 수 있습니다. 사용자 및 Friend. 사용자는 친구와 함께 작업 만들기 및 작업 공유를 할 수 있습니다. 이 경우, 행위자와 함께 작업 만들기 및 작업 공유는 두 가지 구분된 사용 사례이며, 이 사용 사례를 통해 어떤 화면을 빌드해야 하고 어떤 비즈니스 엔터티 및 논리를 개발해야 하는지 알 수 있습니다.

적절한 수의 사용 사례 및 행위자를 캡처했으면 애플리케이션 디자인을 훨씬 쉽게 시작할 수 있습니다. 그러면 개발 시 무슨 앱이며 앱으로 무엇을 해야 하는지보다는, 앱을 만드는 방법에 집중할 수 있습니다.

모바일 애플리케이션 디자인

앱의 특징 및 기능이 결정되면 다음 단계는 UX(사용자 환경)를 해결하는 것입니다.

UX 디자인

UX는 일반적으로 여러 디자인 도구 키트 중 하나를 사용하여 와이어프레임 또는 모형을 통해 수행됩니다. UX 모형을 통해 실제 UI 디자인을 고민할 필요없이 UX를 디자인할 수 있습니다.

UX 모형을 만들 때 앱의 대상이 될 다양한 플랫폼에 대한 인터페이스 지침을 고려하는 것이 중요합니다. 앱은 각 플랫폼에서 “익숙한 방식”이어야 합니다. 각 플랫폼의 공식 디자인 지침은 다음과 같습니다.

1. Apple - 휴먼 인터페이스 지침
2. Android – 디자인 지침
3. UWP – UWP 디자인 기본 내용

예를 들어, 각 앱에는 애플리케이션의 섹션 간 전환을 위한 메타포가 있습니다. iOS는 화면 하단에 탭 표시줄을 사용하고 Android는 화면 상단에 탭 표시줄을 사용하며 UWP는 Pivot 또는 탭 뷰를 사용합니다.

또한 하드웨어 자체는 UX 의사 결정도 지정합니다. 예를 들어 iOS 디바이스에는 물리적 뒤로 단추가 없으므로 탐색 컨트롤러 메타포를 도입합니다.

또한 폼 팩터도 UX 결정에 영향을 줍니다. 태블릿은 훨씬 더 많은 화면 공간을 보유하고 있으므로 더 많은 정보를 표시할 수 있습니다.보통 휴대폰의 여러 화면에 필요한 내용은 태블릿용으로 하나로 압축됩니다.

그리고 수많은 폼 팩터가 있기 때문에 대상으로 지정할 수 있는 중간 크기의 폼 팩터(휴대폰과 태블릿 중간)가 있습니다.

UI(사용자 인터페이스) 디자인

UX가 결정되면 다음 단계는 UI 디자인을 만드는 것입니다. UX는 일반적으로 단순한 흑백 모형이지만 UI 디자인 단계에서는 색상, 그래픽 등을 도입하고 마무리합니다. 좋은 UI 디자인에 시간을 투자하는 것이 중요하며 일반적으로 가장 인기 있는 앱은 디자인이 전문적입니다.

UX와 마찬가지로 각 플랫폼마다 고유한 디자인 언어가 있으므로 잘 디자인된 애플리케이션은 각 플랫폼마다 다르게 나타날 수 있습니다.

개발

일반적으로 개발 단계는 매우 일찍 시작됩니다. 사실, 아이디어가 개념/착안 단계에서 어느 정도 진행되면 기능, 가정을 검증하고 작업 범위를 이해하는 데 도움이 되는 작업 프로토타입이 자주 개발됩니다.

자습서의 나머지 부분에서는 개발 단계에 주로 초점을 둡니다.

안정화

안정화는 앱에서 버그를 찾는 프로세스입니다. 예를 들어, “이 단추를 클릭하면 충돌이 발생합니다”와 같은 기능적 관점뿐만 아니라 유용성 및 성능 관점에서도 해당됩니다. 개발 프로세스 내에서 매우 일찍 안정화를 시작하여 비용이 많이 들기 전에 궤도 수정이 발생하도록 하는 것이 가장 좋습니다. 일반적으로 애플리케이션은 프로토타입, 알파, 베타 및 릴리스 후보 단계를 거칩니다. 사람들마다 다르게 정의하지만 일반적으로 다음과 같은 패턴을 따릅니다.

1. 프로토타입 - 앱은 개념 증명 단계에 있으며 애플리케이션의 핵심 기능이나 특정 부분만 작동합니다. 주요 버그가 있습니다.
2. 알파 – 일반적으로 핵심 기능에 대한 코드가 완성되어 있습니다(빌드되었지만 완전히 테스트되지는 않음). 여전히 주요 버그가 있으며 외부 기능은 아직 없을 수 있습니다.
3. 베타 – 이제 대부분의 기능이 완료되었으며 최소한 가벼운 테스트와 버그 수정을 완료했습니다. 주요 알려진 문제가 여전히 존재할 수 있습니다.
4. 릴리스 후보 – 모든 기능을 완료하고 테스트했습니다. 새로운 버그가 없다면 이 앱은 시장에 릴리스할 후보입니다.

애플리케이션 테스트를 시작하는 것이 결코 이르지 않습니다. 예를 들어, 프로토타입 단계에서 주요 문제가 발견되면 이를 적용하도록 앱의 UX를 계속 수정할 수 있습니다. 알파 단계에서 성능 문제가 발견되면 잘못된 가정 하에 많은 코드를 작성하기 전에 아키텍처를 수정하는 것이 좋습니다.

일반적으로 애플리케이션이 수명 주기에 따라 더 이동함에 따라 더 많은 사람이 애플리케이션을 시험해 보고 테스트하며 피드백을 제공할 수 있도록 합니다. 예를 들어, 프로토타입 애플리케이션은 주요 이해 관계자에게만 표시되거나 제공될 수 있지만 릴리스 후보 애플리케이션은 미리 액세스를 등록하는 고객에게 배포될 수 있습니다.

비교적 적은 수의 디바이스에 대한 초기 테스트 및 배포를 위해 일반적으로 개발 컴퓨터에서 곧바로 배포하는 것으로 충분합니다. 그러나 대상 사용자가 확대됨에 따라 이 작업은 곧 번거로울 수 있습니다. 따라서 테스트 풀에 사람을 초대하고 웹을 통해 빌드를 릴리스하며 사용자 피드백을 허용하는 도구를 제공함으로써 이 프로세스를 훨씬 쉽게 만들어주는 수많은 테스트 배포 옵션을 제공합니다.

테스트 및 배포를 위해 App Center를 사용하여 앱을 지속적으로 빌드, 테스트, 릴리스 및 모니터링할 수 있습니다.

배포

애플리케이션이 안정화되었으면 이제 시장에 내놓을 시간입니다. 플랫폼에 따라 다양한 배포 옵션이 제공됩니다.

iOS

Xamarin.iOS 및 Objective-C 앱은 정확히 동일한 방법으로 배포됩니다.

1. Apple App Store – Apple의 App Store는 iTunes를 통해 Mac OS X에 기본 제공되는 전 세계적으로 사용 가능한 온라인 애플리케이션 리포지토리입니다. 현재 애플리케이션을 위한 가장 널리 사용되는 배포 방법이며, 개발자는 힘들이지 않고도 온라인으로 앱을 마케팅하고 배포할 수 있습니다.
2. 사내 배포 – 사내 배포는 App Store를 통해 공개적으로 제공되지 않는 기업 애플리케이션의 내부 배포를 위한 것입니다.
3. 애드혹 배포 – 애드혹 배포는 주로 개발 및 테스트용으로 사용되며 제한된 수의 올바르게 프로비전된 디바이스에 배포할 수 있도록 해줍니다. Mac용 Xcode 또는 Visual Studio를 통해 디바이스에 배포하는 경우 이를 애드혹 배포라고 합니다.

Android

모든 Android 애플리케이션은 서명된 후 배포되어야 합니다. 개발자는 개인 키로 보호되는 사용자 고유의 인증서를 사용하여 애플리케이션을 서명합니다. 이 인증서는 개발자가 빌드 및 릴리스한 애플리케이션과 애플리케이션 개발자를 연결하는 신뢰성 체인을 제공할 수 있습니다. 공인된 인증 기관에서 Android용 개발 인증서를 서명할 수는 있지만 대부분의 개발자는 이러한 서비스를 활용하지 않고 자신의 인증서를 자체 서명합니다. 인증서의 주요 목적은 서로 다른 개발자와 애플리케이션을 구별하는 것입니다. Android는 이 정보를 사용하여 Android OS 내에서 실행되는 애플리케이션과 구성 요소 간에 권한 위임을 적용하도록 지원합니다.

다른 널리 사용되는 모바일 플랫폼과 달리, Android는 앱 배포에 대해 매우 개방적인 방식을 취합니다. 디바이스는 하나의 승인된 앱 스토어로 국한되지 않습니다. 대신, 누구나 무료로 앱 스토어를 만들 수 있으며 대부분의 Android 휴대폰은 타사 스토어에서 앱을 설치할 수 있습니다.

이를 통해 개발자는 잠재적으로 더 크고 더 복잡한 애플리케이션 배포 채널을 사용할 수 있습니다. Google Play는 Google의 공식 앱 스토어이지만 기타 여러 가지가 있습니다. 널리 사용되는 것은 다음과 같습니다.

1. AppBrain
2. Android용 Amazon App Store
3. Handango
4. GetJar

UWP

UWP 애플리케이션은 Microsoft Store를 통해 사용자에게 배포됩니다. 개발자가 앱을 제출하여 승인을 받으면 해당 앱이 스토어에 표시됩니다. Windows 앱 게시에 대한 자세한 내용은 UWP의 게시 설명서를 참조하세요.

모바일 개발 고려 사항

모바일 애플리케이션을 개발하는 것이 프로세스 또는 아키텍처와 관련하여 기존의 웹/데스크톱 개발과 근본적으로 다른 것은 아니지만 몇 가지 고려해야 할 사항이 있습니다.

일반적인 고려 사항

멀티태스킹

모바일 디바이스에서 멀티태스킹(여러 응용 프로그램을 한 번에 실행)에는 두 가지 중요한 문제가 있습니다. 첫째, 제한된 화면 공간에서는 여러 애플리케이션을 동시에 표시하기 어렵습니다. 따라서 모바일 디바이스에서는 한 번에 하나의 앱만 포그라운드에 있을 수 있습니다. 둘째, 여러 애플리케이션을 열어두고 작업을 수행하면 배터리 전원이 빨리 소모될 수 있습니다.

플랫폼마다 멀티태스킹을 다르게 처리하며, 이 내용은 잠시 후에 살펴볼 것입니다.

폼 팩터

모바일 디바이스는 일반적으로 휴대폰과 태블릿이라는 두 범주로 나뉘며 그 사이에 몇 가지 크로스오버 디바이스가 있습니다. 이러한 폼 팩터 개발은 일반적으로 매우 유사하지만 애플리케이션을 설계하는 것은 매우 다를 수 있습니다. 휴대폰은 화면 공간이 매우 제한되어 있는 반면 태블릿은 이보다 크기는 하지만 대부분의 랩톱보다는 여전히 화면 공간이 적은 모바일 디바이스입니다. 이 때문에 모바일 플랫폼 UI 컨트롤은 소형 폼 팩터에서 효과적으로 작동하도록 특별히 설계되었습니다.

디바이스 및 운영 체제 조각화

전체 소프트웨어 개발 수명 주기에서 다양한 디바이스를 고려하는 것이 중요합니다.

1. 개념화 및 계획 – 하드웨어와 기능은 디바이스마다 다를 수 있으므로 특정 기능을 사용하는 응용 프로그램은 특정 디바이스에서 제대로 작동하지 않을 수 있습니다. 예를 들어, 모든 디바이스에 카메라가 있는 것은 아니므로 화상 채팅 응용 프로그램을 제작하는 경우 일부 디바이스는 동영상을 재생할 수는 있지만 촬영할 수는 없습니다.
2. 디자인 – 응용 프로그램의 UX(사용자 경험)를 디자인할 때는 여러 디바이스의 다양한 화면 비율과 크기에 주의를 기울여야 합니다. 또한 애플리케이션의 UI(사용자 인터페이스)를 디자인할 때 서로 다른 화면 해상도를 고려해야 합니다.
3. 개발 – 코드의 기능을 사용할 때 먼저 해당 기능의 존재 여부를 항상 테스트해야 합니다. 예를 들어, 카메라와 같은 디바이스 기능을 사용하기 전에 항상 OS에서 해당 기능의 존재 여부를 먼저 쿼리합니다. 그런 다음, 기능/디바이스를 초기화할 때 OS에서 해당 디바이스에 대한 현재 지원을 요청한 다음, 해당 구성 설정을 사용해야 합니다.
4. 테스트 – 실제 디바이스에서 조기에 자주 응용 프로그램을 테스트하는 것이 매우 중요합니다. 동일한 하드웨어 사양을 포함하는 디바이스조차도 동작이 매우 다양할 수 있습니다.

제한된 리소스

모바일 디바이스는 갈수록 점점 더 강력해지고 있지만 데스크톱이나 노트북 컴퓨터에 비해 기능이 제한적인 모바일 디바이스입니다.예를 들어, 데스크톱 개발자는 일반적으로 메모리 용량에 대해 걱정하지 않습니다. 이들은 보통 실제 메모리와 가상 메모리 모두를 충분히 사용합니다. 그러나 모바일 디바이스에서는 고화질 사진 몇 장만 로드해도 순식간에 사용 가능한 모든 메모리를 소비할 수 있습니다.

또한 게임이나 텍스트 인식과 같은 프로세서를 많이 사용하는 응용 프로그램은 실제로 모바일 CPU에 부담을 주고 디바이스 성능에 부정적인 영향을 미칠 수 있습니다.

이와 같은 고려 사항 때문에 응답성을 검증하기 위해 현명하게 코드를 작성하고 실제 디바이스에 조기에 자주 배포하는 것이 중요합니다.

iOS 고려 사항

멀티태스킹

멀티태스킹은 iOS에서 매우 엄격하게 제어되며 다른 애플리케이션이 포그라운드로 오면 애플리케이션이 따라야 하는 규칙과 동작이 많습니다. 그렇지 않으면 애플리케이션이 iOS에 의해 종료됩니다.

디바이스별 리소스

특정 폼 팩터 내에서 하드웨어는 여러 모델 간에 크게 다를 수 있습니다. 예를 들어, 일부 디바이스에는 후면 카메라가 있고 일부는 전면 카메라가 있으며 어떤 디바이스는 아무 것도 없습니다.

일부 이전 디바이스(iPhone 3G 이하)는 멀티태스킹도 허용하지 않습니다.

이러한 디바이스 모델 간 차이점으로 인해 기능을 사용하기 전에 해당 기능이 존재하는지 확인하는 것이 중요합니다.

OS 관련 제약 조건

애플리케이션이 잘 응답하고 안전한지 확인하기 위해 iOS는 애플리케이션이 준수해야 하는 여러 가지 규칙을 시행합니다. 멀티태스킹과 관련된 규칙 외에도, 앱이 특정 시간 내에 반환해야 하는 여러 가지 이벤트 메서드가 있습니다. 특정 시간 내에 반환하지 않으면 iOS에서 종료됩니다.

또한 주목할 만한 것은 앱이 액세스할 수 있는 것을 제한하는 보안 제약 조건을 적용하는 샌드박스라는 환경에서 실행된다는 것입니다. 예를 들어, 앱은 자체 디렉터리에서 읽고 쓸 수 있지만 다른 앱 디렉터리에 쓰기를 시도하면 종료됩니다.

Android 고려 사항

멀티태스킹

Android의 멀티태스팅에는 두 구성 요소가 있습니다. 첫 번째는 작업 수명 주기입니다. Android 애플리케이션의 각 화면은 작업으로 표시되며, 애플리케이션이 백그라운드에 배치되거나 포그라운드로 들어올 때 발생하는 특정 이벤트 집합이 있습니다. 응답성이 좋고 올바르게 동작하는 애플리케이션을 만들려면 애플리케이션이 이 수명 주기를 준수해야 합니다. 자세한 내용은 작업 수명 주기 가이드를 참조하세요.

Android에서 멀티태스킹에 대한 두 번째 구성 요소는 서비스 사용입니다. 서비스는 애플리케이션과 독립적으로 존재하며 애플리케이션이 백그라운드에서 실행되는 동안 프로세스를 실행하는 데 사용되는 장기 실행 프로세스입니다. 자세한 내용은 서비스 만들기 가이드를 참조하세요.

많은 디바이스 및 많은 폼 팩터

Google은 Android OS를 실행할 수 있는 디바이스에 제한을 두지 않습니다. 이 개방적 패러다임은 매우 다른 하드웨어, 화면 해상도 및 비율, 디바이스 기능 및 성능을 갖춘 수많은 다양한 디바이스로 채워지는 제품 환경을 만들어냅니다.

Android 디바이스의 극단적인 조각화로 인해 대부분의 사람들은 가장 인기 있는 5개 또는 6개의 디바이스를 선택하여 디자인, 테스트 및 우선 순위를 지정합니다.

보안 고려 사항

Android OS의 애플리케이션은 모두 제한된 권한을 사용하여 별개의 격리된 ID로 실행됩니다. 기본적으로 애플리케이션은 할 수 있는 것이 거의 없습니다. 예를 들어, 특별한 권한이 없다면 애플리케이션은 문자 메시지를 보내거나 휴대폰 상태를 확인하거나 인터넷에 액세스할 수 없습니다! 이러한 기능에 액세스하려면, 애플리케이션은 애플리케이션 매니페스트 파일에 원하는 사용 권한과 설치 시기를 지정해야 합니다. OS는 이러한 권한을 읽고 애플리케이션이 해당 권한을 요청하고 있음을 사용자에게 알린 다음, 사용자가 설치를 계속하거나 취소할 수 있도록 합니다. 애플리케이션이 iOS와 같은 방식으로 큐레이트되지 않기 때문에 개방형 애플리케이션 스토어 모델로 인해 Android 배포 모델에서 필수적인 단계입니다. 애플리케이션 권한 목록은 Android 설명서의 매니페스트 권한 참조 문서를 참조하세요.

Windows 고려 사항

멀티태스킹

UWP의 멀티태스킹은 페이지 및 애플리케이션에 대한 수명 주기와 백그라운드 프로세스라는 두 부분으로 구성됩니다. 애플리케이션의 각 화면은 활성 또는 비활성(비활성 상태를 처리하거나 “삭제 표시”하는 특수 규칙이 있음)과 관련된 이벤트가 있는 Page 클래스의 인스턴스입니다.

두 번째 부분은 애플리케이션이 포그라운드에서 실행되지 않는 경우에도 작업 처리를 위한 백그라운드 에이전트를 제공합니다.

디바이스 성능

UWP 하드웨어는 유형이 거의 같지만 여전히 선택적인 구성 요소이므로 코딩하는 동안 특별한 고려 사항이 요구됩니다. 옵션 하드웨어 기능으로는 카메라, 나침반 및 자이로스코프가 있습니다. 특별 고려 사항이 필요한 특수한 종류의 저용량 메모리(256MB)가 있거나 개발자가 메모리 부족 지원을 제외할 수 있습니다.

보안 고려 사항

UWP의 중요한 보안 고려 사항에 대한 자세한 내용은 보안 설명서를 참조하세요.

요약

이 가이드에서는 모바일 개발과 관련하여 SDLC에 대한 소개를 제공했습니다. 모바일 애플리케이션 빌드에 대한 일반적인 고려 사항을 소개하고 설계, 테스트 및 배포를 비롯한 다양한 플랫폼별 고려 사항도 살펴보았습니다.

출처 - 마이크로 소프트

What is Xamarin?

Building mobile apps can be as easy as opening up the IDE, writing and testing an app, and submitting to an App Store – all done in an afternoon. Or it can be an extremely involved process that involves rigorous up-front design, usability testing, QA testing on thousands of devices, a full beta lifecycle, and then deployment a number of different ways.

This document introduces the Xamarin platform. To learn more about the process of building mobile applications from design through to testing, see Introduction to the Mobile Software Development Lifecycle.

See system requirements to confirm your system.

Introduction to Xamarin

When considering how to build Android and iOS applications, many people think that the native languages, Objective-C, Swift, Java, and Kotlin, are the only choice.

Xamarin allows you develop in C#, with a class library and runtime that works across all many platforms, including iOS, Android, and Windows, while still compiling native (non-interpreted) applications that are performant enough even for demanding games.

Xamarin combines all of the abilities of the native platforms and adds a number of powerful features of its own, including:

1. Complete Binding for the underlying SDKs – Xamarin contains bindings for nearly the entire underlying platform SDKs in both iOS and Android. Additionally, these bindings are strongly-typed, which means that they’re easy to navigate and use, and provide robust compile-time type checking and during development. This leads to fewer runtime errors and higher-quality apps.
2. Objective-C, Java, C, and C++ Interop – Xamarin provides facilities for directly invoking Objective-C, Java, C, and C++ libraries, giving you the power to use a wide array of 3rd party code that has already been created. This lets you take advantage of existing iOS and Android libraries written in Objective-C, Java, or C/C++. Additionally, Xamarin offers binding projects that allow you to easily bind native Objective-C and Java libraries using a declarative syntax.
3. Modern Language Constructs – Xamarin applications are written in C#, a modern language that includes significant improvements over Objective-C and Java such as *Dynamic Language Features, Functional Constructs such as *Lambdas, *LINQ,Parallel Programming features, sophisticated *Generics, and more.
4. Amazing Base Class Library (BCL) – Xamarin applications use the .NET BCL, a large collection of classes that have comprehensive and streamlined features such as powerful XML, Database, Serialization, IO, String, and Networking support, and more. Existing C# code can be compiled for use in an app, which provides access to thousands of libraries that allow you do things that aren’t covered in the BCL.
5. Modern Integrated Development Environment (IDE) – Xamarin uses Visual Studio for Mac on macOS and Visual Studio on Windows. These are both modern IDEs that include features such as code auto completion, a sophisticated Project and Solution management system, a comprehensive project template library, integrated source control, and many others.
6. Mobile Cross Platform Support – Xamarin offers sophisticated cross-platform support for the three major mobile platforms of iOS, Android, and Windows. Applications can be written to share up to 90% of their code, and our Xamarin.Mobile library offers a unified API to access common resources across all three platforms. This can significantly reduce both development costs and time to market for mobile developers that target the three most popular mobile platforms.

Because of Xamarin’s powerful and comprehensive feature set, it fills a void for application developers that want to use a modern language and platform to develop cross-platform mobile applications.

 참고

This Get Started series focuses on getting started building iOS and Android applications. Microsoft offers information about Universal Windows Platform (UWP) development for tablets and desktops. To learn more about cross-platform development with Xamarin (including UWP apps for Windows), read the Building Cross-Platform Applications guide.

How does Xamarin work?

Xamarin offers two commercial products: Xamarin.iOS and Xamarin.Android. They’re both built on top of Mono, an open-source version of the .NET Framework based on the published .NET ECMA standards. Mono has been around almost as long as the .NET framework itself, and runs on nearly every imaginable platform including Linux, Unix, FreeBSD, and macOS.

On iOS, Xamarin’s Ahead-of-Time ( AOT) Compiler compiles Xamarin.iOS applications directly to native ARM assembly code. On Android, Xamarin’s compiler compiles down to Intermediate Language ( IL), which is then Just-in-Time ( JIT) compiled to native assembly when the application launches.

In both cases, Xamarin applications utilize a runtime that automatically handles things such as memory allocation, garbage collection, underlying platform interop, etc.

Xamarin.iOS.dll and Mono.Android.dll

Xamarin applications are built against a subset of the .NET BCL known as the Xamarin Mobile Profile. This profile has been created specifically for mobile applications and packaged in the Xamarin.iOS.dll and Mono.Android.dll (for iOS and Android respectively). This is much like the way Silverlight (and Moonlight) applications are built against the Silverlight/Moonlight .NET Profile. In fact, the Xamarin Mobile profile is equivalent to the Silverlight 4.0 profile with a bunch of BCL classes added back in.

For a full list of available assemblies and classes, see the Xamarin.iOS Assembly List and the Xamarin.Android Assembly List

In addition to the BCL, these .dlls include wrappers for nearly the entire iOS SDK and Android SDK that allows the underlying SDK APIs to be invoked directly from C#.

Application output

When Xamarin applications are compiled, the result is an Application Package, either an .app file in iOS, or .apk file in Android. These files are indistinguishable from application packages built with the platform's default IDEs and are deployable in the exact same way.

Next steps

Now you've learned a little about how Xamarin works, the next step is to start building an app using one of these guides:

• Get started with Xamarin.Forms
• Get started with Xamarin.iOS
• Get started with Xamarin.Android
• Get started with Xamarin.Mac