پشتیبانی از اندازه های مختلف نمایشگر، پشتیبانی از اندازه های مختلف نمایشگر

پشتیبانی از اندازه های مختلف نمایشگر امکان دسترسی به برنامه شما را توسط طیف وسیعی از دستگاه ها و بیشترین تعداد کاربر فراهم می کند.

برای پشتیبانی از اندازه‌های نمایش هرچه بیشتر – چه صفحه‌نمایش‌های مختلف دستگاه یا پنجره‌های برنامه‌های مختلف در حالت چند پنجره‌ای – طرح‌بندی برنامه‌های خود را طوری طراحی کنید که واکنش‌گرا و تطبیقی ​​باشند. طرح‌بندی‌های واکنش‌گرا/تطبیقی ​​بدون در نظر گرفتن اندازه نمایشگر، تجربه کاربری بهینه‌سازی‌شده‌ای را ارائه می‌کنند و برنامه شما را قادر می‌سازد تا تلفن‌ها، تبلت‌ها، تاشوها، دستگاه‌های ChromeOS، جهت‌های عمودی و افقی، و پیکربندی‌های نمایشگر قابل تغییر اندازه مانند حالت تقسیم صفحه و پنجره‌های دسک‌تاپ را در خود جای دهد.

طرح بندی پاسخگو/تطبیقی ​​بر اساس فضای نمایش موجود تغییر می کند. تغییرات از تنظیمات طرح‌بندی کوچک که فضا را پر می‌کند (طراحی واکنش‌گرا) تا جایگزینی کامل یک طرح‌بندی با طرح‌بندی دیگر را شامل می‌شود تا برنامه شما بتواند اندازه‌های مختلف نمایشگر را به بهترین شکل در خود جای دهد (طراحی تطبیقی).

Jetpack Compose به‌عنوان یک جعبه ابزار UI اظهاری، ایده‌آل برای طراحی و اجرای طرح‌بندی‌هایی است که به صورت پویا تغییر می‌کنند و محتوا را در اندازه‌های مختلف نمایش متفاوت ارائه می‌کنند.

تغییرات طرح‌بندی بزرگ را برای کامپوزیشن‌های سطح محتوا آشکار کنید

کامپوزیشن‌های سطح برنامه و سطح محتوا، تمام فضای نمایشی موجود در برنامه شما را اشغال می‌کنند. برای این نوع از اجزای سازنده، ممکن است منطقی باشد که طرح کلی برنامه خود را در نمایشگرهای بزرگ تغییر دهید.

از استفاده از مقادیر فیزیکی سخت افزار برای تصمیم گیری در مورد چیدمان خودداری کنید. ممکن است تصمیم گیری بر اساس یک مقدار ثابت و ملموس وسوسه انگیز باشد (آیا دستگاه تبلت است؟ آیا صفحه نمایش فیزیکی نسبت ابعاد خاصی دارد؟)، اما پاسخ به این سؤالات ممکن است برای تعیین فضای موجود برای رابط کاربری شما مفید نباشد. .

شکل 1. عوامل شکل تلفن، تاشو، تبلت و لپ تاپ

در رایانه لوحی، یک برنامه ممکن است در حالت چند پنجره ای اجرا شود، به این معنی که برنامه ممکن است صفحه نمایش را با برنامه دیگری تقسیم کند. در حالت پنجره دسک‌تاپ یا در ChromeOS، ممکن است یک برنامه در یک پنجره قابل تغییر اندازه باشد. حتی ممکن است بیش از یک صفحه نمایش فیزیکی مانند یک دستگاه تاشو وجود داشته باشد. در همه این موارد، اندازه فیزیکی صفحه نمایش برای تصمیم گیری در مورد نحوه نمایش محتوا مهم نیست.

در عوض، شما باید بر اساس بخش واقعی صفحه اختصاص داده شده به برنامه شما که توسط معیارهای پنجره فعلی ارائه شده توسط کتابخانه Jetpack WindowManager توضیح داده شده است، تصمیم بگیرید. برای مثالی از نحوه استفاده از WindowManager در برنامه Compose، به نمونه JetNews مراجعه کنید.

تطبیق طرح‌بندی‌هایتان با فضای نمایش موجود، میزان کنترل ویژه مورد نیاز برای پشتیبانی از پلتفرم‌هایی مانند ChromeOS و عواملی مانند تبلت‌ها و تاشوها را کاهش می‌دهد.

هنگامی که معیارهای فضای موجود برای برنامه خود را تعیین کردید، اندازه خام را همانطور که در استفاده از کلاس‌های اندازه پنجره توضیح داده شد به یک کلاس اندازه پنجره تبدیل کنید. کلاس‌های اندازه پنجره نقطه‌های شکستی هستند که برای متعادل کردن سادگی منطق برنامه و انعطاف‌پذیری برای بهینه‌سازی برنامه شما برای اکثر اندازه‌های نمایش طراحی شده‌اند. کلاس‌های اندازه پنجره به پنجره کلی برنامه شما اشاره دارد، بنابراین از کلاس‌ها برای تصمیم‌گیری‌های طرح‌بندی که بر روی طرح کلی برنامه شما تأثیر می‌گذارند، استفاده کنید. می‌توانید کلاس‌های اندازه پنجره را به‌عنوان حالت پایین بیاورید، یا می‌توانید منطق اضافی برای ایجاد حالت مشتق‌شده برای انتقال به ترکیب‌پذیرهای تودرتو انجام دهید. 

@Composable
fun MyApp(
    windowSizeClass: WindowSizeClass = currentWindowAdaptiveInfo().windowSizeClass
) {
    // Perform logic on the size class to decide whether to show the top app bar.
    val showTopAppBar = windowSizeClass.windowHeightSizeClass != WindowHeightSizeClass.COMPACT

    // MyScreen knows nothing about window sizes, and performs logic based on a Boolean flag.
    MyScreen(
        showTopAppBar = showTopAppBar,
        /* ... */
    )
}
AdaptiveLayoutSnippets.kt

یک رویکرد لایه‌ای، منطق اندازه نمایشگر را به جای پراکنده کردن آن در سراسر برنامه در مکان‌هایی که نیاز به هماهنگی دارند، به یک مکان محدود می‌کند. یک مکان واحد حالتی را ایجاد می‌کند که می‌تواند به صراحت مانند هر حالت برنامه دیگر به سایر اجزای سازنده منتقل شود. عبور صریح حالت، ترکیب‌پذیرهای منفرد را ساده می‌کند، زیرا ترکیب‌پذیرها کلاس اندازه پنجره یا پیکربندی مشخص شده را همراه با داده‌های دیگر می‌گیرند.

ترکیبات تو در تو انعطاف پذیر قابل استفاده مجدد هستند

ترکیبات زمانی که بتوان آن ها را در مکان های مختلف قرار داد، قابلیت استفاده مجدد بیشتری دارند. اگر یک محصول ترکیبی باید در یک مکان خاص با یک اندازه خاص قرار گیرد، بعید است که در زمینه های دیگر قابل استفاده مجدد باشد. این همچنین به این معنی است که منفرد و قابل استفاده مجدد باید به طور ضمنی بسته به اطلاعات اندازه صفحه نمایش جهانی اجتناب کنند.

یک ترکیب تودرتو را تصور کنید که طرح‌بندی جزئیات فهرست را پیاده‌سازی می‌کند، که ممکن است یک صفحه یا دو صفحه را در کنار هم نشان دهد:

برنامه ای که دو صفحه را در کنار هم نشان می دهد.
شکل 2. برنامه ای که یک چیدمان معمولی با جزئیات لیست را نشان می دهد - 1 ناحیه لیست است. 2 ، منطقه جزئیات.

تصمیم‌گیری فهرست جزئیات باید بخشی از طرح کلی برنامه باشد، بنابراین تصمیم از یک فایل قابل ترکیب در سطح محتوا منتقل می‌شود: 

@Composable
fun AdaptivePane(
    showOnePane: Boolean,
    /* ... */
) {
    if (showOnePane) {
        OnePane(/* ... */)
    } else {
        TwoPane(/* ... */)
    }
}
AdaptiveLayoutSnippets.kt

اگر به جای آن بخواهید یک composable به طور مستقل طرح خود را بر اساس فضای نمایش موجود تغییر دهد، برای مثال، کارتی که در صورت اجازه فضا جزئیات اضافی را نشان می دهد، چه؟ شما می خواهید منطقی را بر اساس اندازه نمایشگر موجود انجام دهید، اما به طور خاص کدام اندازه؟

شکل 3. کارت باریک که فقط یک نماد و عنوان را نشان می‌دهد و یک کارت پهن‌تر که نماد، عنوان و توضیحات کوتاه را نشان می‌دهد.

از تلاش برای استفاده از اندازه صفحه نمایش واقعی دستگاه خودداری کنید. این برای انواع مختلف صفحه نمایش دقیق نخواهد بود و همچنین اگر برنامه تمام صفحه نباشد دقیق نخواهد بود.

از آنجایی که composable قابل ترکیب در سطح محتوا نیست، از معیارهای پنجره فعلی به طور مستقیم استفاده نکنید. اگر کامپوننت با بالشتک قرار داده شده باشد (مثلاً با قسمت‌های داخلی)، یا اگر برنامه شامل اجزایی مانند ریل‌های ناوبری یا نوارهای برنامه باشد، ممکن است میزان فضای نمایشی در دسترس برای ترکیب‌بندی با فضای کلی در دسترس برنامه متفاوت باشد.

از عرضی که در واقع composable داده شده است برای رندر کردن خود استفاده کنید. شما دو گزینه برای بدست آوردن آن عرض دارید:

  • اگر می‌خواهید مکان یا نحوه نمایش محتوا را تغییر دهید، از مجموعه‌ای از اصلاح‌کننده‌ها یا یک طرح‌بندی سفارشی استفاده کنید تا طرح‌بندی واکنش‌گرا باشد. این می تواند به همان اندازه ساده باشد که یک کودک تمام فضای موجود را پر کند، یا در صورت وجود فضای کافی، کودکان را با ستون های متعدد بچینید.

  • اگر می‌خواهید چیزی را که نشان می‌دهید تغییر دهید، از BoxWithConstraints به عنوان جایگزین قدرتمندتری استفاده کنید. BoxWithConstraints محدودیت‌های اندازه‌گیری را ارائه می‌کند که می‌توانید از آن‌ها برای فراخوانی ترکیب‌پذیرهای مختلف بر اساس فضای نمایش موجود استفاده کنید. با این حال، این امر با هزینه‌هایی همراه است، زیرا BoxWithConstraints ترکیب را تا مرحله طرح‌بندی، زمانی که این محدودیت‌ها شناخته می‌شوند، به تعویق می‌اندازد، و باعث می‌شود کارهای بیشتری در طول طرح‌بندی انجام شود. 

@Composable
fun Card(/* ... */) {
    BoxWithConstraints {
        if (maxWidth < 400.dp) {
            Column {
                Image(/* ... */)
                Title(/* ... */)
            }
        } else {
            Row {
                Column {
                    Title(/* ... */)
                    Description(/* ... */)
                }
                Image(/* ... */)
            }
        }
    }
}
AdaptiveLayoutSnippets.kt

اطمینان حاصل کنید که همه داده ها برای اندازه های مختلف نمایشگر در دسترس هستند

هنگام اجرای یک ترکیب بندی که از فضای نمایش اضافی بهره می برد، ممکن است وسوسه شوید که کارآمد باشید و داده ها را به عنوان یک اثر جانبی اندازه نمایشگر فعلی بارگذاری کنید.

با این حال، انجام این کار برخلاف اصل جریان داده های یک طرفه است، جایی که داده ها را می توان بالا برد و در اختیار اجزای سازنده قرار داد تا به طور مناسب ارائه شوند. داده‌های کافی باید در اختیار دستگاه ترکیب‌سازی قرار گیرد تا همیشه برای هر اندازه نمایشگر محتوای کافی داشته باشد، حتی اگر بخشی از محتوا همیشه استفاده نشود. 

@Composable
fun Card(
    imageUrl: String,
    title: String,
    description: String
) {
    BoxWithConstraints {
        if (maxWidth < 400.dp) {
            Column {
                Image(imageUrl)
                Title(title)
            }
        } else {
            Row {
                Column {
                    Title(title)
                    Description(description)
                }
                Image(imageUrl)
            }
        }
    }
}
AdaptiveLayoutSnippets.kt

با توجه به مثال Card ، توجه داشته باشید که description همیشه به Card ارسال می شود. حتی اگر description فقط زمانی استفاده می‌شود که عرض اجازه نمایش آن را بدهد، Card همیشه بدون توجه به عرض موجود به description نیاز دارد.

همیشه ارسال محتوای کافی، طرح‌بندی‌های تطبیقی ​​را ساده‌تر می‌کند و باعث می‌شود که چیدمان‌های تطبیقی ​​ساده‌تر شوند و از ایجاد عوارض جانبی هنگام جابه‌جایی بین اندازه‌های نمایشگر (که ممکن است به دلیل تغییر اندازه پنجره، تغییر جهت، یا تا کردن و باز کردن دستگاه رخ دهد) جلوگیری می‌کند.

این اصل همچنین اجازه می دهد تا وضعیت را در سراسر تغییرات طرح بندی حفظ کنید. با بالا بردن اطلاعاتی که ممکن است در همه اندازه‌های نمایشگر استفاده نشود، می‌توانید وضعیت برنامه را با تغییر اندازه طرح‌بندی حفظ کنید. به عنوان مثال، می‌توانید پرچم بولی showMore را برافراشتید تا وضعیت برنامه حفظ شود زمانی که تغییر اندازه نمایشگر باعث می‌شود که چیدمان بین پنهان کردن و نمایش محتوا تغییر کند: 

@Composable
fun Card(
    imageUrl: String,
    title: String,
    description: String
) {
    var showMore by remember { mutableStateOf(false) }

    BoxWithConstraints {
        if (maxWidth < 400.dp) {
            Column {
                Image(imageUrl)
                Title(title)
            }
        } else {
            Row {
                Column {
                    Title(title)
                    Description(
                        description = description,
                        showMore = showMore,
                        onShowMoreToggled = { newValue ->
                            showMore = newValue
                        }
                    )
                }
                Image(imageUrl)
            }
        }
    }
}
AdaptiveLayoutSnippets.kt

بیشتر بدانید

برای کسب اطلاعات بیشتر در مورد طرح‌بندی‌های تطبیقی ​​در Compose، به منابع زیر مراجعه کنید:

نمونه برنامه ها

  • CanonicalLayouts مخزنی از الگوهای طراحی اثبات شده است که تجربه کاربری بهینه را در نمایشگرهای بزرگ فراهم می کند.
  • JetNews نحوه طراحی اپلیکیشنی را نشان می‌دهد که رابط کاربری خود را برای استفاده از فضای نمایش موجود تطبیق دهد
  • Reply یک نمونه تطبیقی ​​برای پشتیبانی از تلفن همراه، رایانه لوحی و تاشو است
  • اکنون در اندروید برنامه ای است که از طرح بندی های تطبیقی ​​برای پشتیبانی از اندازه های مختلف نمایشگر استفاده می کند

ویدیوها

،

پشتیبانی از اندازه های مختلف نمایشگر امکان دسترسی به برنامه شما را توسط طیف وسیعی از دستگاه ها و بیشترین تعداد کاربر فراهم می کند.

برای پشتیبانی از اندازه‌های نمایش هرچه بیشتر – چه صفحه‌نمایش‌های مختلف دستگاه یا پنجره‌های برنامه‌های مختلف در حالت چند پنجره‌ای – طرح‌بندی برنامه‌های خود را طوری طراحی کنید که واکنش‌گرا و تطبیقی ​​باشند. طرح‌بندی‌های واکنش‌گرا/تطبیقی ​​بدون در نظر گرفتن اندازه نمایشگر، تجربه کاربری بهینه‌سازی‌شده‌ای را ارائه می‌کنند و برنامه شما را قادر می‌سازد تا تلفن‌ها، تبلت‌ها، تاشوها، دستگاه‌های ChromeOS، جهت‌های عمودی و افقی، و پیکربندی‌های نمایشگر قابل تغییر اندازه مانند حالت تقسیم صفحه و پنجره‌های دسک‌تاپ را در خود جای دهد.

طرح بندی پاسخگو/تطبیقی ​​بر اساس فضای نمایش موجود تغییر می کند. تغییرات از تنظیمات طرح‌بندی کوچک که فضا را پر می‌کند (طراحی واکنش‌گرا) تا جایگزینی کامل یک طرح‌بندی با طرح‌بندی دیگر را شامل می‌شود تا برنامه شما بتواند اندازه‌های مختلف نمایشگر را به بهترین شکل در خود جای دهد (طراحی تطبیقی).

Jetpack Compose به‌عنوان یک جعبه ابزار UI اظهاری، ایده‌آل برای طراحی و اجرای طرح‌بندی‌هایی است که به صورت پویا تغییر می‌کنند و محتوا را در اندازه‌های مختلف نمایش متفاوت ارائه می‌کنند.

تغییرات طرح‌بندی بزرگ را برای کامپوزیشن‌های سطح محتوا آشکار کنید

کامپوزیشن‌های سطح برنامه و سطح محتوا، تمام فضای نمایشی موجود در برنامه شما را اشغال می‌کنند. برای این نوع از اجزای سازنده، ممکن است منطقی باشد که طرح کلی برنامه خود را در نمایشگرهای بزرگ تغییر دهید.

از استفاده از مقادیر فیزیکی سخت افزار برای تصمیم گیری در مورد چیدمان خودداری کنید. ممکن است تصمیم گیری بر اساس یک مقدار ثابت و ملموس وسوسه انگیز باشد (آیا دستگاه تبلت است؟ آیا صفحه نمایش فیزیکی نسبت ابعاد خاصی دارد؟)، اما پاسخ به این سؤالات ممکن است برای تعیین فضای موجود برای رابط کاربری شما مفید نباشد. .

شکل 1. عوامل شکل تلفن، تاشو، تبلت و لپ تاپ

در رایانه لوحی، یک برنامه ممکن است در حالت چند پنجره ای اجرا شود، به این معنی که برنامه ممکن است صفحه نمایش را با برنامه دیگری تقسیم کند. در حالت پنجره دسک‌تاپ یا در ChromeOS، ممکن است یک برنامه در یک پنجره قابل تغییر اندازه باشد. حتی ممکن است بیش از یک صفحه نمایش فیزیکی مانند یک دستگاه تاشو وجود داشته باشد. در همه این موارد، اندازه فیزیکی صفحه نمایش برای تصمیم گیری در مورد نحوه نمایش محتوا مهم نیست.

در عوض، شما باید بر اساس بخش واقعی صفحه اختصاص داده شده به برنامه شما که توسط معیارهای پنجره فعلی ارائه شده توسط کتابخانه Jetpack WindowManager توضیح داده شده است، تصمیم بگیرید. برای مثالی از نحوه استفاده از WindowManager در برنامه Compose، به نمونه JetNews مراجعه کنید.

تطبیق طرح‌بندی‌هایتان با فضای نمایش موجود، میزان کنترل ویژه مورد نیاز برای پشتیبانی از پلتفرم‌هایی مانند ChromeOS و عواملی مانند تبلت‌ها و تاشوها را کاهش می‌دهد.

هنگامی که معیارهای فضای موجود برای برنامه خود را تعیین کردید، اندازه خام را همانطور که در استفاده از کلاس‌های اندازه پنجره توضیح داده شد به یک کلاس اندازه پنجره تبدیل کنید. کلاس‌های اندازه پنجره نقطه‌های شکستی هستند که برای متعادل کردن سادگی منطق برنامه و انعطاف‌پذیری برای بهینه‌سازی برنامه شما برای اکثر اندازه‌های نمایش طراحی شده‌اند. کلاس‌های اندازه پنجره به پنجره کلی برنامه شما اشاره دارد، بنابراین از کلاس‌ها برای تصمیم‌گیری‌های طرح‌بندی که بر روی طرح کلی برنامه شما تأثیر می‌گذارند، استفاده کنید. می‌توانید کلاس‌های اندازه پنجره را به‌عنوان حالت پایین بیاورید، یا می‌توانید منطق اضافی برای ایجاد حالت مشتق‌شده برای انتقال به ترکیب‌پذیرهای تودرتو انجام دهید. 

@Composable
fun MyApp(
    windowSizeClass: WindowSizeClass = currentWindowAdaptiveInfo().windowSizeClass
) {
    // Perform logic on the size class to decide whether to show the top app bar.
    val showTopAppBar = windowSizeClass.windowHeightSizeClass != WindowHeightSizeClass.COMPACT

    // MyScreen knows nothing about window sizes, and performs logic based on a Boolean flag.
    MyScreen(
        showTopAppBar = showTopAppBar,
        /* ... */
    )
}
AdaptiveLayoutSnippets.kt

یک رویکرد لایه‌ای، منطق اندازه نمایشگر را به جای پراکنده کردن آن در سراسر برنامه در مکان‌هایی که نیاز به هماهنگی دارند، به یک مکان محدود می‌کند. یک مکان واحد حالتی را ایجاد می‌کند که می‌تواند به صراحت مانند هر حالت برنامه دیگر به سایر اجزای سازنده منتقل شود. عبور صریح حالت، ترکیب‌پذیرهای منفرد را ساده می‌کند، زیرا ترکیب‌پذیرها کلاس اندازه پنجره یا پیکربندی مشخص شده را همراه با داده‌های دیگر می‌گیرند.

ترکیبات تو در تو انعطاف پذیر قابل استفاده مجدد هستند

ترکیبات زمانی که بتوان آن ها را در مکان های مختلف قرار داد، قابلیت استفاده مجدد بیشتری دارند. اگر یک محصول ترکیبی باید در یک مکان خاص با یک اندازه خاص قرار گیرد، بعید است که در زمینه های دیگر قابل استفاده مجدد باشد. این همچنین به این معنی است که منفرد و قابل استفاده مجدد باید به طور ضمنی بسته به اطلاعات اندازه صفحه نمایش جهانی اجتناب کنند.

یک ترکیب تودرتو را تصور کنید که طرح‌بندی جزئیات فهرست را پیاده‌سازی می‌کند، که ممکن است یک صفحه یا دو صفحه را در کنار هم نشان دهد:

برنامه ای که دو صفحه را در کنار هم نشان می دهد.
شکل 2. برنامه ای که یک چیدمان معمولی با جزئیات لیست را نشان می دهد - 1 ناحیه لیست است. 2 ، منطقه جزئیات.

تصمیم‌گیری فهرست جزئیات باید بخشی از طرح کلی برنامه باشد، بنابراین تصمیم از یک فایل قابل ترکیب در سطح محتوا منتقل می‌شود: 

@Composable
fun AdaptivePane(
    showOnePane: Boolean,
    /* ... */
) {
    if (showOnePane) {
        OnePane(/* ... */)
    } else {
        TwoPane(/* ... */)
    }
}
AdaptiveLayoutSnippets.kt

اگر به جای آن بخواهید یک composable به طور مستقل طرح خود را بر اساس فضای نمایش موجود تغییر دهد، برای مثال، کارتی که در صورت اجازه فضا جزئیات اضافی را نشان می دهد، چه؟ شما می خواهید منطقی را بر اساس اندازه نمایشگر موجود انجام دهید، اما به طور خاص کدام اندازه؟

شکل 3. کارت باریک که فقط یک نماد و عنوان را نشان می‌دهد و یک کارت پهن‌تر که نماد، عنوان و توضیحات کوتاه را نشان می‌دهد.

از تلاش برای استفاده از اندازه صفحه نمایش واقعی دستگاه خودداری کنید. این برای انواع مختلف صفحه نمایش دقیق نخواهد بود و همچنین اگر برنامه تمام صفحه نباشد دقیق نخواهد بود.

از آنجایی که composable قابل ترکیب در سطح محتوا نیست، از معیارهای پنجره فعلی به طور مستقیم استفاده نکنید. اگر کامپوننت با بالشتک قرار داده شده باشد (مثلاً با قسمت‌های داخلی)، یا اگر برنامه شامل اجزایی مانند ریل‌های ناوبری یا نوارهای برنامه باشد، ممکن است میزان فضای نمایشی در دسترس برای ترکیب‌بندی با فضای کلی در دسترس برنامه متفاوت باشد.

از عرضی که در واقع composable داده شده است برای رندر کردن خود استفاده کنید. شما دو گزینه برای بدست آوردن آن عرض دارید:

  • اگر می‌خواهید مکان یا نحوه نمایش محتوا را تغییر دهید، از مجموعه‌ای از اصلاح‌کننده‌ها یا یک طرح‌بندی سفارشی استفاده کنید تا طرح‌بندی واکنش‌گرا باشد. این می تواند به همان اندازه ساده باشد که یک کودک تمام فضای موجود را پر کند، یا در صورت وجود فضای کافی، کودکان را با ستون های متعدد بچینید.

  • اگر می‌خواهید چیزی را که نشان می‌دهید تغییر دهید، از BoxWithConstraints به عنوان جایگزین قدرتمندتری استفاده کنید. BoxWithConstraints محدودیت‌های اندازه‌گیری را ارائه می‌کند که می‌توانید از آن‌ها برای فراخوانی ترکیب‌پذیرهای مختلف بر اساس فضای نمایش موجود استفاده کنید. با این حال، این امر با هزینه‌هایی همراه است، زیرا BoxWithConstraints ترکیب را تا مرحله طرح‌بندی، زمانی که این محدودیت‌ها شناخته می‌شوند، به تعویق می‌اندازد، و باعث می‌شود کارهای بیشتری در طول طرح‌بندی انجام شود. 

@Composable
fun Card(/* ... */) {
    BoxWithConstraints {
        if (maxWidth < 400.dp) {
            Column {
                Image(/* ... */)
                Title(/* ... */)
            }
        } else {
            Row {
                Column {
                    Title(/* ... */)
                    Description(/* ... */)
                }
                Image(/* ... */)
            }
        }
    }
}
AdaptiveLayoutSnippets.kt

اطمینان حاصل کنید که همه داده ها برای اندازه های مختلف نمایشگر در دسترس هستند

هنگام اجرای یک ترکیب بندی که از فضای نمایش اضافی بهره می برد، ممکن است وسوسه شوید که کارآمد باشید و داده ها را به عنوان یک اثر جانبی اندازه نمایشگر فعلی بارگذاری کنید.

با این حال، انجام این کار برخلاف اصل جریان داده های یک طرفه است، جایی که داده ها را می توان بالا برد و در اختیار اجزای سازنده قرار داد تا به طور مناسب ارائه شوند. داده‌های کافی باید در اختیار دستگاه ترکیب‌سازی قرار گیرد تا همیشه برای هر اندازه نمایشگر محتوای کافی داشته باشد، حتی اگر بخشی از محتوا همیشه استفاده نشود. 

@Composable
fun Card(
    imageUrl: String,
    title: String,
    description: String
) {
    BoxWithConstraints {
        if (maxWidth < 400.dp) {
            Column {
                Image(imageUrl)
                Title(title)
            }
        } else {
            Row {
                Column {
                    Title(title)
                    Description(description)
                }
                Image(imageUrl)
            }
        }
    }
}
AdaptiveLayoutSnippets.kt

با توجه به مثال Card ، توجه داشته باشید که description همیشه به Card ارسال می شود. حتی اگر description فقط زمانی استفاده می‌شود که عرض اجازه نمایش آن را بدهد، Card همیشه بدون توجه به عرض موجود به description نیاز دارد.

همیشه ارسال محتوای کافی، طرح‌بندی‌های تطبیقی ​​را ساده‌تر می‌کند و باعث می‌شود که چیدمان‌های تطبیقی ​​ساده‌تر شوند و از ایجاد عوارض جانبی هنگام جابه‌جایی بین اندازه‌های نمایشگر (که ممکن است به دلیل تغییر اندازه پنجره، تغییر جهت، یا تا کردن و باز کردن دستگاه رخ دهد) جلوگیری می‌کند.

این اصل همچنین اجازه می دهد تا وضعیت را در سراسر تغییرات طرح بندی حفظ کنید. با بالا بردن اطلاعاتی که ممکن است در همه اندازه‌های نمایشگر استفاده نشود، می‌توانید وضعیت برنامه را با تغییر اندازه طرح‌بندی حفظ کنید. به عنوان مثال، می‌توانید پرچم بولی showMore را برافراشتید تا وضعیت برنامه حفظ شود زمانی که تغییر اندازه نمایشگر باعث می‌شود که چیدمان بین پنهان کردن و نمایش محتوا تغییر کند: 

@Composable
fun Card(
    imageUrl: String,
    title: String,
    description: String
) {
    var showMore by remember { mutableStateOf(false) }

    BoxWithConstraints {
        if (maxWidth < 400.dp) {
            Column {
                Image(imageUrl)
                Title(title)
            }
        } else {
            Row {
                Column {
                    Title(title)
                    Description(
                        description = description,
                        showMore = showMore,
                        onShowMoreToggled = { newValue ->
                            showMore = newValue
                        }
                    )
                }
                Image(imageUrl)
            }
        }
    }
}
AdaptiveLayoutSnippets.kt

بیشتر بدانید

برای کسب اطلاعات بیشتر در مورد طرح‌بندی‌های تطبیقی ​​در Compose، به منابع زیر مراجعه کنید:

نمونه برنامه ها

  • CanonicalLayouts مخزنی از الگوهای طراحی اثبات شده است که تجربه کاربری بهینه را در نمایشگرهای بزرگ فراهم می کند.
  • JetNews نحوه طراحی اپلیکیشنی را نشان می‌دهد که رابط کاربری خود را برای استفاده از فضای نمایش موجود تطبیق دهد
  • Reply یک نمونه تطبیقی ​​برای پشتیبانی از تلفن همراه، رایانه لوحی و تاشو است
  • اکنون در اندروید برنامه ای است که از طرح بندی های تطبیقی ​​برای پشتیبانی از اندازه های مختلف نمایشگر استفاده می کند

ویدیوها

قبلی
چیدمان های متعارف
بعدی
از کلاس های اندازه پنجره استفاده کنید