Отменить отмену

У нас есть попап для отмены заказа. Нам нужны две кнопки, одна из которых отменит заказ, а вторая закроет окно. Конечно, мы не можем назвать их "Отменить" и "Отмена".

Автор статьи предлагает, как назвать кнопку, которая закрывает окно:

1. Оставить заказ
Самый подходящий в большинстве случаев вариант.

2. Never mind
Формальный вариант, для которого тяжеловато подобрать подходящий русский перевод.

3. Закрыть, Назад, Нет, не отменять заказ, и подобные варианты.

Кнопка с деструктивным действием должна ясно выражать результат. Отмена этого действия в идеале должна быть помечена антонимом. Сбросить — Оставить, Удалить — Не удалять, Прервать загрузку — Продолжить загрузку.

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

https://uxdesign.cc/the-microcopyist-cancellation-confirmation-conflagration-8a6047a4cf9

​​Судя по Android P Developer Preview, нас ждёт обновлённый Material Design — много скруглённых углов, кнопки без теней и капса и новые цвета. В альфу Design Library уже завезли кнопки и скругленные карточки (и ещё много интересных изменений).

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

На прошлой неделе Figma представили API для разработчиков. С его помощью можно скачать проект в формате JSON, читать и писать комментарии к файлам и экспортировать любой компонент в виде картинки. Пока что это все возможности, но разработчики обещают добавлять новые фичи.

В JSON-файле каждому экрану соотвествует объект CANVAS. В него входят элементы экрана с их свойствами — цвет, эффекты, шрифт и так далее. Можно работать с компонентами, сетками и констрейнтами.

В качестве юзкейсов Figma предлагают генерировать компоненты или стайлгайды, интегрировать спелл-чек для текстов в интерфейсе, делать живые мокапы и так далее.

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

Github сделали систему, которая автоматически обновляет иконки в проекте вслед за изменениями в макете. Сотрудник создаёт пулл-реквест со ссылкой на обновлённый макет, система continuous integration билдит проект, подтягивает иконки из макета в Фигме и нарезает их в подходящий для проекта формат.

Haiku представили интергацию с Фигмой и написали туториал про то, как анимировать элементы ваших макетов.

#figma #инструмент

​​Воу-воу, нас уже больше 800 человек! Привет всем, кто пришел из @sketchdesigner и @duiux. 👋

У меня два объявления.

Я ищу человека, который разнообразит канал постами об iOS.
Я не разрабатываю под эту платформу, поэтому писать что-то стоящее на тему iOS-разработки не могу. Если здесь есть желающие делиться классными материалами и мыслями — напишите мне в личку (@kondenko), будем вместе делать крутой канал про приложения.

По совету @okunev я решил обновить иконку канала и хочу услышать ваш фидбек. Ставьте лайки к этому посту или пишите, что не нравится — будем менять.

​​Я часто слышал о Protobuf, но плохо представлял себе, что это такое. Разобрался и рассказываю.

Сейчас мы используем JSON, чтобы передать или получить данные с сервера. Мы описываем объект в виде текста, передаем строку на клиентское устройство, парсим и переводим в объект.

Protobuf тоже помогает передавать данные. Для этого мы пишем proto-файлы (они напоминают обычные классы). На их основе мы создаём объекты, а Protobuf компилирует их в бинарный формат. Его уже нельзя прочитать, как JSON, но такие объекты занимают в 10 раз меньше места и обрабатываются в 100 раз быстрее.

Protobuf будет полезен, если мы обмениваемся данными с устройством по bluetooth, или работаем с большими объемами данных. В 2010 году Twitter перевели свою базу данных с XML на Protobuf. Это помогло им уменьшить размер 300 триллионов твитов с 10 петабайт до одного.

Если хотите попробовать сами — вот статья о том, как добавить Protobuf в Android-приложение (там же есть сравнение с JSON):
https://proandroiddev.com/how-to-setup-your-android-app-to-use-protobuf-96132340de5c

Документация для Java:
developers.google.com/protocol-buffers/docs/javatutorial

Завтра Telegram могут заблокировать, поэтому напоминаю, что у Мобайла есть странички в FB и ВК:
fb.me/mobiledesigndev
vk.com/mobiledesigndev

Я продолжу писать в канал, но в случае блокировки стану дублировать посты туда.
А вообще, сейчас самое время позаботиться о прокси — я настроил себе в пару кликов с помощью @socks5_bot.

Google I/O 2018: что нового для разработчиков

На днях прошла конференция Google I/O, где показали много новинок мира Android-разработки. Рассказываю о некоторых из них.

Android Jetpack (g.co/androidjetpack)

Это обновлённый набор библиотек. Он объединил в себе уже известные (AppCompat, Architecture Components) и новые компоненты — например, Paging, Slices и WorkManager. Всё это поддерживается на 95% устройств (судя по всему, версия API 19+).

Navigation и редактор экранов (developer.android.com/topic/libraries/architecture/navigation)

Библиотека Navigation помогает визуально настраивать логику и анимации переходов между экранами. Да, теперь это выглядит как любой другой инструмент для прототипирования, но работает в Android Studio.

Вместе с этим добавили интерфейс анимирования элементов интерфейса, похожий на After Effects. Можно выбрать кнопку, перетащить её в новое место, привязать местоположение и свойства к фреймам, и посмотреть анимацию в редакторе экранов.

Android App Bundle и Dynamic Features (g.co/androidappbundle)

Новый вариант сборки приложения, который помогает уменшить размер apk-файла, вырезая ненужные ресурсы. Если вы соберете приложение с помощью App Bundle и загрузите его в Play Store, гугл соберет apk-файлы, в которых останутся только нужные для каждого конкретного устройства ресурсы.
Также в бандл можно включать модули с фичами, которые используются очень редко. Они будут подгружаться отдельно при необходимости.

Многие из этих инструментов ещё в альфе, поэтому не торопитесь добавлять их в свои приложения.

Презентация для разработчиков: https://www.youtube.com/watch?v=flU42CTF3MQ

Больше новинок с I/O: https://android-developers.googleblog.com/2018/05/google-io-2018-whats-new-in-android.html

#io #разработка

​​Google I/O 2018: что нового для дизайнеров

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

Theme Editor — это плагин для Sketch, который помогает кастомизировать дизайн, при этом придерживаясь гайдлайнов.

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

У иконок теперь 5 стилей — Filled, Sharp, Rounded, Outlined и Two-tone.

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

Скачать: material.io/tools/theme-editor/

Посмотреть: youtu.be/BLrgDgd_1c0

Gallery — Zeplin от Google.

В Gallery можно всей командой работать со скетчами, прототипами и готовыми макетами. Макеты можно выгрузить с помощью Theme Editor.

В Gallery есть свойства компонентов, синхронизация с библиотекой символов в Sketch. комментарии и другие фичи, которые мы ждём от подобного инструмента в 2018 году. Красиво, бесплатно, работает только на macOS High Sierra.

Скачать: material.io/tools/gallery

Посмотреть: youtu.be/TIB3q68ZHYw

#io #дизайн

Что нового в Android P для разработчиков

• Приложения в бэкграунде больше не имеют доступа к микрофону, камере и некоторым сенсорам
• Mockito теперь умеет мокать final методы (и скоро научится static)
• Magnifier — "увеличительное стекло" для выделенного текста (как в iOS)
• Для текста теперь можно задавать расстояние между базовыми линиями (baseline)
• TextClassifier и SmartLinkify — распознаёт ссылки, даты и другие сущности в тексте
• IndoorPositioning — поиск местоположения, который работает в помещениях
• Display Cutout — поддержка "чёлок" на безрамочных устройствах
• Slices — возможность встроить часть вашего приложения в другое приложение (чем-то похоже на виджеты). Работает на KitKat и выше.
• Actions — ссылки на фичи в приложениях. В презентации это описывают как "ярлык с параметрами" и "видимый Intent".
• Поддержка картинок и смарт-реплаев в уведомлениях

С августа у новых приложений в Play Store должен быть targetSdk 26, а в ноябре такое же требование появится для обновлений существующих аппов.

Доклад: https://youtu.be/eMHsnvhcf78

Пост в блоге: https://android-developers.googleblog.com/2018/05/whats-new-in-android-p-beta.html

Adobe XD стал бесплатным для индивидуальных пользователей. У него появился план Starter с 2гб хранилища, ограниченным набором шрифтов в TypeKit и возможностью поделиться прототипом и спецификациями только одного проекта.

Судя по всему, Adobe хотят конкурировать с Figma, но получается не очень — XD устанавливался на мой Windows-десктоп буквально всё утро.

Скачать для macOS и Windows можно здесь: adobe.com/products/xd.html

Недавно Figma представили API для работы с макетами. Теперь почти то же самое выпустили Marvel. Вместо JSON они используют Graph QL — это значит, что пользователь может загружать с сервера не все данные, а только нужную часть.

Уже сейчас Marvel работает с Jira, Sketch, YouTube и другими сервисами.

Документация: https://marvelapp.com/developers/documentation/

🚀 switchMap

Returns a new ObservableSource by applying a function that you supply to each item emitted by the source ObservableSource that returns an ObservableSource, and then emitting the items emitted by the most recently emitted of these ObservableSources.

Да, я тоже сначала ничего не понял. @gazedash посоветовал посмотреть это видео, чтобы разобраться, как работает switchMap.

Объясняю на примере:

1. NumbersObservable каждую секунду выдаёт новое число
2. switchMap на каждое число создаёт PowersObservable, которая начинает выдавать степени этого числа
3. Как только NumbersObservable выдаёт новое число, switchMap отписывается от PowersObservable предыдущего числа, и она перестаёт выдавать степени. Вместо этого создаётся PowersObservable уже для нового числа.
4. Все степени, который получаются на выходе у созданных PowersObservable, сливаются в одну итоговую Observable (это называется flattening).

Пример использования switchMap — синхронизация субтитров с видео (https://github.com/mgp/effective-rxjava/blob/master/items/understand-switch-map.md#an-example-trannoscript-highlighting).

Если после моего объяснения всё ещё непонятно — посмотрите видео. Там про switchMap рассказывают наглядно и на очень простом примере.

​​Сегодня в 20:00 по Москве начнётся WWDC 2018.

Ждём iOS-приложения на маках, замену Macbook Air и обновления Xcode, отдельно хочется увидеть усовершенствованные CoreML и ARKit.

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

Провести трансляцию WWDC или написать пост по итогам?
anonymous poll

⭐️ Большой пост с новинками – 61
👍👍👍👍👍👍👍 78%

🔥 Трансляция – 17
👍👍 22%

👥 78 people voted so far.

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

- maсOS теперь частично поддерживает UIKit — фреймворк для разработки iOS приложений. Портировать приложения с одной платформы на другую можно будет в 2019 году. И нет, эти две системы не собираются объединять.
- Новые инструменты для создания приложений с тёмной темой в Xcode 10
- Swift 4.2 собирает большие приложения в 2 раза быстрее, чем Swift 4.0
- ARKit 2 сохраненяет состояние сцены между разными сеансами использования — можно изменить объект в AR, закрыть приложение, и изменения восстановятся при его запуске
- Поддежрка мультиплеера в AR
- usdz — единый формат для 3D-файлов в iOS
- SiriKit и Shortcuts — позволяет создавать цепочки действий в сторонних приложениях, которые активируются командой, которую задаёт пользователь.

Составил конспект доклада про принципы дизайна интерфейсов, которым следует Apple. Получилось довольно объемно, но там есть вещи, на которые стоит обратить внимание.

Разработчикам cоветую глянуть с 41:05 по 47:50. Там на примере показывают, как работать с ускорением, чтобы перемещать элементы туда, куда ожидает пользователь.

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

Конспект: http://telegra.ph/Designing-Fluid-Interfaces-konspekt-06-09

Продублировал в Notion, потому что Telegraph работает не у всех: https://www.notion.so/Designing-Fluid-Interfaces-a769ed4257354131a67e75e3c2fdba45

Видео: https://developer.apple.com/videos/play/wwdc2018/803/

Сделал заметки по ещё одному докладу, на этот раз про работу с текстом в Android.

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

Конспект в Notion: https://www.notion.so/Best-practices-for-text-on-Android-bbb299ce95694385b6306c96074dafe3

Недавно мне понадобилось создать версию приложения, где данные загружались бы не с сервера, а из JSON-файла, который хранился в ассетах приложения. Класс, который отдаёт данные (сервис), я создаю в одном из Dagger-модулей. Новичкам покажется очевидным, что надо создать новый flavor приложения, создать модуль-наследник и переоределить в нём метод-провайдер этого сервиса. Но проблема в том, что наследоваться от Dagger-модулей нельзя.

Представим, что у нас есть класс App, в котором мы определяем наши Dagger-компоненты, и mock flavor приложения Мы создаём MockApp, который наследуется от App, и переопределяем нужный компонент с новым модулем. Я решил пойти этим путём, но тут появилась новая проблема. Основному сервису нужен Retrofit, а mock-сервису — Gson и Context. Мы уже не сможем провайдить mock-сервиc вместо основного. С точки зрения Dagger это две разные зависимости, и использоваться будет только первая.

Я пошел гуглить и нашёл ответ на StackOverflow, где советовали создать mock и production версии приложения и поместить туда соответствующие модули. Тогда подходящий сервис будет попадать в основной граф зависимостей из выбранного flavor'а .

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

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

Чтобы переопределить зависимость, достаточно добавить провайдер с её заменой. Например, у себя я добавляю MockModule, и сервис с тестовыми данными заменяет собой сервис с реальными данными.

В чем отличия от Dagger:

- В Koin нет компонентов, сабкомпонентов и скоупов. Я для себя не нашёл в этом минусов, а плюс — очень простое управление зависимостями. Для маленького проекта это подходит идеально.
- Граф зависимостей Koin можно проверить юнит-тестом, не собирая приложение.
- Все зависимости надо объявлять вручную, так как Koin не генерирует код.

Очень рекомендую этот фреймворк, особенно если вы только начинаете осваивать dependency injection. А если вы уже профи и вам нужно больше возможностей, посмотрите на Kodein.

Код приложения, о котором я говорил, можно посмотреть здесь:
https://github.com/Kondenko/pocketwaka

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

Вместе с этим появился способ решить ещё одну проблему. Когда вы создаёте зависимость, которой нужны много других зависимостей, приходится писать что-то наподобие MyPresenter(get(), get(), get(), get(), get()). Такая конструкция нужна, чтобы Koin нашел нужные зависимости и подставил их в подходящие места. Плагин koin-reflect использует рефлексию (которой нет в основном фреймворке), чтобы зависимость можно было создать одним выражением: build<MyPresenter>().

Все изменения и фичи бета-версии: https://medium.com/koin-developers/opening-the-koin-1-0-0-beta-version-99cb8be1c308

Документация по скоупам: https://beta.insert-koin.io/docs/1.0/documentation/reference/index.html#\_scope\_features\_for\_android

Когда нам нужно передавать какие-то события из фрагмента его родителю, приходится делать каст Context к нужному интерфейсу в методе onAttach, а в onDetach обнулять ссылку на него, чтобы избежать утечек памяти:

override fun onAttach(context: Context) {
    super.onAttach(context)
    recipeClickListener = context as RecipeClickListener
}

override fun onDetach() {
    super.onDetach()
    recipeClickListener = null
}

Автор этой статьи показывает, как обернуть такую логику в делегат и упростить работу с listener'ами до одной строчки:

private val recipeClickListener: RecipeClickListener by ParentActivityDelegate(this)

За жизненным циклом мы следим внутри самого делегата с помощью LifecycleObserver или RxLifecycle. Благодаря им делегат отвечает за хранение ссылки на нужный контекст и её обнуление.

У этого подхода есть минусы:

- Значение присваивается полю с listener'ом после вызова onCreate и обнуляется перед вызовом onDestroy. То есть, мы не можем использовать его в этих методах.
- Если мы используем LifecycleObserver, у нас нет доступа к onAttach/onDetach.
- Если мы используем RxLifecycle, нам придётся добавить костыли, чтобы получить реактивный поток lifecycle-ивентов.

Реализация: https://gist.github.com/premnirmal/2968e7f83892cdb3bfd8dc6db2581931#file-fragmentdelegates-kt

Статья: https://blog.blueapron.io/delegate-your-lifecycle-to-kotlin-17c1d0d876c9

7 принципов хороших тестов

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

Итак, хорошие тесты:

Быстрые

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

Чтобы ускорить их выполнение:

— Не полагайтесь на Robolectric и PowerMock

— Реже используйте Mockito. Мокать data-классы — явный оверкилл. От себя посоветую библиотеку Pojo Data Mocker, которая заполняет data-классы рандомными данными. Если вам не нужны реальные данные, она очень выручает.

Независимые

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

Исчерпывающие

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

Воспроизводимые

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

Профессиональные

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

Читаемые

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

Автоматизированные

Тесты нужно прогонять часто и регулярно. Чтобы автоматизировать их запуск, можно использовать систему continuous integration, которая будет запускать тесты каждый раз при попытке влить код в ветки master или develop.

https://www.activecampaign.com/blog/inside-activecampaign/seven-principles-great-unit-tests-android/