When the following error occurs like this

"oracle input pattern or replacement parameters exceed 32K size limit ... CLOB ..."

 

CREATE OR REPLACE FUNCTION REPLACE_CLOB( p_origin                          IN CLOB
                                	, p_search_text                     IN VARCHAR2
                                	, p_replace                         IN CLOB
) 
RETURN CLOB 
IS
    l_pos pls_integer;
    out_replace_clob CLOB := p_origin;
BEGIN
    l_pos := instr(p_origin, p_search_text);

    IF l_pos > 0 THEN
        WHILE l_pos > 0 LOOP
            out_replace_clob := substr(out_replace_clob, 1, l_pos-1)
            || p_replace
            || substr(out_replace_clob, l_pos + LENGTH(p_search_text));

            l_pos := instr(out_replace_clob, p_search_text);
        END LOOP;
        RETURN out_replace_clob;
    END IF;

    RETURN p_origin;
END REPLACE_CLOB;

-- v_huge_sql := REPLACE_CLOB(v_huge_sql, '[[REPLACE_LOCATION_IN_QUERY]]'    , v_huge_replace_text);

 

be the happy Gosu.

woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

반응형
LIST
Posted by woojja

댓글을 달아 주세요

The maximum number of columns allowed in a table of ORACLE are 1000.

(in 8i, 9i, 10g, 11g, 12c, 18c and 19c)

(ORACLE 7 had 254 columns limit.)

 

be the happy Gosu.

woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

반응형
LIST
Posted by woojja

댓글을 달아 주세요

The following syntax converts a DataTable to a Dictionary .

 

in C#

Dictionary<string, string> dicCodes = ds.Tables[0].AsEnumerable()
                                    .ToDictionary<DataRow, string, string>(
                                        row => row.Field<string>("Column1Name"),
                                        row => row.Field<string>("Column2Name")
                                    );

 

in VB.NET

Dim dicCodes As Dictionary(Of String, String) =
    ds.Tables(0).AsEnumerable() _
    .ToDictionary(Of String, String)(
                                        Function(row) row.Field(Of String)("Column1Name"),
                                        Function(row) row.Field(Of String)("Column2Name")
                                    )

 

be the happy Gosu.

woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

반응형
LIST

'.NET' 카테고리의 다른 글

[.NET] DataTable to Dictionary using Linq  (0) 2022.01.14
[.NET] .NET MAUI 를 소개합니다.  (0) 2021.11.26
[.NET] Time Zone Identifiers  (2) 2018.07.24
[.NET] Clone  (0) 2017.05.31
[.NET] Collection was modified; enumeration operation may not execute.  (4) 2017.05.30
[.NET] .NET Core Roadmap  (0) 2017.02.10
Posted by woojja

댓글을 달아 주세요

이미지 관련 Web Site 가 있어 소개합니다. Web Api 도 있고요.

https://javascript.plainenglish.io/17-killer-websites-for-web-developers-13e1e30345b8

첫번째로 Storytale 입니다.

 

https://storytale.io/

 

Storytale — High-class web illustrations under simple subscription

Huge library of stylish illustrations that grows every week. You can get them all by yearly subscription and download any illustrations you want for commecial and personal projects.

storytale.io

 

두번째로는 Unsplash Source 입니다. 이곳은 Web api 입니다.

 

https://source.unsplash.com/

 

Unsplash Source

A simple API for embedding free high-resolution photos from Unsplash.

source.unsplash.com

 

세번째로는 pfpmaker 입니다.

간단히 프로필 사진을 만들어 보세요.

https://pfpmaker.com/

 

Free Profile Picture Maker - Create an awesome profile pic from any photo

Easily create a perfect profile picture and get 14x times more views & 36x times more chances to receive a message. Upload your photo and instantly get dozens of designs generated with AI

pfpmaker.com

 

행복한 고수되십시오.

woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

반응형
LIST

'ETC > Free Resources' 카테고리의 다른 글

[Free Resources] 유용한 Image 관련 Web Sites  (0) 2021.12.14
[Free Resources] Build-your-own-x  (0) 2021.08.23
[Free Resources] Awesome CS Courses  (0) 2021.08.23
Posted by woojja

댓글을 달아 주세요

다음 글은 https://www.codemag.com/Article/2111082/An-Introduction-to-.NET-MAUI의 글을 번역했습니다.

 

An Introduction to .NET MAUI

You’ve been using Xamarin for years. Steven shows how the .NET Multi-platform App UI (.NET MAUI) hasn't just kept up with everything, but how it compare...

www.codemag.com

 

Microsoft 환경에서 모바일 개발을 해본적이 있습니까? 그럼 아마도 Xamarin 을 들어봤을 겁니다. Xamarin 기술은 Xamarin 이라는 회사에 의해 2011년 구축되었으며 2016년 Microsoft 가 Xamarin 사를 인수한 이후부터 Microsoft 의 모바일개발 주력 제품이 되었습니다.

Xamarin 은 개발자가 VisualStudio 상에서 C# 코드를 사용하여 IOS, Android, UWP 용 Application 을 개발할 수 있도록 해줍니다. platform-specific 한 작업을 제외한 모든 작업을 shared codebase 에서 수행합니다. 즉, 여러분이 원하는 작업의 대부분을 단일 공유라이브러리 상에서 작성할 수 있습니다.

Xamarin.Forms 의 출현으로 shared codebase 위에 추가로 XAML 을 이용하여 User interface 를 정의할 수 있는 abstraction layer 가 제공되었습니다. 개발경험을 개선하기 위해 Microsoft 는 몇년동안 많은 도구들을 추가로 만들어 Xamarin 을 모바일 개발자를 위한 완벽한 제품으로 만들었습니다. 이런 노력의 자연스런 다음 단계로 2020 년 .NET Multi-platform App UI (.NET MAUI) 라는 형식을 소개하였습니다. 이번 Article 에서는 .NET MAUI 가 무엇인지 Xamarin.Forms 에 비교해서 무엇이 크게 변경이 되었는지에 관해 자세히 알아보겠습니다.

 

.NET MAUI 란 무엇인가?

.NET MAUI 는 현재 Xamarin.Forms 로 부터 진화했습니다. IOS, Android 와 같은 다양한 형태의 Workload 들이 이제 .NET 의 일부인 Single .NET 6 Base Class Library (BCL) 에 존재합니다. 그래서 여러분의 코드에서 사용되는 기본 platform 의 세부정보를 효과적으로 추상화합니다. 여러분의 App 이 IOS, Android, MacOS 에서 실행된다면 일관된 API 와 동작을 제공하기위해서 Common BCL 에 의존하며, Window 상에서 작동하는 App 이라면 이를 처리하는 .NET Runtime 은 CoreCLR 입니다.
이런 BCL 을 사용하면 다른 platform 에서 동일한 Sared code 를 실행할 수 있지만 User interface definition(정의)을 공유할 수는 없습니다. 그래서 UI 추상화에 따른 추가적인 Layer 의 필요성은 하나의 문제점으로 이를 .NET MAUI 가 해결할 것이며 다양한 추가적인 Desktop Scenario 로 나타납니다(branching out).
아키텍쳐관점에서 보면 여러분이 작성하는 대부분의 코드들은 Figure 1 에 보이는 다이어그램의 상위 두 layer 와 상호작용합니다. .NET MAUI layer 는 아래 Layer 들과의 통신을 처리합니다. 하지만 platform-specific 한 기능에 접근해야하는 경우 해당 layer 의 호출을 막지않습니다.

 

Figure 1 : .NET MAUI Architecture

.NET MAUI 로 바꾸는 것은 Xamarin.Forms 팀에게도 8 년이나 된 Toolkit 들을 처음부터 Rebuild 하고 그동안 주저했던 낮은 수준의 이슈들을 해결할 수있는 기회라고 할 수 있습니다. 성능과 확장을 위한 Redesigning 은 이런 노력의 필수적인 부분입니다. 전세계의 많은 회사들이 Xamarin 을 사용하고 있습니다. 그래서 현재의 Toolkit 을 빠르게 변경하는 것은 거의 불가능합니다. 예전에 Xamarin.Forms 를 이용하여 cross-platform UserInterface 를 Build 한 경험이 있다면, .NET MAUI 에 대해 공부할때 많은 유사점을 알수있습니다. 그래도 살펴볼만한 몇가지 차이점이 있습니다.

 

새로운 Handler Infrastructure

여러분이 이미 Xamarin.Forms 개발을 해본 경험이 있다면, renderer 라는 개념을 알고 있을 것입니다. renderer 는 각 platform 에 맞게 일관된 방식으로 화면에 특정 Control 을 렌더링하는 코드입니다. 개발자는 특정 platform 의 특정 타입의 control 을 지정할 수 있으며 built-in behavior 를 재정의 할 수 있는 custom renderer 를 생성할 수 있습니다. 예를 들어, Android 입력 field 의 아래밑줄을 제거하고 싶다면 모든 fielsd 에 적용되는 단일 사용자 지정 renderer(Single custom renderer) 를 작성하기만 하면 됩니다.
.NET MAUI 에서 renderer 의 개념은 더이상 사용하지 않지만, 현재 사용하는 renderer 를 .NET MAUI 로 가져오는 것은 호환성 API 를 통해 가능합니다. 앞으로 Handler 는 renderer 를 완전히 대체할 것입니다. 하지만 왜? 현재 Xamrin.Forms 구현에는 대안의 접근방식(alternative approach)으로 개발을 해야했던 몇가지 근본적인 architectural 한 문제(underlying architectural issues)가 있습니다.

renderer 와 control 은 Xamarin.Forms 내에서 아주 밀접하게 연결되어 (tightly coupled) 있어서 이상적이지 않습니다.

사용자 지정 renderer (custom renderer) 를 어셈블리수준에서 등록(register)한다는 말은 platform 이 모든 control 을 어셈블리 스캔하여 앱이 시작하는 동안 사용자지정 renderer 를 적용해야해야 하는지를 확인한다는 것을 의미합니다. 이런 동작은 상대적으로 말하면 느린 프로세스라고 할 수 있습니다. 게다가 Xamarin.Forms platform renderer 는 성능에 영향을 미치는 추가적인 view element 도 삽입합니다.

Xamarin.Forms 는 여러 platform (multiple different platform) 의 상단에 위치한 추상화 layer 입니다. 이 가상화로 인해 간혹 renderer 범위내에서 변경하는 방법으로 platform-specific 한 코드에 접근해는 것이 매우 어려울 수 있습니다. Private method 로 지정하면 여러분이 구현한 Code 가 차단(block) 될 수 있습니다. Xamarin.Forms 팀은 이 문제를 해결하기위해서 platform-specific API 와 같은 추가적인 구성을 구축했지만 이 API 사용법은 일반적으로 사용자에게 명확하지 않습니다.

사용자지정 renderer 를 생성은 그리 직관적이지 않습니다. 잘 알려져 있지 않은 base renderer type 을 상속해야하고 잘 알려져 있지 않은 method 를 재정의 해야합니다. 여러분이 만든 custom renderer 가 control 의 특정 instance 에만 적용되도록 하고 싶다면, custom type (e.g CustomButton 과 같은) 을 생성하고, renderer 를 지정해야하며 일반 Button 대신 해당 control 을 사용해야합니다. 이런 방식은 불필요한 code overhead 가 발생합니다.

이 모든 내용들이 개선해야할 좋은 이유처럼 들리지만 왜 지금 변경해야할 까요? platform 을 재구성(reshaping)할 수 있는 이런 기회와 함께 약간의 약간 골치아픈부분이었던 이런 근본적인 개념을 다시 생각(rethinking)할 수 있는 기회가 된 것입니다. renderer 하나만 놓고 봤을 때 성능, API 단순화 그리고 균질화 측면에서 이득이 큽니다.

 

기본 Infrastructure 재구성

기본 Infrastructure 재구성의 첫 단계는 control 간의 강한 연결을 제거하는 것입니다. .NET MAUI 팀은 control 들을 interface 뒤에 두고 각 component 는 interface 를 통해 상호작용하도록 구현하였습니다. 이런 방식은 IButton 과 같은 무언가를 다르게 구현하는 것을 쉽게합니다. 동시에 기본 Infrastructure 가 모든 구현사항들이 동일한 방식으로 처리하는지 확인합니다. Figure 2 는 이를 개념적 관점으로 보여줍니다.

 

Figure 2 : Control 구현에서 강한 연결(tight coupling)제거를 위한 추상화

reflection 을 이용한 assembly scan 을 방지하기 위해서 팀은 handler 등록하는 방식을 변경하기로 결정했습니다. Attribute 로 assembly level 에서 등록하는 대신 handler 는 platform 에 의해 명시적으로 등록합니다. 그리고 이제 startup 코드에서 모든 custom handler 를 등록할 수 있습니다. 이 Article 후반부에서 작업방법을 다루겠지만 그렇게하면 startup 시 발생하는 assembly scanning panalty 를 제거합니다.

native platform 깊숙히 숨겨진 것을 쉽게 접근할 수 있도록 만들기 위해 팀은 mapper dictionary 를 정의하는 접근 방식을 채택했습니다. mapper 는 native view object 에 곧바로 접근 할 수 있게 하는 특정 control 의 interface 에 정의된 속성(properties) (그리고 action) 가 있는 dictionary 입니다. 이 native view object 를 올바른 Type 으로 형변환(casting) 하면 여러분이 작성한 shared code 에서 platform-specific code 로 즉시 접근 할 수 있도록 합니다. 다음 sample 은 generic view 에 대해 mapper dictionary 를 호출하는 방법과 platform-specific code 를 이용하여 배경색을 설정하는 방법을 보여 줍니다. 또한 native view 에 접근하는 방법을 보여줍니다.

 

#if __ANDROID__

ViewHandler.ViewMapper[nameof(IView.BackgroundColor)] =
    (h, v) => (h.NativeView as AView).SetBackgroundColor(Color.Green);

var textView = label.Handler.NativeView;

#endif

 

이 sample 에서 배경색에 접근하기 위해서 generic ViewHandler 를 사용하는데 이는 각 view 가 background 속성(property)을 가지고 있기 때문입니다. 여러분이 필요한 상세수준에 따라 ButtonHandler 같은 더욱 specific한 handler 를 사용할 수도 있습니다. 그렇게하면 native button control 을 직접 노출하기 때문에 형변환할 필요가 없습니다. 이 새로운 mapper dictionary 덕분에 기존의 built-in platform-specific API 는 더이상 사용되지 않습니다. 다음은 어떻게 기존 custom renderer 를 handler 로 변경하여 현재 존재하는 overhead 를 어떻게 개선하는지 살펴보도록 하겠습니다.

 

Randerer 와 Handler 의 차이점

Xamarin.Forms renderer 의 구현은 기본적으로 native control 의 platform-specific 한 구현입니다. renderer 를 생성하려면 다음 단계를 수행합니다 : 

 

원하는 control 의 하위 class (subclass) 로 지정합니다. 이 것은 필수는 아니지만 따를만한 규칙입니다.
control 내에 필요한 public property 들을 생성합니다.
native control 생성을 담당하는 ViewRenderer 의 subclass 를 생성합니다.
control 을 customize 하기 위해 OnElementChanged 를 재정의(override) 합니다. 이 method 는control 이 화면에 생성될 때 호출됩니다.
특정 속성(property) 의 값이 변경되었을 때  대상으로 지정하려면 OnElementPropertyChanged 를 재정의합니다.
ExportRenderer assembly attribute 를 추가하여 Scan 가능하게 합니다.
여러분이 작성한 XAML 에 새로 만든 custom control 을 사용합니다.

 

.NET MAUI 를 사용하여 동일한 control 을 만드는 방법을 살펴봅시다. handler 를 생성하는 과정은 다음과 같습니다 :

 

native control 생성을 담당하는 ViewHandler class 의 subclass 를 생성합니다.
native control 을 rendering 하는 CreateNativeView method 를 재정의합니다.
property 변경에 응답(respond)할 mapper dictionary 를 생성합니다.
startup class 에 handler 를 등록(register)합니다.

 

둘 사이에 유사점이 있지만 .NET MAUI 구현이 훨씬 더 간결합니다. .NET MAUI 내부의 일부 변경으로 인해 custom renderer 를 사용할 때 함께 따라오던 많은 기술적인 사항들도정리되었습니다. handler infrastructure 의 architecture 를 Figure 3 에 요약했습니다. 이 sample 은 button 이 device 화면에 rendering 되기 위해 통과하는 layer 들을 보여줍니다.

 

Figure 3 : .NET MAUI handler Architecture

 

Handler 구현

custom handler 를 구현하기 위해서 control-specific 한 interface 부터 생성합니다. 앞에서 말했던 것 처럼 control 과 handler 사이에 느슨하게 결합(loosly coupled)하도록 할 겁니다. cross-platform control 에 대한 참조가 유지되는 것을 피하기 위해서 여러분이 생성한 control 을 위한 interface 가 필요합니다.

 

public interface IMyButton : IView
{
    public string Text { get; }
    public Color TextColor { get; }
    void Completed();
}

 

여러분이 만들 custom control 이 이 interface 를 구현하면 여러분이 만든 handler 에서 이 control 의 특정 type 을 지정할 수 있습니다.

 

public class MyButton : View, IMyButton
{
}

 

그 다음, platform-specific 한 동작(behavior) 을 원하는 각 platform 에서 위에서에 정의한 interface 를 대상으로 하는 handler 를 생성합니다. 이 sample 에서는 IOS 의 native button 구현인 Apple 의 UIButton control 을 대상(target) 으로 합니다. 

 

public partial class MyButtonHandler : ViewHandler<IMyButton, UIButton>
{
}

 

이 handler 가 ViewHandler 를 상속하고 있기때문에 CreateNativeView 를 구현해야합니다.

 

protected override UIButton CreateNativeView()
{
    return new UIButton();
}

 

기본 값을 재정의하고 객체가 생성되기전에 native control 과 상호작용하기위해 이 method를 사용하는 것이 가능합니다. 그렇게 하면 이전에 custom renderer 에서 수행했던 많은 작업들을 설정하는 것이 가능합니다. 다양한 시나리오를 처리하기위한 추가적인 method 들이 존재하지만 이 Article 에서는 다루지 않겠습니다.

 

Mapper 작업

 

이 Article 앞부분에서 언급한 Mapper 는 Xamarin.Forms 의 OnElementChanged method 를 대체하는 것으로 handler 의 속성변경을 처리하는 역할을 합니다. 그리고 변경이 발생했을 때 여러분이 작성한 custom code 와 연결할 수 있는 곳이기도 합니다. 다음은 여러분이 이전에 작성한 IMyButton 의 property mapper 입니다 :

 

public static PropertyMapper<IMyButton,
    MyButtonHandler> MyButtonMapper =
    new PropertyMapper<IMyButton, MyButtonHandler>
        (ViewHandler.ViewMapper)
{
    [nameof(ICustomEntry.Text)] = MapText,
    [nameof(ICustomEntry.TextColor)] = MapTextColor
};

 

dictionary 는 property 변경과 customize 한 behavior 를 처리하는데 사용할 수 있는 static method 에 property 를 mapping 합니다.

 

public static void MapText(MyButtonHandler handler, IMyButton button)
{
    handler.NativeView?.SetTitle(button.Text, UIControlState.Normal);
}

 

마지막으로 이 handler 가 여러분이 작성한 button 에 customize 한 behavior 를 제공할 수있도록 등록하는 작업이 남았습니다. 기억하시겠지만 .NET MAUI 는 이제 더이상 assembly scanning 을 하지 않습니다. 여러분이 startup 에 handler 를 수동으로 등록해야합니다. 다음 section 에서는 handler 를 등록하는 방법에 대해 다룹니다.

 

.NET Generic Host 채택 (Adopting)

여러분은 이미 ASP.NET Core 에서 제공되는 .NET Generic Host 에 대해서 알고 있을 겁니다. .NET Generic Host 는 App 을 구성하고 시작하는 명료한 방법을 제공합니다. 구성(configuration), 의존성 주입(dependency injection), logging 등과 같은 표준화된 방법들을 통해서 이루어집니다. object 는 일반적으로 모든것을 host 로 capsule화(encap) 하며, 일반적으로 Program class 의 Main method 에서 구성됩니다. 다른 방법으로 host 를 구성하기위한 진입점을 제공하기위해서 Startup class 를 제공할 수도 있습니다. ASP.NET Core 에서 out-of-the-box generic host 는 다음과 같습니다 : 

 

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }
    public static IHostBuilder
        CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                });
}

 

.NET MAUI 또한 .NET Generic Host model 을 사용할 것이기 때문에 이제는 한 곳에서 여러분의 앱을 초기화하는 것이 가능합니다. 또한 폰트, 서비스 그리고 third-party library 들을 중앙(centralized location)에서 구성하는 기능을 제공합니다. CreateMauiApp method 를 포함하는 MauiProgram class 를 행성하여 이런 작업을 수행합니다. 여러분이 작성한 앱이 초기화될 때 모든 platform 은 자동으로 이 method 를 호출합니다.

 

using Microsoft.Maui;
using Microsoft.Maui.Hosting;

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>()
            .ConfigureFonts(fonts =>
            {
                fonts.AddFont("ComicSans.ttf","ComicSans");
            });

        return builder.Build();
    }
}

 

MauiApp 을 Build 해서 Return 하는 것이 MauiProgram Class 가 실행해야하는 최소한의 작업입니다. UseMauiApp Method 에서 참조하고 있는 App 인 Appication class 는 Application 의  Root 객체입니다.  이 객체는 startup 이 완료되면 실행되는 window 를 정의합니다. App 은 실행되는 앱의 시작페이지를 정의하는 곳이기도 합니다.

 

using Microsoft.Maui;
using Microsoft.Maui.Controls;

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

 

이 article 의 앞부분에서 handler 의 새로운 개념을 언급했습니다. 이 새로운 handler architecture 에 연결하려한다면 MauiProgram class 가 등록할 수 있는 장소입니다. ConfigureMauiHandler method 를 호출하고 handler collection 의 AddHandler method 를 호출하여 등록합니다.

 

using Microsoft.Maui;
using Microsoft.Maui.Hosting;

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>()
            .ConfigureMauiHandlers(handlers =>
        {
            handlers.AddHandler(typeof(MyEntry),typeof(MyEntryHandler));
        });

        return builder.Build();
    }
}

 

이 예제에서는 MyEntry 의 모든 Instance 에 MyEntryHandler 를 적용합니다. 그래서 이 handler 의 코드는 여러분이 작성한 모바일 앱의 MyEntry type 의 모든 object 에 대해 실행됩니다. 이 것은 여러분이 작성한 handler 로 완전히 새로운 control 을 target 으로 정하길 원할 때 적합한 해결방법입니다. 혹시 여러분이 원하는 모든 작업이 사용가능한(out-of-the-box) control 의 속성을 변경하는 것이라면, MauiProgram class 에서도 곧바로 작업할 수 있습니다. 아니면 control 이 실행되기 앞서 여러분이 실행되리라 생각되는 모든 곳에서 실행될 것입니다. (조금 이상함 ^^;) (원문 : If all you want to do is change a property on an out-of-the-box control, you can do this straight from the MauiProgram class as well, or really anywhere you know your code will run prior to the control being used.)

 

#if __ANDROID__

Microsoft.Maui.Handlers.ButtonHandler
    .ButtonMapper["MyCustomization"] = (handler, view) =>
        {
            handler.NativeView.SetBackgroundColor(Color.Green);
        };

#endif

 

이 예제는 Handler code 가 Android 플랫폼에서만 작동할 수 있도록 compiler 지시문을 사용합니다. 다른 platform 에서는 사용할 수 없는 API 를 사용하기 때문입니다. 만약 platform 별 code작업이 많다면 compiler 지시문으로 여러분의 코드를 지저분하게 하는 대신에 다른 multi-targeting 규칙(convention) 사용을 고려할 수도 있습니다. 이것은 본질적으로 여러분이 작성한  platform 별 code 로 구분하는 대신 접미사를 platform 이름으로 구분하는 platform 별 file 로 분리하는 것을 의미합니다. Project file 에서 조건문을 사용하여 특정 platform 용으로 compile 할 때 platform 별 file 들만 포함되도록 보장할 수 있습니다.

 

기존 Xamarin.Forms 사용자 지정(custom) Renderer 사용

만약 기존 Xamarin.forms App 을 .NET MAUI 로 migration 하려한다면,  여러분이 작성한 app 의 일부 기능을 처리하기 위해서 custom renderer 를 이미 작성했을 수도 있습니다. 이 custom renderer 들은 많은 수정 없이 .NET MAUI 에서 사용가능하지만 handler infrastructure 로 전환하는 것이 좋습니다. Xamarin.forms custome renderer 를 사용하려면 MauiProgram class 에 등록합니다.

 

var builder = MauiApp.CreateBuilder();

#if __ANDROID__

    builder.UseMauiApp<App>()
        .ConfigureMauiHandlers(handlers =>
        {
            handlers.AddCompatibilityRenderer(
                typeof(Microsoft.Maui.Controls.BoxView),
                typeof(MyBoxRenderer));
        });

#endif

return builder;

 

AddCompatibilityRenderer method 를 사용하여 custom renderer 를 .NET MAUI control 에 연결할 수 있습니다. platform 별로 작업할 필요가 있는데, multiple platform app 을 작성하고 있다면 각 platform 별로 renderer 를 추가해 줄 필요가 있습니다.

 

Single(단일) Project 로 Resource 이동

Xamarin.Forms 의 짜증나는 것들중 하나는 여러 project 사이에서 유사한 Resouce 를 여러번 복사해야하는 것입니다. 예를 들어서 만약 여러분의 앱에서 사용하고 싶은 특정 이미지를 가지고 있을 때, 여러분은 각각의 platform project 에 모두 포함시켜야하고 여러분 앱이 지원하고자 하는 모든 다양한 device 의 해상도에 맞게 제공하는 것이 좋습니다. font 나 app icon 도 비슷한 문제를 가지고 있습니다.

.NET MAUI 의 새 Single Project 기능은 모든 resource 들을 공유 head project 에 통합하며 지원하는 모든 platform 이 사용할 수 있습니다. .NET MAUI Build task 는 platform 별 artifact 로 compile 해 내려갈 때 resource 들이 올바른 위치에 있는지 확인합니다. Single project 접근 방법은 app manifest 수정과 NuGet package 수정같은 경험도 개선합니다. Figure 4 는 single project 가 VisualStudio 에서 어떻게 보일수 있는지 Mockup 을 보여줍니다. 동일한 Project 에 여러 공유 Logic 과 함께 공유 resource 를 포함합니다.

 

 

Figure 4 : &amp;nbsp;The new Single Project experience in Visual Studio

Figure 4 : Visual Studio 에서의 새 Single Project 경험

 

 

다른 쓸만한 Library 들은 무엇이 있나?

많은 공개적으로 유지관리되는 Library 들은 만든 사람이 .NET MAUI 에 이식해야합니다. Xamarin.Forms 형식이 없는 .NET 표준 Library 는 아무런 update 없이도 잘 작동할 것입니다. 다른 Library 들은 새로운 interface 와 type 들을 채택해야하고 .NET 호환 NuGet 으로 다시 Compile 해야합니다. 이들중 일부는 초기 alpha/beta version 의 library 로 출시를 함으로써 이미 이 process 를 시작했습니다. 만약 여러분이 과거에 Xamarin application 을 개발한 경험이 있다면 Xamarin Essentials 및/또는 Xamarin Community Toolkit 도 사용해 봤을 겁니다.

Essential 은 이제 .NET MAUI 의 일부분이 되었으며, Microsoft.Maui.Essential namespace 에 있습니다.

Xamarin.Forms 가 .NET MAUI 로 진화한 것처럼, Xamarin Community Toolkit 도 진화하고 있으며 .NET MAUI Community Toolkit 으로 알려질 것입니다. 지금처럼 완전히 open-source, community-supported library 로 되겠지만 두 Toolkit 간의 더욱 효과적인 code 공유와 engineering 노력을 결합할 수 있도록 Windows Community Toolkit 과 병합됩니다. Xamarin Community Toolkit 은 Xamarin.Forms 와 같은 공개일정에 따라 Service update 를 받습니다.

https://github.com/CommunityToolkit/Maui 에서 .NET MAUI Community Toolkit 정보를 확인하세요.

 

기존 App 을 .NET MAUI 로 전환

 

비록 Microsoft 가 기존에 개발된 app 을 .NET MAUI 로 이식하는 것을 현재는 권하지 않지만 .NET MAUI 가 release 되면 upgrade 경로를 제공하는 것이 언제나 우선시되었습니다. Xamarin.Forms 와 .NET MAUI 의 유사성때문에 migration process 는 간단할 수 있습니다. .NET Upgrade Assistant 는 .NET Framework 에서 .NET 5로 Upgrade 할 수있도록 도와주는 도구입니다. .NET Upgrade Assistant 의 상위에 있는 Extension 의 도움으로 Xamarin.Forms Project 를 .NET MAUI SDK Style 의 Project로 자동으로 migrate 하는 것이 가능하며 동시에 여러분이 작성한 코드의 일부 잘 알려진 namespace 를 변경하는 작업을 수행하는 것도 가능합니다. 그러면 .NET Upgrade Assistant 는 여러분의 코드를 자동적으로 upgrade 하고 변환하는데 필요한 단계를 제안합니다. 그리고 새로운 version 에 맞도록 특정 project property 와 attribute 를 mapping 하고 동시에 오래된 것들은 제거합니다. Figure 5 에서 보는 바와 같이 광범위한 logging 을 사용하여, 도구가 여러분의 project 를 upgrade 하기위해 취한 단계를 모두 확인할 수 있습니다. 이는 migration 동안 잠재적인 문제를 debugging 하는데 도움이 됩니다.

 

Figure 5 : &amp;nbsp;Informational output from the .NET Upgrade Assistant for .NET MAUI

Figure 5 : .NET MAUI 용 .NET Upgrade Assistant 의 정보 output

 

.NET MAUI 초기 동안에는, 몇가지 NuGet package 지원이 적절하지 않을 수 있습니다. .NET Upgrade Assistant 는 Analyzer 들과 작동하여 package 가 안전하게 제거되거나 다른 version으로 upgrade 할 수 있는지 확인합니다.

비록 여러분이 작성한 Project 를 100% upgrade 하지 못한다고 하더라도, 많은 양의 지루한 이름바꾸기와 반복해야하는 단계를 없애줍니다. 개발자로서, 여러분은 모든 종속성을 upgrade 해야하고 호환성 서비스와 renderer 들을 수동으로 등록해야합니다. Microsoft 는 가능한한 이런 노력들을 최소화하려고 노력하겠다고 했습니다. 정확한 process 에 대한 추가 문사는 release 되는 시점에 사용가능하게 될 것입니다.

https://dotnet.microsoft.com/platform/upgrade-assistant 에서 .NET Upgrade Assistant 에 대한 내용을 확인하십시오.

 

결론

 

과거에 Xamarin.Forms 로 작업했던 개발자들은 .NET MAUI 에서 친숙한 점들을 많이 발견할 수 있습니다. Infrastructure 의 아랫단 변경, 더 넓은 platform 범위(scope), 그리고 .NET 6 로의 전반적인 통합(overall unification) 또한 platform 을 처음 사용하는 사용자들에게는 매력적입니다. Single project feature 를 사용하여 더 많은 resource 와 code 를 shared library 로 중앙화하면 solution 관리를 엄청나게 단순화 합니다. handler 를 사용함으로써 추가적인 성능향상을 이룰수 있으며 노련한 Xamarin 개발자들에게 탐색할 항목을 제공합니다.

비록 .NET6 의 .NET MAUI 의 version이 매우 기대되지만, platform 의 첫번째 version 일 뿐입니다. 저는 개인적으로 추가기능이 곧 제공될 것으로 기대합니다. 그리고 전체 platform 이 open source 라는 점이 무엇보다 가장 좋습니다. 이는 여러분을 비롯한 .NET ecosystem 의 모든 사람들이 platform 을 개선하고 향상시키는데 기여할 수 있음을 의미합니다. 저는 미래가 어떻게 될지 너무나 궁금합니다.!

여러분이 .NET MAUI 를 직접 사용해보고 싶다면 다음 GitHub repository (https://dotnet.microsoft.com/platform/upgrade-assistant) 와 Microsoft Docs(https://docs.microsoft.com/dotnet/maui/) 에서 확인할 수 있습니다. 이 곳은 이미 시작하기(getting start) content 를 제공하고 있습니다.

 

위 글은 다음 글을 번역했습니다.

https://www.codemag.com/Article/2111082/An-Introduction-to-.NET-MAUI

 

An Introduction to .NET MAUI

You’ve been using Xamarin for years. Steven shows how the .NET Multi-platform App UI (.NET MAUI) hasn't just kept up with everything, but how it compare...

www.codemag.com

많은 부분 예상이 되는 오역이 있다면 알려주셨으면 합니다. ^^

 

행복한 고수되셔요...

 woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

반응형
LIST

'.NET' 카테고리의 다른 글

[.NET] DataTable to Dictionary using Linq  (0) 2022.01.14
[.NET] .NET MAUI 를 소개합니다.  (0) 2021.11.26
[.NET] Time Zone Identifiers  (2) 2018.07.24
[.NET] Clone  (0) 2017.05.31
[.NET] Collection was modified; enumeration operation may not execute.  (4) 2017.05.30
[.NET] .NET Core Roadmap  (0) 2017.02.10
Posted by woojja

댓글을 달아 주세요

반응형