12/10월 _ App.StartScreen: App.OnStart에서 Navigate에 대한 새로운 선언적 대안

App.OnStart 는  전역 변수의 초기화, 데이터를 컬렉션으로 미리 가져오기, 어떤 화면을 먼저 표시할지 결정하는 데 널리 사용됩니다. 

성능 최적화 지침에서 그 사용을 적극 권장합니다.

하지만 이  속성에는 문제가 있습니다. 

첫 화면이 나오기 전에 해야 할 일을 순서대로 목록을 나열하고  어떤 일을해야할때  그 일을 순서에 따라 수행해야합니다.  재정렬하고, 그렇지 않으면 할 수있는 최적화를 제한합니다.

Microsoft Teams 통합으로 상황이 심각해졌습니다. 

빠른 앱 로드 시간은 항상 중요하지만 Teams의 경우 더 중요합니다.

앱은 메모리에 유지되지 않으며 최대 몇 초 이내에 로드되고 닫힐 것으로 예상됩니다. 

분석에 따르면 App.OnStart는 팀에서 앱을 느리게 로드하는 주요 원인이며 필수적이기 때문에 시스템이 성능을 향상시키기 위해 할 수 있는 일은 많지 않습니다.

 

그래서  App.OnStart에서 수행하는 모든 작업에 대한 새로운 대안을 제공할 것입니다. 

앱이 더 빨리 로드되고 더 나은 사용자 경험을 제공할 뿐만 아니라 작성 및 디버그도 더 쉬워집니다. 

선언적이란 어떤 일이 일어나길 원하는지 계속 우리 에게 말하지만 언제 또는 어떻게 말할 필요는 없다는 것을 의미 합니다 . 

앱 시작 화면

기본적으로 앱이 시작될 때 표시되는 첫 번째 화면은 Studio의 트리 보기에 있는 첫 번째 화면입니다. 이 동작은 App.OnStart 내에서 Navigate 함수를 호출하여 오늘 수정할 수 있습니다.

이것은 성능 문제를 야기합니다. App.OnStart에 Navigate 함수 호출이 포함되어 있으면 If 함수에 있고 거의 호출되지 않더라도 앱의 첫 번째 화면을 표시하기 전에 App.OnStart 실행을 완료해야 합니다. 이상적으로는 종속성이 충족되는 즉시 첫 번째 화면을 표시하지만 앱의 다른 화면에서만 필요한 작업은 연기합니다.

App.StartScreen은 최적화를 차단하지 않고 어떤 화면을 먼저 표시해야 하는지를 나타내는 새로운 선언적 방법입니다.

당신이 과거에 이것을 썼을 수도 있는 곳:

App.OnStart = Collect( OrdersCache, Orders );
              If( Param( "AdminMode" ) = "1", Navigate( AdminScreen ), Navigate( HomeScreen ) )

대신 버전 3.21101 이상에서 다음과 같이 작성할 수 있습니다.

App.OnStart = Collect( OrdersCache, Orders );
App.StartScreen = If( Param( "AdminMode" ) = "1", AdminScreen, HomeScreen )

나는 그들이 매우 유사해 보이지만 미묘한 차이가 있다는 것을 압니다. 주의할 사항:

• App.StartScreen은 수행해야 할 작업이 아니라 계산을 설명합니다 .  
  부작용도 없고, 네비게이트 호출도 없고, 필수적인 것도 없습니다. 가장 먼저 표시할 화면 개체를 반환합니다. 
  이 정보가 필요할 때와 더 이상 관련이 없을 때를 결정하는 것은 시스템에 달려 있습니다.
• App.StartScreen은 두 번째 경우 App.OnStart에서 분리됩니다. 그것들은 독립적이며 별도로 평가될 수 있습니다. 
  App.OnStart가 완료되기 전에 첫 번째 화면을 표시할 수 있습니다. 
  현재 App.OnStart에 Navigate 호출이 포함된 경우 전체 App.OnStart가 완료될 때까지 첫 번째 화면을 표시할 수 없으므로 앱 로드 시간을 개선하는 최적화를 차단합니다.

앱의 시작 화면을 지정하려면 App.StartScreen 속성에 화면 이름을 지정합니다.

이 경우 Screen2 는 현재 사용자, Param 함수 호출, 데이터베이스 레코드 등을 고려할 수 있는 공식으로 대체될 수 있습니다.

앱 의 ... 메뉴에서 시작 화면으로 이동을  선택하여 이것이 작동하는지 테스트 할 수 있습니다 .

앱이 막 시작된 ​​것처럼 우리는 Screen2에 있습니다.

App.OnStart에서 탐색 종료

App.StartScreen을 도입함으로써 우리는 또한 App.OnStart에서 Navigate의 사용을 중단하는 프로세스 를 시작할 것 입니다.

앱은 App.OnStart에서 Navigate를 계속 호출할 수 있습니다. 

기존 앱은 동작에 변화가 없어야 합니다(아래에 언급된 한 가지 작은 예외가 있으며 쉬운 해결 방법이 있음).  

App.OnStart에서 탐색을 활성화하는 새로운 스위치가 설정에 있습니다. OnStart에서 탐색을 사용하는 기존 앱의 경우 이 스위치가 켜집니다. 새 앱의 경우 이 스위치는 기본적으로 꺼져 있지만 켤 수 있습니다.

스위치를 끈 상태에서 App.OnStart에서 탐색을 사용하려고 할 때 Studio에 오류가 표시됩니다. 

스위치가 켜져 있으면 메시지는 경고일 뿐입니다.

앞으로의 선언적 길: 명명된 수식

App.StartScreen은 우리의 첫 번째 단계일 뿐입니다. 작업에는 두 가지 중요한 새로운 선언적 기능이 있습니다.

전역 변수를 설정하기 위해 App.OnStart에서 Set을 사용하는 사람이 얼마나 됩니까?

다음을 작성하는 대신 다음과 같이 하면 어떻게 될까요?

App.Onstart = Set( ThisUser, LookUp( Users, Email = User().Email ) )

대신 다음과 같이 썼습니다.

ThisUser = LookUp( Users, Email = User().Email )

나는 또 다른 매우 미묘한 차이를 알고 있습니다. 두 번째 경우 에는 Set 함수를 사용하는 대신 명명된 수식을  정의 합니다. 이는 Excel에서 수식 입력줄이나 이름 관리자를 사용하여 이름을 정의하는 것과 같습니다.

이 접근 방식이 더 나은 점은 무엇입니까?

• 모든 공식과 마찬가지로 값은 항상 최신 상태입니다. 
  종속성이 변경되면 자동으로 다시 계산됩니다. 
  앱이 사용자 데이터 소스의 현재 사용자 항목을 수정하더라도 ThisUser 레코드는 항상 정확합니다. 
  나중에 다른 Set 호출로 수동으로 업데이트할 필요가 없습니다.
• ThisUser는 항상 사용할 수 있습니다. 
  앱이 실행을 시작하기 전에 초기화되지 않은 시간이 없습니다. 
  사용자를 찾지 못하는 경우를 제외하고는 공백 또는 Null 값을 갖지 않습니다.
• 수식은 앱의 다른 곳에서 수정할 수 없습니다. Set이 호출되고 사용되는 시간 사이에는 다른 수식이 값을 수정할 수 없습니다. 
  ThisUser에 대한 단일 정보 소스, 이 공식이 있고 다른 어떤 것도 이에 영향을 줄 수 없기 때문에 훌륭합니다.
• 성능 이점: Power Fx는 사용될 때 ThisUser만 평가하면 됩니다. 작업을 연기하거나 재정렬하거나 제거할 수도 있습니다.
  ThisUser가 세션에서 사용자가 방문하는 화면에서 사용되지 않으면 해당 세션에 대해 전혀 평가되지 않습니다.

선언적 미래: 프리페치 및 캐시된 데이터

얼마나 많은 사람들이 App.OnStart에서 Collect를 사용하여 데이터 소스에서 데이터를 미리 가져오고 캐싱합니까? 

오늘 이것을 쓰는 대신:

App.OnStart = Collect( CachedOrders, Orders )
Gallery1.Items = CachedOrders
Form1.Datasource = Orders
Button1.OnSelect = SubmitForm( Form1 );  ClearCollect( CachedOrders, Orders )

당신은 미래에 이것을 썼습니다:

Orders.Prefetch = True
Gallery1.Items = Orders
Form1.Datasource = Orders
Button1.OnSelect = SubmitForm( Form1 )

두 번째 형식은 훨씬 간단하고 강력하며 쓰기 쉽습니다. 

각 제작자가 OnStart의 Collect로 자체 캐시를 수동으로 관리하도록 하는 대신 시스템이 대신 작업을 수행할 수 있습니다. "이 테이블 미리 가져오기" 및 "이 테이블을 2시간 동안 캐시"와 같은 선언적 지시문은 캐싱을 제어하는 ​​데 필요한 모든 것입니다. 

이점들:

• 앱의 수식은 수정할 필요가 없습니다. 
  캐싱 여부에 관계없이 Gallery1.Items는 Orders에 바인딩됩니다. 
  실제 데이터 원본 대신 메모리 내 컬렉션(CacheOrders)을 참조하기 위해 모든 수식을 변경할 필요는 없습니다. 
  즉, 앱의 동작을 변경하지 않고 나중에 미리 가져오기 및 캐싱을 추가하거나 수정할 수 있습니다.
• 비위임 제한을 초과합니다. 
  수집은 최대 2,000개의 레코드로 제한됩니다. 
  컬렉션에서 이 한계를 넘어서려면 복잡한 공식 작성이 많이 필요하고 많은 사람들이 신경 쓰지 않습니다. 
  그런 다음 앱을 확장할 때 버그가 있을 수 있습니다. 
  직접 데이터 원본을 사용하면 이 제한을 점차적으로 초과할 수 있습니다.
• 처음에 필요한 것만 뽑습니다. 
  마찬가지로 갤러리 컨트롤은 필요에 따라 더 많은 데이터를 페이징할 수 있습니다. 
  처음에는 처음 100개의 레코드만 필요할 수 있습니다. 
  App.OnStart와 마찬가지로 처음에는 모든 것이 필요하지 않기 때문에 prefetch 지시문은 처음에 가져온 레코드 수를 표시하고 나머지는 페이징해야 함을 나타낼 수 있습니다.
• 캐시는 변경 후 수동으로 업데이트할 필요가 없습니다. 
  원본 데이터 소스가 업데이트되면 캐시를 수동으로 업데이트해야 합니다. 
  이는 번거롭고 오류가 발생하기 쉬우며 전체 캐시를 무효화해야 하므로 비효율적입니다.

 

 

[ 출처 :Micrsoft PowerApps 블로그 ]