Porting Windows Phone Silverlight XAML dan UI ke UWP

Topik sebelumnya adalah Pemecahan Masalah.

Praktik mendefinisikan UI dalam bentuk markup XAML deklaratif diterjemahkan dengan sangat baik dari aplikasi Windows Phone Silverlight ke Platform Windows Universal (UWP). Anda akan menemukan bahwa bagian besar markup Anda kompatibel setelah Anda memperbarui referensi kunci Sumber Daya sistem, mengubah beberapa nama jenis elemen, dan mengubah "clr-namespace" menjadi "using". Sebagian besar kode imperatif di lapisan presentasi Anda—menampilkan model, dan kode yang memanipulasi elemen UI—juga akan mudah untuk port.

Pertama-tama lihat markup XAML

Topik sebelumnya menunjukkan kepada Anda cara menyalin XAML dan file code-behind ke dalam proyek Windows 10 Visual Studio baru Anda. Salah satu masalah pertama yang mungkin Anda perhatikan disorot di perancang Visual Studio XAML adalah bahwa PhoneApplicationPage elemen di akar file XAML Anda tidak valid untuk proyek Platform Windows Universal (UWP). Dalam topik sebelumnya, Anda menyimpan salinan file XAML yang dihasilkan Visual Studio saat membuat proyek Windows 10. Jika Anda membuka versi MainPage.xaml tersebut, Anda akan melihat bahwa di akar adalah jenis Halaman, yang ada di namespace Windows.UI.Xaml.Controls . Jadi, Anda dapat mengubah semua <phone:PhoneApplicationPage> elemen menjadi <Page> (jangan lupa sintaks elemen properti) dan Anda dapat menghapus xmlns:phone deklarasi.

Untuk pendekatan yang lebih umum untuk menemukan jenis UWP yang sesuai dengan jenis Windows Phone Silverlight, Anda dapat merujuk ke Namespace layanan dan pemetaan kelas.

Deklarasi awalan namespace XAML

Jika Anda menggunakan instans jenis kustom dalam tampilan Anda—mungkin instans model tampilan atau pengonversi nilai—maka Anda akan memiliki deklarasi awalan namespace XAML di markup XAML Anda. Sintaks ini berbeda antara Windows Phone Silverlight dan UWP. Berikut adalah beberapa contohnya:

    xmlns:ContosoTradingCore="clr-namespace:ContosoTradingCore;assembly=ContosoTradingCore"
    xmlns:ContosoTradingLocal="clr-namespace:ContosoTradingLocal"

Ubah "clr-namespace" menjadi "using" dan delete any assembly token and semi-colon (assembly will inferred). Hasilnya terlihat seperti ini:

    xmlns:ContosoTradingCore="using:ContosoTradingCore"
    xmlns:ContosoTradingLocal="using:ContosoTradingLocal"

Anda mungkin memiliki sumber daya yang jenisnya ditentukan oleh sistem:

    xmlns:System="clr-namespace:System;assembly=mscorlib"
    /* ... */
    <System:Double x:Key="FontSizeLarge">40</System:Double>

Dalam UWP, hilangkan deklarasi awalan "Sistem" dan gunakan awalan "x" (sudah dinyatakan) sebagai gantinya:

    <x:Double x:Key="FontSizeLarge">40</x:Double>

Kode imperatif

Model tampilan Anda adalah salah satu tempat di mana ada kode penting yang mereferensikan jenis UI. Tempat lain adalah file kode di belakang yang langsung memanipulasi elemen UI. Misalnya, Anda mungkin menemukan bahwa baris kode seperti ini belum dikompilasi:

    return new BitmapImage(new Uri(this.CoverImagePath, UriKind.Relative));

BitmapImage berada di namespace System.Windows.Media.Imaging di Windows Phone Silverlight, dan menggunakan direktif dalam file yang sama memungkinkan BitmapImage digunakan tanpa kualifikasi namespace seperti dalam cuplikan di atas. Dalam kasus seperti ini, Anda dapat mengklik kanan nama jenis (BitmapImage) di Visual Studio dan menggunakan perintah Atasi pada menu konteks untuk menambahkan direktif namespace baru ke file. Dalam hal ini, namespace Windows.UI.Xaml.Media.Imaging ditambahkan, yang merupakan tempat jenis berada di UWP. Anda dapat menghapus System.Windows.Media.Imaging menggunakan direktif, dan itu saja yang diperlukan untuk kode port seperti itu dalam cuplikan di atas. Setelah selesai, Anda akan menghapus semua namespace Layanan Silverlight Windows Phone.

Dalam kasus sederhana seperti ini, di mana Anda memetakan jenis di namespace layanan lama ke jenis yang sama di yang baru, Anda dapat menggunakan perintah Temukan dan Ganti Visual Studio untuk membuat perubahan massal pada kode sumber Anda. Perintah Atasi adalah cara yang bagus untuk menemukan namespace baru jenis. Sebagai contoh lain, Anda dapat mengganti semua "System.Windows" dengan "Windows.UI.Xaml". Itu pada dasarnya akan mem-port semua menggunakan direktif dan semua nama jenis yang sepenuhnya memenuhi syarat yang merujuk ke namespace tersebut.

Setelah semua yang lama menggunakan direktif dihapus dan yang baru ditambahkan, Anda dapat menggunakan perintah Atur Menggunakan Visual Studio untuk mengurutkan arahan Anda dan menghapus yang tidak digunakan.

Terkadang, memperbaiki kode imperatif akan sama kecilnya dengan mengubah jenis parameter. Di lain waktu, Anda harus menggunakan WINDOWS Runtime API alih-alih .NET API untuk aplikasi Windows Runtime 8.x. Untuk mengidentifikasi API mana yang didukung, gunakan panduan porting lainnya dalam kombinasi dengan .NET untuk gambaran umum aplikasi Windows Runtime 8.x dan referensi Windows Runtime.

Dan, jika Anda hanya ingin sampai ke panggung tempat proyek Anda dibangun, Anda dapat mengomentari atau mencolok kode yang tidak penting. Kemudian iterasi, satu masalah pada satu waktu, dan lihat topik berikut di bagian ini (dan topik sebelumnya: Pemecahan Masalah), sampai masalah build dan runtime diserikan dan port Anda selesai.

UI adaptif/responsif

Karena aplikasi Windows 10 Anda dapat berjalan di berbagai perangkat yang berpotensi luas—masing-masing dengan ukuran dan resolusi layarnya sendiri—Anda harus melampaui langkah-langkah minimal untuk memindahkan aplikasi dan Anda mungkin ingin menyesuaikan UI agar terlihat terbaik di perangkat tersebut. Anda dapat menggunakan fitur Visual State Manager adaptif untuk mendeteksi ukuran jendela secara dinamis dan mengubah tata letak sebagai respons, dan contoh cara melakukannya yang ditunjukkan di bagian Antarmuka Pengguna adaptif dalam topik studi kasus Bookstore2.

Alarm dan Pengingat

Kode yang menggunakan kelas Alarm atau Pengingat harus di-port untuk menggunakan kelas BackgroundTaskBuilder untuk membuat dan mendaftarkan tugas latar belakang, dan menampilkan toast pada waktu yang relevan. Lihat Pemrosesan latar belakang dan Roti Panggang.

Animasi

Sebagai alternatif pilihan untuk animasi keyframe dan dari/ke animasi, pustaka animasi UWP tersedia untuk aplikasi UWP. Animasi ini telah dirancang dan disetel agar berjalan dengan lancar, terlihat hebat, dan untuk membuat aplikasi Anda muncul terintegrasi dengan Windows seperti yang dilakukan aplikasi bawaan. Lihat Mulai Cepat: Menganimasikan UI Anda menggunakan animasi pustaka.

Jika Anda menggunakan animasi keyframe atau dari/ke animasi di aplikasi UWP Anda, maka Anda mungkin ingin memahami perbedaan antara animasi independen dan dependen yang telah diperkenalkan oleh platform baru. Lihat Mengoptimalkan animasi dan media. Animasi yang berjalan pada utas UI (yang menganimasikan properti tata letak, misalnya) dikenal sebagai animasi dependen, dan ketika dijalankan pada platform baru, mereka tidak akan berpengaruh kecuali Anda melakukan salah satu dari dua hal. Anda dapat menargetkannya kembali untuk menganimasikan properti yang berbeda, seperti RenderTransform, sehingga membuatnya independen. Atau Anda dapat mengatur EnableDependentAnimation="True" elemen animasi untuk mengonfirmasi niat Anda menjalankan animasi yang tidak dapat dijamin berjalan dengan lancar. Jika Anda menggunakan Blend for Visual Studio untuk menulis animasi baru, properti tersebut akan diatur untuk Anda jika perlu.

Penanganan tombol kembali

Dalam aplikasi Windows 10, Anda dapat menggunakan satu pendekatan untuk menangani tombol kembali dan itu akan berfungsi di semua perangkat. Di perangkat seluler, tombol disediakan untuk Anda sebagai tombol kapasitif pada perangkat, atau sebagai tombol di shell. Di perangkat desktop, Anda menambahkan tombol ke chrome aplikasi setiap kali navigasi belakang dimungkinkan dalam aplikasi, dan ini muncul di bilah judul untuk aplikasi berjendela atau di bilah tugas untuk mode Tablet (hanya Windows 10). Peristiwa tombol kembali adalah konsep universal di semua keluarga perangkat, dan tombol yang diterapkan dalam perangkat keras atau dalam perangkat lunak menaikkan peristiwa BackRequested yang sama.

Contoh di bawah ini berfungsi untuk semua keluarga perangkat dan ada baiknya untuk kasus di mana pemrosesan yang sama berlaku untuk semua halaman, dan di mana Anda tidak perlu mengonfirmasi navigasi (misalnya, untuk memperingatkan tentang perubahan yang belum disimpan).

   // app.xaml.cs

    protected override void OnLaunched(LaunchActivatedEventArgs e)
    {
        [...]

        Windows.UI.Core.SystemNavigationManager.GetForCurrentView().BackRequested += App_BackRequested;
        rootFrame.Navigated += RootFrame_Navigated;
    }

    private void RootFrame_Navigated(object sender, NavigationEventArgs e)
    {
        Frame rootFrame = Window.Current.Content as Frame;

        // Note: On device families that have no title bar, setting AppViewBackButtonVisibility can safely execute 
        // but it will have no effect. Such device families provide a back button UI for you.
        if (rootFrame.CanGoBack)
        {
            Windows.UI.Core.SystemNavigationManager.GetForCurrentView().AppViewBackButtonVisibility = 
                Windows.UI.Core.AppViewBackButtonVisibility.Visible;
        }
        else
        {
            Windows.UI.Core.SystemNavigationManager.GetForCurrentView().AppViewBackButtonVisibility = 
                Windows.UI.Core.AppViewBackButtonVisibility.Collapsed;
        }
    }

    private void App_BackRequested(object sender, Windows.UI.Core.BackRequestedEventArgs e)
    {
        Frame rootFrame = Window.Current.Content as Frame;

        if (rootFrame.CanGoBack)
        {
            rootFrame.GoBack();
        }
    }

Ada juga satu pendekatan untuk semua keluarga perangkat untuk keluar dari aplikasi secara terprogram.

   Windows.UI.Xaml.Application.Current.Exit();

Pengikatan, dan pengikatan yang dikompilasi dengan {x:Bind}

Topik pengikatan meliputi:

• Mengikat elemen UI ke "data" (yaitu, ke properti dan perintah model tampilan)
• Mengikat elemen UI ke elemen UI lain
• Menulis model tampilan yang dapat diamati (yaitu, ia menaikkan pemberitahuan saat nilai properti berubah dan kapan ketersediaan perintah berubah)

Semua aspek ini sebagian besar masih didukung, tetapi ada perbedaan namespace. Misalnya, System.Windows.Data.Binding memetakan ke Windows.UI.Xaml.Data.Binding, System.ComponentModel.INotifyPropertyChanged memetakan ke peta Windows.UI.Xaml.Data.INotifyPropertyChanged, dan System.Collections.Specialized.INotifyPropertyChanged ke Windows.UI.Xaml.Interop.INotifyCollectionChanged.

Bilah aplikasi dan tombol bilah aplikasi Windows Phone Silverlight tidak dapat terikat seperti yang dapat dilakukan di aplikasi UWP. Anda mungkin memiliki kode penting yang membangun bilah aplikasi dan tombolnya, mengikatnya ke properti dan string yang dilokalkan, dan menangani peristiwanya. Jika demikian, Anda sekarang memiliki opsi untuk mem-port kode imperatif dengan menggantinya dengan markup deklaratif yang terikat pada properti dan perintah, dan dengan referensi sumber daya statis, sehingga membuat aplikasi Anda secara bertahap lebih aman dan lebih dapat dipertahankan. Anda dapat menggunakan Visual Studio atau Blend for Visual Studio untuk mengikat dan menata tombol bilah aplikasi UWP sama seperti elemen XAML lainnya. Perhatikan bahwa di aplikasi UWP, nama jenis yang Anda gunakan adalah CommandBar dan AppBarButton.

Fitur terkait pengikatan aplikasi UWP saat ini memiliki batasan berikut:

• Tidak ada dukungan bawaan untuk validasi entri data dan antarmuka IDataErrorInfo dan INotifyDataErrorInfo .
• Kelas Pengikatan tidak menyertakan properti pemformatan yang diperluas yang tersedia di Windows Phone Silverlight. Namun, Anda masih dapat menerapkan IValueConverter untuk menyediakan pemformatan kustom.
• Metode IValueConverter mengambil string bahasa sebagai parameter alih-alih objek CultureInfo .
• Kelas CollectionViewSource tidak menyediakan dukungan bawaan untuk pengurutan dan pemfilteran, dan pengelompokan bekerja secara berbeda. Untuk informasi selengkapnya, lihat Pengikatan data secara mendalam dan Sampel pengikatan data.

Meskipun fitur pengikatan yang sama masih sebagian besar didukung, Windows 10 menawarkan opsi mekanisme pengikatan baru dan lebih berkinerja yang disebut pengikatan terkompilasi, yang menggunakan ekstensi markup {x:Bind}. Lihat Pengikatan Data: Meningkatkan Performa Aplikasi Anda Melalui Peningkatan Baru ke Pengikatan Data XAML, dan Sampel x:Bind.

Mengikat Gambar ke model tampilan

Anda dapat mengikat properti Image.Source ke properti apa pun dari model tampilan yang berjenis ImageSource. Berikut adalah implementasi khas properti seperti itu di aplikasi Windows Phone Silverlight:

    // this.BookCoverImagePath contains a path of the form "/Assets/CoverImages/one.png".
    return new BitmapImage(new Uri(this.CoverImagePath, UriKind.Relative));

Di aplikasi UWP, Anda menggunakan skema URI ms-appx. Sehingga Anda dapat menjaga sisa kode Anda tetap sama, Anda dapat menggunakan kelebihan beban yang berbeda dari konstruktor System.Uri untuk menempatkan skema URI ms-appx di URI dasar dan menambahkan sisa jalur ke dalamnya. Seperti ini:

    // this.BookCoverImagePath contains a path of the form "/Assets/CoverImages/one.png".
    return new BitmapImage(new Uri(new Uri("ms-appx://"), this.CoverImagePath));

Dengan begitu, sisa model tampilan, nilai jalur di properti jalur gambar, dan pengikatan dalam markup XAML, semuanya dapat tetap sama persis.

Kontrol, dan gaya/templat kontrol

Aplikasi Windows Phone Silverlight menggunakan kontrol yang ditentukan dalam namespace Microsoft.Phone.Controls dan namespace System.Windows.Controls . Aplikasi XAML UWP menggunakan kontrol yang ditentukan dalam namespace Windows.UI.Xaml.Controls . Arsitektur dan desain kontrol XAML di UWP hampir sama dengan kontrol Windows Phone Silverlight. Namun, beberapa perubahan telah dilakukan untuk meningkatkan serangkaian kontrol yang tersedia dan untuk menyatukannya dengan aplikasi Windows. Berikut adalah contoh spesifik.

Nama kontrol	Ubah
Bilah Aplikasi	Properti Page.TopAppBar .
ApplicationBariconButton	Setara dengan UWP adalah properti Glyph . PrimaryCommands adalah properti konten CommandBar. Parser XAML menginterpretasikan xml dalam elemen sebagai nilai properti kontennya.
ApplicationBarMenuItem	Setara dengan UWP adalah AppBarButton.Label yang diatur ke teks item menu.
ContextMenu (di Toolkit Windows Phone)	Untuk satu pilihan fly-out, gunakan Flyout.
Kelas ControlTiltEffect.TiltEffect	Animasi dari pustaka animasi UWP dibangun ke dalam Gaya default kontrol umum. Lihat tindakan Animating pointer.
LongListSelector dengan data yang dikelompokkan	Fungsi Windows Phone Silverlight LongListSelector dengan dua cara, yang dapat digunakan dalam konser. Pertama, ia dapat menampilkan data yang dikelompokkan menurut kunci, misalnya, daftar nama yang dikelompokkan menurut huruf awal. Kedua, ia dapat "memperbesar" antara dua tampilan semantik: daftar item yang dikelompokkan (misalnya, nama), dan daftar hanya kunci grup itu sendiri (misalnya, huruf awal). Dengan UWP, Anda dapat menampilkan data yang dikelompokkan dengan Panduan untuk kontrol tampilan daftar dan kisi.
LongListSelector dengan datar	Untuk alasan performa, dalam kasus daftar yang sangat panjang, kami merekomendasikan LongListSelector alih-alih kotak daftar Windows Phone Silverlight bahkan untuk data datar dan tidak dikelompokkan. Dalam aplikasi UWP, GridView lebih disukai untuk daftar panjang item apakah data dapat dikelompokkan atau tidak.
Panorama	Panorama Windows Phone Silverlight mengontrol peta ke Panduan untuk kontrol hub di aplikasi Windows Runtime 8.x dan Panduan untuk kontrol hub. Perhatikan bahwa kontrol Panorama membungkus dari bagian terakhir ke yang pertama, dan gambar latar belakangnya bergerak secara paralaks relatif terhadap bagian. Bagian hub tidak membungkus, dan paralaks tidak digunakan.
Pivot	Kontrol Pivot Windows Phone Silverlight yang setara dengan UWP adalah Windows.UI.Xaml.Controls.Pivot. Ini tersedia untuk semua keluarga perangkat.

Catatan Status visual PointerOver relevan dalam gaya/templat kustom di aplikasi Windows 10, tetapi tidak di aplikasi Windows Phone Silverlight. Ada alasan lain mengapa gaya/templat kustom yang ada mungkin tidak sesuai untuk aplikasi Windows 10, termasuk kunci sumber daya sistem yang Anda gunakan, perubahan pada set status visual yang digunakan, dan peningkatan performa yang dilakukan pada gaya/templat default Windows 10. Kami menyarankan agar Anda mengedit salinan baru templat default kontrol untuk Windows 10 lalu menerapkan kembali kustomisasi gaya dan templat Anda ke templat tersebut.

Untuk informasi selengkapnya tentang kontrol UWP, lihat Kontrol menurut fungsi, daftar Kontrol, dan Panduan untuk kontrol.

Bahasa desain dalam Windows 10

Ada beberapa perbedaan dalam bahasa desain antara aplikasi Windows Phone Silverlight dan aplikasi Windows 10. Untuk semua detailnya, lihat Desain. Terlepas dari perubahan bahasa desain, prinsip desain kami tetap konsisten: memperhatikan detail tetapi selalu berusaha untuk kesederhanaan melalui fokus pada konten yang tidak chrome, mengurangi elemen visual dengan sengit, dan tetap autentik untuk domain digital; gunakan hierarki visual terutama dengan tipografi; desain pada kisi; dan hidupkan pengalaman Anda dengan animasi cairan.

Pelokalan dan globalisasi

Untuk string yang dilokalkan, Anda dapat menggunakan kembali file .resx dari proyek Windows Phone Silverlight di proyek aplikasi UWP Anda. Salin file, tambahkan ke proyek, dan ganti namanya menjadi Resources.resw sehingga mekanisme pencarian akan menemukannya secara default. Atur Tindakan Build ke PRIResource dan Salin ke Direktori Output ke Jangan salin. Anda kemudian dapat menggunakan string dalam markup dengan menentukan atribut x:Uid pada elemen XAML Anda. Lihat Mulai Cepat: Menggunakan sumber daya string.

Aplikasi Windows Phone Silverlight menggunakan kelas CultureInfo untuk membantu meng-globalisasi aplikasi. Aplikasi UWP menggunakan MRT (Teknologi Sumber Daya Modern), yang memungkinkan pemuatan dinamis sumber daya aplikasi (pelokalan, skala, dan tema) baik saat runtime maupun di permukaan desain Visual Studio. Untuk informasi selengkapnya, lihat Panduan untuk file, data, dan globalisasi.

Topik ResourceContext.QualifierValues menjelaskan cara memuat sumber daya khusus keluarga perangkat berdasarkan faktor pemilihan sumber daya keluarga perangkat.

Media dan grafik

Saat Anda membaca tentang media dan grafik UWP, ingatlah bahwa prinsip desain Windows mendorong pengurangan sengit dari apa pun yang berlebihan, termasuk kompleksitas grafis dan kekacauan. Desain Windows dititipkan oleh visual, tipografi, dan gerakan yang bersih dan jelas. Jika aplikasi Anda mengikuti prinsip yang sama, maka aplikasi tersebut akan tampak lebih seperti aplikasi bawaan.

Windows Phone Silverlight memiliki jenis RadialGradientBrush yang tidak ada di UWP, meskipun jenis Brush lainnya. Dalam beberapa kasus, Anda akan bisa mendapatkan efek yang sama dengan bitmap. Perhatikan bahwa Anda dapat membuat sikat gradien radial dengan Direct2D di Microsoft DirectX dan XAML C++ UWP.

Windows Phone Silverlight memiliki properti System.Windows.UIElement.OpacityMask , tetapi properti tersebut bukan anggota dari jenis UIElement UWP. Dalam beberapa kasus, Anda akan bisa mendapatkan efek yang sama dengan bitmap. Dan Anda dapat membuat masker opasitas dengan Direct2D di aplikasi Microsoft DirectX dan XAML C++ UWP. Tetapi, kasus penggunaan umum untuk OpacityMask adalah menggunakan bitmap tunggal yang beradaptasi dengan tema terang dan gelap. Untuk grafik vektor, Anda dapat menggunakan kuas sistem sadar tema (seperti bagan pai yang diilustrasikan di bawah). Tetapi, untuk membuat bitmap sadar tema (seperti tanda centang yang diilustrasikan di bawah), memerlukan pendekatan yang berbeda.

Dalam aplikasi Windows Phone Silverlight, tekniknya adalah menggunakan masker alfa (dalam bentuk bitmap) sebagai OpacityMask untuk Persegi panjang yang diisi dengan kuas latar depan:

    <Rectangle Fill="{StaticResource PhoneForegroundBrush}" Width="26" Height="26">
        <Rectangle.OpacityMask>
            <ImageBrush ImageSource="/Assets/wpsl_check.png"/>
        </Rectangle.OpacityMask>
    </Rectangle>

Cara paling mudah untuk memindahkan ini ke aplikasi UWP adalah dengan menggunakan BitmapIcon, seperti ini:

    <BitmapIcon UriSource="Assets/winrt_check.png" Width="21" Height="21"/>

Di sini, winrt_check.png adalah masker alfa dalam bentuk bitmap sama seperti wpsl_check.png, dan itu bisa sangat baik menjadi file yang sama. Namun, Anda mungkin ingin menyediakan beberapa ukuran winrt_check.png yang berbeda untuk digunakan untuk faktor penskalaan yang berbeda. Untuk informasi selengkapnya tentang itu, dan untuk penjelasan tentang perubahan pada nilai Lebar dan Tinggi , lihat Melihat atau efektif piksel, melihat jarak, dan faktor skala dalam topik ini.

Pendekatan yang lebih umum, yang sesuai jika ada perbedaan antara bentuk tema terang dan gelap dari bitmap, adalah menggunakan dua aset gambar —satu dengan latar depan gelap (untuk tema terang) dan satu dengan latar depan terang (untuk tema gelap). Untuk detail lebih lanjut tentang cara memberi nama set aset bitmap ini, lihat Menyesuaikan sumber daya Anda untuk bahasa, skala, dan kualifikasi lainnya. Setelah sekumpulan file gambar dinamai dengan benar, Anda dapat merujuknya dalam abstrak, menggunakan nama akarnya, seperti ini:

    <Image Source="Assets/winrt_check.png" Stretch="None"/>

Di Windows Phone Silverlight, properti UIElement.Clip dapat berupa bentuk apa pun yang dapat Anda ekspresikan dengan Geometri dan biasanya diserialisasikan dalam markup XAML dalam bahasa mini StreamGeometry . Di UWP, jenis properti Klip adalah RectangleGeometry, sehingga Anda hanya dapat mengklip wilayah persegi panjang. Memungkinkan persegi panjang didefinisikan menggunakan bahasa mini akan terlalu permisif. Jadi, untuk memindahkan wilayah kliping dalam markup, ganti sintaks atribut Klip dan buat menjadi sintaks elemen properti yang mirip dengan yang berikut ini:

    <UIElement.Clip>
        <RectangleGeometry Rect="10 10 50 50"/>
    </UIElement.Clip>

Perhatikan bahwa Anda dapat menggunakan geometri arbitrer sebagai masker dalam lapisan dengan Direct2D di aplikasi Microsoft DirectX dan XAML C++ UWP.

Navigasi

Saat Anda menavigasi ke halaman di aplikasi Windows Phone Silverlight, Anda menggunakan skema alamat Pengidentifikasi Sumber Daya Seragam (URI):

    NavigationService.Navigate(new Uri("/AnotherPage.xaml", UriKind.Relative)/*, navigationState*/);

Dalam aplikasi UWP, Anda memanggil metode Frame.Navigate dan menentukan jenis halaman tujuan (seperti yang ditentukan oleh atribut x:Class dari definisi markup XAML halaman):

    // In a page:
    this.Frame.Navigate(typeof(AnotherPage)/*, parameter*/);

    // In a view model, perhaps inside an ICommand implementation:
    var rootFrame = Windows.UI.Xaml.Window.Current.Content as Windows.UI.Xaml.Controls.Frame;
    rootFrame.Navigate(typeof(AnotherPage)/*, parameter*/);

Anda menentukan halaman startup untuk aplikasi Windows Phone Silverlight di WMAppManifest.xml:

    <DefaultTask Name="_default" NavigationPage="MainPage.xaml" />

Di aplikasi UWP, Anda menggunakan kode imperatif untuk menentukan halaman startup. Berikut adalah beberapa kode dari App.xaml.cs yang menggambarkan caranya:

    if (!rootFrame.Navigate(typeof(MainPage), e.Arguments))

Pemetaan URI dan navigasi fragmen adalah teknik navigasi URI, sehingga tidak berlaku untuk navigasi UWP, yang tidak didasarkan pada URI. Pemetaan URI ada sebagai respons terhadap sifat yang ditik lemah untuk mengidentifikasi halaman target dengan string URI, yang menyebabkan masalah kerapuhan dan pemeliharaan jika halaman berpindah ke folder yang berbeda dan karenanya ke jalur relatif yang berbeda. Aplikasi UWP menggunakan navigasi berbasis jenis, yang ditik dengan kuat dan diperiksa kompilator, dan tidak memiliki masalah yang dipecahkan pemetaan URI. Kasus penggunaan untuk navigasi fragmen adalah meneruskan beberapa konteks ke halaman target sehingga halaman dapat menyebabkan fragmen tertentu dari kontennya digulir ke dalam tampilan, atau ditampilkan. Tujuan yang sama dapat dicapai dengan meneruskan parameter navigasi saat Anda memanggil metode Navigasi .

Untuk informasi selengkapnya, lihat Navigasi.

Referensi kunci sumber daya

Bahasa desain telah berkembang untuk Windows 10 dan akibatnya gaya sistem tertentu telah berubah, dan banyak kunci sumber daya sistem telah dihapus atau diganti namanya. Editor markup XAML di Visual Studio menyoroti referensi ke kunci sumber daya yang tidak dapat diselesaikan. Misalnya, editor markup XAML akan menggaris bawahi referensi ke kunci PhoneTextNormalStyle gaya dengan berlekuk merah. Jika itu tidak dikoreksi, aplikasi akan segera berakhir saat Anda mencoba menyebarkannya ke emulator atau perangkat. Jadi, penting untuk menghadiri kebenaran markup XAML. Dan Anda akan menemukan Visual Studio untuk menjadi alat yang bagus untuk menangkap masalah tersebut.

Selain itu, lihat Teks, di bawah ini.

Bilah status (baki sistem)

Baki sistem (diatur dalam markup XAML dengan shell:SystemTray.IsVisible) sekarang disebut bilah status, dan ditampilkan secara default. Anda dapat mengontrol visibilitasnya dalam kode imperatif dengan memanggil metode Windows.UI.ViewManagement.StatusBar.ShowAsync dan HideAsync .

Teks

Teks (atau tipografi) adalah aspek penting dari aplikasi UWP dan, saat porting, Anda mungkin ingin mengunjungi kembali desain visual tampilan Anda sehingga selaras dengan bahasa desain baru. Gunakan ilustrasi ini untuk menemukan gaya sistem UWP TextBlock yang tersedia. Temukan yang sesuai dengan gaya Windows Phone Silverlight yang Anda gunakan. Atau, Anda dapat membuat gaya universal Anda sendiri dan menyalin properti dari gaya sistem Windows Phone Silverlight ke dalamnya.

Gaya TextBlock Sistem untuk aplikasi Windows 10

Di aplikasi Windows Phone Silverlight, keluarga font default adalah Segoe WP. Dalam aplikasi Windows 10, keluarga font default adalah Segoe UI. Akibatnya, metrik font di aplikasi Anda mungkin terlihat berbeda. Jika Anda ingin mereproduksi tampilan teks Windows Phone Silverlight, Anda dapat mengatur metrik Anda sendiri menggunakan properti seperti LineHeight dan LineStackingStrategy. Untuk informasi selengkapnya, lihat Panduan untuk font dan Mendesain aplikasi UWP.

Perubahan tema

Untuk aplikasi Windows Phone Silverlight, tema defaultnya gelap secara default. Untuk perangkat Windows 10, tema default telah berubah, tetapi Anda dapat mengontrol tema yang digunakan dengan mendeklarasikan tema yang diminta di App.xaml. Misalnya, untuk menggunakan tema gelap di semua perangkat, tambahkan RequestedTheme="Dark" ke elemen Aplikasi akar.

Petak peta

Petak peta untuk aplikasi UWP memiliki perilaku yang mirip dengan Live Tiles untuk aplikasi Windows Phone Silverlight, meskipun ada beberapa perbedaan. Misalnya, kode yang memanggil metode Microsoft.Phone.Shell.ShellTile.Create untuk membuat petak peta sekunder harus di-port untuk memanggil SecondaryTile.RequestCreateAsync. Berikut adalah contoh sebelum dan sesudah, pertama versi Windows Phone Silverlight:

    var tileData = new IconicTileData()
    {
        Title = this.selectedBookSku.Title,
        WideContent1 = this.selectedBookSku.Title,
        WideContent2 = this.selectedBookSku.Author,
        SmallIconImage = this.SmallIconImageAsUri,
        IconImage = this.IconImageAsUri
    };

    ShellTile.Create(this.selectedBookSku.NavigationUri, tileData, true);

Dan UWP yang setara:

    var tile = new SecondaryTile(
        this.selectedBookSku.Title.Replace(" ", string.Empty),
        this.selectedBookSku.Title,
        this.selectedBookSku.ArgumentString,
        this.IconImageAsUri,
        TileSize.Square150x150);

    await tile.RequestCreateAsync();

Kode yang memperbarui petak peta dengan metode Microsoft.Phone.Shell.ShellTile.Update , atau kelas Microsoft.Phone.Shell.ShellTileSchedule , harus di-port untuk menggunakan kelas TileUpdateManager, TileUpdater, TileNotification, dan/atau ScheduledTileNotification .

Untuk informasi selengkapnya tentang petak peta, toast, lencana, banner, dan pemberitahuan, lihat Membuat petak peta dan Bekerja dengan petak peta, lencana, dan pemberitahuan toast. Untuk detail tentang ukuran aset visual yang digunakan untuk UWP Tiles, lihat Petak peta dan aset visual toast.

Roti panggang

Kode yang menampilkan toast dengan kelas Microsoft.Phone.Shell.ShellToast harus di-port untuk menggunakan kelas ToastNotificationManager, ToastNotifier, ToastNotification, dan/atau ScheduledToastNotification . Perhatikan bahwa pada perangkat seluler, istilah yang menghadap konsumen untuk "toast" adalah "banner".

Lihat Bekerja dengan petak peta, lencana, dan pemberitahuan toast.

Melihat atau efektif piksel, melihat jarak, dan faktor skala

Aplikasi Windows Phone Silverlight dan aplikasi Windows 10 berbeda dalam cara mereka mengabstraksi ukuran dan tata letak elemen UI yang jauh dari ukuran fisik dan resolusi perangkat yang sebenarnya. Aplikasi Windows Phone Silverlight menggunakan piksel tampilan untuk melakukan ini. Dengan Windows 10, konsep piksel tampilan telah disempurnakan ke dalam piksel yang efektif. Berikut adalah penjelasan tentang istilah itu, apa artinya, dan nilai tambahan yang ditawarkannya.

Istilah "resolusi" mengacu pada ukuran kepadatan piksel dan bukan, seperti yang umumnya dipikirkan, jumlah piksel. "Resolusi efektif" adalah cara piksel fisik yang menyusun gambar atau glyph mengatasi perbedaan mata yang diberikan dalam jarak pandang dan ukuran piksel fisik perangkat (kepadatan piksel menjadi timbal balik ukuran piksel fisik). Resolusi yang efektif adalah metrik yang baik untuk membangun pengalaman karena berpusat pada pengguna. Dengan memahami semua faktor, dan mengontrol ukuran elemen UI, Anda dapat membuat pengalaman pengguna menjadi lebih baik.

Untuk aplikasi Windows Phone Silverlight, semua layar ponsel memiliki lebar persis 480 piksel tampilan, tanpa terkecuali, tidak peduli berapa banyak piksel fisik yang dimiliki layar, atau berapa pun kerapatan piksel atau ukuran fisiknya. Ini berarti bahwa elemen Gambar dengan Width="48" akan tepat sepersepuluh dari lebar layar ponsel apa pun yang dapat menjalankan aplikasi Windows Phone Silverlight.

Untuk aplikasi Windows 10, tidak masalah bahwa semua perangkat adalah beberapa jumlah piksel efektif tetap. Itu mungkin jelas, mengingat berbagai perangkat yang dapat dijalankan oleh aplikasi UWP. Perangkat yang berbeda adalah jumlah piksel efektif yang berbeda, mulai dari 320 epx untuk perangkat terkecil, hingga 1024 epx untuk monitor berukuran sederhana, dan jauh lebih tinggi hingga lebar yang jauh lebih tinggi. Yang harus Anda lakukan adalah terus menggunakan elemen berukuran otomatis dan panel tata letak dinamis seperti yang selalu Anda miliki. Juga akan ada beberapa kasus di mana Anda akan mengatur properti elemen UI Anda ke ukuran tetap dalam markup XAML. Faktor skala secara otomatis diterapkan ke aplikasi Anda tergantung pada perangkat apa yang dijalankannya dan pengaturan tampilan yang dibuat oleh pengguna. Dan faktor skala tersebut berfungsi untuk menjaga elemen UI apa pun dengan ukuran tetap yang menyajikan target sentuhan (dan pembacaan) berukuran lebih atau kurang konstan kepada pengguna di berbagai ukuran layar. Dan bersama dengan tata letak dinamis UI Anda tidak akan hanya secara optik menskalakan pada perangkat yang berbeda, sebaliknya akan melakukan apa yang diperlukan agar sesuai dengan jumlah konten yang sesuai ke dalam ruang yang tersedia.

Karena 480 sebelumnya adalah lebar tetap dalam piksel tampilan untuk layar berukuran telepon, dan nilai itu sekarang biasanya lebih kecil dalam piksel yang efektif, aturan praktis adalah mengalikan dimensi apa pun di markup aplikasi Windows Phone Silverlight Anda dengan faktor 0,8.

Agar aplikasi Anda memiliki pengalaman terbaik di semua tampilan, kami sarankan Anda membuat setiap aset bitmap dalam berbagai ukuran, masing-masing cocok untuk faktor skala tertentu. Menyediakan aset dalam skala 100%, skala 200%, dan skala 400%(dalam urutan prioritas tersebut) akan memberi Anda hasil yang sangat baik dalam banyak kasus di semua faktor skala menengah.

Catatan Jika, karena alasan apa pun, Anda tidak dapat membuat aset dalam lebih dari satu ukuran, maka buat aset berskala 100%. Di Microsoft Visual Studio, templat proyek default untuk aplikasi UWP menyediakan aset branding (gambar dan logo petak peta) hanya dalam satu ukuran, tetapi tidak berskala 100%. Saat menulis aset untuk aplikasi Anda sendiri, ikuti panduan di bagian ini dan berikan ukuran 100%, 200%, dan 400%, dan gunakan paket aset.

Jika Anda memiliki karya seni yang rumit, maka Anda mungkin ingin memberikan aset Anda dalam ukuran yang lebih besar. Jika Anda memulai dengan seni vektor, maka relatif mudah untuk menghasilkan aset berkualitas tinggi pada faktor skala apa pun.

Kami tidak menyarankan Anda mencoba mendukung semua faktor skala, tetapi daftar lengkap faktor skala untuk aplikasi Windows 10 adalah 100%, 125%, 150%, 200%, 250%, 300%, dan 400%. Jika Anda menyediakannya, Store akan memilih aset berukuran benar untuk setiap perangkat, dan hanya aset tersebut yang akan diunduh. Store memilih aset yang akan diunduh berdasarkan DPI perangkat.

Untuk informasi selengkapnya, lihat Desain responsif 101 untuk aplikasi UWP.

Ukuran jendela

Di aplikasi UWP, Anda dapat menentukan ukuran minimum (lebar dan tinggi) dengan kode imperatif. Ukuran minimum default adalah 500x320epx, dan itu juga ukuran minimum terkecil yang diterima. Ukuran minimum terbesar yang diterima adalah 500x500epx.

   Windows.UI.ViewManagement.ApplicationView.GetForCurrentView().SetPreferredMinSize
        (new Size { Width = 500, Height = 500 });

Topik berikutnya adalah Porting untuk I/O, perangkat, dan model aplikasi.

Topik terkait

• Pemetaan namespace layanan dan kelas