<p>Xamarin.Forms.Shell 사양</p>

에 만든 2018년 04월 10일 · 199코멘트 · 출처: xamarin/Xamarin.Forms

Xamarin.Forms 셸 사양

새로운 개발자가 적절한 구성과 올바른 요소를 사용하여 최소한의 노력과 기본적으로 좋은 사람이 되는 명확한 경로를 통해 완전한 앱 경험을 얻을 수 있도록 간단하고 간단하게 만드십시오.

Shell은 특정 지점에서 독단적인 API이며, 실행 플랫폼에 따라 변경될 수 있는 일부 .Default로 모든 값을 항상 기본값으로 설정하지는 않습니다. 대신 플랫폼 기본값에 관계없이 모든 플랫폼에서 존중되는 값을 설정할 수 있습니다.

참고: 도면 사양이 #2452로 이동했습니다.

시각 치료

스크린샷이 필요합니다...

쉘 계층

처음에는 Shell 계층 구조를 이해하는 것이 처음에는 압도적으로 보일 수 있습니다. 복잡한 계층 구조를 나타내며 풍부한 계층 구조를 만드는 데 필요한 상용구 xaml의 양을 최소화하기 위한 강력한 메커니즘을 제공합니다.

따라서 셸을 처음 배울 때 바로 가기 없이 먼저 학습한 다음 바로 가기를 도입하여 작성되는 XAML의 양을 쉽게 최소화하는 방법을 확인하는 것이 가장 쉽습니다.

뒤따르는 모든 샘플은 사양의 다른 곳에서 논의되는 템플릿화된 ShellContent를 사용하지 않습니다. ContentTemplate과 함께 ShellContents를 올바르게 사용하지 않으면 시작 시 모든 페이지가 로드되어 시작 성능에 부정적인 영향을 미칩니다. 이 샘플은 학습용입니다.

다행히 ContentTemplates와 함께 ShellContents를 사용하는 것이 일반적으로 사용하지 않는 것보다 더 간결합니다.

바로가기 없음

이러한 샘플 중 상당수는 불필요하게 복잡해 보이지만 실제로는 복잡합니다. 다음 섹션에서는 이것들이 단순화될 것입니다.

간단한 한 페이지 앱

<Shell xmlns="http://xamarin.com/schemas/2014/forms"
       xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
       xmlns:local="clr-namespace:MyStore"
       FlyoutBehavior="Disabled"
       x:Class="MyStore.Shell">

  <ShellItem>
    <ShellSection>
      <ShellContent>
        <local:HomePage />
      </ShellContent>
    </ShellSection>
  </ShellItem>
</Shell>

step1

MainPage에서 Shell.NavBarVisible="false" 를 설정하여 상단 표시줄을 완전히 숨길 수 있습니다. 또한 플라이아웃은 이 모드에서 다소 희박해 보이기 때문에 이 샘플에서는 비활성화되어 있습니다.

하단 탭이 있는 2페이지 앱

<Shell xmlns="http://xamarin.com/schemas/2014/forms"
       xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
       xmlns:local="clr-namespace:MyStore"
       FlyoutBehavior="Disabled"
       x:Class="MyStore.Shell">

  <ShellItem>

    <ShellSection Title="Home" Icon="home.png">
      <ShellContent>
        <local:HomePage />
      </ShellContent>
    </ShellSection>

    <ShellSection Title="Notifications" Icon="bell.png">
      <ShellContent>
        <local:NotificationsPage />
      </ShellContent>
    </ShellSection>

  </ShellItem>
</Shell>

step2

ShellSection 섹션을 ShellItem 추가하면 또 다른 하단 탭이 나타납니다. 적절한 제목과 아이콘을 설정하면 탭 항목 제목과 아이콘을 제어할 수 있습니다.

상단 및 하단 탭이 있는 2페이지 앱

<Shell xmlns="http://xamarin.com/schemas/2014/forms"
       xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
       xmlns:local="clr-namespace:MyStore"
       FlyoutBehavior="Disabled"
       x:Class="MyStore.Shell">

  <ShellItem>

    <ShellSection Title="Home" Icon="home.png">
      <ShellContent>
        <local:HomePage />
      </ShellContent>
    </ShellSection>

    <ShellSection Title="Notifications" Icon="bell.png">

      <ShellContent Title="Recent">
        <local:NotificationsPage />
      </ShellContent>

      <ShellContent Title="Alert Settings">
        <local:SettingsPage />
      </ShellContent>

    </ShellSection>

  </ShellItem>
</Shell>

step3

가산함으로써 제 ShellContent 로 ShellSection 상부 탭 막대를 첨가하고 아래쪽 페이지는 탭이 선택 될 때 사이에 대칭된다.

플라이아웃 탐색을 사용하는 두 페이지 앱

<Shell xmlns="http://xamarin.com/schemas/2014/forms"
       xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
       xmlns:local="clr-namespace:MyStore"
       x:Class="MyStore.Shell">

  <Shell.FlyoutHeader>
    <local:FlyoutHeader />
  </Shell.FlyoutHeader>

  <ShellItem Title="Home" Icon="home.png">
    <ShellSection>
      <ShellContent>
        <local:HomePage />
      </ShellContent>
    </ShellSection>
  </ShellItem>

  <ShellItem Title="Notifications" Icon="bell.png">
    <ShellSection>
      <ShellContent>
        <local:NotificationsPage />
      </ShellContent>
    </ShellSection>
  </ShellItem>
</Shell>

step4

이 샘플에서 플라이아웃이 다시 활성화됩니다. 여기에서 사용자는 플라이아웃을 중개자로 사용하여 두 페이지 사이를 전환할 수 있습니다. 보기 좋게 헤더도 추가되었습니다.

단축 구문 사용

이제 계층 구조의 모든 수준이 표시되고 간략하게 설명되었으므로 계층 구조를 정의할 때 필요하지 않은 대부분의 래핑을 생략할 수 있습니다. Shell 오직 포함 ShellItem 오직 포함 S ShellSection 차례로 오직 포함 S ShellContent 들. 그러나 자동 업래핑을 허용하는 암시적 변환 연산자가 있습니다.

간단한 한 페이지 앱

<Shell xmlns="http://xamarin.com/schemas/2014/forms"
       xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
       xmlns:local="clr-namespace:MyStore"
       FlyoutBehavior="Disabled"
       x:Class="MyStore.Shell">

  <local:HomePage />
</Shell>

암시적 래핑을 사용하면 페이지가 ShellItem 까지 자동으로 래핑됩니다. 모든 중간 레이어를 작성할 필요는 없습니다. Title 및 Icon 으로부터 Page 어떤 암시 적으로 생성 된 부모까지 결합됩니다.

하단 탭이 있는 2페이지 앱

<Shell xmlns="http://xamarin.com/schemas/2014/forms"
       xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
       xmlns:local="clr-namespace:MyStore"
       FlyoutBehavior="Disabled"
       x:Class="MyStore.Shell">

  <ShellItem>
    <local:HomePage Icon="home.png" />
    <local:NotificationsPage Icon="bell.png" />
  </ShellItem>
</Shell>

이제 페이지가 암시적으로 ShellContent 및 자체 ShellSection으로 래핑됩니다. 그 결과 이전과 마찬가지로 두 개의 다른 탭이 생성됩니다.

상단 및 하단 탭이 있는 2페이지 앱

<Shell xmlns="http://xamarin.com/schemas/2014/forms"
       xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
       xmlns:local="clr-namespace:MyStore"
       FlyoutBehavior="Disabled"
       x:Class="MyStore.Shell">

  <ShellItem>
    <local:HomePage Icon="home.png" />

    <ShellSection Title="Notifications" Icon="bell.png">
        <local:NotificationsPage />
        <local:SettingsPage />
    </ShellSection>
  </ShellItem>
</Shell>

플라이아웃 탐색을 사용하는 두 페이지 앱

<Shell xmlns="http://xamarin.com/schemas/2014/forms"
       xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
       xmlns:local="clr-namespace:MyStore"
       x:Class="MyStore.Shell">

  <Shell.FlyoutHeader>
    <local:FlyoutHeader />
  </Shell.FlyoutHeader>

  <local:HomePage Icon="home.png" />
  <local:NotificationsPage Icon="bell.png" />
</Shell>

여기서 암시적 래핑은 셸 항목까지 진행되므로 스스로 래핑할 필요가 없습니다.

탐색 모델

푸시 탐색

모든 탐색은 View의 .Navigation 속성을 기반으로 합니다. 푸시는 표시된 현재 ShellSection으로 이동합니다. 이것은 푸시 이벤트에서 상단 탭이 사라지고 하단 탭이 남아 있음을 의미합니다.

URI 탐색

위에서 설명한 대로 표준 탐색 속성을 사용하여 셸을 탐색할 수 있지만 셸은 훨씬 더 편리한 탐색 메커니즘을 도입합니다.

탐색 URI의 형식은 다음과 같습니다.

[Shell.RouteScheme]://[Shell.RouteHost]/[Shell]/[ShellItem]/[ShellSection]/[ShellContent]/[NavStack1]/[NavStack2]...

셸 계층의 모든 항목에는 연결된 경로가 있습니다. 개발자가 경로를 설정하지 않으면 런타임에 경로가 생성됩니다. 런타임 생성 경로는 앱의 여러 실행에서 안정적이라고 보장되지 않으므로 딥 링크에 유용하지 않습니다.

뒤로 버튼 다루기

Shell은 기본 컨트롤을 사용할 필요가 없는 부러운 위치에 있기 때문에 모든 형태의 뒤로 버튼 재정의가 지원될 수 있고 지원되어야 합니다.

뒤로 버튼을 올바르게 처리하려면 다음 기능을 지원해야 합니다.

상호 작용 가로채기 및 중지
뒤로 버튼을 다른 것으로 교체
원할 때 뒤로 버튼을 완전히 숨기기
소프트웨어 및 하드웨어 버튼 작업

API는 사용 편의성을 위해 페이지 수준으로 세분화되어야 하지만 보다 일반적인 수준에서 스택 위로 추가로 처리할 수 있어야 합니다.

코드 샘플 및 API

시료

<Shell>
  <Shell.FlyoutHeaderTemplate>
    <DataTemplate>
      <Grid>
        <Label Text="{x:Bind HeaderText}" />
      </Grid>
    </DataTemplate>
  </Shell.FlyoutHeaderTemplate>

  // Flyout Item 1
  <ShellItem Title="My music" ItemsSource="{x:Bind MyMusicModels}" TabLocation="Bottom">
    <ShellItem.ItemTemplate>
      <local:MyMusicItemTemplateSelection />
    </ShellItem.ItemTemplate>
  </ShellItem>

  // Flyout Item 2
  <ShellItem Title="Home" Icon="home.png" GroupBehavior="ShowTabs">
    <ShellContent Title="My Friends">
      <local:FriendsPage />
    </ShellContent>
    <local:FeedPage />
    <local:ProfilePage />
  </ShellItem>

  // Flyout Item 3
  <local:SettingsPage />

  // Flyout Item 4
  <MenuItem Text="Log Out" Command="{x:Bind LogOutCommand}" />
</Shell>

Shell을 사용하는 단일 페이지 앱

<Shell FlyoutVisibility="Disabled">
  <local:MyPage />
</Shell>

단일 탭 그룹 앱(플라이아웃 없음)

<Shell FlyoutVisibility="Disabled">
  <ShellItem>
    <local:MyPage />
    <local:MySecondPage />
    <local:MyThirdPage />
  </ShellItem>
</Shell>

탭이 없는 플라이아웃의 여러 페이지

<Shell FlyoutVisibility="Disabled">
  <local:MyPage />
  <local:MySecondPage />
  <local:MyThirdPage />
</Shell>

단일 페이지 검색 가능 앱

<Shell FlyoutVisibility="Disabled">
  <local:MyPage />
</Shell>

```샤프
공개 클래스 MyPage : ContentPage
{
공개 클래스 MyPageSearchHandler : SearchHandler
{
공개 MyPageHandler()
{
SearchBoxVisibility = SearchBoxVisibility.Collapsed;
IsSearchEnabled = true;
자리 표시자 = "나를 검색하세요!";
}

protected override async void OnSearchConfirmed (string query)
{
  IsSearching = true;

  await PerformSearch (query);
  UpdateResults ();

  IsSearching = false;
}

protected override void OnSearchChanged (string oldValue, string newValue)
{
  // Do nothing, we will wait for confirmation
}

}

공개 마이페이지()
{
Shell.SetSearchHandler(이것은 새로운 MyPageSearchHandler());
}
}

## API Definition

### Shell
This is the base class for Shell's. It defines a somewhat strict navigational model however all shells must adhere to it in general. It does not include any theming or design language specific features.

```csharp
[ContentProperty("Items")]
public class Shell : Page, IShellController
{
  // Attached Properties
  public static readonly BindableProperty BackButtonBehaviorProperty;
  public static readonly BindableProperty FlyoutBehaviorProperty;
  public static readonly BindableProperty NavBarVisibleProperty;
  public static readonly BindableProperty SearchHandlerProperty;
  public static readonly BindableProperty SetPaddingInsetsProperty;
  public static readonly BindableProperty TabBarVisibleProperty;
  public static readonly BindableProperty TitleViewProperty;
  public static readonly BindableProperty ShellBackgroundColorProperty;
  public static readonly BindableProperty ShellDisabledColorProperty;
  public static readonly BindableProperty ShellForegroundColorProperty;
  public static readonly BindableProperty ShellTabBarBackgroundColorProperty;
  public static readonly BindableProperty ShellTabBarDisabledColorProperty;
  public static readonly BindableProperty ShellTabBarForegroundColorProperty;
  public static readonly BindableProperty ShellTabBarTitleColorProperty;
  public static readonly BindableProperty ShellTabBarUnselectedColorProperty;
  public static readonly BindableProperty ShellTitleColorProperty;
  public static readonly BindableProperty ShellUnselectedColorProperty;

  public static BackButtonBehavior GetBackButtonBehavior(BindableObject obj);
  public static FlyoutBehavior GetFlyoutBehavior(BindableObject obj);
  public static bool GetNavBarVisible(BindableObject obj);
  public static SearchHandler GetSearchHandler(BindableObject obj);
  public static bool GetSetPaddingInsets(BindableObject obj);
  public static bool GetTabBarVisible(BindableObject obj);
  public static View GetTitleView(BindableObject obj);
  public static void SetBackButtonBehavior(BindableObject obj, BackButtonBehavior behavior);
  public static void SetFlyoutBehavior(BindableObject obj, FlyoutBehavior value);
  public static void SetNavBarVisible(BindableObject obj, bool value);
  public static void SetSearchHandler(BindableObject obj, SearchHandler handler);
  public static void SetSetPaddingInsets(BindableObject obj, bool value);
  public static void SetTabBarVisible(BindableObject obj, bool value);
  public static void SetTitleView(BindableObject obj, View value);
  public static Color GetShellBackgroundColor(BindableObject obj);
  public static Color GetShellDisabledColor(BindableObject obj);
  public static Color GetShellForegroundColor(BindableObject obj);
  public static Color GetShellTabBarBackgroundColor(BindableObject obj);
  public static Color GetShellTabBarDisabledColor(BindableObject obj);
  public static Color GetShellTabBarForegroundColor(BindableObject obj);
  public static Color GetShellTabBarTitleColor(BindableObject obj);
  public static Color GetShellTabBarUnselectedColor(BindableObject obj);
  public static Color GetShellTitleColor(BindableObject obj);
  public static Color GetShellUnselectedColor(BindableObject obj);
  public static void SetShellBackgroundColor(BindableObject obj, Color value);
  public static void SetShellDisabledColor(BindableObject obj, Color value);
  public static void SetShellForegroundColor(BindableObject obj, Color value);
  public static void SetShellTabBarBackgroundColor(BindableObject obj, Color value);
  public static void SetShellTabBarDisabledColor(BindableObject obj, Color value);
  public static void SetShellTabBarForegroundColor(BindableObject obj, Color value);
  public static void SetShellTabBarTitleColor(BindableObject obj, Color value);
  public static void SetShellTabBarUnselectedColor(BindableObject obj, Color value);
  public static void SetShellTitleColor(BindableObject obj, Color value);
  public static void SetShellUnselectedColor(BindableObject obj, Color value);

  // Bindable Properties
  public static readonly BindableProperty CurrentItemProperty;
  public static readonly BindableProperty CurrentStateProperty;
  public static readonly BindableProperty FlyoutBackgroundColorProperty;
  public static readonly BindableProperty FlyoutHeaderBehaviorProperty;
  public static readonly BindableProperty FlyoutHeaderProperty;
  public static readonly BindableProperty FlyoutHeaderTemplateProperty;
  public static readonly BindableProperty FlyoutIsPresentedProperty;
  public static readonly BindableProperty GroupHeaderTemplateProperty;
  public static readonly BindableProperty ItemsProperty;
  public static readonly BindableProperty ItemTemplateProperty;
  public static readonly BindableProperty MenuItemsProperty;
  public static readonly BindableProperty MenuItemTemplateProperty;

  public Shell();

  public event EventHandler<ShellNavigatedEventArgs> Navigated;

  public event EventHandler<ShellNavigatingEventArgs> Navigating;

  public ShellItem CurrentItem {get; set;}

  public ShellNavigationState CurrentState {get; }

  public Color FlyoutBackgroundColor {get; set;}

  public FlyoutBehavior FlyoutBehavior {get; set;}

  public object FlyoutHeader {get; set;}

  public FlyoutHeaderBehavior FlyoutHeaderBehavior {get; set;}

  public DataTemplate FlyoutHeaderTemplate {get; set;}

  public bool FlyoutIsPresented {get; set;}

  public DataTemplate GroupHeaderTemplate {get; set;}

  public ShellItemCollection Items {get; }

  public DataTemplate ItemTemplate {get; set;}

  public MenuItemCollection MenuItems {get; }

  public DataTemplate MenuItemTemplate {get; set;}

  public string Route {get; set;}

  public string RouteHost { get; set; }

  public string RouteScheme { get; set; }

  public async Task GoToAsync(ShellNavigationState state, bool animate = true);

  protected virtual void OnNavigated(ShellNavigatedEventArgs args);

  protected virtual void OnNavigating(ShellNavigatingEventArgs args);
}

설명

첨부된 속성:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 검색 핸들러 속성 | 페이지 수준 검색 기능의 정의에 대한 연결된 속성입니다. 계층 구조의 여러 지점에 연결할 수 있습니다. 여기에 정의된 일부 기능을 사용합니다. https://material.io/guidelines/patterns/search.html#search -in-app-search |
| BackButton동작 | 뒤로 버튼이 작동하는 방식을 완전히 재정의할 수 있습니다. 화면 및 물리적 뒤로 버튼에 적용됩니다. |
| 플라이아웃 동작 | 플라이아웃이 표시되는 방식을 정의합니다. 이것은 ShellItem s, ShellContent s 또는 Page s에 연결하여 기본 동작을 재정의할 수 있습니다. |
| NavBarVisibleProperty | NavBar가 표시될 때 표시되어야 하는지 여부를 정의하기 위해 Page 에 속성 설정 |
| SetPaddingInsetsProperty | Page 에 이 속성을 설정하면 Padding 가 설정되어 해당 콘텐츠가 Shell 크롬 아래에서 흐르지 않도록 합니다. |
| TabBarVisibleProperty | TabBar가 표시될 때 표시되어야 하는지 여부를 정의하기 위해 Page 에 속성 설정 |
| TitleView 속성 | 에 속성 한 세트입니다 Page 정의 할 수있는 TitleView |
| ShellBackgroundColor 속성 | 셸의 크롬 요소에 사용해야 하는 배경색을 설명합니다. 이 색상은 셸 내용 뒤에 채워지지 않습니다. |
| ShellDisabledColorProperty | 비활성화된 텍스트/아이콘을 음영 처리할 색상 |
| ShellForegroundColor 속성 | 쉘의 일반 텍스트/아이콘 음영 처리 색상 |
| ShellTabBarBackgroundColorProperty | TabBar에 대한 ShellBackgroudnColor 재정의. 설정하지 않으면 ShellBackgroundColor가 사용됩니다 |
| ShellTabBarDisabledColorProperty | TabBar에 대한 ShellDisabledColor 재정의. 설정하지 않으면 ShellDisabledColorProperty가 사용됩니다. |
| ShellTabBarForegroundColorProperty | TabBar에 대한 ShellForegroundColorProperty 재정의. 설정하지 않으면 ShellForegroundColorProperty가 사용됩니다 |
| ShellTabBarTitleColorProperty | TabBar에 대한 ShellTitleColorProperty 재정의. 설정하지 않으면 ShellTitleColorProperty가 사용됩니다. |
| ShellTabBarUnselectedColorProperty | TabBar에 대한 ShellUnselectedColorProperty 재정의. 설정하지 않으면 ShellUnselectedColorProperty가 사용됩니다. |
| ShellTitleColor 속성 | 현재 페이지의 제목에 사용된 색상 |
| ShellUnselectedColorProperty | 셸에서 선택되지 않은 텍스트/아이콘에 사용되는 색상 chrome |

속성:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 현재 항목 | 현재 선택된 ShellItem |
| 현재 상태 | 셸의 현재 탐색 상태입니다. 이 상태를 GoToAsync에 다시 전달하면 셸이 뒤로 탐색 상태로 돌아갑니다. |
| FlyoutBackgroundColorProperty | 플라이아웃 메뉴의 배경색 |
| 플라이아웃 동작 | 기본 설정 FlyoutBehavior 에 대한 Shell . |
| 플라이아웃헤더 | 플라이아웃의 헤더로 사용되는 개체입니다. FlyoutHeaderTemplate 가 null이 아니면 BindingContext 로 팽창된 개체에 전달됩니다. FlyoutHeaderTemplate 가 null이고 FlyoutHeader 가 View 유형이면 직접 사용됩니다. 그렇지 않으면 ToString()을 호출하고 결과를 표시하여 표시됩니다. |
| 플라이아웃헤더동작 | 내용을 표시하기 위해 플라이아웃을 스크롤해야 할 때 FlyoutHeader 의 동작을 설정합니다. |
| 플라이아웃 헤더 템플릿 | 플라이아웃의 헤더를 만드는 데 사용되는 템플릿입니다. |
| 플라이아웃이 제시됨 | 플라이아웃이 현재 표시되는지 여부를 가져오거나 설정합니다. |
| 그룹 헤더 템플릿 | ShellItem 가 플라이아웃에서 탭 그룹으로 표시되도록 요청하는 경우 DataTemplate 그룹 헤더를 표시하는 데 사용됩니다. null이면 헤더가 표시되지 않습니다. |
| 항목 | 셸의 기본 콘텐츠입니다. 항목은 플라이아웃에 표시할 항목 목록과 사이드바 항목을 선택할 때 표시될 콘텐츠를 정의합니다. |
| 항목 템플릿 | DataTemplate 플라이아웃에서 Items 컬렉션의 항목을 표시하는 데 사용됩니다. 개발자가 플라이아웃에서 시각적 개체를 제어할 수 있습니다. |
| 메뉴 항목 | 자체 섹션의 플라이아웃에 표시될 MenuItem 컬렉션입니다. |
| 메뉴 항목 템플릿 | DataTemplate 사용에 표시 될 때 MenuItem 플라이 아웃에. |
| 노선 | 딥링킹을 수행할 때 이 요소를 처리하기 위한 경로 부분입니다. |
| 루트호스트 | 딥링크 생성 시 생성된 URI의 호스트 부분에 배치할 문자열 |
| 노선표 | 딥 링크를 생성할 때 생성된 URI의 스키마 부분에 배치할 문자열 |

공개 방법:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| GoToAsync | ShellNavigationState 합니다. 애니메이션이 완료되면 완료될 작업을 반환합니다. |

공개 이벤트:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 탐색 | Shell 는 사용자 상호 작용 또는 API를 호출하는 개발자로 인해 탐색을 수행하려고 합니다. 개발자는 가능한 경우 여기에서 탐색을 취소할 수 있습니다. |
| 탐색 | Shell 이(가) 탐색 이벤트를 완료했습니다. |

ShellItemCollection

ShellItem 컬렉션

public sealed class ShellItemCollection : IEnumerable<ShellItem>, IList<ShellItem>

메뉴 항목 컬렉션

MenuItem 컬렉션

public sealed class MenuItemCollection : IEnumerable<MenuItem>, IList<MenuItem>

ShellSectionCollection

ShellSection 컬렉션

public sealed class ShellSectionCollection : IEnumerable<ShellSection>, IList<ShellSection>

ShellContentCollection

ShellContent 컬렉션

public sealed class ShellContentCollection : IEnumerable<ShellContent>, IList<ShellContent>

ShellNavigatingEventArgs

발생하려는 탐색 이벤트를 설명하는 데 사용되는 EventArgs 입니다. 개발자가 원하는 경우 ShellNavigationEventArgs 사용하여 탐색 이벤트를 취소할 수도 있습니다.

public class ShellNavigatingEventArgs : EventArgs
{
  public ShellNavigationState Current { get; }

  public ShellNavigationState Target { get; }

  public ShellNavigationSource Source { get; }

  public bool CanCancel { get; }

  public bool Cancel ();
}

속성:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 현재 | Shell 의 현재 NavigationState입니다. 이 ShellNavigationState GoToAsync 를 호출하면 이 탐색 이벤트가 효과적으로 취소됩니다. |
| 대상 | 이 탐색 이벤트가 완료된 후 Shell 의 상태입니다. |
| 출처 | 이 이벤트를 트리거하기 위해 발생한 탐색 유형입니다. 여러 플래그가 설정되어 있을 수 있습니다. |
| 취소 취소 | 탐색 이벤트를 취소할 수 있는지 여부입니다. 모든 이벤트를 취소할 수 있는 것은 아닙니다. |

공개 방법:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 취소 | 현재 탐색 이벤트를 취소합니다. 취소에 성공하면 true를 반환합니다. |

ShellNavigatedEventArgs

public class ShellNavigatedEventArgs : EventArgs
{
  public ShellNavigationState Previous { get; }

  public ShellNavigationState Current { get; }

  public ShellNavigationSource Source { get; }
}

속성:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 이전 | Shell 의 이전 NavigationState입니다. |
| 현재 | 이 탐색 이벤트가 완료되었을 때 Shell 의 새 상태입니다. |
| 출처 | 이 이벤트를 트리거하기 위해 발생한 탐색 유형입니다. 여러 플래그가 설정되어 있을 수 있습니다. |

ShellNavigationState

public class ShellNavigationState
{
  public Uri Location { get; set; }

  public ShellNavigationState ();
  public ShellNavigationState (string location);
  public ShellNavigationState (Uri uri);

  public static implicit operator ShellNavigationState (Uri uri);
  public static implicit operator ShellNavigationState (String value);
}

속성:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 위치 | Shell 의 탐색 상태를 설명하는 Uri |

생성자:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| (무효) | null 위치를 사용하여 새 ShellNavigationState 생성 |
| (문자열) | 제공된 string 설정된 위치를 사용하여 새 ShellNavigationState 생성 |
| (우리) | 제공된 Uri 설정된 위치를 사용하여 새 ShellNavigationState 생성 |

ShellNavigationSource

[Flags]
public enum ShellNavigationSource
{
  Unknown = 0,
  Push,
  Pop,
  PopToRoot,
  Insert,
  Remove,
  ShellItemChanged,
  ShellSectionChanged,
  ShellContentChanged,
}

BaseShell항목

public class BaseShellItem : NavigableElement
{
  public static readonly BindableProperty FlyoutIconProperty;
  public static readonly BindableProperty IconProperty;
  public static readonly BindableProperty IsCheckedProperty;
  public static readonly BindableProperty IsEnabledProperty;
  public static readonly BindableProperty TitleProperty;

  public ImageSource FlyoutIcon { get; set; }

  public ImageSource Icon { get; set; }

  public bool IsChecked { get; }

  public bool IsEnabled { get; set; }

  public string Route { get; set; }

  public string Title { get; set; }
}

속성:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 플라이아웃 아이콘 | 플라이아웃에 표시될 때 사용할 기본 아이콘입니다. 설정하지 않으면 기본적으로 아이콘으로 설정됩니다. |
| 아이콘 | 플라이아웃이 아닌 크롬 부분에 표시할 아이콘입니다. |
| 체크됨 | BaseShellItem 가 현재 플라이아웃에서 선택되어 있는 경우(따라서 강조 표시되어야 함) |
| 활성화됨 | BaseShellItem 가 크롬에서 선택 가능한 경우 |
| 노선 | Routing.Route 설정에 해당 |
| 제목 | UI에 표시할 제목 |

셸 그룹 항목

public class ShellGroupItem : BaseShellItem
{
  public static readonly BindableProperty FlyoutDisplayOptionsProperty;;

  public FlyoutDisplayOptions FlyoutDisplayOptions { get; set; }
}

속성:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 플라이아웃디스플레이옵션 | 이 항목과 해당 하위 항목이 플라이아웃에 표시되는 방식을 제어합니다. |

쉘 아이템

[ContentProperty("Items")]
public class ShellItem : ShellGroupItem, IShellItemController, IElementConfiguration<ShellItem>
{
  public static readonly BindableProperty CurrentItemProperty;

  public ShellItem();

  public ShellSection CurrentItem { get; set; }

  public ShellSectionCollection Items;

  public static implicit operator ShellItem(ShellSection shellSection);

  public static implicit operator ShellItem(ShellContent shellContent);

  public static implicit operator ShellItem(TemplatedPage page);

  public static implicit operator ShellItem(MenuItem menuItem);
}

속성:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 현재 항목 | 선택한 ShellSection . |
| 항목 | ShellItem의 기본 콘텐츠인 ShellSectionCollection 입니다. 이 컬렉션은 ShellItem 내의 모든 탭을 정의합니다. |

쉘섹션

[ContentProperty("Items")]
public class ShellSection : ShellGroupItem, IShellSectionController
{
  public static readonly BindableProperty CurrentItemProperty;
  public static readonly BindableProperty ItemsProperty

  public ShellSection();

  public ShellContent CurrentItem { get; set; }

  public ShellContentCollection Items { get; }

  public IReadOnlyList<Page> Stack { get; }

  public static implicit operator ShellSection(ShellContent shellContent);

  public virtual async Task GoToAsync(List<string> routes, IDictionary<string, string> queryData, bool animate);

  protected virtual IReadOnlyList<Page> GetNavigationStack();

  protected virtual void OnInsertPageBefore(Page page, Page before);

  protected async virtual Task<Page> OnPopAsync(bool animated);

  protected virtual async Task OnPopToRootAsync(bool animated);

  protected virtual Task OnPushAsync(Page page, bool animated);

  protected virtual void OnRemovePage(Page page);
}

속성:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 현재 항목 | ShellSection의 선택된 ShellContent 입니다. |
| 항목 | ShellContentCollection 는 ShellSection의 루트 콘텐츠입니다. |
| 스택 | ShellSection에서 현재 푸시된 탐색 스택입니다. |

행동 양식:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| GoToAsync | 딥링크에서 알려진 위치로 이동하는 데 사용됩니다. 대부분의 경우 직접 호출할 필요가 없습니다. |
| GetNavigationStack | 현재 탐색 스택을 반환합니다. |
| OnInsertPageBefore | INavigation 인터페이스 InsertPageBefore 메소드가 호출될 때 호출됨 |
| OnPopAsync | INavigation 인터페이스 PopAsync 메소드가 호출될 때 호출됨 |
| OnPopToRootAsync | INavigation 인터페이스 PopToRootAsync 메소드가 호출될 때 호출됨 |
| OnPushAsync | INavigation 인터페이스 PushAsync 메소드가 호출될 때 호출됨 |
| 제거 페이지 | INavigation 인터페이스 RemovePage 메소드가 호출될 때 호출됨 |

셸 콘텐츠

[ContentProperty("Content")]
public class ShellContent : BaseShellItem, IShellContentController
{
  public static readonly BindableProperty ContentProperty;
  public static readonly BindableProperty ContentTemplateProperty;
  public static readonly BindableProperty MenuItemsProperty;

  public ShellContent();

  public object Content { get; set; }

  public DataTemplate ContentTemplate { get; set; }

  public MenuItemCollection MenuItems { get; }

  public static implicit operator ShellContent(TemplatedPage page);
}

속성:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 내용 | ShellContent의 내용입니다. 보통 ContentPage 또는 BindingContext 의 Page 에 의해 팽창 ContentTemplate |
| 콘텐츠 템플릿 | ShellContent 의 콘텐츠를 동적으로 확장하는 데 사용됩니다. Content 속성은 인플레이션 후 BindingContext 로 설정됩니다. |
| 메뉴 항목 | 이 ShellContent가 표시된 페이지일 때 플라이아웃에 표시할 항목 |

검색 핸들러

public class SearchHandler : BindableObject, ISearchHandlerController
{
  public static readonly BindableProperty ClearIconHelpTextProperty;
  public static readonly BindableProperty ClearIconNameProperty;
  public static readonly BindableProperty ClearIconProperty;
  public static readonly BindableProperty ClearPlaceholderCommandParameterProperty;
  public static readonly BindableProperty ClearPlaceholderCommandProperty;
  public static readonly BindableProperty ClearPlaceholderEnabledProperty;
  public static readonly BindableProperty ClearPlaceholderHelpTextProperty;
  public static readonly BindableProperty ClearPlaceholderIconProperty;
  public static readonly BindableProperty ClearPlaceholderNameProperty;
  public static readonly BindableProperty CommandParameterProperty;
  public static readonly BindableProperty CommandProperty;
  public static readonly BindableProperty DisplayMemberNameProperty;
  public static readonly BindableProperty IsSearchEnabledProperty;
  public static readonly BindableProperty ItemsSourceProperty;
  public static readonly BindableProperty ItemTemplateProperty;
  public static readonly BindableProperty PlaceholderProperty;
  public static readonly BindableProperty QueryIconHelpTextProperty;
  public static readonly BindableProperty QueryIconNameProperty;
  public static readonly BindableProperty QueryIconProperty;
  public static readonly BindableProperty QueryProperty;
  public static readonly BindableProperty SearchBoxVisibilityProperty;
  public static readonly BindableProperty ShowsResultsProperty;

  public ImageSource ClearIcon { get; set; }

  public string ClearIconHelpText { get; set; }

  public string ClearIconName { get; set; }

  public ICommand ClearPlaceholderCommand { get; set; }

  public object ClearPlaceholderCommandParameter { get; set; }

  public bool ClearPlaceholderEnabled { get; set; }

  public string ClearPlaceholderHelpText { get; set; }

  public ImageSource ClearPlaceholderIcon { get; set; }

  public string ClearPlaceholderName { get; set; }

  public ICommand Command { get; set; }

  public object CommandParameter { get; set; }

  public string DisplayMemberName { get; set; }

  public bool IsSearchEnabled { get; set; }

  public IEnumerable ItemsSource { get; set; }

  public DataTemplate ItemTemplate { get; set; }

  public string Placeholder { get; set; }

  public string Query { get; set; }

  public ImageSource QueryIcon { get; set; }

  public string QueryIconHelpText { get; set; }

  public string QueryIconName { get; set; }

  public SearchBoxVisiblity SearchBoxVisibility { get; set; }

  public bool ShowsResults { get; set; }

  protected virtual void OnClearPlaceholderClicked();

  protected virtual void OnItemSelected(object item);

  protected virtual void OnQueryChanged(string oldValue, string newValue);

  protected virtual void OnQueryConfirmed();
}

속성:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| ClearIconHelpText | 지우기 아이콘에 대한 액세스 가능한 도움말 텍스트 |
| ClearIconName속성 | 스크린 리더와 함께 사용하기 위한 지우기 아이콘의 이름 |
| 클리어 아이콘 | 검색 상자의 내용을 지우기 위해 표시되는 아이콘입니다. |
| ClearPlaceholder명령 매개변수 | ClearPlaceholderCommand 대한 매개변수 |
| ClearPlacehodlerCommand | ClearPlaceholder 아이콘을 누를 때 실행할 명령 |
| ClearPlaceholderEnabled | ClearPlaceholderIcon의 활성화 상태입니다. 기본값은 true입니다. |
| ClearPlaceholderHelpText | 명확한 자리 표시자 아이콘에 대한 액세스 가능한 도움말 텍스트 |
| ClearPlaceholderIcon | 검색 상자가 비어 있을 때 ClearIcon 위치에 표시되는 아이콘입니다. |
| ClearPlaceholderName | 화면 판독기와 함께 사용하기 위한 명확한 자리 표시자 아이콘의 이름 |
| 명령 매개변수 | Command 대한 매개변수 |
| 명령 | 쿼리 확인 시 실행할 ICommand
| DisplayMemberPath | ItemsSource 각 데이터 항목에 대해 표시되는 속성의 이름 또는 경로입니다. |
| 검색 가능 | 검색 상자의 활성화 상태를 제어합니다. |
| 항목 소스 | 제안 영역에 표시할 항목 모음입니다. |
| 항목 템플릿 | 제안 영역에 표시되는 항목의 템플릿입니다. |
| 자리 표시자 | 검색 상자가 비어 있을 때 표시할 문자열입니다. |
| QueryIconHelpText속성 | 쿼리 아이콘에 대한 액세스 가능한 도움말 텍스트 |
| QueryIconName속성 | 화면 판독기와 함께 사용하기 위한 쿼리 아이콘의 이름 |
| 쿼리 아이콘 | 검색이 가능함을 사용자에게 표시하는 데 사용되는 아이콘 |
| 쿼리 | 검색 상자의 현재 문자열입니다. |
| SearchBox가시성 | Shell 크롬에서 검색 상자의 가시성을 정의합니다. |
| 쇼결과 | 텍스트 입력 시 검색 결과를 예상해야 하는지 결정 |

보호 방법:

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| OnClearPlaceholderClicked | ClearPlaceholder 아이콘을 누를 때마다 호출됩니다. |
| 항목 선택됨 | 사용자가 검색 결과를 누를 때마다 호출됨 |
| OnQuery확인됨 | 사용자가 Enter 키를 누르거나 검색 상자에서 항목을 확인할 때마다 호출됩니다. |
| 쿼리 변경됨 | Query 가 변경될 때 호출됩니다. |

검색창 가시성

public enum SearchBoxVisiblity
{
  Hidden,
  Collapsable,
  Expanded
}

| 가치 | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 숨겨진 | 검색 상자가 보이지 않거나 액세스할 수 없습니다. |
| 접을 수 있는 | 사용자가 검색 상자를 표시하는 작업을 수행할 때까지 검색 상자가 숨겨집니다. |
| 확장 | 검색 상자는 완전히 확장된 항목으로 표시됩니다. |

BackButton동작

public class BackButtonBehavior : BindableObject
{
  public ImageSource IconOverride { get; set; }
  public string TextOverride { get; set; }
  public ICommand Command { get; set; }
  public object CommandParameter { get; set; }
}

| API | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 아이콘 재정의 | 뒤로 버튼에 사용되는 아이콘을 변경합니다. |
| 텍스트 재정의 | 텍스트가 사용되는 경우 뒤로 탐색을 나타내는 데 사용되는 텍스트를 변경합니다. |
| 명령 | 뒤로 버튼을 눌렀을 때 호출할 대체 명령을 제공합니다. |
| 명령 매개변수 | Command 와 함께 사용되는 명령 매개변수 |

플라이아웃디스플레이옵션

ShellGroupItem 가 FlyoutMenu에 표시되는 방식을 결정합니다.

  public enum FlyoutDisplayOptions
  {
    AsSingleItem,
    AsMultipleItems,
  }

| 가치 | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| AsSingleItem | ShellGroupItem 은 플라이아웃에서 단일 항목으로 표시됩니다. |
| AsMultipleItems | ShellGroupItem 는 플라이아웃의 각 하위 항목에 대해 하나씩 항목 그룹으로 표시됩니다. |

플라이아웃헤더동작

스크롤할 때 FlyoutHeader의 동작을 제어합니다.

public enum FlyoutHeaderBehavior {
  Default,
  Fixed,
  Scroll,
  CollapseOnScroll,
}

| 가치 | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 기본값 | 플랫폼 기본 동작. |
| 고정 | 헤더는 항상 표시되고 변경되지 않은 상태로 유지됩니다. |
| 스크롤 | 사용자가 메뉴를 스크롤할 때 헤더가 보이지 않게 스크롤됨 |
| CollapseOnScroll | 사용자가 스크롤할 때만 헤더가 제목으로 축소됨 |

플라이아웃 동작

public enum FlyoutBehavior
{
  Disabled,
  Flyout,
  Locked
}

| 가치 | 설명 |
| -----------| -------------------------------------------------- ------------------------------------------|
| 장애인 | 사용자는 플라이아웃에 액세스할 수 없습니다. |
| 플라이아웃 | 플라이아웃은 사용자가 열거나 닫을 수 있는 일반 플라이아웃으로 작동합니다. |
| 잠김 | 플라이아웃은 잠겨 있으며 사용자가 닫을 수 없으며 콘텐츠를 과도하게 사용하지 않습니다. |

데이터 템플릿 확장

이 확장은 유형을 ControlTemplate으로 빠르게 변환합니다. 이는 템플릿이 다음과 같이 지정되는 경우에 유용합니다.

<ListView>
  <ListView.ItemTemplate>
    <DataTemplate>
      <local:MyCell />
    </DataTemplate>
  </ListView.ItemTemplate>
</ListView>

이것은 다음으로 압축될 수 있다.

<ListView ItemTemplate="{DataTemplate local:MyCell}" />

public sealed class ControlTemplateExtension : IBindingExtension<ControlTemplate>

public sealed class DataTemplateExtension : IBindingExtension<DataTemplate>

잡동사니

푸시된 플라이아웃에서 탭을 선택하면 어떻게 됩니까?

이것은 탭에 초점을 맞추고 PopToRoot를 호출하는 것과 같습니다.

ShellItem을 전환하고 이전 ShellItem의 ShellContent 백스택에 항목이 있으면 어떻게 됩니까?

이전 ShellItem이 템플릿화된 경우 백 스택이 손실됩니다. ShellItem이 템플릿화되지 않은 경우 BackStack은 그대로 유지되고 이전 ShellItem으로 다시 전환할 때 백스택이 제대로 반영됩니다. 다시 전환하면 위의 답변에 표시된 것처럼 백 스택이 지워질 수 있습니다.

효율적인 페이지 로딩

셸 사용의 주요 문제는 사용자가 응용 프로그램 실행을 시작할 때 모든 페이지를 로드할 수 있다는 점입니다. 많은 수의 콘텐츠 페이지가 필요한 경우 이 대규모 프런트로드 할당으로 인해 시작 성능이 상당히 저하될 수 있습니다. 이 템플릿을 수정하려면 가능한 한 사용되어야 합니다.

템플릿화된 ShellContents

셸 탭 항목 템플릿은 사용 가능한 템플릿 중 가장 세분화된 형태이며 다행히도 가장 쉽게 수행할 수 있습니다. 다음 쉘을 가져 가라.

<?xml version="1.0" encoding="utf-8" ?>
<MaterialShell xmlns="http://xamarin.com/schemas/2014/forms"
               xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
               xmlns:local="clr-namespace:MyStore"
               x:Class="MyStore.Shell">

  <ShellItem Title="My apps &amp; games">
    <local:UpdatesPage />
    <local:InstalledPage />
    <local:LibraryPage />
  </ShellItem>

  <ShellItem GroupBehavior="ShowTabs">
    <local:HomePage />
    <local:GamesPage />
    <local:MoviesTVPage />
    <local:BooksPage />
    <local:MusicPage />
    <local:NewsstandPage />
  </ShellItem>
</MaterialShell>

이 셸이 로드되면 9페이지가 한 번에 모두 확장됩니다. 템플릿을 사용하지 않기 때문입니다. 기본 템플릿을 사용하려면 이것을 다음과 같이 변환할 수 있습니다.

<?xml version="1.0" encoding="utf-8" ?>
<MaterialShell xmlns="http://xamarin.com/schemas/2014/forms"
               xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
               xmlns:local="clr-namespace:MyStore"
               x:Class="MyStore.Shell">

  <ShellItem Title="My apps &amp; games">
    <ShellContent Title="Updates"        Icon="updates.png" ContentTemplate="{DataTemplate local:UpdatesPage}" />
    <ShellContent Title="Installed Apps" Icon="apps.png"    ContentTemplate="{DataTemplate local:InstalledPage}" />
    <ShellContent Title="Library"        Icon="library.png" ContentTemplate="{DataTemplate local:LibraryPage}" />
  </ShellItem>

  <ShellItem GroupBehavior="ShowTabs">
    <ShellContent Title="Home"          Icon="updates.png"   ContentTemplate="{DataTemplate local:HomePage}" />
    <ShellContent Title="Games"         Icon="games.png"     ContentTemplate="{DataTemplate local:GamesPage}" />
    <ShellContent Title="Movies and TV" Icon="moviesTV.png"  ContentTemplate="{DataTemplate local:MoviesTVPage}" />
    <ShellContent Title="Books"         Icon="books.png"     ContentTemplate="{DataTemplate local:BooksPage}" />
    <ShellContent Title="Music"         Icon="music.png"     ContentTemplate="{DataTemplate local:MusicPage}" />
    <ShellContent Title="Newsstand"     Icon="newsstand.png" ContentTemplate="{DataTemplate local:NewsstandPage}" />
  </ShellItem>
</MaterialShell>

페이지는 이제 필요할 때만 로드되며 필요에 따라 언로드할 수도 있습니다. 필요한 경우 ShellItem 자체를 컬렉션과 DataTemplateSelector로 템플릿화할 수도 있습니다. 이를 통해 ShellContents도 열심히 로드해야 하는 것을 방지할 수 있습니다. . ShellContent 템플릿은 성능 문제에 대한 템플릿을 제공하는 핵심 영역이어야 합니다.

Google Play 스토어 사용자 인터페이스 재구성

이것은 응용 프로그램을 코딩하는 가장 좋은 방법의 데모를 위한 것이 아니라 GPS용 UI를 함께 밀어 넣는 가장 간결한 형식입니다. 또한 ViewModel 및 DataTemplateSelector를 사용하여 관련 페이지를 가상화하려고 시도하지 않습니다. 즉, 앱 시작 시 모든 페이지가 로드되므로 성능이 매우 좋지 않습니다. 독자는 경고합니다.

모든 페이지 콘텐츠는 올바르게 작동하는 것으로 간주되며 이는 크롬에 대한 일반적인 개념을 이해하기 위한 것입니다.

셸.xaml

이에 대한 적절한 구현은 모든 페이지에 대해 ShellItems를 사용하고 ItemsSource 및 ItemTemplate을 설정합니다. 이렇게 하면 각 페이지가 필요할 때만 로드되고 더 이상 필요하지 않을 때 언로드될 수 있습니다.

<?xml version="1.0" encoding="utf-8" ?>
<MaterialShell xmlns="http://xamarin.com/schemas/2014/forms"
               xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
               xmlns:local="clr-namespace:MyStore"
               x:Class="MyStore.Shell"
               FlyoutHeaderBehavior="Fixed"
               FlyoutHeader="{x:Bind HeaderViewModel}">
  <MaterialShell.FlyoutHeaderTemplate>
    <local:CircleImageAndLabelControl HeightRequest="350" />
  </MaterialShell.FlyoutHeaderTempalte>

  <ShellItem Title="My apps &amp; games">
    <ShellItem.ShellAppearance>
      <MaterialShellAppearance NavBarCollapseStyle="Full">
    </ShellItem.ShellAppearance>
    <local:UpdatesPage />
    <local:InstalledPage />
    <local:LibraryPage />
  </ShellItem>

  <local:NotificationsPage Title="My notifications" />

  <local:SubscriptionsPage />

  <ShellItem GroupBehavior="ShowTabs">
    <ShellItem.ShellAppearance>
      <MaterialShellAppearance NavBarCollapseStyle="Full" TabBarCollapseStyle="Full" UseSwipeGesture="false">
    </ShellItem.ShellAppearance>
    <local:HomePage />
    <local:GamesPage />
    <ShellContent Title="Movies &amp; TV" Icon="moviesTV.png" ContentTemplate="{DataTemplate local:MoviesTVPage}">
      <ShellContent.MenuItems>
        <MenuItem Title="Open Movies &amp; TV app" Command="{xBind MoviesTVAppCommand}" />
      </ShellContent.MenuItems>
    </ShellContent>
    <ShellContent Title="Books" Icon="books.png" ContentTemplate="{DataTemplate local:BooksPage}">
      <ShellContent.MenuItems>
        <MenuItem Title="Open Books app" Command="{xBind BooksAppCommand}" />
      </ShellContent.MenuItems>
    </ShellContent>
    <ShellContent Title="Music" Icon="music.png" ContentTemplate="{DataTemplate local:MusicPage}">
      <ShellContent.MenuItems>
        <MenuItem Title="Open Music app" Command="{xBind MusicAppCommand}" />
      </ShellContent.MenuItems>
    </ShellContent>
    <ShellContent Title="Newsstand" Icon="newsstand.png" ContentTemplate="{DataTemplate local:NewsstandPage}">
      <ShellContent.MenuItems>
        <MenuItem Title="Open Newsstand app" Command="{xBind NewsstandAppCommand}" />
      </ShellContent.MenuItems>
  </ShellItem>

  <local:AccountPage />

  <MenuItem Title="Redeem" Icon="redeem.png" Command="{x:Bind RedeemCommand}" />

  <local:WishlistPage />

  <MenuItem Title="Play Protect" Icon="protect.png" Command="{x:Bind NavigateCommand}" CommandParameter="ProtectPage" />

  <MenuItem Title="Settings" Icon="settings.png" Command="{x:Bind SettingsCommand}" CommandParameter="SettingsPage" />

  <MaterialShell.MenuItems>
    <MenuItem Title="Help &amp; feedback" Command="{x:Bind NavigateCommand}" CommandParameter="HelpPage" />
    <MenuItem Title="Parent Guide" Command="{x:Bind NavigateCommand}" CommandParameter="ParentPage" />
    <MenuItem Title="Help &amp; feedback" Command="{x:Bind UrlCommand}" CommandParameter="http://support.google.com/whatever" />
  </MaterialShell.MenuItems>
</MaterialShell>

상점 페이지

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:local="clr-namespace:MyStore"
             x:Class="MyStore.HomePage"
             Title="Home"
             Icon="home.png"
             ShellAppearance.BackgroundColor="Green">
  <Label Text="Home content here" />
</ContentPage>

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:local="clr-namespace:MyStore"
             x:Class="MyStore.MoviesTVPage"
             Title="Movies &amp; TV"
             Icon="movies.png"
             ShellAppearance.BackgroundColor="Red">
  <Label Text="Movies and TV content here" />
</ContentPage>

그리고 검색창을 추가합니다.

public class HomePage : ContentPage
{
  public class HomeSearchHandler : SearchHandler
  {
    public HomeSearchHandler ()
    {
      SearchBoxVisibility = SearchBoxVisibility.Expanded;
      IsSearchEnabled = true;
      Placeholder = "Google Play";
      CancelPlaceholderIcon = "microphone.png"
    }

    protected override void OnSearchConfirmed (string query)

{      // Navigate to search results page here
    }

    protected override void OnSearchChanged (string oldValue, string newValue)
    {
    }

    protected override void OnCancelPlaceholderPressed ()
    {
      // Trigger voice API here
    }
  }

  public HomePage
  {
    Shell.SetSearchHandler (this, new HomeSearchHandler ());
  }  
}

색상과 내용을 올바르게 설정하는 등의 작업이 수행됩니다.

뒤로 버튼을 누를 때까지 플라이아웃에 액세스할 수 없는 설정 페이지와 같은 페이지의 경우:

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:local="clr-namespace:MyStore"
             x:Class="MyStore.SettingsPage"
             Title="Settings"
             Icon="settings.png"
             ShellAppearance.BackgroundColor="Grey"
             MaterialShell.FlyoutBehavior="Disabled">
  <Label Text="Settings content here" />
</ContentPage>

할 것

[x] 검색 상자용 API 추가
[x] ContentSafeArea 처리를 위한 API 추가
[x] 플로팅 메뉴용 API 추가
[x] 창 메뉴 항목에 대한 API 추가
[x] 스낵바용 API 추가
[x] 탐색 중단을 위한 API 추가
[x] 하단 시트용 API 추가
[x] 위치 FAB에 API 추가
[x] 탐색 아이디어를 더 명확하게 만들기 위해 스토리 추가(일부 완료)
[x] LeftBarButton 스타일 API 추가
[x] ShellContent에서 백 스택을 가져오기 위한 메커니즘 추가
[x] 선택한 탭에 따라 리본 색상을 변경하는 API 추가
[x] SearchHandler에 대한 선택적 제안 지원 추가
[x] 항상 확장된 검색 표시줄과 검색 표시줄을 아이콘으로 구성하기 위한 지원 추가
[x] MaterialShell 클래스에서 "현재" 페이지를 가져오기 위한 API를 추가합니다. 일부 탐색 시나리오에 필요합니다.
[x] 백 스택에 "상태"를 저장하기 위한 API 추가
[x] 플라이아웃이 나오지 않도록 차단하는 API 추가
[x] ShellContent의 ala GPS -> 음악 -> 음악 앱 열기에 대한 "하위 메뉴" 항목에 대한 API 추가
[x] CancelPlaceholder 명령 및 아이콘용 API 추가(보통 음성 검색용 마이크 아이콘에 사용됨)
[x] 세그 API
[x] INavigation으로 수행할 작업 알아보기
[ ] Google 지도 기능과 일치하도록 하단 시트 API 확장
[x] 플라이아웃 프레젠테이션을 처리하는 API
[ ] 필요할 때 플라이아웃 제스처를 비활성화하는 API
[ ] 큰 제목 API
[ ] 전환 API

문제

ISearchHandler [수정됨]

이 인터페이스가 하는 일이 많고 시간이 지남에 따라 확장해야 할 수도 있습니다. 따라서 사용자가 구현할 수 있는 추상 기본 클래스여야 합니다. 이 불행한 것은 또 다른 객체 할당을 의미합니다. 그러나 향후에도 유연성을 유지합니다. 이러한 변화가 일어날 가능성이 높습니다.

플로팅 메뉴

첨부 API는 약간 무겁고 사용자에게 너무 혼란스러울 수 있습니다. 더 나쁜 것은 첨부 파일이 애니메이션과 함께 작동하는지 확인하기 위해 모든 플랫폼에 잘 매핑되지 않을 수 있습니다. 이 API를 검증하려면 더 많은 작업이 필요합니다.

shell enhancement ➕

출처

jassmith

👍61 🎉27 ❤16 👎2

가장 유용한 댓글

여러분, 어제 Jason과 저는 이 사양을 개선하는 방법에 대해 논의했으며 대규모 업데이트를 수행할 예정이며 이를 여러 문제로 분할하고 있습니다.

migueldeicaza 에 2018년 04월 13일

👍15

모든 199 댓글

우리 개발자 커뮤니티인 여러분의 의견을 정말 들어야 하기 때문에 이 대화를 흥겹게 합시다!

먼저, @jassmith 에게 이것을 포착하고 공개 토론을 위한 제안서를

저는 제 생각을 공유하고, 어리석은 질문을 하고, 너무 유도적이지 않은 질문을 할 것입니다. Xamarin.Forms의 프로그램 관리자로서 저는 종종 질문을 해서 아무런 단서가 없는 것처럼 들리지만(때로는 모를 때도 있음) 말을 입에 넣는 것.

이 제안에서 제가 좋아하는 부분이 있습니다. 왜냐하면 제가 여러분 중 많은 사람들과 이야기해 왔으며 우리는 해결을 위해 노력하고 있는 문제를 어떻게 해결할 수 있는지 알 수 있기 때문입니다.

저도 예약이 있습니다.

Shell 개념과 개발자 경험에 대한 몇 가지 일반적인 생각으로 시작하겠습니다.

앱 경험

적절하게 구성된 완전한 앱 경험을 얻으려면 기본적으로 아주 적은 노력과 명확한 경로로 올바른 요소를 사용합니다.

이 접근 방식을 사용하여 최상위 수준에서 애플리케이션을 설명하면 다음과 같은 결과를 얻을 수 있습니다.

모든 플랫폼에서 동일하게 보이도록 테마가 있는 앱
머티리얼 디자인(이 경우) 기본적으로 패턴 켜짐
구성으로 활성화된 최신 탐색 패턴
iOS, Android 및 UWP에서 동일하게 보이도록 항목 또는 버튼을 사용자 지정하기 위해 노력할 필요가 없습니까?

정확합니까? 강조해야 할 다른 이점은 무엇입니까?

App 대신 MaterialShell 있습니다. 이점을 얻으려면 새로운 최상위 애플리케이션 패러다임을 학습/채택해야 합니까?

내 앱에 들어가면 ContentPage 땅으로 돌아갑니다. 맞죠? 하지만 내 Button 와 Entry 는 모두 물질적이고 예쁘다. 여전히 OnPlatform 등을 사용하여 다른 플랫폼에서 다르게 보이게 할 수 있습니까?

기존 앱에서 이 "쉘"을 사용하기 위한 마이그레이션 경로는 어떻게 됩니까? 새로운 MaterialShell 소개하고, 내 앱의 구조와 모양을 설명하고, 새로운 장점을 보기 위해 실행하면 됩니다.

커스터마이징

Flyout 또는 메뉴 항목 모양이 마음에 들지만 디자이너 구성 요소에 맞게 조정해야 하는 경우 옵션은 무엇입니까? 어느 시점에서 "이 모든 것을 스스로 롤링했어야 했다"고 말하고 있는 것을 표준 Xamarin.Forms 앱 구조로 옮기고 있습니까?

MaterialShell 를 완전히 포기해야 하는 경우 스타일링의 장점을 모두 잃고 iOS와 Android 및 UWP 간에 상당히 다르게 보이는 Entry 시작했던 (오늘처럼) 다시 돌아갑니다. ? 하지 않았으면 합니다.

제가 예상하는 전환점이 있습니다. 빠르게 진행하기 위해 이 접근 방식을 사용한 후에는 몇 가지 제한 사항에 도달하고 내 옵션을 탐색해야 합니다. 그것들은 무엇이며 어떤 시점에서 MaterialShell 사용하지 않는 것이 더 낫습니까?

문제

읽는 모든 사람에게 몇 가지 질문을 하며 이 첫 번째 댓글을 마무리하겠습니다.

이 제안이 해결하려는 문제가 잘 정의되어 있습니까?
공유하는 문제인가요?
이 사양을 읽으면서 이전 프로젝트에서 직면한 어떤 문제가 해결될 것이라고 생각합니까?

davidortinau 에 2018년 04월 13일

👍7

가능하다면 스크린샷/디자인 이미지가 더 나아질 것입니다.

또한 다음을 확인하십시오.

http://www.noesisengine.com/webgl/Samples.Buttons.html

TonyHenrique 에 2018년 04월 13일

👍1

@jassmith 전체적인 아이디어를 이미지로

내 쿼리는

태블릿 지원, 다른 레이아웃에 적응하는 앱의 응답성은 해결되지 않습니다.
현재 모델에서 새 모델로의 마이그레이션이 어려울까요? 앱 개발자 관점 및 Xamarin Forms 기여자 관점에서.
나는 대부분의 앱이 플랫폼 특성을 존중하지 않고 단일 UI(동일한 UI 개념을 달성하기 위해 언젠가는 작성해야 하는 사용자 지정 렌더러의 양 때문에)가 필요하다는 것에 동의합니다. 플랫폼별 UI가 있는 앱, 그렇지 않으면 모든 사람이 새로운 표준을 사용해야 합니다.
MaterialShell 내부에 렌더러 개념이 계속 존재합니까?
실제로 iOS에서 이것이 이런 식으로 렌더링되기를 원한다고 말할 수 있습니까? Flutter에는 Android에서 작동하는 Cupertino Styles(apple UI)와 iOS에서 작동하는 Android UI가 있습니다. Xamarin Forms는 어떤 방향으로 이동할 것입니다. 개발자는 지금 flutter가 제공하는 그런 종류의 기능을 가지고 있습니까?

muhaym 에 2018년 04월 13일

👍3

여기에는 부동 레이블/자리 표시자 및 오류 메시지를 지원하는 TextInputLayout과 유사한 항목도 포함됩니까? 그렇다면 wpf와 유사한 'ValidateOnDataErrors'를 포함하도록 Binding 를 확장해야 한다고 생각합니다.

여기에서 내 구현을 참조하십시오.
https://github.com/XamFormsExtended/Xfx.Controls/blob/develop/src/Xfx.Controls/XfxBinding.cs

ChaseFlorell 에 2018년 04월 13일

또한 MaterialShell이 Shell을 확장하여 iOS 모양과 느낌을 위한 HumanInterfaceShell을 만들 수 있는지 궁금합니다.

ChaseFlorell 에 2018년 04월 13일

👍7

@ChaseFlorell 그것도 내 의견이 될 예정이었습니다. 재질은 훌륭하지만 특정 UI 요구 사항에 맞게 자체 쉘을 작성하려는 경우에는 또 다른 문제입니다.

dylanberry 에 2018년 04월 13일

👍8

@davidortinau , @jassmith ,

이 사양을 작성하고 피드백을 제공할 수 있게 해주셔서 감사합니다.

이 제안이 해결하려는 문제가 잘 정의되어 있습니까?

예. 탐색 시스템은 Xamarin Forms에서 완전히 개발되지 않았으므로 이를 완료하거나 완전히 우회하는 방법에 대한 개방형 문제가 있습니다.

공유하는 문제인가요?

예.

이 사양을 읽으면서 이전 프로젝트에서 직면한 어떤 문제가 해결될 것이라고 생각합니까?

나는 그것이 문제를 해결할 것이라고 생각하지 않는다고 말함으로써 이 질문에 대답할 것입니다. 우리의 특별한 문제는 현재의 내비게이션 시스템이 너무 단단하지 않다는 것이지 충분히 단단하지 않다는 것입니다. 가장 명확한 예는 TabbedPage입니다. TabbedView 보기가 없으므로 앱에 탭이 필요하면 TabbedPage를 사용해야 합니다. 따라서 전체 화면은 TabbedPage가 차지해야 하며 자체 버튼이나 화면에 넣을 수 있는 다른 컨트롤에 대한 공간을 사용할 수 없습니다. 내 권장 사항은 페이지의 기능을 다시 상위 계층으로 이동하는 것보다 더 많은 기능을 페이지 _밖_으로 이동하고 보기로 이동하는 것이었습니다.

FloatingMenu 및 FlyoutBehavior와 같은 항목은 탐색이 Xamarin.Forms 시스템에 추가로 하드 코딩되고 소프트웨어 개발자가 추가 제어를 수행할 수 없음을 암시하기 때문에 저를 두렵게 합니다. 좀 더 표준화된 접근 방식을 사용하는 것이 어느 정도 가치가 있다는 것을 알 수 있지만 확실히 비용이 들 것입니다.

우리는 항상 Silverlight, WPF 및 UWP와 같은 다른 XAML 기반 기술에서 작업했습니다. 이러한 기술에서는 탐색 작동 방식을 더 많이 정의할 수 있는 훨씬 더 개방적인 접근 방식이 있습니다. 최근에는 UI/UX 컨설턴트를 고용했습니다. 그는 XF의 단점을 몰랐습니다. 우리는 그에게 우리 소프트웨어의 기능을 기반으로 몇 가지 화면을 만들어달라고 요청했습니다. 그가 추천한 많은 부분은 TabbedView가 없는 것과 같은 이유로 구현할 수 없었습니다. 탐색을 더 쉽게 만드는 대신 이 프레임워크가 실제로 UX/UI 디자이너가 제공한 디자인을 구현하기 더 어렵게 만들까봐 두렵습니다.

내가 말하고 싶은 또 다른 것은 이 프레임워크가 다른 XAML 플랫폼에서는 전례가 없어 보이고 다른 플랫폼과 호환되지 않는 새 프레임워크를 제공하는 것보다 플랫폼 전반에 걸쳐 표준화를 제공하는 데 우선 순위가 있어야 한다는 것입니다. 현재 Silverlight, Xamarin.Forms 및 WPF의 세 가지 플랫폼용으로 빌드하고 있습니다. 우리에게 필요한 것은 편차를 줄이는 것이 아니라 그 이상을 만들기 위해 플랫폼 전반에 걸쳐 표준화하는 것입니다.

@dylanberry ,

특정 UI 요구 사항에 맞게 자체 쉘을 작성하려는 경우에는 또 다른 문제입니다.

예. 이것이 제 관심사입니다. 각 앱에는 고유한 사용 사례가 있으며, 더 엄격해질수록 구현하기가 더 어려워질 수 있습니다.

이 문제도 있습니다. https://github.com/xamarin/Xamarin.Forms/issues/2452#issuecomment -380991817

MelbourneDeveloper 에 2018년 04월 13일

👍7 👎1

나는 위의 내용을 되풀이하고 제스처와 포인터가 어떻게 irt 모양 프리미티브 기능을 하는지 물어볼 것입니다.

RichiCoder1 에 2018년 04월 13일

👍2

일반적인 의견은 시스템에 추가된 모든 코드 행에 대해 버그가 있는 코드가 추가될 가능성이 3번 이상 있다는 것입니다. Xamarin Forms에는 수정이 필요한 버그가 이미 많이 있습니다. 코드가 많을수록 버그가 추가될 가능성이 기하급수적으로 증가합니다. 더 많은 버그가 있을 것입니다. XF 팀은 코드 베이스의 크기를 늘리기 보다는 줄이기 위해 노력해야 한다고 생각합니다. 코드 기반을 줄이는 것이 버그가 발생할 가능성을 줄이는 유일한 방법입니다.

MelbourneDeveloper 에 2018년 04월 13일

👎8 👍5 ❤1

기존 버그를 수정하고 먼저 모든 것이 견고한지 확인하는 대신 새로운 것을 다시 발명하는 이유는 무엇입니까?

opcodewriter 에 2018년 04월 13일

👍4

저에게 그것은 감동받았지만 탐색은 Xamarin Forms의 가장 큰 걸림돌이며 지난 3년 동안 저에게 가장 큰 고통을 안겨주었습니다.

탐색은 MasterDetail 패턴이 있는 세 플랫폼 모두에서 일관되지 않아 햄버거에 많은 문제를 일으켜 페이지를 모달로 푸시해야 합니다. 그런 다음 다시 추가할 수 없기 때문에 사용자 정의 탐색 모음을 구현해야 하지만 Android에서는 애니메이션이 끔찍해 보입니다(심지어 MD).

이상적으로는 대부분의 경우 자신의 ContentView를 사용하여 탐색 모음의 내용을 선택 해제하고 재정의할 수 있어야 합니다. PlatformSpecifics는 원래 도구 모음 항목의 위치를 지정할 수 있는 것으로 논의되었지만(Bryan과 이야기할 때) 제한된 용도로 사용되었습니다.
페이지 팝업 애니메이션과 같은 프레임워크 항목을 재정의하는 기능

제안된 많은 것들이 매우 유용해 보입니다. 특정 페이지에서 머티리얼 셸을 사용할 수 있고 앱 전체에 적용되지 않는 한 코드는 정말 유용합니다. 현재로서는 UX 담당자에게 "Xamarin Forms의 제한 사항입니다"라고 계속해서 말하고 있기 때문에 확실히 우리가 사용할 것입니다(이전 역할에서 했던 것처럼). 감히 말하지만, 이전에 Forms 앱의 스타일을 지정한 UX 관점에서 피드백을 받아야 합니다. XamlC처럼 옵트인해야 합니다.

mackayn 에 2018년 04월 13일

👍5

이름은 확실하지 않지만 FlexShell이 더 이해하기 쉬울 것입니다...하지만 이제 Flexbox가 있습니다.

또한 이것은 테마가 죽었다는 것을 의미합니까? 어쨌든 사용하지 않았습니다.

mackayn 에 2018년 04월 13일

@맥케인

현재로서는 UX 담당자에게 "Xamarin Forms의 제한 사항입니다"라고 계속해서 말하고 있기 때문에 확실히 우리가 사용할 것입니다(이전 역할에서 했던 것처럼).

알겠습니다. 하지만 버그와 제한 사항이 있는 완전히 새로운 구현을 만드는 대신 현재 구현을 수정하거나 개선하는 것이 더 합리적이지 않습니까? 그것은 바로 다음과 같이 말합니다.

MaterialShell은 어떤 점에서 독단적인 API입니다."

진지하게, Xamarin Forms는 얼마나 많은 다른 방향으로 갈 수 있습니까? XF 팀은 최소한 Android 및 iOS에 대한 현재 XF 구현을 수정하는 것을 간신히 유지할 수 있습니다. 버그 수정, XAML 미리 보기 수정, 성능은 어떻습니까?

크로스 플랫폼 솔리드 및 그라디언트 브러시에 대한 간단하지만 훨씬 유용한 지원을 추가하자는 제안으로 누군가가 제안한 티켓이 있었지만 @jassmith의 응답은 문제가 될 수 있다는 것이었습니다. 하지만 이제 이 티켓은 같은 것을 제안합니다.... 더 이상 문제가 되지 않는 방법은 무엇입니까? 그림을 이동

opcodewriter 에 2018년 04월 13일

👍6 ❤1

@opcodewriter

예, 예를 들어 Prism 팀을 방해하는 탐색 이상 현상이 작년에 있었고 문제를 해결할 수 없었습니다.

지금은 건설적인 피드백을 제공하려고 하는 것뿐입니다. Xamarin Forms는 진화의 중요한 시기에 있습니다. 이 API는 앱 전체의 접근 방식이 아닌 유연한 방식으로 구현되는 경우 많은 문제를 해결할 수 있습니다.

mackayn 에 2018년 04월 13일

👍3

@jassmith 는 XF가 Shell에 대해 Flutter 접근 방식(네이티브 컨트롤 대신 렌더링 엔진 사용)을 사용한다는 것을 의미합니까?

mhmd-azeez 에 2018년 04월 13일

여러분, 어제 Jason과 저는 이 사양을 개선하는 방법에 대해 논의했으며 대규모 업데이트를 수행할 예정이며 이를 여러 문제로 분할하고 있습니다.

migueldeicaza 에 2018년 04월 13일

👍15

위의 감정 중 일부를 되풀이하고 싶습니다. 물론 무한한 자원이 없다면 우리가 가진 것을 개선합시다.

ddotlic 에 2018년 04월 13일

👍3 ❤2

ListView 수정(아직도 제대로 작동하지 않는다고 믿기 어렵습니다), CheckBox, RadioButton과 같은 컨트롤 구현, 브러시 지원 구현(SolidColorBrush, GradientBrush), 페이지 기반 팝업 표시 기능 또는 ContentView, 버그 수정(투명한 보기에 대해 보고된 최근 버그 참조), 성능, 도구 등....

왜 새로운 일을 시작하고 싶습니까?????

opcodewriter 에 2018년 04월 13일

👍8 ❤5

@TonyHenrique 예 사진이 좋을 것입니다. 불행히도 나는 예술가가 아니며 내가 참조용으로 사용하는 이미지에 대한 권리를 소유하지 않습니다. 일부 디자인 팀 구성원이 사양에 적합한 이미지를 생성하는 데 도움을 줄 시간이 있기를 바랍니다.

@muham

태블릿 지원. 레이아웃이 태블릿에 맞게 조정되도록 하기 위한 것입니다. 물론 콘텐츠 페이지 내부 에 레이아웃을 지정하는 경우는 다루지 않습니다. 이는 다른 기능입니다. 대체로 나는 새로운 VSM으로 그것을 처리할 것입니다.
대부분 ContentPages를 올바른 위치에 배치하고 새로운 탐색 개념에 적응하는 것입니다. 나는 그것이 항상 사소할 것이라고 말하지는 않겠지만 그것이 쇠약하게 해서는 안 됩니다.
어떤 기능도 제거하지 않습니다. 사실 저는 MaterialShell의 일부 기능을 놓치고 있지만 그렇지 않으면 Shell의 플랫폼별 UI 버전인 Shell 기본 클래스를 포함하도록 사양을 업데이트하는 중입니다.
예. 드로잉을 추가하면 드로잉을 처리하는 방법을 알고 있는 렌더러가 변경됩니다.
예. 계층 구조의 모든 수준에서 사용되는 렌더러를 바꿀 수 있습니다. 렌더러는 리소스 사전의 특수 키로 설정되는 템플릿에 의해 변경될 뿐입니다. 이 템플릿을 원하는 대로 변경하거나 null을 설정하여 비활성화할 수 있습니다.

@ChaseFlorell 아니요, 하지만 사양에 수정 사항을 첨부하려면 제안을 받을 수 있습니다. Shell 대 MaterialShell에 관해서는 위에서 언급했습니다. 1단계는 MaterialShell이 의미가 있는지 확인한 다음 기본 클래스로 나누는 것이 2단계입니다.

@dylanberry 기본 클래스를 사용하면 훨씬 쉽게 만들 수 있습니다. DrawingTemplates를 변경하는 것만큼 간단하지 않습니다. 최적의 성능을 위해 플랫폼별 코드에서 이것의 MaterialShell 측면을 구현하려고 합니다.

@RichiCoder1 제스처가 여기에 올 것이지만 요점은 하위 영역 제스처가 있는 보기가 CommandableSpan API의 일부로 제공되고 제스처가 있는 그림도 지원하도록 확장된다는 것입니다. 그러나 일반적으로 제스처를 사용하지 않고 기본 백엔드가 입력을 처리하도록 하는 것이 좋습니다. 이것은 현재 이 시점에서 MaterialShell 사양과 관련이 없으며 더 자세히 설명하게 되어 기쁘게 생각하는 Drawing 사양에 속합니다. 길고 짧은 것은 DrawingTemplate이 중요한 이유는 렌더러가 슬라이더를 구성하는 방법을 알고 기본 백엔드에서 입력 처리를 계속 처리할 수 있는 여러 도면이 있는 SliderDrawingTemplate을 포함할 수 있기 때문입니다. 이것은 당신이 이것을 해야 한다는 것을 의미하지 않으며, 렌더러를 가능한 한 빠르게 만드는 것은 단순히 선택 사항일 것입니다.

@mackayn a Transitions/Segue API가 곧 출시될 예정입니다. 나는 아직 초기 제안서의 이름을 짓는 중입니다. 확실히 페이지 전환만 단계 1에 있는 단계에서 제공되는 무언가가 될 것입니다. 그러나 프레임워크 애니메이션을 재정의할 수 있습니다. 옵트인에 관해서. 셸은 응용 프로그램의 루트여야 하며 TemplatedPage 외에는 중첩할 수 없습니다. 즉, 내부 통제 테마는 100% 통제할 수 있습니다. 새 템플릿을 켜고 끄는 마법의 스위치에 불과하며 우리와 같은 방식으로 해당 스위치를 제어할 수 있습니다. 이를 통해 페이지, 레이아웃 또는 제어 수준에서 테마를 선택하거나 선택 해제할 수 있습니다.

@encrypt0r 정확하지 않습니다. 하이브리드라고 생각하시면 됩니다. 렌더링을 허용하지만 후드 아래에서는 모든 플랫폼별 컨트롤이 드로잉 코드로 테마가 됩니다. 그러나 쉽게 추가할 수 있는 Ski에 탈출용 해치가 있습니다(v1 근처에서 만들어지는지 의심스럽긴 하지만).

@opcodewriter ListView2(실제로 이름이 지정되지는 않음)는 마침내 올해 로드맵에 있습니다. 왜 새로운 ListView인가? 원래 API는 이전 버전과의 호환성을 완전히 깨뜨리지 않고는 효과적으로 고칠 수 없는 거의 무한한 수의 버그와 문제를 야기합니다. Cell/ViewCell 및 ItemsView와 같은 것그리고 TemplatedItemsList는 1.0에서 의도한 대로 잘 작동했지만 API의 현대적인 사용에 필요한 기능을 거의 수행하지 못했습니다.

불행히도 ListView 유형 자체 내에서 이 문제를 해결할 방법이 생각나지 않으며 커뮤니티에서도 불행히도 그렇게 할 수 없었다고 생각합니다. 현재 최선의 선택은 ListView를 있는 그대로 유지한 다음 오버헤드가 적고 부기장이 적으며 존재할 필요가 없는 덜 이상한 유형으로 훨씬 더 매끄럽게 만들고 대상 프레임워크가 최선을 다하는 것을 신뢰하는 것입니다.

우리가 할 수 없는 거대한 backcompat 변경 사항이 될 이전 재활용 전략을 제거하기만 하면 Xamarin.Forms 코드베이스의 상당한 부분이 제거됩니다. ListView2는 가드레일(또는 Cell의 경우 2개의 서로 다른 내부 프로젝트의 부정한 합병)이 되도록 의도된 이러한 항목을 제거하여 금속에 훨씬 더 가까이 다가갈 수 있도록 해주며 이제는 모두에게 피해를 줍니다.

오래된 캐싱 전략은 오늘날 존재하는 모든 렌더러에 영향을 미칩니다. 모든 렌더러가 요소 변경을 지원하는 이유입니다. 그것이 나의 최선의 추정에 의해 사라지면 프로젝트에 있는 모든 코드의 약 10%가 사라집니다. 정말 프로젝트의 가장 큰 암입니다.

jassmith 에 2018년 04월 14일

❤6 👍4

@davidortinau 귀하의 의견은 너무 멋진 형식을 가지고 있기 때문에 얻을 수 있습니다!

이 접근 방식을 사용하여 최상위 수준에서 애플리케이션을 설명하면 다음과 같은 결과를 얻을 수 있습니다.
모든 플랫폼에서 동일하게 보이도록 테마가 있는 앱
머티리얼 디자인(이 경우) 기본적으로 패턴 켜짐
구성으로 활성화된 최신 탐색 패턴
iOS, Android 및 UWP에서 동일하게 보이도록 항목 또는 버튼을 사용자 지정하기 위해 노력할 필요가 없습니까?
정확합니까? 강조해야 할 다른 이점은 무엇입니까?

네 맞습니다. 강조할 수 있는 다른 이점이 많이 있지만 일단 사용하기 시작하면 분명해집니다. 하단 시트와 마찬가지로 FAB를 사용하고 URL을 사용하여 탐색(업데이트 예정) 등 훨씬 더 많은 작업을 수행할 수 있습니다.

앱 대신 MaterialShell이 있습니다. 이점을 얻으려면 새로운 최상위 애플리케이션 패러다임을 학습/채택해야 합니까?

잘못된. 앱 MainPage는 MaterialShell입니다. 애플리케이션은 여전히 앱 루트입니다.

내 앱에 들어가면 ContentPage 랜드로 돌아갑니다. 맞습니까? 그러나 내 모든 버튼과 항목은 물질적이며 아름답습니다.

위에서 틀린 부분을 제외하고는 맞습니다.

여전히 OnPlatform 등을 사용하여 모양(또는 동작)을 다른 플랫폼에서 다르게 할 수 있습니까?

예.

기존 앱에서 이 "쉘"을 사용하기 위한 마이그레이션 경로는 어떻게 됩니까?

Google Play 스토어 재현 사례를 살펴보고 모든 앱의 현재 페이지를 거기에 넣는 것을 상상해 보세요. 이것은 앱에서 Nav/Tab/MD 페이지를 직접 사용하는 영역만 대체합니다. ContentPages에는 영향을 미치지 않습니다.

새로운 MaterialShell을 소개하고 앱의 구조와 모양을 설명하고 새로운 장점을 보기 위해 실행합니다.

빙고

플라이아웃 또는 메뉴 항목의 모양이 마음에 들지만 디자이너 구성 요소에 맞게 조정해야 하는 경우 옵션은 무엇입니까?

헤더, 헤더 축소 및 숨기기 방법을 완전히 제어할 수 있습니다. 플라이아웃에서 각 "셀"(셀이 아님)의 모양/느낌을 완전히 제어합니다. 거기에 있는 각 그룹의 헤더도 완전히 제어할 수 있습니다. 사실상 모든 것의 "모양"을 제어하지만 추가 콘텐츠를 배치할 수 있는 몇 가지 추가 위치를 추가해야 합니다.

어느 시점에서 "이 모든 것을 스스로 롤링했어야 했다"고 말하고 있는 것을 표준 Xamarin.Forms 앱 구조로 옮기고 있습니까?

Google Play 스토어 물리적 레이아웃 플라이아웃이 원하는 것과 완전히 다르게 보이는 경우. 약간 다르지 않고 완전히 다릅니다.

MaterialShell을 완전히 포기해야 하는 경우 스타일 지정을 모두 잃게 되며 iOS와 Android 및 UWP 간에 상당히 다른 항목을 보고 시작했던 곳(오늘처럼)으로 돌아갑니까? 하지 않았으면 합니다.

No MaterialShell은 자식이 가져오도록 일부 기본 리소스를 설정하는 것입니다. 스스로 할 수 있을 것입니다. 어쨌든 해야 할 수도 있지만 실제로 MaterialShell이 기본적으로 그렇게 하도록 약속하지 않았습니다. 옵트아웃 대신 옵트인으로 설정하면 모든 하위 트리에 대한 단일 API 호출이 됩니다.

제가 예상하는 전환점이 있습니다. 빠르게 진행하기 위해 이 접근 방식을 사용한 후에는 몇 가지 제한 사항에 도달하고 내 옵션을 탐색해야 합니다. 그것들은 무엇이며 어떤 시점에서 MaterialShell을 사용하지 않는 것이 더 낫습니까?

의도는 쉘이 아닌 것이 더 나을 수 없다는 것입니다. Material을 원하지 않을 수도 있지만 항상 Shell을 원해야 합니다(다시 Shell 기본 클래스가 제공됩니다). 왜요? 셸의 모양/느낌을 훨씬 더 구성할 수 있고 탐색 스토리가 훨씬 더 통합되며 셸에서 할 수 없는 다른 페이지에서 할 수 있는 정상적인 일은 없어야 합니다.

더 나은 점은 Shell 렌더러가 실제로 쉽게 구성되고 정상인지 확인하는 것입니다. 마법의 히든 클래스도 없고, 우리가 하드 뎁스(hard deps)를 사용하는 커스텀 네이티브 뷰 서브클래스도 아닙니다. 가능한 한 렌더러의 모든 구성 요소를 구성하고 교체할 수 있습니다. 그렇게하면 원하는대로 작동하지 않으면 실제로 수정할 수 있습니다 ...

왜 우리는 처음에 그것을 하지 않았습니까? 초창기에는 디자인 목표가 아니었고 결국 결혼하게 되었습니다... 이것은 충분히 크고 새롭기 때문에 우리가 그 실수를 가지고 다닐 필요가 없습니다.

jassmith 에 2018년 04월 14일

👍5 ❤4

@opcodewriter

진지하게, Xamarin Forms는 얼마나 많은 다른 방향으로 갈 수 있습니까? XF 팀은 최소한 Android 및 iOS에 대한 현재 XF 구현을 수정하는 것을 간신히 유지할 수 있습니다.

버그 수정, XAML 미리 보기 수정, 성능은 어떻습니까?

^^ 이

@migueldeicaza

여러분, 어제 Jason과 저는 이 사양을 개선하는 방법에 대해 논의했으며 대규모 업데이트를 수행할 예정이며 이를 여러 문제로 분할하고 있습니다.

Miguel, 이것은 분명히 큰 일이 될 것입니다. 모든 개발자를 대신하여 말할 수는 없지만 우리 팀은 안정성, 성능 및 유연성의 세 가지를 원한다고 말할 수 있습니다. 우리는 버그 수정을 원합니다. 우리는 앱이 원활하게 실행되기를 원하고 "죄송합니다. 우리 플랫폼에서는 불가능합니다"라고 말하지 않고 UI/UX 디자이너가 제공하는 디자인을 구현할 수 있기를 원합니다. 이 사양은 그 목표에 반하는 것 같습니다. 이는 작업에 더 많은 리소스를 투입해야 하므로 리소스가 안정성, 성능 및 유연성을 확보할 수 있는 여유가 없습니다.

MelbourneDeveloper 에 2018년 04월 14일

👍9 👎3 😕2

이것이 xamarin 형식으로 개발하는 새로운 기본 동작/방법입니까? 아니면 여전히 각 플랫폼별 모양과 느낌으로 앱을 빌드할 수 있는 옵션이 있습니까?

DanielCauser 에 2018년 04월 14일

@DanielCauser 장기적으로 이것이 "기본" 방식이 될 수 있다고 생각하지만 이것이 현재 방식을 대체하지는 않습니다. 사람들이 현재 기본적으로 손으로 만들고 있는 훨씬 더 많은 셸을 제공하는 더 통합되고 현대적인 방법일 것입니다. 게다가 쉘을 단일 컨트롤로 제공할 것이기 때문에 쉘이 어떻게 그려지고 배치되는지에 대해 많이 최적화할 수 있습니다. 더 이상 셸에 대한 3개의 드로잉 패스가 없습니다.

jassmith 에 2018년 04월 15일

❤5

제안하는 개선 사항이 기본 Xamarin Forms 코드의 개선 사항을 통해 이루어진다는 전제 하에 저는 이 아이디어에 신중하게 찬성합니다. 이것이 Forms 위에 더 많은 복잡성을 추가한다면 나는 그것을 사용하지 않을 것입니다.
내 돈을 위해 현재보다 더 유연하고 빠르며 완성된 Forms를 만드는 방향으로 개발자 리소스를 사용하는 것을 훨씬 선호합니다. 그런 일이 발생하면 제안된 모든 새 기능을 여기에서 직접 만들 수 있습니다. 이 경우 DIY는 Xamarin에서 제공하는 일반 도구 키트보다 나와 내 고객에게 더 잘 맞을 것이 거의 확실합니다. 몇 가지 주목할만한 예외를 제외하고 이 제안은 내가 현재 직면하고 있는 문제를 해결하지 못합니다.

programmation 에 2018년 04월 16일

👍3

@jassmith

500개 이상의 열린 문제가 있습니다.
Xamarin Forms는 3년이 지났고 기본 컨트롤 및 기능에 여전히 버그가 있으며 중요한 기능이 여전히 부족하고 성능이 아직 완전히 확정되지 않았습니다(일부 개선이 이루어졌음을 알고 있지만 Android의 성능은 눈에 띄게 낮습니다).
Xamarin Forms 개발 팀은 여전히 규모가 작습니다.

지금 완전히 새로운 기능에 대한 작업을 시작하려는 이유는 무엇입니까? 먼저 위의 내용에 초점을 맞추는 것이 더 합리적이지 않습니까?

ListView와 관련된 위의 귀하의 의견에 대해: 완전히 재설계\교체하는 것을 포함하여 모든 종류의 대담한 채택에 박수를 보냅니다. Xamarin Forms에서 모든 것이 그렇게 좋은 것은 아닙니다. 건드려서는 안 됩니다.

opcodewriter 에 2018년 04월 16일

👍2

@opcodewriter

1) 네 있습니다. 나는 그 문제에 동의하고 개인적으로 추진하는 우선순위 작업 항목을 계속할 것입니다.

2) Android에서의 성능은 이에 대한 원동력의 일부입니다. 이것은 프레임워크가 페이지 전환을 위한 더 많은 헤드업 시간을 제공하므로 JIT 시간과 같은 것을 숨길 수 있습니다. 훨씬 더 지능적으로 페이지를 사전에 로드하고 유지할 수 있습니다. XF 팀이 해결할 수 없는 것은 전체 JIT 시간입니다. AOT가 활성화된 Android에서 앱을 실행하고 훨씬 더 빠른 경우 제가 도와드릴 수 있는 방법은 없습니다.

3) 여기에는 논쟁이 없습니다.

지금 완전히 새로운 기능에 대한 작업을 시작하려는 이유는 무엇입니까? 먼저 위의 내용에 초점을 맞추는 것이 더 합리적이지 않습니까?

이 작업은 예정되어 있지 않으며 여기에서 사양에 대해 논의하고 있습니다. 나의 경영진은 나의 조언에 따라 적절하다고 생각될 때 일정을 잡을 것입니다.

ListView와 관련된 위의 귀하의 의견에 대해: 완전히 재설계\교체하는 것을 포함하여 모든 종류의 대담한 채택에 박수를 보냅니다. Xamarin Forms에서 모든 것이 그렇게 좋은 것은 아닙니다. 건드려서는 안 됩니다.

ListView는 진정으로 Xamarin.Forms의 버그 곰입니다. 500개의 문제 중 220개가 버그로 표시되어 있으며(많은 하우스키핑 또는 개선 문제도 있음) 25% 이상의 북쪽은 ListView와 관련이 있습니다. 비교를 위해 전체 UWP 플랫폼과 관련된 비율과 거의 같습니다. 기본적으로 폐기 후 렌더러가 사용되는 것으로 설명되는 Android의 더 나쁜 수는 ListView 버그이기도 하지만 ListView가 검색 쿼리에 아무데도 표시되지 않기 때문에 내 검색에 표시되지 않을 것입니다.

jassmith 에 2018년 04월 16일

@jassmith는 기존 문제를 수정하는 것
- 진정한 팝업 지원(기본 및 공통 기능은 여전히 없음)
- 뒤로 탐색할 때 페이지 탐색 취소(오랜 미해결 문제)
- 기본 컨트롤 누락(CheckBox, RadioButton 등 없음)
- 크로스 플랫폼 드로잉(캔버스 컨트롤 또는 다른 방법)
- 솔리드\그라디언트 브러시의 플랫폼 간 그리기 지원(SolidColorBrush, GradientBrush)

프레임워크를 더 풍부하게 만드는 방향으로 더 많은 작업이 수행되고 CSS 스타일이나 Flexbox(자체 문제와 함께 제공됨)와 같은 항목을 추가하지 않기를 바랍니다.

opcodewriter 에 2018년 04월 16일

@opcodewriter

진정한 팝업 지원(기본 및 공통 기능은 여전히 없음)

공평하게, 현실이 될 만큼 높은 우선 순위를 얻지는 않는 것 같습니다. 이것은 실제로 어느 시점에서 꽤 많이 진행되었습니다.

뒤로 탐색할 때 페이지 탐색 취소(오래 해결되지 않은 문제)

이것은 실제로 MaterialShell이 해결하고자 하는 것입니다. 이것이 NavigationPage에서 수행될 수 없는 꽤 확실한 이유가 있습니다.

기본 컨트롤 누락(CheckBox, RadioButton 등 없음)

이들 중 일부는 현재 진행 중인 F100 이니셔티브의 일부입니다.

크로스 플랫폼 드로잉(캔버스 컨트롤 또는 다른 방법)

이것은 #2452에 명시된 것과 같이 이것에 대한 자매 API가 될 것입니다.

단색/그라디언트 브러시의 플랫폼 간 그리기 지원(SolidColorBrush, GradientBrush)

위와 같은 답변입니다.

jassmith 에 2018년 04월 16일

@jassmith

공평하게, 현실이 될 만큼 높은 우선 순위를 얻지는 않는 것 같습니다. 이것은 실제로 어느 시점에서 꽤 많이 진행되었습니다.

좋습니다. 2018년 말까지 우선 순위를 정하기를 기대합니다. :)

이것은 실제로 MaterialShell이 해결하고자 하는 것입니다. 이것이 NavigationPage에서 수행될 수 없는 꽤 확실한 이유가 있습니다.

이것이 현재 구현에서 수행할 수 없는 이유를 자세히 설명해 주시겠습니까?

이들 중 일부는 현재 진행 중인 F100 이니셔티브의 일부입니다.

알 겠어요. 손가락이..

opcodewriter 에 2018년 04월 16일

이것이 현재 구현에서 수행할 수 없는 이유를 자세히 설명해 주시겠습니까?

우리가 트랙에서 크게 벗어나고 있기 때문에 여기서 더 자세히 다루지는 않겠지만 요지는 다음과 같습니다.

iOS에서는 뒤로 스와이프 제스처를 반응적으로 취소할 수 없습니다. 이것이 사람들이 더 큰 전화로 다시 탐색하는 데 사용하는 주요 방법이기 때문에 이것은 눈에 띄는 누락이 됩니다.
iOS에서 이 동작을 재정의하는 것이 기술적으로 가능하지만 iOS의 새 버전이 나올 때 실제로 지원되거나 작동할지 확신할 수 없는 방식으로 UINavigationController의 내부에 상당히 깊이 들어가야 합니다. 간단히 말해서 Apple은 사람들이 이 일을 하는 것을 별로 좋아하지 않는 것 같습니다.

스타일링에 미치는 영향과 관련하여 다른 사소한 우려도 있습니다. 그러나 긴 이야기는 짧습니다. 이 특정 기능에 대해 여전히 논의하고 싶다면 새 호를 여는 것이 좋습니다. :)

jassmith 에 2018년 04월 16일

@jassmith
난 그냥 처리 생각했다 gestureRecognizerShouldBegin 같은 및 전화 뭔가 OnBackButtonPressed 충분합니다.

opcodewriter 에 2018년 04월 16일

전반적으로 나는 내가 읽고 있는 많은 것을 정말로 좋아하지만 이것은 핵심 Xamarin Forms nuget/repo에서 수행되어야 하는 것과 같지 않습니다.

이것은 Xamarin Forms에 기본 제공되는 것이 아니라 그 위에 구축되어야 하는 독단적인 접근 방식입니다. 저는 이것을 개발자가 다른 접근 방식을 취할 수 있도록 하는 별도의 라이브러리로 봅니다. 노출해야 하는 Xamarin Forms의 필수 부분이 있어야 하며 이는 해당 비트 위에 빌드되어야 합니다.

개발자가 Xamarin Classic/Native 또는 Xamarin Forms를 사용하기로 결정할 때와 마찬가지로 Xamarin Forms 또는 Xamarin Forms with Shell을 사용하기로 결정하는 것과 유사한 결정을 볼 수 있습니다.

Xamarin Forms는 플랫폼을 서로 닮도록 맞추려고 하지 않고 최고의 크로스 플랫폼 UI 프레임워크를 만드는 데 중점을 두어야 합니다. 오늘날 Xamarin Forms는 플랫폼 느낌이 존중되도록 하는 훌륭한 작업을 수행합니다.

기본 셸이 Xamarin Forms 리포지토리에 있고 셸 처리와 관련된 일부 코드가 있는 것을 볼 수 있지만 Material Shell이 특정 디자인 언어 및 탐색 패턴에 너무 밀접하게 결합되어 있어 Xamarin Forms 리포지토리에 있어야 한다고 생각하기에는 어렵습니다.

MisterJimson 에 2018년 04월 17일

👍5

@MisterJimson
의견을 보내 주셔서 감사합니다. 공개 API 노출 영역의 정확한 위치는 아직 결정되지 않았습니다. 두 접근 방식 모두 장단점이 있습니다.

사양은 Shell과 MaterialShell 클래스를 모두 포함하도록 업데이트될 예정입니다. MaterialShell 클래스는 핵심에서 벗어나는 것을 고려하는 부분입니다. Shell은 귀하가 설명한 것입니다.

jassmith 에 2018년 04월 18일

Shell breakout 및 탐색 사양 업데이트로 업데이트됨

jassmith 에 2018년 04월 18일

기존 XF 구현이 만들어지면 정말 좋겠습니다. BCL의 일부가 아닌 애드온으로 이와 같은 것을 사용할 수 있도록 하는 것이 더 강력하고 더 좋습니다. 따라서 정확하고 안정적인 강력한 기반 플랫폼을 보유하면 기존 앱과 이와 같은 새로운 계층에 도움이 될 것입니다.

이 물건의 발전을 기대합니다.

tpetrina 에 2018년 04월 18일

@jassmith @brianlagunas

단지 몇 가지 관찰.

BackButtonBehavior, 전혀 원하지 않는 경우에 대비하여 가시성 속성이 있어야 합니까?
Materialshell 탐색 체계는 Prism과 비슷합니다. 이러한 기존 프레임워크에서 작동합니까? (프리즘, FreshMVVM, MVVMCross)
탐색 모음에서 레이아웃을 완전히 재정의할 수 있습니까? 그대로 Forms는 이와 관련하여 매우 제한적이며 새로운 버전의 Forms가 사용자 정의 코드를 손상시킬 가능성이 높다는 사실을 알고 안전하게 사용자 지정 렌더러 경로를 따라가도록 하는 투박한 탐색 모음으로 끝납니다.
MasterDetail은 많이 다루지 않습니다. 플라이아웃 메뉴를 사용자 정의할 수 있습니까?
우리는 햄버거에 대해 어떤 통제권을 갖게 될까요?

나는 단지 기존의 문제점과 한계가 해결될 뿐만 아니라 새로운 기능이 새로운 기능을 갖추도록 하고 싶습니다.

mackayn 에 2018년 04월 18일

잘 들린다.

저는 XF를 처음 접했지만 프레임워크는 다소 취약하다는 평판을 얻었지만 확실히 이것은 여러분의 노력 덕분에 빠르게 개선되고 있습니다.

그래서 그것이 가치있는 것에 대해 이것은 내 의견입니다 :-)

또한, 금형 및 기술적 부채 상환과 함께 할 수있는 프레임 워크를 모두 자 마린 순간에 많은 사랑을 받고하지만 @opcodewriter에 동의하는 것이 좋아요.

나는 또한 이것이 다른 계층이어야 한다는 @MisterJimson 의 생각을 좋아합니다. 그러나 당신은 당신의 능력과 얼마나 많은 프레임워크를 지원할 수 있는지에 대해 스스로에게 정직해야 합니다. 우리 모두는 새롭고 반짝이는 것들을 코딩하고 어려운 결정을 피하는 경향이 있지만, 우리는 우리 코드의 견고한 기반을 개발하기 위해 당신에게 의존합니다.

다른 사람의 코드에 대해 걱정하지 않고 내 코드를 작동시키는 데 충분한 문제가 있습니다 :-)

XF는 현재 좋은 위치에 있으며 정말 견고한 도구 세트가 될 가능성이 있습니다.

이것에 대한 모든 노력에 감사드립니다.

stevehurcombe 에 2018년 04월 18일

@맥케인

BackButtonBehavior, 전혀 원하지 않는 경우에 대비하여 가시성 속성이 있어야 합니까?

CanExecute가 false를 반환하여 명령을 설정합니다. 나는 잠시 동안 보조 방법을 추가하지 않기로 결정했습니다.

Materialshell 탐색 체계는 Prism과 비슷합니다. 이러한 기존 프레임워크에서 작동합니까? (프리즘, FreshMVVM, MVVMCross)

나는 확실히 그렇게 바랍니다! 확신할 수는 없지만 나는 그들과 그들의 모든 문제를 생각하고 있었습니다. 예를 들어 모든 탐색이 단일 이벤트를 통해 발생하는 이유입니다.

탐색 모음에서 레이아웃을 완전히 재정의할 수 있습니까? 그대로 Forms는 이와 관련하여 매우 제한적이며 새로운 버전의 Forms가 사용자 정의 코드를 손상시킬 가능성이 높다는 사실을 알고 안전하게 사용자 지정 렌더러 경로를 따라가도록 하는 투박한 탐색 모음으로 끝납니다.

이 부분이 더 어렵습니다. 여기에서 가능한 한 많은 확장성을 허용하고 싶지만 이 기능을 제정신이고 합리적인 방식으로 개선하는 방법에 대한 제안은 정말 열려 있습니다.

MasterDetail은 많이 다루지 않습니다. 플라이아웃 메뉴를 사용자 정의할 수 있습니까?

헤더를 임의의 보기로 설정하고, 그룹 헤더 및 항목에 사용되는 템플릿을 제어하고, 메뉴 항목을 추가할 수 있습니다. 레이아웃의 일부 측면을 제어하지만 100%는 아닙니다. 다시 한 번 당신이 필요하다고 생각하는 것에 대해 몇 가지 생각을 해보는 것이 좋을 것입니다. 바닥글 동작 속성이 있는 바닥글의 필요성을 분명히 알고 있습니다.

우리는 햄버거에 대해 어떤 통제권을 갖게 될까요?

BackButtonBehavior는 햄버거도 재정의합니다. 아마도 이름을 바꿔야 할 것입니다. 여기에서 다시 제안을 받습니다. 원래 LeftBarButton이라고 불렀지만 RTL 상황에서는 왼쪽에 있지 않습니다...

jassmith 에 2018년 04월 18일

👍1

@stevehurcombe 기술적 투자 회수는 계속 진행 중입니다. 이것은 팀의 훨씬 더 작은 파견대에 의해 동시에 실행될 것입니다. 불행히도 현실은 이 사양의 많은 부분이 이상한 방식으로 기술적인 회수에 관한 것입니다. Xamarin.Forms는 1.0 릴리스와 함께 엄청난 양의 API 부채를 발생시켰고 그 이후로 계속 그 부채를 지고 있습니다. XF의 어떤 것들은 단순히 API가 표현하는 방식 때문에 제대로 작동하게 하기가 매우 어렵거나 심지어 제대로 작동하게 하는 것이 불가능합니다.

탭 표시줄과 탐색 표시줄 간의 긴밀한 상호 작용이 그러한 영역 중 하나이므로 MDP의 탭 또는 항목 간 탐색에 결함이 없는지 확인하는 것은 또 다른 영역입니다. 각 요소가 앱의 셸을 전체적으로 볼 수 없기 때문에 작은 문제가 발생하는 영역이 많이 있습니다.

툴링과 관련하여 완전히 별도의 팀이 이 작업을 전담하고 있으며 큰 발전을 이루고 있습니다. 내부 도구는 지난 6개월 동안 크게 개선되었으며 여러분이 그것을 사용해 보기를 정말로 기대합니다!

jassmith 에 2018년 04월 18일

👍1

@맥케인

Materialshell 탐색 체계는 Prism과 비슷합니다. 이러한 기존 프레임워크에서 작동합니까? (프리즘, FreshMVVM, MVVMCross)

두려워하지 마세요 . 커뮤니티가 문제가 여기에 있다는 것을 깨닫기 전에

dansiegel 에 2018년 04월 18일

👍1

@dansiegel

두 팀 모두 대화 중이라는 사실을 알게 되어 기쁩니다. 그것만 알면 됩니다 👍

mackayn 에 2018년 04월 19일

👍2 👎1

@jassmith 이제 XF에서 일부가 실행 중이거나 아키텍처가 최상이 아니라는 것이 분명합니다. 따라서 돼지에게 립스틱을 바르는 대신(여기서 무례한 것은 원하지 않음), 새로운 프레임워크를 처음부터 다시 만들거나 기존 프레임워크를 대규모로 리팩토링하는 것이 어떻습니까? 매우 무섭게 들리겠지만 대다수의 Xamarin Forms 개발자가 신경 쓰지 않을 것이라고 확신합니다. 우리 모두는 앱을 리팩토링하여 훨씬 더 잘 실행되는 앱을 갖게 되어 기쁠 것입니다.
"우리는 이런 종류의 변경을 원하지 않기 때문에" 좋은 리팩토링으로 PR이 거부되는 것을 보았습니다. 누가 그 규칙을 만들었는지 모르지만 그는 심호흡을 하고 긴장을 풀고 "규칙"을 재고해야 합니다.
무엇이 최선입니까? 프레임워크를 유지할 수 없는 프레임워크를 사용하여 개발자를 계속 좌절시키거나 리팩토링 작업을 수행해야 하는 좌절한 개발자를 가집니까? 내 2센트만...

opcodewriter 에 2018년 04월 19일

👎1 👍1

@opcodewriter 당신과 나는 동의하지만 이것은 이 사양에서

jassmith 에 2018년 04월 19일

탐색에 관한 새로운 자료를 읽고 정말 마음에 듭니다. 탐색 명령을 바인딩하고 URL(예: Prism의 영향을 받은 것으로 가정)에 대한 탐색 방향을 지정하는 것이 좋습니다.

RichiCoder1 에 2018년 04월 20일

아이러니하게도 URI 탐색 체계는 예전에 우리가 하고 싶었고 프레임워크에 합리적으로 가져올 수 없었기 때문에 Prism을 구현하기 시작했습니다. 그들의 신용을 받지 않으려면 100% 받을 자격이 있습니다. :)

속기의 정확한 의미는 아직 파악되지 않았습니다.

다음과 같이 끝날 가능성이 높다고 생각합니다.

<Button Command="{segue:Uri}" CommandParameter="app://Foo/Bar/Baz" />

또는

<Button Command="{segue:Push}" CommandParameter="{DataTemplate local:MyPage}" />

따라서 확장은 그들이 취하는 매개변수에 대해 더 정확할 수 있습니다. 네임스페이스는 주로 Intellisense로 쉽게 발견할 수 있도록 유지하는 데 사용됩니다.

jassmith 에 2018년 04월 20일

👍3

@jassmith 이 segue 물건을 정말 좋아합니다. 푸시 모달을 어떻게 지원할 생각인지 여쭤봐도 될까요?

모든 세부 사항을 가지고 있지는 않지만 프리즘처럼 마크업 확장으로 싸인 URL 탐색을 상상할 수 있습니다.

<!-- push -->
<Button Command="{segue:Uri}" CommandParameter="path/to/page" />

<!-- push modal -->
<Button Command="{segue:Uri Modal='true'}" CommandParameter="path/to/page" />

<!-- reset stack -->
<Button Command="{segue:Uri}" CommandParameter="app://root/path/to/page" />

ChaseFlorell 에 2018년 04월 20일

먼저 URI 탐색은 Shell에서만 작동한다는 점에 유의해야 합니다. 이상한 경우 없이 스택을 일관되게 이해할 수 있는 유일한 장소이며 개념을 지원하기 위해 탐색 상호 작용을 설계할 수 있습니다.

지금은 전체 URI만 지원합니다. 부분은 상황에 맞기 때문에 다루기가 훨씬 더 어렵습니다.

현재 위치가 app://Shell/Apps/Games/Details 라고 가정하면 3가지 예가

특히 이것은 현재 ShellItem에 Apps 경로가 있고 현재 ShellTabItem에 Games 경로가 있으며 ContentPage가 경로 세부 정보가 있는 스택에 푸시된 Shell에 있음을 의미합니다.

<!-- push -->
<Button Command="{segue:Uri}" CommandParameter="app://Shell/Apps/Games/Details/page" />

<!-- push modal -->
<Button Command="{segue:Uri}" CommandParameter="app://page" />

<!-- reset stack -->
<Button Command="{segue:Uri}" CommandParameter="app://Shell/Apps/Games" />

쉘 uri에서 첫 번째 위치는 항상 쉘입니다. 그렇지 않은 경우 모달 푸시로 간주됩니다. 다음은 ShellTab이고 ShellTabItem입니다. 그 다음은 ShellTabItem의 탐색 스택을 따릅니다. 현재로서는 가능한 모든 페이지 컨트롤에 URI 탐색을 백포팅할 생각이 없습니다. 이것은 MasterDetailPage를 사용하는 사람들에게 정말 털이 납니다...

jassmith 에 2018년 04월 20일

경로 등록 및 경로 속성을 사용하면 유형 기반 라우팅이 필요하지 않습니다. 사양에서 제거하겠습니다.

jassmith 에 2018년 04월 23일

@jassmith 는 이 탐색

CanExecute 을 처리하는 방법
다중 탭을 사용자에게 제어(읽기 방지)할 수 있는 방법은 무엇입니까?
상대 탐색을 어떻게 처리합니까? IE는 3페이지이고 앞으로 가야 하지만 스택이 완전히 동적입니까?
prism은 NavigationParameters 라는 환상적인 개념을 가지고 있어 쿼리 문자열 /Navigation/MyPage/MyPageDetails?id=33 통해 기본 값뿐만 아니라 복잡한 객체 new NavigationParameters {{nameof(MyObject), MyObject}} 도 전달할 수 있습니다. 비슷한 것을 지원할 계획이 있습니까?

ChaseFlorell 에 2018년 04월 24일

👍2

@ChaseFlorell

1) 세그와 함께? 현재는 할 수 없습니다. 확실히 더 생각해봐야 합니다. segue 명령을 내리는 방법이 있지만 그것은... 짜증난다. 그렇게 하면 처리할 수 있지만 그 시점에서 정말 가치가 없습니다.

2) Segue는 푸시가 완료될 때까지 자체적으로 비활성화됩니다. 이전 탐색 작업이 완료될 때까지 no-op 명령을 활성화하려고 추가로 시도합니다.

3) 세그와 함께 푸시/팝과 같은 기존 탐색을 사용할 수 있습니다. 이는 상대적인 조치입니다.

4) [QueryParameterAttribute]는 이미 존재하거나 존재하지 않을 수 있습니다. 확인도 거부도 할 수 없습니다. ;)

복잡한 개체 지원을 추가할 가능성은 거의 없습니다. 아이디어는 변환기를 사용하여 간단한 값을 가져와 복잡한 개체로 바꾸는 것입니다.

jassmith 에 2018년 04월 24일

👍2

(P & P에 다시 CAB-복합 UI 응용 프로그램 블록에서) URI 기반 응용 프로그램 탐색을 구축 과거의 경험에서, 나는 강하게 당신이 사용하지 않는 게 좋을 것 System.Uri 유형을 대신 단지 URI처럼 모든 것을 보이게, 그러나 URI 구현 자체를 사용하지 마십시오. @pprovost 는 평생 그에게 남겨진 노동의 상처를 증언할 수 있습니다. 인터넷 URI 제한 및 오류(예: 호스트 이름)에 직면했을 때 수많은 문제를 겪었던 것을 기억합니다.

kzu 에 2018년 04월 28일

이미 피해를 입은 부분이 있다고 생각합니다.

kzu 에 2018년 04월 28일

실제로 System.Uri는 URI 기반 탐색 체계를 지원할 때 가장 좋은 선택입니다. CAB는 URI 탐색을 사용했지만 System.Uri 개체 대신 문자열을 사용할 수 있도록 하여 URI처럼 보이게 만들었습니다. 호스트 이름은 절대 필요하지 않았습니다.

당신이 요구하는 것은 예측 가능한 결과를 생성하지 않는 어떤 문자열 구문도 허용할 수 있는 매우 느슨한 문자열 기반 API입니다. URI/문자열 기반 탐색 체계가 작동하려면 규칙이 있어야 합니다.

brianlagunas 에 2018년 04월 29일

임의의 URI는 XF에서도 작동하지 않습니다. URL에서 유효하지 않지만 파일 시스템에서 유효한 문자 목록은 정확히 작지 않습니다. 이것들은 모두 문자열이 작동하는 경우이며 URI는 이스케이프하거나 사용자가 작동하지 않는(또는 실패하는) 이유를 파악하고 "URI 안전"으로 이름을 바꾸지 않아도 되며 필요하지도 않을 것입니다.

더 제한적인(또는 더 나은 의미론/파싱/검증?) 자신의 추상화를 구성할 수 있지만 IMHO, System.Uri 는 무료가 아닌 많은 인터넷 수하물을 가져옵니다. 이것은 Mono/MonoDevelop이 경로를 나타내기 위해 고유한 FilePath 를 생성한 방식과 유사하며 일반적으로 문자열입니다.

적어도 모든 URI는 상대적인 것으로 간주되어 작업을 단순화합니다. CAB에서는 스키마 및 호스트 이름 부분과 함께 절대 uri를 사용했는데 문제가 있었습니다.

Uri 보다 ResoucePath 와 같은 것을 훨씬 선호합니다. 하지만 이 게임 후반부에는 어쨌든 거래가 완료되었다고 확신합니다.

kzu 에 2018년 04월 29일

파일 시스템 경로가 무엇과 관련이 있다고 생각하는지 잘 모르겠습니다...

시스템을 혼동하기 위해 URI를 어떻게 사용하겠습니까? 스키마와 호스트 이름을 무시하고 경로를 찾기 시작합니다([az]로만 제한됨). 어떤 이상한 문자를 넣어도 찾을 수 없으면 그냥 멈춥니다. 그리고 입력한 쿼리 문자열은 유효한 C# 식별자여야 합니다. 그렇지 않으면 단순히 일치하지 않습니다. 쿼리 문자열 데이터의 이스케이프된 데이터는 이스케이프되지 않습니다.

jassmith 에 2018년 04월 29일

@kzu URI는 XF에서 잘 작동하며 파일 시스템 스키마보다 XF에 더 적합합니다. 실제로 웹사이트에서 앱을 시작할 때 URI가 필요합니다. Prism 구현을 보고 URI 기반 탐색이 얼마나 강력한지 확인해야 합니다. URI 기반 탐색 체계를 사용하여 Prism으로 구축된 모든 앱 중에서 잘못된 문자와 관련된 문제가 제출된 적이 없습니다. XF 플랫폼의 URI 기반 스키마에 대한 귀하의 우려는 문제가 되지 않을 것이라고 확신합니다.

brianlagunas 에 2018년 04월 29일

맞는 말이다. Prism @brianlagunas에 대한 배경 정보에 감사드립니다! 이제 사양을 주의 깊게 읽고 실제로 유용한 피드백을 제공해야 합니다. ;)

kzu 에 2018년 04월 29일

매우 좋은 이니셔티브이지만 고객을 위해 "특별한" 작업을 수행하기 위해 적절한 가상 방법 또는 기타 방법을 만들어 확장성과 사용자 지정이 고려되기를 바랍니다.

예를 들어 가능할까요 / 어떻게:

예를 들어 아이콘이 있는 배지를 표시하는 탭 확장성. 또는 "더보기" 또는 " * " 버튼과 같은 팝업 창을 위에 표시합니다.
사용자 지정 스낵바(예: 사용자 지정 배경/전경 색상으로 방금 수행한 작업에 대한 "실행 취소" 버튼 포함)
가장 빠른 탐색을 제공하기 위해 애니메이션이 없는 것과 같이 셸에 프로그래밍된 기본 애니메이션과 다른 애니메이션을 사용하여 Android에서 프래그먼트 푸시.

기술 정보: 쉘이 페이지를 재활용하여 페이지를 두 번 탐색하면 기본 요소가 그 아래에 있는 다른 VM과 함께 재사용됩니까?

rogihee 에 2018년 05월 05일

안녕하세요 @rogihee

구현에 대한 귀하의 피드백을 환영합니다. 확장 가능하다고 생각합니다. https://github.com/xamarin/Xamarin.Forms/blob/9558f2837280e02b41848d3a3c3213d49a664751/Xamarin.Forms.Platform.iOS/Renderers/ShellRenderer.cs

Android는 현재 여전히 활발히 개발 중이지만 동일한 접근 방식을 사용합니다.

jassmith 에 2018년 05월 06일

@rogihee 페이지 재활용에 건전한 방법을 알아 내려고 노력하고 있습니다. 일반적으로 명시적으로 옵트인해야 하므로 현재는 그렇지 않습니다.

jassmith 에 2018년 05월 06일

이 "Create*" 옵션이 좋아 보입니다. 이것에 대한 빠른 진행을 보는 것이 좋습니다!

요소를 재사용하면 성능에 영향이 있는지 궁금합니다. 개인적으로 나는 더 높은 Mem/CPU 사용량보다 앱의 속도와 "유연한" 느낌을 우선시합니다(물론 결국 어딘가에 상관 관계가 있지만). 그리고 다른 무엇보다 iOS / Android를 우선시하십시오 :-).

rogihee 에 2018년 05월 06일

Shell은 유동성에 대한 인식에 매우 중점을 둡니다. 아직 어디에나 있지는 않지만 함께 오고 있습니다.

쉘이 설계된 부하를 처리할 수 있는지 확인하기 위해 쉘로 미친 짓을 하려는 초기 사용자를 확보해야 합니다.

jassmith 에 2018년 05월 06일

@jassmith mig는 Build에서 3분 동안 쉘을 언급했습니다.....

juepiezhongren 에 2018년 05월 11일

나는 그의 아빠가 아니다

jassmith 에 2018년 05월 11일

timahrentlov 에 2018년 05월 23일

세계의 현재 상태와 일치하도록 API를 업데이트했지만 여전히 샘플을 업데이트해야 합니다.

jassmith 에 2018년 06월 05일

일부 업데이트된 샘플을 추가했지만 속기 구문을 사용할 때 다른 샘플을 수정하고 경로 설명을 업데이트해야 하는 많은 작업을 수행해야 합니다(간단한 경로를 얻음에 따라!)

jassmith 에 2018년 06월 05일

👍1

이런, 파티에 너무 늦게 온 것 같아. 훌륭한 글과 토론. 나는 그것을 모두 훑어보고 (공항에서 미안합니다) 내 자신의 제안이 있습니다. 다른 곳에서 언급했다면 죄송합니다.

@jassmith @migueldeicaza 탐색 모음에 동작을 추가하여 ListView가 스크롤될 때 스크롤되고 반대 방향으로 스크롤될 때 표시되도록 동작을 추가해 주 시겠습니까 ? 거의 모든 전문 앱이 더 많은 부동산을 보여주기 위해 이 작업을 수행합니다. 이것은 소형 장치에서 특히 유용합니다.

또 다른 하나는 이해하기 쉽도록 XAML 태그의 이름을 바꾸지 않는 이유입니다. ShellSection 대신 Tab을 사용하시겠습니까? 이제 ShellX 태그가 많이 있습니다.

adrianknight89 에 2018년 06월 09일

iOS의 경우 탐색 모음에서 스크롤 모드를 활성화하기 위해 켜고 끄는 속성이 있다고 생각합니다. Android의 경우 새 레이아웃(CoordinatorLayout, AppBarLayout 등)을 사용하기 시작해야 합니다. XF의 Android 구현은 여전히 기본 컨테이너로 RelativeLayout을 사용하고 있기 때문에 이와 관련하여 상당히 구식입니다. 이 특정 문제에 대한 개선 티켓이 어딘가에 있다고 생각합니다. Shell이 다양한 스크롤 모드를 지원하는 것을 보고 싶습니다.

또한 페이지에 오류/다른 유형의 팝업을 표시하기 위해 사용자 지정 동작을 구현해야 하는 경우가 많습니다. Shell은 이 기능을 즉시 지원해야 하므로 타사 플러그인에 의존하거나 복잡한 UI 계층을 만들 필요가 없습니다.

adrianknight89 에 2018년 06월 09일

@adrianknight89

ListView가 스크롤될 때 스크롤되고 반대 방향으로 스크롤될 때 표시될 수 있도록 탐색 모음에 동작을 추가해 주시겠습니까? 거의 모든 전문 앱이 더 많은 부동산을 보여주기 위해 이 작업을 수행합니다. 이것은 소형 장치에서 특히 유용합니다.

그것이 내가 정말로 할 수있는 올바른 방법을 알아 내려고 노력하는 것입니다. 불행히도 모든 플랫폼이 이 기능을 지원하는 것은 아니므로 결국 플랫폼별 거래가 될 것입니다. Android는 최소한 이를 지원하기 위해 처음부터 구축되었으므로 여전히 작동하는지 확인하기 위해 가끔 켭니다.

또 다른 하나는 이해하기 쉽도록 XAML 태그의 이름을 바꾸지 않는 이유입니다. ShellSection 대신 Tab을 사용하시겠습니까? 이제 ShellX 태그가 많이 있습니다.

여기 네이밍은 정말 어렵습니다. ShellTab은 상단과 하단에 대해 약간 혼란스럽습니다. 대신 더 일반적인 계층적 이름을 선택했지만 이름 지정에 만족하지 않는다는 점을 인정해야 합니다. 제안은 100% 환영합니다... 그들의 이름을 다시 리팩토링하기를 완전히 기대하지는 않지만 무엇을 할 수 있습니까...

iOS의 경우 탐색 모음에서 스크롤 모드를 활성화하기 위해 켜고 끄는 속성이 있다고 생각합니다. Android의 경우 새 레이아웃(CoordinatorLayout, AppBarLayout 등)을 사용하기 시작해야 합니다. XF의 Android 구현은 여전히 기본 컨테이너로 RelativeLayout을 사용하고 있기 때문에 이와 관련하여 상당히 구식입니다. 이 특정 문제에 대한 개선 티켓이 어딘가에 있다고 생각합니다. Shell이 다양한 스크롤 모드를 지원하는 것을 보고 싶습니다.

Shell은 CoordinatorLayout + AppBarLayout을 사용하고 기본적으로 당분간 스크롤 지원을 "비활성화"하지만 작동합니다. iOS 스크롤 오프도 구현하기 쉽습니다. 불행히도 UWP의 NavigationView는 이 기능을 지원하지 않습니다.

또한 페이지에 오류/다른 유형의 팝업을 표시하기 위해 사용자 지정 동작을 구현해야 하는 경우가 많습니다. Shell은 이 기능을 즉시 지원해야 하므로 타사 플러그인에 의존하거나 복잡한 UI 계층을 만들 필요가 없습니다.

예, 예가 필요합니다 :)

jassmith 에 2018년 06월 09일

@jassmith

James Montemagno의 연결 플러그인을 사용하여 데이터 연결 상태의 변경 사항을 수신하고 있습니다. 인터넷 연결이 끊어지면 인터넷이 다시 온라인 상태가 될 때까지 슬라이드/페이드 아웃 및 정지 상태로 유지되는 알림을 표시하는 것이 좋습니다.

Instagram에서 이 알림은 탐색 모음 바로 아래에 있습니다. Tumblr에서 하단 탐색 모음 바로 위에 있습니다. YouTube에서는 이상하게도 하단 탐색 모음 아래에 있습니다. 아마도 이와 같은 것이 Shell의 일부가 될 수 있습니까?

내가 아는 한 제안된 팝업 컨트롤은 가볍게 닫을 수 있지만 기존 창을 오버레이하는 것입니다. 방금 언급한 알림과 잠재적으로 다른 유형의 알림은 부모 창을 오버레이할 필요가 없으므로(즉, 부모 시각적 트리는 여전히 제스처에 반응함) Popup이 적합한지 확실하지 않습니다.

Shell은 이 View(Notification[View]라고 함)가 어떻게 보이는지와 배치 및 진입/종료 애니메이션 동작을 정의하는 속성을 가질 수 있습니다. 따라서 본질적으로 Shell, INavigation 또는 다른 것에 내장된 크로스 플랫폼 토스트/스낵바 구현입니다. 이것은 플랫폼별로 기본적으로 보이도록 강요되지 않지만 모든 플랫폼에서 동일합니다.

d1c014c0-fc7b-4788-9689-1948a7294426

bc91d3ca-b95f-4485-a917-db6ab47510c1

adrianknight89 에 2018년 06월 09일

1.0에서 나온 구식 아키텍처를 제거하지 않고 안정성, 유연성 등을 둘러싼 논쟁과 관련하여 나는 그것들을 달성하는 것이 가능하다고 생각하지 않습니다. 저는 ListView2를 매우 선호합니다.

@jassmith

새로운 ListView에 대한 개선 티켓이 아직 있습니까?
v1.0이 언제 나올 것 같습니까? EOY에서 볼 수 있는 기회가 있을까요?

또한, 나는 팀이 너무 작아지는 것에 대해 같은 우려를 가지고 있습니다. 사실 예전에 이런 얘기를 한 적이 있어요. 팀이 앞으로 더 크게 성장할 수 있기를 바랍니다. 🙏 @davidortinau @migueldeicaza

adrianknight89 에 2018년 06월 09일

👍2

@jassmith 저는 App 클래스용 렌더러가 있다면 현재 타사 해커가 달성해야 하는 많은 일을 할 수 있다고 믿었습니다. 예를 들어, RgPopups 플러그인은 앱의 기본 보기를 잡고 렌더링된 보기를 앱에 주입하여 전체 화면 팝업 모양을 제공합니다. 이것은 현재 "순수한" Xamarin Forms로 달성할 수 없습니다. 그러나 앱에 렌더러가 있다면 우리는 이것을 스스로 할 수 있습니다.

programmation 에 2018년 06월 12일

저는 이러한 종류의 알림을 Shell에 추가하는 데 찬성합니다. 어떻게 해야 하는지 알아보려고 합니다.

jassmith 에 2018년 06월 13일

애플리케이션 내에서 원하는 위치에 임의로 페이지를 넣을 수 있도록 만들어 주시겠습니까? 이것은 동시에 여러 페이지를 화면에 표시하고 분할 보기(마스터 세부 정보 페이지)를 사용하여 구성하지 않으려는 태블릿/데스크톱/노트북(대형 화면 장치)에서 특히 중요합니다. 예: Google 지도를 참조하세요.

콘텐츠가 지도 위에 어떻게 "떠다니는지" 확인하십시오(분할 보기 없음). 탭이나 부동 영역 내 탐색과 같은 것을 사용하려는 경우 페이지가 있는 계층 구조가 극도로 제한되어 있기 때문에 Xamarin Forms를 사용하여 이러한 종류의 작업을 즉시 수행할 수 없습니다(페이지를 중첩할 수 없음 내부 보기). 우리는 실제로 NavigationPage와 유사한 기능을 제공하지만 보기인 자체 사용자 정의 보기를 개발하여 이러한 종류의 레이아웃을 수행할 수 있었지만 많은 작업/어려운 작업이었습니다.

애플리케이션 내에서 원하는 곳에 콘텐츠(페이지 포함)를 넣을 수 있어야 합니다.

jsiemens 에 2018년 06월 27일

애플리케이션 내에서 원하는 위치에 임의로 페이지를 넣을 수 있도록 만들어 주시겠습니까?

@jsiemens 는 이 보기가 전화에서는 제대로 보이지 않지만 데스크톱 및 태블릿에서는 멋지게

dansiegel 에 2018년 06월 27일

@dansiegel 적어도 개인적으로 VSM 또는 이와 동등한 것을 사용하여 특정 뷰포트 임계값(현재 GMaps가 하는 것과 같이) 아래에서 스크롤 보기를 이동하고 압축할 것입니다. 그러나 탐색 및 상태 관리가 어떻게 작동하는지 궁금할 것입니다.

RichiCoder1 에 2018년 06월 27일

탐색: 사용자 여정의 관점에서 시작한 다음 사용자가 어떻게 작동할 것으로 기대하는지 살펴본다면 극복할 수 없는 문제가 아니라고 확신합니다. 탐색은 전화의 전체 화면 특성과 예를 들어 더 큰 화면의 작은 보기에 응답해야 합니다.

사용자는 태블릿과 더 작은 보기를 단일 탐색 이정표로 '볼' 것입니다. 작은 화면에는 두 개의 이정표가 있을 수 있습니다. 탐색은 어떻게든 반응해야 합니다.

개발자로서 우리는 상황에 맞는 것이므로 반응하는 특성을 확실히 처리해야 합니다. 우리는 그것을 처리하기 위해 프레임워크에 의존할 수 없지만 프레임워크는 그것을 지원해야 합니다.

stevehurcombe 에 2018년 06월 27일

@jsiemens @dansiegel 현재 이것을 처리하는 방법은 ControlTemplate 입니다. 내 "페이지" 유형 콘텐츠를 ContentView 로 만들고 플랫폼에 적합한 ContentPage ( NavigationPage 내부)에 호스팅합니다. ControlTemplates 를 사용하면 ControlTemplate 의 바인딩 가능한 속성을 기반으로 켜거나 끄는 여러 바인딩된 ContentViews (일반적으로 Grid 을 오버레이할 수 있음)를 가질 수 있습니다. ControlTemplate 자체( DynamicResource 를 사용할 수도 있음). 최종 결과는 모든 콘텐츠가 페이지에 있지만 모든 콘텐츠가 항상 표시되는 것은 아닌 웹 사이트의 CSS 패널과 약간 유사하게 작동합니다. ControlTemplate 는 이것에 대해 마법과도 같으며 나는 그들의 기능이 Shell에서 보존되기를 원합니다.

programmation 에 2018년 06월 28일

@dansiegel 나는 단순히 앱이 태블릿/노트북/데스크톱에서 실행되는지 여부에 따라 다른 쉘을 로드하도록 코딩할 것입니다.

jsiemens 에 2018년 06월 28일

@jsiemens 괜찮습니다. 제 의견은 귀하의 아이디어를 더욱 구체화하기 위해 추가 대화와 비판적 사고를 촉진하기 위한

dansiegel 에 2018년 06월 28일

@dansiegel 예, 그것이 내가

이 사양에 대한 주제가 아니라고 생각하지만 복잡한 레이아웃을 구성하는 방법(예: @MelbourneDeveloper 의 세 번째 우선 순위 - 유연성)에 대해 이야기하고 있기 때문에 여기에 언급했습니다. 이것은 확실히 가장 중요한 레이아웃입니다. 저와 제 팀을 위한 마음입니다(탐색 페이지 및 탭과 같은 '페이지 전용' 콘텐츠를 포함할 수 있는 콘텐츠 패널을 지도 상단에 띄울 수 있기를 원하는 매핑 앱을 구축 중입니다).

쉘을 사용하여 이것이 어떻게 해결될지 모르겠지만 쉘에 대한 나의 초기 반응은 내가 이미 할 수 없는 일을 하지 않는 것 같습니다. 일반적으로 Xamarin Forms 팀은 내가 이미 할 수 있었던 일을 다른 방식으로 수행할 수 있는 기능을 계속 구축하고 있다고 생각합니다(예: CSS, Visual State Manager, 이제 Drawing 및 Shell 사양). 그래서 그것은 나에게 많은 가치를 가져다주지 않습니다. 차라리 내가 이전에 할 수 없었던 일을 할 수 있게 해주는 새로운 기능을 갖고 싶습니다(사용자 정의 컨트롤 및/또는 렌더러 외부에서). 셸이 구문이 더 우아하기 때문에 이를 달성하기 위한 답이라면 저는 모두 찬성하지만 궁극적으로 실제로 가치를 가져오기 위해 현재 페이지/뷰 계층 구조보다 더 강력하고 표현력이 뛰어나길 바랍니다.

jsiemens 에 2018년 06월 28일

네이티브 위젯을 사용하지 않고 레이아웃 내의 모든 하위 보기를 렌더링할 수 있는 경우 xamarin 보기별로 네이티브 보기 생성을 분리할 수 있습니까? 일종의 자동 하이브리드 플러터/자마린 접근 방식으로 XF 뷰 그룹이 단일 표면으로 렌더링되고 하나의 기본 뷰로 블리트됩니다. Android 보기 생성/레이아웃 C# -> Java interop 비용을 피하는 것이 유용할 것입니다.

roceh 에 2018년 07월 03일

진행중!!

juepiezhongren 에 2018년 07월 18일

@jassmith 셸 종료 후, 함께 추첨하나요?

juepiezhongren 에 2018년 07월 25일

쉘은 macos와 wpf를 지원합니까?

juepiezhongren 에 2018년 09월 18일

@juepiezhongren 초기 대상은 iOS 및 Android입니다. 그 후에 다른 플랫폼이 우선 적용됩니다.

도면은 현재 개발되지 않습니다. 현재 사양에서는 Shell에서 유효합니다. 오늘날과 마찬가지로 Xamarin.Forms 내에서 SkiaSharp 및 Skia 기반 컨트롤을 사용할 수 있습니다.

우리는 재료 및 기타 디자인 스타일에 대한 일관된 디자인을 지원하기 위해 다른 기본 전략을 연구하고 있습니다.

davidortinau 에 2018년 09월 18일

@davidortinau 쉘이 RTL을 더 잘 지원하도록 합니까?

mhmd-azeez 에 2018년 09월 18일

어떤 면에서 더 나은가요? 현재 RTL 지원에서 놓치고 있는 것은 무엇입니까? 우리는 모든 곳에서 이 문제를 해결해야 합니다.

davidortinau 에 2018년 09월 18일

솔직히 말하면 한동안 XF 개발을 하지 않았지만 대부분의 제한 사항은 알려져 있습니다. #1222 및 #2448을 살펴보세요.

쉘은 다음과 같은 일반적인 제한 사항에 도움이 될 수 있습니다.

NavigationPage 버튼 위치, 도구 모음 항목 위치 및 전환 애니메이션은 현재 FlowDirection 설정이 아닌 장치 로캘에 의해 제어됩니다.
FlowDirection에 대한 전역 앱 설정

기타 플랫폼별 제한 사항

mhmd-azeez 에 2018년 09월 18일

Xamarin.Forms의 가장 중요한 기능입니다. 애초에 이렇게 지어졌어야 했다.