Suurien ja monimutkaisten pohjaan perustuvien sovellusten muodostaminen

Useimmissa ohjeiden tämän osan artikkeleissa käsitellään sitä, millaiseksi käyttäjät kokevat sovellusten suorituksen aikaisen suorituskyvyn. Tässä artikkelissa käsitellään sovellusten suorituskykyä sellaisena, jona niiden tekijät sen kokevat.

Sovellusten suurentuessa ja monimutkaistuessa Power Apps Studion on voitava ladata ja hallita suuria määritä ohjausobjekteja, kaavoja ja tietolähteitä samalla, kun keskinäiset riippuvuudet kasvavat räjähdysmäisesti. Power Apps Studion lataaminen voi kestää pidempään, minkä lisäksi ominaisuuksissa, kuten IntelliSensessa ja värikoodauksessa, voi olla viivettä. Jäljempänä esitettyjen suositusten avulla voidaan parantaa suurten ja monimutkaisten sovellusten käyttöä Power Apps Studiossa. Ne voivat myös auttaa sovelluksesi suorituspalvelun suorituskykyä.

Tämän artikkelin esimerkit perustuvat Hospital Emergency Response -esimerkkiratkaisuun.

Käytössä App.Formulas eikä App.OnStart

Paras tapa lyhentää sekä Power Apps Studion että oman sovelluksesi latausaikaa on korvata muuttujan ja kokoelman alustaminen App.OnStartissa App.Formulasin nimetyllä kaavalla.

Tarkastellaanpa seuraavaa esimerkkiä, jossa käytetään kaavaa App.OnStart.

// Get the color of text on a dark background.
Set(varColorOnDark,RGBA(0, 0, 0, 1));

// Get the color of the menu icons.
Set(varColorMenuIcon,"#0070a9");

// Get the styles for a form.
Set(varFormStyle,
    {
        DataCard: { Height: 50 },
        Title: { Height: 50, Size: 21, Color: varColorOnDark },
        Control: { Height: 50, Size: 18 },
        Label: { Size: 18, Color: varColorOnDark }
    }
);

ClearCollect(
    FacilitiesList,
    ForAll(
        Facilities,
        { Name: 'Facility Name', Id: Facility }
    )
);
If(
    Not IsBlank(Param("FacilityID")),
    Set(ParamFacility,
        LookUp(
            FacilitiesList,
            Id = GUID(Param("FacilityID"))
        ).Name
    );
);

Koska kyse on peräkkäisistä lausekkeista, sovelluksen on arvioitava nämä Set- ja Collect-kutsut, ennen kuin se voi näyttää ensimmäisen näytön, mikä saa sovelluksen latautumaan hitaammin. Koska lisäksi koko App.OnStart on otettava huomioon kokonaisuutena, järjestys säilytettävä ja virheet koostettava ennen lopullisen tuloksen suorittamista, kaava on monimutkainen Power Apps Studion analysoitavaksi.

Tähän on olemassa parempikin tapa. Käytä sen sijaan kaavaa App.Formulas ja määritä nämä muuttujat ja kokoelmat nimetyiksi kaavoiksi seuraavan esimerkin mukaisesti.

// Get the color of text on a dark background.
varColorOnDark = RGBA(0, 0, 0, 1);

// Get the color of the menu icons.
varColorMenuIcon = "#0070a9";

// Get the styles for a form.
varFormStyle = 
    {
        DataCard: { Height: 50 },
        Title: { Height: 50, Size: 21, Color: varColorOnDark },
        Control: { Height: 50, Size: 18 },
        Label: { Size: 18, Color: varColorOnDark }
    };

FacilitiesList =
    ForAll(
        Facilities,
        { Name: 'Facility Name', Id: Facility }
    );

ParamFacility = 
    If( Not IsBlank(Param("FacilityID")),
        LookUp(
            FacilitiesList,
            Id = GUID(Param("FacilityID"))
        ).Name,
        Blank()
    );

Tämä voi vaikuttaa pieneltä muutokselta, mutta sen vaikutus voi olla merkittävä. Koska kukin nimetty kaavio on itsenäinen muista, Power Apps Studio voi analysoida ne itsenäisesti, mikä tarkoittaa, että yksi suuri App.OnStart jaetaan pienempiin osiin. Tämä muutos yksin on voinut lyhentää Power Apps Studion latausaikoja jopa 80 prosentilla.

Myös sovellus latautuu nopeammin, koska sen ei tarvitse arvioida näitä kaavoja, ennen kuin se tarvitsee tuloksen. Sovelluksen ensimmäinen näyttö näytetään välittömästi.

Nimettyjä kaavoja ei voi käyttää kaikissa tilanteissa, koska niitä ei voi muokata tai käyttää muuttujaa Set. Joissakin tilanteissa on käytettävä tilamuuttujaa, jota voi muokata. Set sopii täydellisesti tällaisiin tilanteisiin, ja sen käyttöä kannattaa jatkaa. Useimmiten OnStart-määrityksessä kuitenkin käytetään yleisiä muuttujia määrittämään staattisia arvoja, jotka eivät muutu. Tällöin nimetty kaava on parempi vaihtoehto.

Koska nimetyt kaavat ovat muuttumattomia, etuliite var (lyhenne sanasta "variable", muuttuja) ei sovellu enää nimeämiskäytännöksi. Emme muutaneet tämän esimerkin nimiä, koska se edellyttäisi vastaavia muutoksia muuhun sovellukseen.

Vaikka nimetyn kaavan sijoittaminen App.OnStartiin onkin houkuttelevaa, sitä ei pidä tehdä. Se ei kuulu sinne. Koska kyse on On-toimintaominaisuudesta, App.OnStart arvioi jokaisen lauseen järjestyksessä sekä luo yleisiä muuttujia ja on yhteydessä tietokantoihin vain kerran sovelluksen latauksen yhteydessä. Nimetyt kaavat ovat kaavoja, joilla määritetään, miten jokin lasketaan aina tarvittaessa, ja joiden totuusarvo on aina tosi. Ja juuri tämän kaavan ominaispiirteen ansiosta ne pysyvät itsenäisinä ja sallivat sovelluksen latautumisen valmistumisen ennen arviointia.

Pitkien kaavojen jakaminen

Vaikka App.OnStart on yksi pahimmista pitkien kaavojen aiheuttajista ja hyvä aloituskohta, se ei ole ainoa syypää.

Asiaan perehdyttäessä on havaittu, että lähes kaikissa sovelluksissa, joilla on pitkä Power Apps Studio -latausaika, ainakin yhdessä kaavassa on yli 256 000 merkkiä. Joissakin sovelluksissa, joiden latausajat ovat kaikkien pisimmät, on kaavoja, joissa on yli miljoona merkkiä. Tämän pituiset kaavat kuormittavat Power Apps Studiota merkittävästi.

Tilannetta pahentaa se, että pitkän kaavan ohjausobjektin kopioiminen ja liittäminen kopioi kaavan ohjausobjektin ominaisuuksissa ilman, että sitä toteutetaan. Power Apps mallinnuksessa on käytetty Exceliä, jossa kaavasta on yleisesti useita kopioita. Excel-kaavat kuitenkin rajoittuvat vain yhteen lausekkeeseen ja niiden enimmäispituus on 8 000 merkkiä. Power Apps -kaavoista voi tulla paljon pidempiä imperatiivisen logiikan ja ketjutusoperaattorin (; tai ;; kielialueen mukaan) käyttöönoton myötä.

Yleinen ratkaisu on jakaa pitkät kaavat pienemmiksi osiksi ja käyttää osat uudelleen, kuten edellä, kun Set/Collect -lausekkeita App.OnStart-ominaisuudessa muutettiin nimetyiksi kaavoiksi App.Formulas-ominaisuudessa. Muissa ohjelmointikielissä uudelleenkäytettäviä osia kutsutaan usein alirutiineiksi tai käyttäjän määrittämiksi funktioiksi. Nimettyjä kaavoja voidaan pitää käyttäjän määrittämien funktioiden yksinkertaisina muotoina, joissa ei ole parametreja eikä sivuvaikutuksia.

Nimettyjen kaavojen käyttäminen kaikkialla

Aiemmassa esimerkissä nimettyjä kaavoja käytettiin korvaamaan App.OnStart. Niiden avulla voit kuitenkin korvata laskelman missä tahansa kohtaa sovellusta.

Esimerkiksi yksi Hospital Emergency Response -esimerkkiratkaisun näyttö sisältää tämän logiikan Screen.OnVisible-ominaisuudessa:

ClearCollect(
    MySplashSelectionsCollection,
    {
        MySystemCol: First(
            Filter(
                Regions,
                Region = MyParamRegion
            )
        ).System.'System Name',
        MyRegionCol: First(
            Filter(
                Regions,
                Region = MyParamRegion
            )
        ).'Region Name',
        MyFacilityCol: ParamFacility,
          MyFacilityColID:  LookUp(
            FacilitiesList,
            Id = GUID(Param("FacilityID"))
        ).Id
    }
); 

Tämä kaava voidaan jakaa joukoksi nimettyjä kaavoja. Se myös helpottaa kaavan lukemista.

MyRegion = LookUp(
                    Regions,
                    Region = MyParamRegion
           );

MyFacility = LookUp(
                    FacilitiesList,
                    Id = GUID(Param("FacilityID")
            );

MySplashSelectionsCollection = 
    {
        MySystemCol: MyRegion.System.'System Name',
        MyRegionCol: MyRegion.'Region Name',
        MyFacilityCol: ParamFacility,
        MyFacilityColID:  MyFacility.Id
    };

ParamFacility poimittiin aiemmin nimettynä kaavana, kun suurin osa Set-kutsuista siirrettiin App.OnStart-ominaisuudesta App.Formulas-ominaisuuden nimettyihin kaavoihin.

Nimetyt kaavat arvioidaan vasta sitten, kun niiden arvoja tarvitaan. Jos Screen.OnVisible-ominaisuuden alkuperäinen tarkoitus oli lykätä työ näytön näyttämiseen saakka, työ lykätään edelleen yleisinä nimettyinä kaavoina App.Formulas-ominaisuudessa.

With-funktion käyttäminen

Voit jakaa logiikkaa myös käyttämällä With-funktiota kaavassa. Luo ensimmäiseen parametriin tietue, jossa halutut arvot ovat kenttiä, ja käyttää sitten näitä kenttiä toisessa parametrissa palautusarvon laskemiseen With-funktiosta. Esimerkiksi edellä oleva esimerkki voidaan kirjoittaa yhtenä nimettynä kaavana:

MySplashSelectionsCollection = 
    With( { MyRegion: LookUp(
                            Regions,
                            Region = MyParamRegion
                      ),
            MyFacility: LookUp(
                            FacilitiesList,
                            Id = GUID(Param("FacilityID")
                      ) 
           },
           {
                MySystemCol: MyRegion.System.'System Name',
                MyRegionCol: MyRegion.'Region Name',
                MyFacilityCol: ParamFacility,
                MyFacilityColID:  MyFacility.Id
           }
    )

Yksi With-funktion tällä tavalla käyttämisen haittapuoli on, että MyFacility ei voi käyttää MyRegion-parametria, koska ne on määritetty samassa With-funktiossa. Tätä ongelmaa ei ole nimetyissä kaavoissa. Yksi ratkaisu on käyttää sisäkkäisiä With-funktioita ja nimetä kullekin tietue As-avainsanalla, jolloin kaikkia With-muuttujia on helppo käyttää.

Kaaviokomponenttien käyttäminen

Kaaviokomponentteja käyttää useimmiten luotaessa käyttöliittymäohjausobjekti, joka voidaan sijoittaa kaavioon ohjausobjektin tavoin. Niitä voidaan käyttää myös laskutoimitusten suorittamiseen ilman sijoittamista käyttöliittymään mukautettujen tulosominaisuuksien avulla, mikä on vaihtoehto nimetyille kaavoille. Kaaviokomponentteja on helppo jakaa sovellusten kesken komponenttikirjastojen avulla, ja niitä tuetaan täysin, toisin kuin nimettyjä kaavoja. Niitä on kuitenkin vaikeampi määrittää ja käyttää kuin nimettyjä kaavoja.

Logiikan jakaminen:

1. Siirry Power Apps Studiossa Komponentit-välilehteen puunäkymässä.
2. Uuden komponentin luominen.
3. Ota Käyttöoikeussovelluksen vaikutusalue käyttöön Ominaisuudet-ruudussa.
4. Lisää mukautettu ominaisuus.
5. Määritä ominaisuuden tyypiksi Tulos ja valitse sopiva tietotyyppi.
6. Valitse Luo.
7. Valitse uusi ominaisuus ominaisuuden valitsimessa, joka sijaitsee kaavarivin vieressä näytön yläosassa.
8. Kirjoita jaettavan ja uudelleenkäytettävän logiikan kaava.

Logiikan käyttäminen:

1. Siirry Näytöt-välilehteen puunäkymässä.
2. Laajenna Lisää-ruudussa Mukautettu ja lisää komponenttisi.
3. Laske ominaisuuden arvo käyttämällä ComponentName.PropertyName-ominaisuutta.

Imperatiivisen logiikan piilotetun ohjausobjektin sisältävän Select-kutsun käyttäminen

Imperatiivisen logiikan avulla voidaan muokata tilaa Set- ja Collect-kutsujen avulla, antaa käyttäjälle ilmoitus Notify-kutsun avulla, siirtyä toiseen näyttöön tai sovellukseen Navigate- ja Launch-kutsujen avulla sekä kirjoittaa arvo tietokantaan Patch-, SubmitForm- tai RemoveIf-kutsuilla.

Nimetyt kaavat Kaaviokomponentin tulosominaisuudet eivät tue imperatiivista logiikkaa. Yleinen tapa jakaa imperatiivinen logiikka on käyttää piilotetun ohjausobjektin OnSelect-ominaisuutta.

1. Lisää Painike-ohjausobjekti näyttöön.
2. Määritä OnSelect-ominaisuus suoritettavaan imperatiiviseen logiikkaan.
3. Määritä Näkyvä-ominaisuuden arvoksi epätosi, koska käyttäjän ei tarvitse nähdä tai käsitellä sitä.
4. Kutsu Select( Button ), kun imperatiivinen logiikka halutaan suorittaa.

Tämän esimerkin yhdessä näytössä on esimerkiksi seuraava OnSelect-ominaisuus Painike-ohjausobjektissa. (Tämä yksinkertainen esimerkki on vain havainnollistamista varten. Yleensä tätä menetelmää käytetään vain pidemmissä kaavoissa.)

btnAction_17.OnSelect = 
    Trace("Feedback Screen: Submit Button",TraceSeverity.Information);
    If(
        // Proceed if all forms are validated.
        And(
            FormFeedback.Valid
        ),
    
        // Set the updates to static variables.
        Set(updatesFeedback,Patch(Defaults('App Feedbacks'), FormFeedback.Updates));
        // Submit the first form. Subsequent actions can be found in the OnSuccess.
        SubmitForm(FormFeedback);
        ,
    
        Notify("Please complete all fields before proceeding",
               NotificationType.Warning,2000)
    );

Tämä logiikka jaetaan osiin asettamalla osta erillisiin Painike-ohjausobjekteihin ja tekemällä niille Select-kutsun alkuperäisestä:

btnTrace.OnSelect = 
    Trace("Feedback Screen: Submit Button",TraceSeverity.Information);

btnSubmit.OnSelect = 
    If(
        // Proceed if all forms are validated.
        And(
            FormFeedback.Valid
        ),
    
        // Set the updates to static variables.
        Set(updatesFeedback,Patch(Defaults('App Feedbacks'), FormFeedback.Updates));
        // Submit the first form. Subsequent actions can be found in OnSuccess.
        SubmitForm(FormFeedback);
        ,
    
        Notify("Please complete all fields before proceeding",
               NotificationType.Warning,2000)
    );

btnAction_17.OnSelect = 
    Select( btnTrace );
    Select( btnSubmit );

Tämä menetelmä toimii vain samassa näytössä. Muut menetelmät, jotka ovat hieman monimutkaisempia toimivat eri näytöissä. Sellaisia ovat esimerkiksi Vaihtovalitsin-ohjausobjektin käyttö, OnCheck-ominaisuuden määrittäminen suoritettavalle logiikalle ja Oletus-ominaisuuden määrittäminen yleiselle muuttujalle ja määrittämällä muuttuja käyttämällä ominaisuuksia Set( global, true ); Set( global, false ) siinä kohdassa, jossa haluat suorittaa logiikan.

Tässä esimerkissä logiikkaa on jo jaettu jonkin verran. Kommentissa sanotaan, että seuraavat toiminnot löytyvät OnSuccess-ominaisuudesta. Tämä tapahtuma suorittaa imperatiivisen logiikan sen jälkeen, kun tietue on lähetetty, mikä on SubmitForm-funktiokohtainen ratkaisu.

Sovelluksen osiointi

Joidenkin sovellusten ohjausobjektien määrä nousee tuhansiin ja tietolähteiden satoihin, mikä hidastaa Power Apps Studiota. Pitkien kaavojen tavoin suuret sovellukset voidaan jakaa pienemmiksi osiksi, jotka yhdessä toimivina luovat yhden käyttökokemuksen.

Pohjaan perustuvien sovellusten erottaminen

Yksi lähestymistapa on ottaa käyttöön osioita erillisissä pohjaan perustuvissa sovelluksissa ja käyttää Launch-funktiota eri sovellusten välillä siirtymiseen ja tarvittavan kontekstin välittämiseen.

Tätä menetelmää käytettiin Hospital Emergency Response -esimerkkiratkaisussa. Erilliset sovellukset hallitsevat kutakin sovelluskokonaisuuden pääaluetta. Sovelluksilla on komponenttikirjaston kautta yhteinen valikko, jonka kukin sovellus näyttää aloitusnäytössä:

Kun käyttäjä valitsee alueen, komponentti käyttää metatietoja käytettävissä olevista sovelluksista ja siitä, mikä sovellus isännöi komponenttia. Jos toivottu näyttö on tässä sovelluksessa (eli ThisItem.Screen ei ole tyhjä), Navigate-kutsu tehdään. Mutta jos toivottu näyttö on jossain muussa sovelluksessa (eli ThisItem.PowerAppID ei ole tyhjä), käytetään Launch-funktiota sekä kohteen sovellustunnusta ja FacilityID-kontekstia:

If(
    IsBlank(ThisItem.Screen),
    If(IsBlank(ThisItem.PowerAppID), 
        Launch(ThisItem.URL),           
        Launch("/providers/Microsoft.PowerApps/apps/" & ThisItem.PowerAppID, 
               "FacilityID", Home_Facility_DD.Selected.Id)
    ),
    Navigate(
        ThisItem.Screen,
        Fade
    )
);

Alkuperäisen sovelluksen tila menetetään, kun toinen sovellus käynnistetään. Muista tallentaa mikä tahansa tila, ennen kuin kutsut Launch-funktion. Kirjoita se tietokantaan, tee kutsut´SaveData tai välitä tila kohdesovelluksiin parametreilla, jotka luetaan Param-funktiolla.

Mukautettuja sivuja sisältävä mallipohjainen sovellus

Osat voidaan toteuttaa myös mukautettuina sivuina. Mukautetut sivut toimivat pohjaan perustuvana minisovelluksena, jossa mallipohjainen sovellus on siirtymissäilö.