Разное

Макеты для верстки: PSD макеты для вёрстки сайтов

06.06.2018

Содержание

Бесплатные макеты Figma для верстки сайта

Portfolio landing page

Ссылка на макет

Классный сайт для портфолио, лично мне нравится простой и чистый дизайн.

Сложность: низкая

 

Clean simple landing page

Ссылка на макет

Довольно простой по дизайну, но не самый простой в плане верстки сайт. Есть что отработать (декоративные элементы, слайдеры и т.д.)

Сложность: средняя

 

Client chat

Ссылка на макет

Ооочень похоже на мессенджер Slack 🙂 Но тем не менее, интересно такое сверстать, особенно в плане семантики.

Сложность: средняя

 

Restaurant template

Ссылка на макет

Неплохой одностраничник на тему ресторана. Так же есть немало мелочей, которые можно отработать.

Сложность: средняя

 

Valorant concept

Ссылка на макет

Концепт по недавно вышедшей игре Valorant. В целом, это не совсем макет сайта, но мне дизайн нравится, и в принципе, можно под себя переделать. Для практики — самое то)

Сложность: высокая (только из-за нестандартного макета)

 

Thrivetalk landing page

Ссылка на макет

Простой лендинг, для отработки сеток (flexbox) самое то)

Сложность: низкая

 

 

Пока это все, на самом деле найти адекватные макеты для figma не так уж и просто, но будем стараться) Если же вы хотите еще, или хотите сборник psd-макетов от меня — пишите в комментарии, и все будет!

 

Всем добра, удачи в верстке макетов)

Метки: макеты, figma

18 правил идеального psd-макета — полезный чек-лист для дизайнеров / ХабрОбщий принцип — Не делай брак.
Не бери брак. Не передавай брак.
Тойота.

Мы редко берём в разработку проекты с уже реализованным дизайном, но такое случается. Когда макеты создаются внутри студии, на любом проблемном этапе вёрстки разработчик может уточнить у менеджера проекта или самого дизайнера, что имелось ввиду и как это должно выглядеть. Но в ситуации, когда заказчик уже кому-то отдал деньги за макеты и после пришёл к тебе за разработкой, так не получится: вести коммуникацию между дизайнером и разработчиком становится невозможным, а исправлять огрехи в макетах некому. Из этой статьи вы узнаете, где лажают горе-дизайнеры и что стоит проверить перед тем, как отдавать макеты на вёрстку.

«Почти» по сетке


Сетка призвана упрощать вёрстку и определять местоположение ключевых элементов. В некоторых случаях дизайнеры намеренно отходят от 12-колоночного грида для создания неординарного дизайна.

Но если при создании макета вы всё-таки придерживались сетки — будьте добры убедиться, что это правда так. Верстальщики то и дело жалуются, что в проекте от страницы к странице дизайн может сильно отличаться: идентичные блоки появляются то левее, то правее, иконки разного размера, а кнопки не похожи друг на друга.

Когда элементы выбиваются из сетки, процесс вёрстки затягивается — тратится дополнительное время на выяснение положения блоков или на правки, если сверстанная страница не совпадает с макетом визуально. Также возникают проблемы с адаптивностью страниц, поскольку неясно, как вышедшие за рамки сетки объекты должны себя вести на устройствах меньшей диагонали.

Сергей, разработчик в студии Сибирикс:
«Наверное, самая главная проблема в том, что далеко не все дизайнеры знают хотя бы основы html и css, поэтому и макеты делаются без оглядки на вёрстку. Например, частенько встречается, когда на адаптиве блоки перекомпануются таким образом, что без дублирования контента для мобильной и десктопной версии не обойтись — это замедляет работу над вёрсткой».


Владимир, руководитель студии:
«Есть миллион случаев, когда программист говорит «это невозможно», а потом берет и делает, как нужно. Значит-таки возможно. И большинство ограничений, неудобных для программиста, но интересных с точки зрения дизайна — искусственные. Чёткую границу провести невозможно. Работает только итерационное обсуждение и попытки реализовать задуманное. Пробовать, смотреть, обсуждать, делать, экспериментировать. Иначе всё скатится к унылым шаблонам. Для части проектов это ОК. А для части — нет. Делаете ли вы в духе конвейера или делаете фестивальные работы? Мы писали про это подробнее в бегунке креативности».

Копипаст слоёв


В Фотошопе удобно размножать слои: скопировал вместе со стилем и всеми настройками и перетащил в нужное место. В творческом порыве некоторые дизайнеры не утруждают себя дать слоям адекватные названия и упорядочить их между собой, а после уже не могут понять, к какому блоку какой слой принадлежит и где его вообще искать на макете.

При передаче на вёрстку убедитесь, что ваши слои названы однозначно и распределены по папкам, исходя из логики макета. И не забудьте удалить ненужные или хотя бы склеить слои с эффектами между собой (почему не всегда можно так делать — ниже).

Непонятные отступы


В идеальном макете все отступы и размеры у блоков должны быть унифицированы. Там на один пиксель больше, тут — на один меньше, а верстальщику потом сидеть и выбирать, как правильно. Возможно, это не слишком повлияет на внешний вид страницы, хотя клиенты бывают разные: кому-то каждый лишний пиксель бросается в глаза. А возможно, тестировщик наложит готовую верстку на макет-исходник через плагин Pixel Perfect и напишет список из миллиона багов, сочтя такие несоответствия ошибкой. Проследите, чтобы отступы контентной области от шапки и подвала были одинаковыми на всех ваших страницах.

Объекты тоже таят скрытые опасности — иногда при создании форм в Фотошопе, даже если дизайнер использовал сетку, случаются вот такие погрешности:

Верстальщик вряд ли станет учитывать эти тонкости и, скорее всего, обрежет размеры объекта, чтобы тот точно вписался в сетку. Поэтому правило — ВСЕ объекты должны иметь целочисленные размеры, иначе результат может очень отличаться от первоначального макета.

Цвета «на глаз»


В фотошопе есть удобный инструмент — «пипетка», и дизайнеры любят им пользоваться — тыкнул, и не надо запоминать номер цвета. Но если тыкнуть в край элемента, цвет может исказиться оттенком фона. Другая опасность — если радиус пипетки более 1 пикселя, Фотошоп покажет среднее значение между соседними цветами.

Андрей, разработчик

«Особенно раздражает, когда цвета дизайнер определял “на глаз”, а потом ты сидишь с набором разнокалиберных серых и не знаешь, какой именно использовать. Это происходит из-за того, что нет банальной карты цветов проекта, на которую мог бы опираться и сам дизайнер при работе над внутренними страницами, и верстальщик».
Негласное правило не рекомендует использовать чёрный под номером #000000 — он слишком контрастный на фоне белого. Глядите на разницу:

Ещё один лайфхак дизайнеров, который раздражает верстальщиков, — чтобы сделать цвет светлее (в том числе у текста), дизайнер просто увеличивает прозрачность слоя. Верстальщику придётся пользоваться пипеткой, и опять же, велика вероятность погрешности (особенно в случаях с градиентными заливками у элементов).

Растрированные элементы


Текст


Если дизайнер до веба какое-то время делал макеты для печати в типографии, он может грешить привычкой растрировать тексты, но для верстальщика это становится серьёзной проблемой: такой текст невозможно скопировать — можно только заново набрать вручную. И это меньшая из проблем: откуда верстальщику брать начертание, размер и цвет растрированного текста — вот это вопрос.

Тени и градиенты


При верстке разработчику удобнее и быстрее посмотреть параметры тени или градиента, чем тыкать пипеткой в разных областях этой зоны, когда слой растрирован. Это ускоряет верстку и влияет на результат: шансов ошибиться с цветовым переходом меньше.

Если поверх изображения накладывается темный фон (например, ховер), его нельзя склеивать с самим изображением — это должен быть отдельный полупрозрачный либо градиентный слой, чтобы можно было заглянуть в его параметры.

Эффекты наложения


При наложении берутся в расчёт содержание нижних слоёв, и передать такие эффекты при вёрстке непросто, поэтому верстальщики их сильно недолюбливают. И не зря: далеко не каждая версия браузера готова отображать их так, как задумывал дизайнер.


Эффекты наложения в разных браузерах

Проблемы со шрифтом


Дробные размеры


Обычно это происходит случайно, если ко всему блоку применили, например, инструмент трансформирования — шрифт увеличился/уменьшился пропорционально картинке. Проблема в том, что браузеры не учитывают дробные значения и попросту округляют их до ближайшего.

Множество шрифтов


На весь проект желательно использовать не более 3-х начертаний — это могут быть шрифты одной гарнитуры (Light, Regular и Bold) или разных. Это не жёсткое ограничение — всё зависит от задач проекта, но определённый смысл в нём есть: чем меньше вариаций шрифта, тем выше сосредоточенность на тексте у читателя. Считается правилом вместе с макетом передавать гарнитуры, которые там использовались, или хотя бы давать ссылки на Google Fonts.
Андрей, разработчик:
«Сейчас большинство браузеров отошли от шрифтов в форматах TTF, OTF — и если разработчик будет использовать их по-старинке, не везде они будут отображаться корректно. Мы в студии давно перешли на формат WOFF или WOFF2, чтобы не было проблем. Перевести шрифт в него можно здесь или здесь».

Использование нестандартных шрифтов


Нестандартные шрифты и их начертания должны быть проверены на наличие веб-версии. Дело в том, что такие шрифты влияют на скорость загрузки страницы — для их отображения браузеру нужно сначала их скачать, и на это уйдёт какое-то время. По-хорошему вес нестандартного шрифта не должен превышать 1 мегабайт. И лучше, чтобы такой шрифт на странице был только один. Ну и не забывайте, что шрифты стоят денег. Иногда — больших. У нас были случаи, где шрифт специально дорабатывался под конкретный проект — та ещё задачка.

Корявая типографика


Часто бывает, что межстрочные интервалы и отступы между абзацами не совпадают внутри блоков на макете и отличаются от страницы к странице — проследите за их одинаковостью. Не отделяйте заголовки от абзацев в отдельные текстовые блоки, чтобы вручную увеличить отступ между ними — пользуйтесь настройками интерлиньяжа и абзацами.
Евгений, разработчик:
«По возможности не стоит использовать сложные эффекты на типовых текстовых страницах, если предполагается, что заказчик сам сможет их менять из админ-панели. Скорее всего, у него получится «обернуть» такие элементы в div. Иногда это решается сниппетами или иными приемами, но всё равно вызывает сложность при наполнении контентом».
Обязательно стоит показать на макете оформление параграфа, абзаца, заголовков 1-4 уровня (h2, h3, h4, h5), маркированных и нумерованных списков. А ещё лучше собрать всё это в отдельный документ — гайдлайн или UI-kit. Сюда же можно добавить поведение ссылок (активная, при наведении, посещенная).


UI-kit для проекта «Спасская башня»

Непонятная анимация


У элементов вроде кнопок или выпадающих списков есть несколько состояний, но часто дизайнеры рисуют лишь какое-то одно из них. Благодаря этому получаются, например, неопрятные всплывашки, которые верстальщик за неимением образца сделал сам.

Проверьте, что объекты, участвующие в анимациях и интерактивных взаимодействиях, разбиты послойно. Например: вид при наведении на объект — один слой, вид при клике по нему — другой, вид в статике — третий. Те же правила работают и для баннеров.

Желательно пометить слои с анимациями и интерактивами цветами и сопроводить их комментариями. Также очень желательно в комментариях прописать, как именно это должно работать и привести примеры.

Евгений, арт-директор:
«Фотошоп фотошопом, но сейчас появилось столько прогрессивных инструментов, внутри которых к каждому элементу сразу создаются нужные строчки кода — верстальщику не составляет большого труда превратить дизайн-макет в свёрстанную страницу. А вообще, конечно, всё зависит от самого верстальщика — если он норм, то и результат будет норм, в каком бы редакторе это ни было нарисовано:)»

Иконки в PNG


В проекте, в зависимости от задач, иконки бывают разные: иногда дизайнер создаёт уникальный набор собственноручно, иногда ему проще и быстрее найти нужную из миллиона вариантов где-нибудь здесь и доработать её при необходимости.

Но бывает, что дизайнеры используют иконки в формате PNG — в нём при масштабировании на экранах с большим разрешением (а сейчас даже на мобилках плотность пикселей бешеная) края изображения расплываются. Отсюда правило: все иконки должны быть в формате SVG — так они остаются чёткими, каким бы ни был их размер.

Некоторые верстальщики предпочитают, чтобы иконки были собраны в одном месте — в отдельной папке — и чтобы их названия были идентичны слоям в макете. Другим удобнее, чтобы SVG-изображения были встроены в основной файл, поскольку так гораздо проще и быстрее вырезать svg из макета, чем искать нужную иконку в другой папке.

Чек-лист


В творческом порыве сложно уследить за тем, чтобы всё было сделано правильно. Там слой скопировался и остался без названия, там объект немножко вылез за край колонки, тут шрифт случайно «зажирнился» встроенными фотошопными настройками вместо выбора нужного начертания — с кем не бывает? А с тем, у кого есть наш чек-лист!

Чек-лист для подготовки Photoshop-макета к передаче на вёрстку


  1. Если дизайнер использовал сетку, все блоки на макете расположены строго по ней.
  2. У всех объектов на макете целочисленные размеры.
  3. Повторяющиеся элементы на страницах всегда ОДИНАКОВЫЕ.
  4. Все слои сгруппированы по папкам и распределены по логике макета. Лишние удалены, похожие — объединены.
  5. Отступы от элементов унифицированы.
  6. Цвета на макете совпадают с основными цветами проекта.
  7. Текст как текст (не растрирован).
  8. Эффекты наложения, тени и градиенты не растрированы.
  9. Использование эффектов наложения целесообразно.
  10. У шрифтов недробные размеры.
  11. Шрифты, используемые в проекте, собраны в отдельной папке.
  12. Нестандартные шрифты и их начертания проверены на наличие веб-версии. Вес одного нестандартного шрифта не превышает 1 Мб.
  13. Межстрочные интервалы и отступы в тексте унифицированы.
  14. Все иконки в формате SVG и собраны в одном месте. Наименования иконок одинаковые и понятные, совпадают с наименованием идентичных слоёв на макете.
  15. Для всех активных элементов есть слои с ховерами.
  16. Объекты, участвующие в в анимациях/интерактивных взаимодействиях, разбиты послойно. Для баннеров — аналогично.
  17. К анимациям и интерактивным взаимодействиям прописаны комментарии и указаны примеры, как это должно выглядеть.
  18. Для макета создан гайдлайн с палитрой цветов проекта и стилями текста.

Готовим .psd для верстки / Хабр

Не претендую на новаторство, возможно, многие уже используют все то, что будет описано. Этот топик скорее предложение к дискуссии по поводу подготовки макетов к верстке. Думаю, обитатели хабра, особенно посещающие ветку «Веб-дизайн», в основной массе знакомы с ресурсом ilovepsd.ru. Поэтому пожелания с этого сайта, по работе с файлами, я перечислять не буду. Кто заинтересовался, прошу под хабракат.

Зачастую, когда я отдаю файлы шаблонов заказчику, я готовлю две версии. Одна полная, другая подготовлена для верстки. Обе, конечно, попадают к верстальщику. Первая — что бы абсолютно все было под рукой готовое к редактированию, если что. Вторая — что бы ускорить работу.
Склеиваем слои и эффекты

Допустим у нас есть фон под меню. Состоит он из 4-х слоев, к некоторым из них применены эффекты. В большинстве случаев верстальщику нужно вырезать центральную часть шириной в 1 пиксел, что бы затем повторять её по горизонтали. Кто не понял к чему я клоню — это значит что верстальщику нужно выделить слои, нажать правую кнопку мыши, найти пункт «Merge layers», кликнуть. Минимум 3 действия и это минимум 3 действия по каждому подобному случаю. Таким образом мы сможем сэкономить верстальщику, пусть и немного, но все же времени.

Комментируем правильно

Я не буду начинать холивар о том, должен ли веб-дизайнер уметь верстать? Я считаю, что он точно обязан знать параметры которые задаются в CSS. Поэтому, где позволяет ситуация, я прописываю на CSS, что происходит с элементом.

Сетка

Речь идет о родной сетке photoshop’а. Не всегда возможно применить, но зачастую можно настроить сетку под выбранный вами вертикальный ритм или как можно ближе к системе, по которой вы работали расставляя все на макете.
Часто отступы между элементами бывают кратны 5 пикселам. В таких случаях я выставляю параметры сетки, как показано на картинке и оставляю памятку верстальщику, что бы настроил соответствующим образом и включил сетку. Еще раз говорю — это только пример, настраивайте так, что бы подошло вашему макету. Таким образом при верстке, местами, становится намного легче считать расстояния и размеры.

Вот и все. Информации немного, надеюсь вы дополните. Еще больше надеюсь, что сами верстальщики отпишутся о методах, описанных выше.

P.S. Если что-то из написанного, на ваш взгляд, откровенная чушь — прокомментируйте развернуто, пожалуйста. Это поможет мне не делать хе*ни, за что будут благодарны люди, которым после меня макеты резать.

Собранные требования к psd-макету веб-сайта / Хабр

Привет, фрондэнд разработчики!

При верстке сайта с psd-макета, мы постоянно сталкиваемся с проблемой реализации некоторых элементов, которые нарисовал дизайнер. Будь то кнопка, или какой-то хитрый градиент. Нам приходится либо изворачиваться, тратя на это свое рабочее время или просить дизайнера переделать или в крайнем случае забить и сделать более-менее что-то похожее.

Если наш заказчик жутко внимательный, то часто принимая последнее решение, у нас возникают проблемы несоответствия того, что сверстано в итоге, с тем, что нарисовал дизайнер. Все эти факторы накладывают на нас — разработчиков темное пятно, в то время как дизайнер получил свою премию и уже пьет коктели, в нас кидают помидорами и обвиняют в некомпетентности, хотя проблема далеко не в нас, а в том, что дизайнер иногда не знаком даже с основами верстки и не знает, что некоторые вещи рисовать нельзя.

Немного набрал в весе мозга и статуса в компании, в какой-то момент я понял, что так дальше продолжаться не может и начал собирать свои требования в psd макетам.

Через какое-то время я смог оценить весь profit от введения этих стандартов и требований:

— дизайнер становится более организованный, он помнит, что нужно соблюдать правила и как следствие psd макеты начинают меньше весить, в них отсутствуют неиспользуемые слои, структура становится понятна не только верстальщику, но и самому дизайнеру. В будущем когда ему нужно что-то дорисовать — ему не приходится искать слои блок по всему psd файлу, а он идет в папку в блоком и сразу же принимается за работу. Также в этом случае, есть возможность прямо в файле создать папку с предыдущей версией блока.

— верстальщик получая «правильный» макет может более точно оценить срок выполнения, так как точно понимает, что ему не придется никуда больше ходить и просить что-то переделывать, также сюда можно добавить и сокращение сроков выполнения. Так как в случае соблюдения правил, становится возможно пользоваться штуками типа csshat.com + lesshat.com

— результат на выходе получается более идентичный тому, что нарисовано, так как все что дизайнера «натворил» можно реализовать в браузере.
Итог: дизайнер счастлив(не надо ничего переделывать), верстальщик счастлив(все хорошо верстается и тратится ночь на доп.работу, чтоб успеть и нервы впорядке), заказчик (сверстаный макет соответствует утвержденному макету), в итоге все остаются в профите от введение этих правил.

Ниже привожу список требований:

1) Соблюдение сетки в макете, если знаешь что это такое и как ее «готовить».
Зачем? о_О:
— чисто эстетические наслаждение
— возможность быстро собирать каркас страницы и позиционировать элементы на
странице в соответствии с представленном макетом, чтобы верстка получалась более честной по отношению к тому, что ты нарисовал(а).

2) Если применяется градиент к слою, использовать обычный режим наложения (blend Mode: normal) и его реальные цвета.
Не должно быть никаких полупрозрачных градиентов и сложных режимов наложения типа »multiply, screen, overlay, и т.д.».
Плохо: joxi.ru/Md6l32D
Хорошо joxi.ru/M2w9Nwe и еще пример joxi.ru/11ndBHq

3) Нежелательно использовать «слой на слое» для создание различных эффектов, типа градиента, слой должен быть один.
Пример: joxi.ru/AGx4CQy

4) Никаких градиентных границ (бордеров, stroke).

5) Использование сложных режимов наложения (blend mode) касается любых свойств слоя (типа inner shadow, drop shadow и т.д.).

6) ОБЯЗАТЕЛЬНО прикладывать к макету шрифты, которые были использованы в макете, в формате TTF, OTF

7) По возможности — не использовать в макете больше 2-х не стандартных шрифтов, их кол-во сильно влияет на рендеринг страницы в браузере, что негативно сказывается на отношения пользователя к сайту.

8) Обязательно наличие отдельного макета, в котором представлено оформления стандартных элементов типографики веб-страницы (заголовки, параграфы, таблицы, списки, блоки цитаты) joxi.ru/MKnCZQM

9) Если нарисовали типовую кнопку, ссылку, элемент, которые имеет состояние «наведения», нажатия — не заставляйте нас додумывать как это должно работать. Если есть ссылка, покажите ее цвет при наведении, если есть кнопка, покажите ее внешний вид при наведении или нажатии, а также при ее состоянии «неактивности». Это касается любых подобных элементов, стрелок в галереи и т.д. и т.п. joxi.ru/ZSmaLye

10) Каждый блок должен находится в своей папке и имеет правильное человеческое название, чтобы не собирать части блока по всему макету. joxi.ru/Agsfo3L

11) Если есть скрытые слои или папки, которые показывают какие-то части сайта (модальные окна, выпадающие панели и т.д.) — необходимо выделять папку / слой — цветом, чтобы его не пропустить, также он должен иметь название, которое близко по смыслу его функциональности. joxi.ru/G1h9LbN

Вывод: Соблюдение данных рекомендаций, поможет реализовать этап создания проекта — верстка, максимально точно к созданому макету и поможет избежать:
— несоответствие макета и сверстанного варианта;
— проблем с утверждением верстки;
— проблем с кроссбраузерность и работы верстки в целом.

Спасибо.

Требования к дизайн-макетам web-страниц для верстки или делаем идеальный psd-макет

«Я не делаю брак, я не принимаю брак, я не передаю брак»
Toyota Production System

В очень редких случаях, может случиться так, что мы возьмем на дальнейшую разработку проект с уже реализованным дизайном. Но такая практика предполагает дополнительные трудовые затраты.

Если макеты создаются в студии, то разработчик может легко уточнить у менеджера проекта или дизайнера любые вопросы, например, что конкретно имелось в виду в техническом задании, или же как в представлении дизайнера должен выглядеть итог работы. Но если заказчик уже начал с кем-то проект, а затем пришел к нашему специалисту, наладить такую коммуникацию будет невозможно. Особенно много сложностей это доставляет, когда в макетах есть ошибки, ведь исправлять их теперь некому. Каковы самые распространенные огрехи горе-дизайнеров? Что стоит проверить перед тем, как отдать макеты на верстку? Эти и другие вопросы по теме мы рассмотрим в данной статье.

Требования к файлу:

  1. Макет должен быть представлен в формате (.psd). В противном случае сайт будет отличаться от макета.
  2. Строго необходимо цветовое пространство RGB. Именно оно используется по умолчанию в web. CMYK подходит для полиграфии, а не для web.
  3. Единицами измерения должны быть пиксели, а не сантиметры, миллиметры и другие меры длины . Указания значений не должны быть дробными!
  4. Все слои одного логического элемента должны быть в одной папке (например, модуль авторизации).
  5. Слои ни в коем случае не должны быть склеены.
  6. Векторные элементы должны быть векторными элементами: иконки, стрелки и т.д. Допускаются элементы shape и smart-объекты с ai-элементами.
  7. Выравнивание слоев – строго по “Rulers”. Их необходимо оставлять в макете.
  8. “Rulers” должны быть выровнены строго с точностью до одного пикселя. Полпикселя не допустимы.
  9. Необходимо группировать слои по папкам (смысловым блокам) с осмысленными названиями, а не «Группа 3 copy». То же самое касается всех слоев (шапка, контент, подвал и т.п.).Придерживаемся иерархии «сверху вниз» и «слева направо».
  10. В случае фиксированного шаблона необходимо четкое соответствие ширины макета утвержденной минимальной ширине сайта.
  11. Для адаптивного сайта должны быть макеты или элементы для 640px – 960px – 1200px – 1600px.
  12. При разработке дизайна «под разрешение» обязательно отрисовывать в разрешение окна браузера, а не монитора (при 1024 ширина браузера 1000).
  13. В дизайне должны быть «служебные страницы» (404).



Текстовое содержимое. Четкие размеры и отступы:

  1. Необходимо использовать «родные» направляющие photoshop или готовые модульные сетки, чтобы точно определить расположение элемента на странице.
  2. Нужно осознанно выбирать пропорции и размеры объектов и делать их кратными 10, например, 1000px, а не 998px.
  3. Размер шрифта должен быть без дробей. Никогда не нужно растягивать шрифт принудительно.
  4. Не допускается растрирование текста или размещение его в smart-объекте.
  5. Используемые шрифты, за исключением Tahoma, Arial, Verdana, Times New Roman, Courier, необходимо прикладывать к передаваемым материалам. Передаваемые шрифты должны быть только форматов ttf и otf.
  6. Допустимо и даже приветствуется использование свободных кириллических шрифтов от Google web fonts.
  7. Все текстовые элементы должны быть сглажены методом “Windows LCD”.
  8. Необходимо описать поведение ссылок в дизайне («неактивная», «при наведении», «посещенная») в меню / модуле, то же самое касается ссылок, отличающихся от дефолтного стиля (например, ссылки в меню, pathway и т.д.)

Самое главное – дизайнер должен быть верстальщиком, быть в состоянии самостоятельно сверстать то, что нарисовал (пусть и не быстро, не на 100% валидно).

Графические фишки:

  1. Фон должны быть повторяющимся, текстурированные фоны без логики повтора не принимаются.
  2. Все слои должны быть в нормальном режиме наложения (normal). Не допускается наличие слоев в других режимах, как то multiply, overlay и т.д.
  3. Необходимо использовать минимум элементов, что потребуют создания графических файлов png-24 (полупрозрачность etc).
  4. Обязательно должна присутствовать favicon.ico для сайта. Не нужно забывать про favicon для Apple.
  5. Векторные мелкие элементы должны быть отрисованы согласно однопиксельной сетке.
  6. Настоятельно рекомендуется выстраивать отступы между элементами, чьи значения кратны 10, в отдельных случаях – кратны 5.

Исходные материалы макета

  • Макет в формате PSD
  • Шрифты
  • Исходные изображения

Важно прикрепить в отдельную папку все изображения в исходном качестве и дополнительные материалы, которые используются в макете.

Все нестандартные шрифты копируются в ту же папку. У верстальщика может не быть необходимого вам красивого шрифта. И на его поиски уйдет много времени.

Давайте пояснения к элементам, которые могут вызвать вопросы. Если есть особые задумки, которые не так просто показать на макете, то запишите их в отдельный текстовый файл. К тому моменту, когда верстальщик доберется к этому элементу макета, вы и сами можете забыть, чего хотели, и придется вновь тратить время на то, чтобы вспомнить идею и объяснить ее верстальщику.

Auto Layout Guide: неоднозначные макеты

Неоднозначные макеты возникают, когда система ограничений имеет два или более допустимых решения. Есть две основные причины:

  • Макет нуждается в дополнительных ограничениях, чтобы однозначно указывать позицию и местоположение каждого вида.

    После того, как вы определите, какие виды являются неоднозначными, просто добавьте ограничения, чтобы однозначно указать и позицию вида, и его размер.

  • Макет имеет конфликтующие необязательные ограничения с одинаковым приоритетом, и система не знает, какое ограничение оно должно нарушить.

    Здесь необходимо указать системе, какое ограничение оно должно нарушить, изменив приоритеты, чтобы они больше не были равны. Система нарушает ограничение, имеющее самый низкий приоритет.

Обнаружение неоднозначных макетов

Как и в случае неудовлетворительных макетов, Интерфейсный Разработчик может часто обнаруживать и предлагать предложения по исправлению неоднозначных макетов во время разработки. Эти неоднозначности отображаются в виде предупреждений в навигаторе ошибок, ошибках в структуре документа и красных линиях на холсте.Для получения дополнительной информации см. Определение неудовлетворенных ограничений.

Как и в случае неудовлетворительных макетов, Интерфейсный Разработчик не может обнаружить все возможные неоднозначности. Многие ошибки могут быть обнаружены только путем тестирования.

Если во время выполнения возникает неоднозначная компоновка, автоматическая компоновка выбирает одно из возможных решений. Это означает, что макет может отображаться или не отображаться так, как вы ожидаете. Кроме того, нет предупреждений, записанных в консоль, и нет способа установить точку останова для неоднозначных макетов.

В результате, неоднозначные макеты зачастую сложнее обнаружить и идентифицировать, чем неудовлетворительные макеты. Даже если неоднозначность имеет очевидный видимый эффект, может быть трудно определить, связана ли ошибка с неоднозначностью или с ошибкой в ​​логике компоновки.

К счастью, есть несколько методов, которые вы можете вызвать, чтобы помочь определить неоднозначные макеты. Все эти методы должны использоваться только для отладки. Установите точку останова где-нибудь, где вы можете получить доступ к иерархии представлений, а затем вызовите один из следующих методов из консоли:

  • имеет однозначную планировку .Доступно как для iOS, так и для OS X. Вызовите этот метод в неуместном представлении. Возвращает ДА истинно , если структура представления неоднозначна. В противном случае возвращается , NO , , false .

  • упражнение на неопределенность в раскладе . Доступно как для iOS, так и для OS X. Вызовите этот метод для представления с неоднозначным расположением. Это переключит систему между возможными действительными решениями.

  • ограничения, влияющие на макет для оси: .Доступно для iOS. Вызовите этот метод в представлении. Он возвращает массив всех ограничений, влияющих на это представление вдоль указанной оси.

  • ограничения, влияющие на макет для ориентации: . Доступно для OS X. Вызовите этот метод в представлении. Он возвращает массив всех ограничений, влияющих на это представление вдоль указанной ориентации.

  • _autolayoutTrace . Доступен как частный метод в iOS. Вызовите этот метод в представлении. Он возвращает строку с диагностической информацией обо всей иерархии представления, содержащей это представление.Двусмысленные представления помечены, так же как представления, у которых переводит AutoSizeMaskIntoConstraints , установленный в ДА.

Возможно, вам придется использовать синтаксис Objective C при запуске этих команд в консоли. Например, после того, как точка останова прервет выполнение, введите , вызвав [self.myView exercAmbiguityInLayout] в окне консоли, чтобы вызвать метод exercAmbiguityInLayout для объекта myView . Аналогично, введите po [self.myView autolayoutTrace] для распечатки диагностической информации об иерархии представлений, содержащей myView .

Примечание

Обязательно исправьте все ошибки, обнаруженные Интерфейсным Разработчиком, перед запуском перечисленных выше методов диагностики. Интерфейсный Разработчик пытается исправить любые ошибки, которые он находит. Это означает, что если он находит неоднозначный макет, он добавляет ограничения, чтобы макет больше не был неоднозначным.

В результате hasAmbiguousLayout возвращает NO false . exercAmbiguityInLayout , по-видимому, не оказывает никакого влияния, а ограничение AffectingLayoutForAxis: может возвращать дополнительные неожиданные ограничения.

,Руководство по автоматической разметке

: Понимание автоматической разметки

Понимание Auto Layout

Auto Layout динамически рассчитывает размер и положение всех представлений в иерархии представлений на основе ограничений, накладываемых на эти представления. Например, вы можете ограничить кнопку так, чтобы она была центрирована по горизонтали с представлением «Изображение», и чтобы верхний край кнопки всегда оставался на 8 пунктов ниже нижней части изображения. Если размер или положение вида изображения изменяется, положение кнопки автоматически настраивается в соответствии.

Этот основанный на ограничениях подход к проектированию позволяет создавать пользовательские интерфейсы, которые динамически реагируют как на внутренние, так и на внешние изменения.

Внешние изменения

Внешние изменения происходят, когда изменяется размер или форма вашего суперпредставления. С каждым изменением вы должны обновлять макет вашей иерархии представлений, чтобы наилучшим образом использовать доступное пространство. Вот некоторые распространенные источники внешних изменений:

  • Пользователь изменяет размеры окна (OS X).

  • Пользователь входит или выходит из Split View на iPad (iOS).

  • Устройство вращается (iOS).

  • Бары активного вызова и записи звука появляются или исчезают (iOS).

  • Вы хотите поддерживать разные классы размера.

  • Вы хотите поддерживать разные размеры экрана.

Большинство из этих изменений могут произойти во время выполнения, и они требуют динамического ответа от вашего приложения.Другие, такие как поддержка разных размеров экрана, представляют приложение, адаптирующееся к различным средам. Даже если размер экрана обычно не изменяется во время выполнения, создание адаптивного интерфейса позволяет вашему приложению одинаково хорошо работать на iPhone 4S, iPhone 6 Plus или даже iPad. Автоматическая разметка также является ключевым компонентом для поддержки слайд-шоу и разделенных видов на iPad.

Внутренние изменения

Внутренние изменения происходят при изменении размера представлений или элементов управления в вашем пользовательском интерфейсе.

Вот несколько общих источников внутренних изменений:

  • Содержимое, отображаемое приложением, изменится.

  • Приложение поддерживает интернационализацию.

  • Приложение поддерживает Dynamic Type (iOS).

При изменении содержимого вашего приложения новый контент может потребовать другой макет, чем старый. Это обычно происходит в приложениях, которые отображают текст или изображения. Например, новостное приложение должно настроить свой макет в зависимости от размера отдельных новостных статей.Аналогичным образом, фотоколлаж должен обрабатывать широкий диапазон размеров изображения и пропорций.

Интернационализация — это процесс адаптации вашего приложения к различным языкам, регионам и культурам. Макет интернационализированного приложения должен учитывать эти различия и корректно отображаться на всех языках и регионах, которые поддерживает приложение.

Интернационализация имеет три основных эффекта на макет. Во-первых, когда вы переводите свой пользовательский интерфейс на другой язык, метки требуют различного пространства.Немецкий, например, обычно требует значительно больше места, чем английский. Японский часто требует гораздо меньше.

Во-вторых, формат, используемый для представления дат и чисел, может меняться от региона к региону, даже если язык не меняется. Хотя эти изменения, как правило, более тонкие, чем языковые, пользовательский интерфейс по-прежнему должен адаптироваться к небольшим изменениям в размере.

В-третьих, изменение языка может повлиять не только на размер текста, но и на организацию макета.Разные языки используют разные направления компоновки. Например, в английском языке используется направление макета слева направо, а в арабском и иврите используется направление макета справа налево. В общем, порядок элементов пользовательского интерфейса должен соответствовать направлению макета. Если кнопка находится в правом нижнем углу представления на английском языке, она должна быть в левом нижнем углу на арабском языке.

Наконец, если ваше приложение для iOS поддерживает динамический тип, пользователь может изменить размер шрифта, используемого в вашем приложении. Это может изменить как высоту, так и ширину любых текстовых элементов в вашем пользовательском интерфейсе.Если пользователь изменяет размер шрифта во время работы приложения, шрифты и макет должны адаптироваться.

Автоматическая компоновка

в сравнении с рамочной компоновкой

Существует три основных подхода к созданию пользовательского интерфейса. Вы можете программно разметить пользовательский интерфейс, использовать маски автоматического изменения размера для автоматизации некоторых ответов на внешние изменения или использовать автоматическую разметку.

Традиционно приложения размечали свой пользовательский интерфейс, программно устанавливая фрейм для каждого представления в иерархии представлений.Рамка определяла происхождение, высоту и ширину вида в системе координат суперпредставления.

Чтобы создать свой пользовательский интерфейс, вам нужно было рассчитать размер и положение для каждого представления в иерархии представлений. Затем, если произошло изменение, вам пришлось пересчитать фрейм для всех задействованных видов.

Во многих отношениях программное определение фрейма представления обеспечивает большую гибкость и мощность. Когда происходит изменение, вы можете буквально вносить любые изменения, которые вы хотите.Тем не менее, поскольку вы также должны сами управлять всеми изменениями, разработка простого пользовательского интерфейса требует значительных усилий для разработки, отладки и обслуживания. Создание действительно адаптивного пользовательского интерфейса увеличивает сложность на порядок.

Вы можете использовать маски автоматического изменения размера, чтобы облегчить некоторые из этих усилий. Маска авторазмера определяет, как изменяется кадр представления при изменении кадра его суперпредставления. Это упрощает создание макетов, которые адаптируются к внешним изменениям.

Однако маски авторазмера поддерживают относительно небольшое подмножество возможных макетов. Для сложных пользовательских интерфейсов вам, как правило, необходимо дополнить маски автоматического изменения размера своими собственными программными изменениями. Кроме того, маски авторазмера адаптируются только к внешним изменениям. Они не поддерживают внутренние изменения.

Хотя маски с автоматическим изменением размера являются итеративным улучшением программных макетов, автоматическая компоновка представляет собой совершенно новую парадигму. Вместо того, чтобы думать о фрейме представления, вы думаете о его отношениях.

Auto Layout определяет ваш пользовательский интерфейс, используя ряд ограничений. Ограничения, как правило, представляют отношения между двумя представлениями. Затем Auto Layout рассчитывает размер и местоположение каждого вида на основе этих ограничений. Это создает макеты, которые динамически реагируют как на внутренние, так и на внешние изменения.

Логика, используемая для разработки набора ограничений для создания определенных поведений, очень отличается от логики, используемой для написания процедурного или объектно-ориентированного кода.К счастью, освоение Auto Layout ничем не отличается от освоения любой другой задачи программирования. Есть два основных шага: сначала вам нужно понять логику, лежащую в основе макетов на основе ограничений, а затем вам нужно изучить API. Вы успешно выполнили эти шаги при изучении других задач программирования. Авто макет не является исключением.

Остальная часть этого руководства предназначена для облегчения вашего перехода к автоматической компоновке. Глава «Автоматическое расположение без ограничений» описывает высокоуровневую абстракцию, которая упрощает создание пользовательских интерфейсов с поддержкой автоматического размещения.Глава «Анатомия ограничений» содержит базовую теорию, которую вы должны понять, чтобы успешно взаимодействовать с Auto Layout самостоятельно. Работа с Ограничениями в Интерфейсном Разработчике описывает инструменты для проектирования Автоматической Разметки, и главы Программно Создание Ограничений и Автоматической разметки поваренной книги описывают API подробно. Наконец, Auto Layout Cookbook представляет широкий спектр типовых макетов разного уровня сложности, которые вы можете изучать и использовать в своих собственных проектах, а Debugging Auto Layout предлагает советы и инструменты для исправления ошибок, если что-то пойдет не так.

Автоматическая компоновка без ограничений

Copyright © 2018 Apple Inc. Все права защищены. Условия использования | Политика конфиденциальности | Обновлено: 2016-03-21

,
Используйте ConstraintLayout для разработки ваших просмотров Android

В этом коде вы узнаете, как использовать редактор макетов Android Studio с ConstraintLayout — новым, гибким и эффективным макетом, доступным в репозитории поддержки Android. Редактор макетов использует ConstraintLayout для определения положения элемента пользовательского интерфейса. Ограничение представляет собой соединение или выравнивание с другим видом, родительским макетом или невидимым руководством.

Вы будете работать в основном с редактором макетов для этой кодовой метки и не будете напрямую редактировать код XML или Java.К концу этой кодовой метки у вас будет достаточно опыта работы с Редактором макетов в Android Studio, чтобы иметь возможность создавать сложный макет, такой как показан ниже.

Пререквизиты

  • Опыт разработки приложений для Android
  • опыта с Android Studio

Что ты будешь делать

  • Узнайте, как автоматически ограничивать элементы пользовательского интерфейса в макете.
  • Как разместить и изменить размеры элементов в макете.
  • Как добавить ограничения для размещения и выравнивания элементов с другими элементами.
  • Как настроить размеры и поля макета элемента.
  • Научитесь автоматически выводить ограничения для макета.
  • Используйте барьеры для выравнивания элементов, которые динамически изменяются по размеру.
  • Используйте цепочки для позиционирования нескольких элементов.

Что вам понадобится

Чтобы загрузить образец приложения, вы можете:

Загрузить ZIP

.. или клонировать GitHub-репозиторий из командной строки с помощью следующей команды:

 $ git clone https://github.com/googlecodelabs/constraint-layout.git

Хранилище макетов ограничений содержит один проект приложения:

  • constraint-layout-start — проект, содержащий макеты, которые вы будете строить в этом коде.

Часто задаваемые вопросы

Сначала давайте посмотрим, как выглядит готовое приложение-образец.Следуйте этим инструкциям, чтобы открыть образец приложения в Android Studio.

  1. Если вы загрузили файл почтового индекса Restric-layout-master , распакуйте его.
  2. Откройте папку constraint-layout-master , чтобы увидеть папку constraint-layout-start .
  3. Откройте проект ограничение-макет-начало в Android Studio.
  4. Нажмите кнопку Run и выберите эмулятор или подключите устройство Android, которое должно поддерживать Android Lollipop (минимальный поддерживаемый SDK — 22).Должен появиться экран компоновки ограничений:

Чтобы использовать ConstraintLayout, соответствующая библиотека поддержки должна быть включена в файл build.gradle (Модуль: приложение) в вашем проекте. Зависимость зависимость-макет предоставляется в виде отдельной библиотеки поддержки, которая работает на всех версиях Android вплоть до Android 2.3 (Gingerbread).

Начальное приложение уже включает зависимость в build.gradle. Шаблоны Android Studio также включают эту зависимость для новых проектов.

При создании нового проекта приложения всегда открывайте build.gradle и убедитесь, что в него включена самая последняя версия зависимости. Android Studio выделяет любую зависимость, которая не является самой последней версией. Если зависимость выделена, наведите указатель мыши на оператор, и Android Studio предложит более новую версию. Замените x.x.x предлагаемым номером версии.

 зависимостей {
  ...
  compile 'com.android.support.constraint: ограничение-расположение: x.x.x»
}

Если вы видите сообщение об ошибке синхронизации Gradle, убедитесь, что для инструкции buildToolsVersion в build.gradle установлено значение 25.0.3 или новее:

В нашем случае buildToolsVersion "29.0.2"

Сообщение об ошибке обычно имеет ссылку, которая помогает в загрузке версии инструментов сборки.

Android Studio предоставляет редактор макетов для быстрого создания макетов. Вы можете перетаскивать элементы пользовательского интерфейса в визуальный дизайн и вид чертежа, размещать элементы в макете, добавлять ограничения и устанавливать атрибуты.Давайте посмотрим:

  1. Откройте activity_main_done.xml на панели Проект. Откроется редактор макетов.
  2. Состояние Design уже должно быть выбрано; если нет, щелкните по состоянию Design в правом верхнем углу окна редактора.

  1. Если нет чертежа, щелкните значок Показать чертеж на панели инструментов.

Ваша панель редактора макетов должна выглядеть так, как показано ниже.

На рисунке выше показаны компоненты редактора макетов:

  1. Панель инструментов
  2. Палитра
  3. Дизайнерский вид
  4. Blueprint view
  5. Дерево компонентов

Нажмите кнопку Device in Editor на панели инструментов (как показано на рисунке выше), чтобы выбрать разные устройства и посмотреть, как выглядит макет на разных экранах устройств.

Чтобы увидеть XML-код макета, щелкните Text рядом с кнопкой «Дизайн».Чтобы увидеть разделенное представление XML и поверхность конструктора, нажмите кнопку Split . Вы можете увидеть атрибуты XML для каждого элемента в макете. Например, ниже показан элемент EditText с ограничениями в представлении конструктора и атрибутами ограничения XML для того же элемента EditText , как показано на вкладке Текст .

Элемент EditText в режиме конструктора:

Элемент EditText в XML, показывающий только атрибуты ограничения:

Например, атрибут app: layout_constraintLeft_toLeftOf в приведенном выше XML-коде размещает левую сторону элемента слева от элемента настроек .

Редактор макетов использует ограничения , чтобы определить положение элемента пользовательского интерфейса в макете. Ограничение представляет собой соединение или выравнивание с другим видом, родительским макетом или невидимым руководством. Вы можете создать ограничения вручную, как мы покажем позже, или автоматически, используя инструмент Autoconnect.

Autoconnect может создать два или более ограничений для элемента пользовательского интерфейса для родительского макета. После перетаскивания элемента в макет он создает ограничения на основе позиции элемента.

  1. Откройте activity_main_autoconnect.xml из панели проекта.
    Вкладка Design уже должна быть выбрана; если нет, щелкните по нему.
  2. Убедитесь, что инструмент автоматического подключения, расположенный на панели инструментов, включен.
    Может быть отключено по умолчанию.
  3. В чертеже или в предварительном просмотре щелкните, затем перетащите ImageView к центру макета, пока не появятся пунктирные направляющие.
  4. Отпустите кнопку мыши, когда увидите направляющие, идущие сверху вниз, а также слева направо.
    Вы видите, что синие зигзагообразные линии, которые представляют ограничения, соединяют верхний, левый, нижний и правый края представления с краями родительского представления, центрируя ImageView в макете, как показано на анимированном рисунке ниже:

Ограничения автоматически добавляются ко всем четырем сторонам вида, потому что вид находится достаточно близко к центру для редактора макетов, чтобы предположить, что он должен быть центрирован в макете.

Обратите внимание на эти маркеры в представлении «План» или «Дизайн» в ImageView:

Ручка изменения размера : Вы можете перетащить квадратные маркеры изменения размера, чтобы изменить размер элемента.При перетаскивании ручка меняется на угловой угол.

Дескриптор ограничения : щелкните дескриптор ограничения, показанный в виде круга на каждой стороне элемента, а затем перетащите его на другой дескриптор ограничения или родительскую границу, чтобы создать ограничение. Ограничение представлено зигзагообразной линией.

Чтобы выровнять ImageView по верху, выберите ImageView, наведите указатель мыши на нижнюю ручку ограничения до появления всплывающей подсказки, а затем Command ( в MacOS) или Control ( Ctrl в Windows) щелкните по нижней части. дескриптор ограничения, чтобы удалить его:

Теперь вид прикреплен к верхней части макета, поскольку существует только одно вертикальное ограничение (вверху).Горизонтальные ограничения по-прежнему располагают вид в центре.

При включенном Autoconnect вы можете перетащить любой элемент (например, кнопку) в любую часть макета, чтобы создать ограничения для родительского макета. Чтобы показать, как это работает:

  1. Перетащите кнопку из раздела «Виджеты» палитры в любую позицию макета и отпустите кнопку.

  1. Выберите кнопку в макете и перетащите ее в правый нижний угол, как показано ниже — , пока не появятся подсказки бокового и нижнего полей .Когда вы увидите указания в обоих направлениях, отпустите кнопку. Кнопка привязывается к руководству автоматически.

Autoconnect затем генерирует ограничения для родительского макета. Два положения автоматически добавляются, чтобы расположить кнопку относительно родительского макета. Поскольку вы перетаскивали кнопку, чтобы наметить ориентиры, редактор макетов включает в себя 16dp в качестве правого и нижнего полей, которые соответствуют направляющим по умолчанию:

В этом упражнении вы начинаете макет с нуля, добавляя и изменяя размеры ImageView .

  1. Откройте activity_main_start.xml на панели проекта и перейдите на вкладку Design .
  2. Отключите инструмент автоматического подключения (щелкните его один раз, чтобы отобразить), чтобы ограничения не отображались автоматически при добавлении элемента пользовательского интерфейса.

Важно : Редактор макетов автоматически запускается с включенным средством автоматического подключения. Поскольку в этом разделе мы узнаем о ручных ограничениях, пожалуйста, убедитесь, что Autoconnect отключена, выключив кнопку.

Добавьте ImageView в макет

  1. Найдите ImageView в разделе «Изображения» в палитре и перетащите его в любое место макета.

Откроется диалоговое окно Resources . Образец Restric-layout-start уже включает ресурсы для кодовой метки.

  1. Выберите ресурс @ drawable / singapore и нажмите OK .

ImageView появляется в макете.

  1. Перетащите элемент вокруг макета и перетащите углы, чтобы изменить размер изображения. Изменяя размер изображения, ширина и высота фиксируются к определенным размерам.

Вы увидите индикаторы на панели Component Tree . Нажмите на индикатор, чтобы увидеть больше информации. Предупреждения и ошибки включают в себя:

  • Отсутствуют ограничения, которые вы добавите позже в этом разделе.
  • Отсутствует атрибут contentDescription для ImageView .

Атрибуты описания содержимого

важны для создания доступных приложений. Вы будете использовать уже доступный ресурс @ string / placeholder для атрибута.

Изменить атрибуты

Чтобы добавить или изменить значения атрибутов, используйте панель «Атрибуты », которая открывается в правой части редактора макетов:

  1. Выберите элемент ImageView , если он еще не выбран.
  2. Откройте вкладку Атрибуты в правой части панели инструментов:

Откроется панель Атрибуты , чтобы вы могли изменить атрибуты выбранного элемента пользовательского интерфейса.

  1. Добавьте @ string / placeholder в атрибут contentDescription .
  2. На панели Атрибуты вы также можете увидеть другие атрибуты для ImageView . Выберите centerCrop в раскрывающемся меню scaleType , чтобы изменить атрибут scaleType .

Добавить ограничения в родительский макет

Следующий анимированный рисунок демонстрирует, как выполнить эти шаги:

  1. Чтобы добавить ограничение к левому краю ImageView , щелкните и удерживайте маркер ограничения и перетащите линию к левому краю родительского макета.
  2. Чтобы добавить ограничение правого края для ImageView , перетащите указатель ограничения к правому краю родительского макета.
  3. Чтобы добавить верхнее ограничение для ImageView , перетащите указатель ограничения в верхнюю часть родительского макета.
  4. Чтобы добавить нижнее ограничение для ImageView , перетащите курсор из маркера ограничения в нижнюю часть родительского макета.

Редактор макетов автоматически включает поле по 8 дп вокруг ImageView по умолчанию.Размер поля отображается над линией ограничения:

Вы будете работать с полями в следующем разделе.

,
Руководство по автоматической разметке: стековые виды

Следующие рецепты показывают, как вы можете использовать представления стека для создания макетов повышенной сложности. Представления стека — это мощный инструмент для быстрого и удобного проектирования пользовательских интерфейсов. Их атрибуты позволяют в высокой степени контролировать то, как они планируют свои упорядоченные представления. Вы можете дополнить эти настройки дополнительными пользовательскими ограничениями; однако это увеличивает сложность макета.

Чтобы просмотреть исходный код этих рецептов, см. Проект Auto Layout Cookbook.

Simple Stack View

Этот рецепт использует один вертикальный вид стека для размещения метки, изображения и кнопки.

взглядов и ограничений

В Интерфейсном Разработчике начните с перетаскивания вертикального представления стека и добавьте метку цветов, представление изображения и кнопку редактирования. Затем установите ограничения, как показано.

  1. Stack View.Leading = Superview.LeadingMargin

  2. Stack View.Trailing = Superview.TrailingMargin

  3. Stack View.Top = Top Layout Guide.Bottom + Standard

  4. Руководство по разметке дна. Верх = Вид стека. Низ + Стандарт

Атрибуты

В инспекторе Атрибутов установите следующие атрибуты стекового представления:

стек

Ось

центровка

распределение

Разнос

Stack View

вертикальный

Заливка

Заливка

8

Затем установите следующие атрибуты в представлении изображения:

Посмотреть

Атрибут

Стоимость

Просмотр изображения

Образ

(я

.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *