Спойлер для андроид что это

Lepzon.ru

Как сделать спойлер в Дискорде на Андроид

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

Как сделать спойлер из картинки

Нужно сказать, что прятать текст вместе с изображениями можно только в ПК-версии Discord. Поэтому сейчас мы покажем, как картинку положить в спойлер на компьютере.

1. Переходим в Дискорд и выбираем собеседника.
2. Нажимаем на кнопку вложения (плюсик в чате) и добавляем изображение из проводника компьютера.
3. В окне настройки загрузки поставьте галочку Пометить как спойлер.
4. Добавьте картинку в чат, и она станет сполейром.

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

Когда нужно сделать это с текстом на версии ПК, выделите его и нажмите ПКМ. В меню вы увидите иконку в виде глаза – нажмите её.

Создаём спойлер в Андроид

В мобильных устройствах нужно работать со спойлерами иначе. Если вы хотите написать своему другу и спрятать для него сообщение в Дискорд, сделайте так: ||Привет, дружище ||. Две вертикальные палки по краям текста скроют его. Вы ещё не знаете, как поставить вертикальные линии в Android? Тогда советуем прочитать вот эту статью о знаках андро-клавиатуры.

На айфонах выделяйте текст долгим тапом. Через секунду появится в меню пункт Mark as Spoiler, который нужно выбрать. И тогда текст тоже уйдёт под спойлер. Делать их просто, но теги не будут работать со ссылками на приглашение в свой канал Дискорд.

Как сделать спойлер из изображения на телефоне

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

1. Запустите файловый менеджер или проводник в телефоне.
2. Найдите среди папок и файлов картинку, которую хотите добавить в спойлер.
3. Вызываем контекстное меню изображения (выбор или долгое нажатие).
4. Выбираем пункт Переименовать и меняем имя на SPOILER_любые цифры или символы.
5. Нажимаем на кнопку Поделиться файлом и выбераем Дискорд.

Отправьте изображение на нужный сервер. Оно превратится в спойлер сразу же после добавления.

Текст в речь в Discord

Теперь пройдёмся по более интересным возможностям. Может быть кто-нибудь из вас не знал, но приложение умеет говорить написанный нами текст. И это довольно забавно. Качество голоса – не самое лучшее. Всё же иногда функция может выручить. Её можно использовать для развлечения в чате с другом. Вот как она работает.

1. Выберите нужный сервер и собеседника.
2. Поставьте перед текстом тег /tts (text to speech).
3. Через пробел напишите текст на русском языке, который должен проговорить Discord.

Чтобы прослушать своё сообщение в чате выберите три точки в конце строки и нажмите Зачитать сообщение. Кстати, читать роботом можно и любые другие сообщения в чате. Голос зависит от устройства, на котором установлен Дискорд.

Серверы приходится модерировать. Если на нём много людей и среди них точно есть тролли, они будут использовать воспроизведение где нужно и где нет. Модератор может отключить text to speech на канале или на всём сервере. Пройдите по пути: Настройки > Уведомления > Озвучивание текста. Есть три положения:

• Для всех каналов – никто не сможет воспользоваться озвучкой;
• Не использовать – выключить на всех каналах озвучку;
• Для текущего канала – будет работать только для этого канала.

Команда /tts в чате тоже может быть отключена модератором. Используйте тот же путь, чтобы найти настройку.

Как закрепить сообщение в Discord

Продолжаем настраивать чат. Как работать со спойлером в Дискорд – разобрались. Теперь давайте закрепим одно из важных сообщений в переписке. Это часто приходится делать на каналах с большой посещаемостью. Чтобы оставить сообщение выше всех:

1. Возле сообщения, которое необходимо закрепить, нажмите кнопку меню.
2. Нажмите Закрепить.
3. Подтвердите закрепление текста.

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

Источник

Android: выдвигающийся экран снизу

Данная статья является переводом статьи Emrullah Luleci, а также её продолжения.

Нижний экран (Здесь и далее под «нижним экраном/слоем» будет подразумеваться элемент bottom sheet — прим. пер.) — компонент, выезжающий снизу экрана, который используется для отображения дополнительного контента. Подробнее об этом элементе можно узнать на официальной сайте посвященном материальному дизайну.

Зависимости

Для использования этого элемента, добавьте последние версии библиотек поддержки в свой проект:

Создайте класс наследник от AppCompatActivity:

Создание макетов

Содержимое нижнего экрана

Для удобства воспользуемся макетами. Назовем файл с нижним слоем bottom_sheet.xml.

behavior_peekHeight: Определяет высоту видимой части.

behavior_hideable: Определяет, может ли нижний экран скрываться свайпом вниз.

Container view

Создайте CoordinatorLayout в качестве корневого вью. Добавьте в него прямым наследником bottom_sheet.xml. Элементы app_bar и activity_bottom_sheet_content не имеют прямого отношения к нижнему экрану, поэтому их можно заменить или удалить.

На данном этапе нижний экран должен работать примерно так:

Динамическое управление

Поведением и свойствами нижнего экрана можно также управлять динамически с помощью Java.

Прикрепление элементов к нижнему экрану

Также можно прикрепить вью к нижнему экрану, чтобы прикрепленный элемент перемещался одновременно с нижним слоем.

Добавим Floating Action Button в макет созданный выше. Новый компонент должен являться непосредственным наследником CoordinatorLayout также как и bottom_sheet. Для прикрепления элемента к нижнему экрану необходимо добавить app:layout_anchor с id вью нижнего экрана, а также app:layout_anchorGravity со значением top|end.

Теперь плавающая кнопка закреплена в верхнем углу нашего нижнего экрана и перемещается вместе с ним.

Скрытие плавающей кнопки при скроле

Для скрытия кнопки при скроле необходимо добавить слушатель к нижнему экрану и отображать/скрывать кнопку. Для начала найдем необходимые вью:

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

Результат обоих вариантов можно увидеть ниже:

Источник

Автотесты на Android. Картина целиком

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

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

Зачем нужны автотесты?

Есть мнение, что UI-тесты не нужны, если у вас достаточное количество юнит- и интеграционных тестов. Но от следующей метафоры никуда не деться. Представьте, что вы собираете велосипед. У вас есть два хорошо протестированных колеса, протестированная рама вместе с седлом, протестированная система педалей с цепью и рулем. То есть мы с вами имеем хороший набор интеграционных и юнит-тестов. А велосипед-то в итоге поедет? Чтобы это проверить, вы нанимаете ручных тестировщиков, которые перед каждым релизом должны убедиться, что безупречные детали корректно взаимодействуют друг с другом, и велосипед будет ездить и доставлять пользователю удовольствие.

Так же и с любым программным обеспечением для мобилок. К сожалению, в мобильном мире мы не можем откатить неудачные изменения быстро, ведь все обновления идут через Google Play Store и App Store, что сразу накладывает ограничения в виде долгой раскатки в сравнении с веб- и backend-аналогами, обязательной совместимости версий и зависимости от решения пользователя обновляться или нет. Поэтому нам критически важно всегда убеждаться перед релизом, что основные пользовательские сценарии приложения работают именно так, как ожидается.

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

Все это естественным образом подводит к необходимости автоматизации проверки пользовательских сценариев, то есть написания end-to-end- или автотестов. У «Авито» есть рассказ о том, как автотесты помогают и сколько они стоят (2019 год). Однако большинство команд такой метод отпугивает своей сложностью и необходимостью вкладывать существенные ресурсы, чтобы выстроить процесс. Это возвращает нас к цели данной статьи и вообще к одной из целей Avokado Project — стандартизировать процесс автотестирования в Android и существенно уменьшить его стоимость.

Картина целиком

Итак, обещанная картина целиком.

Если вы чего-то не понимаете, не переживайте. Мы сейчас пройдемся подробно по всем пунктам.

Процесс написания тестов

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

Выбор инструментов для написания автотестов

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

Первая развилка — это выбор между кроссплатформенным решением (Appium и т. д.) и нативным решением (Espresso, UI Automator). Много копий сломано в этих спорах. Рекомендуем посмотреть выступление наших коллег, полное драматизма и накала страстей.

Спойлер — мы за нативные решения. По нашему опыту, они:

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

Кроме того, Google поддерживает Espresso и UI Automator.

Больше почитать про сравнение вы можете в статьях:

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

Kaspresso

Kaspresso — это фреймворк, который:

• предоставляет DSL, значительно облегчающий написание автотестов;
• дает встроенную многоуровневую защиту от флекающих тестов;
• ускоряет работу UI Automator;
• предоставляет полные логи о том, что происходит в тесте;
• дает возможность запуска любых ADB-команд внутри тестов;
• предоставляет механизм интерцепторов для перехвата всех действий и проверок. На данном механизме построено логирование и защита от нестабильных тестов;
• описывает лучшие практики (исходя из нашего опыта) по написанию автотестов.

Вы можете прочитать о Kaspresso на GitHub и Habr.

Test runner

Вы написали несколько тестов. Теперь их нужно запустить. За этот этап отвечает Test Runner, или просто раннер.

Что нам предлагает Google? Утилиту AndroidJUnitRunner и ее специальный режим — Orchestrator. AndroidJUnitRunner делает то, что от него и требуется — просто запускает тесты, позволяя еще и параллелить их выполнение. Orchestrator позволяет продолжить выполнение тестов, даже если некоторые из них упали, и дает возможность минимизировать общее состояние между тестами. Так достигается изоляция исполнения каждого теста.

Но со временем требований к раннеру становится все больше. Вот некоторые из них:

• запускать отдельные группы тестов;
• запускать тесты только на определенных девайсах;
• перезапускать упавшие тесты (вторая волна защиты от последствий нестабильных тестов после Kaspresso);
• эффективно распределять тесты по девайсам с учетом истории прогонов и успешности предыдущих запусков;
• подготавливать отчеты о прогоне в разных форматах;
• отображать результаты прогона (желательно Allure based);
• поддержать истории прогонов для дальнейшего анализа;
• просто интегрироваться с вашей инфраструктурой.

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

Однако, Marаthon, к сожалению, не обладает некоторыми важными, по нашему мнению, свойствами. В частности, в нем нет:

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

Кроме того, мы считаем, что раннер должен быть платформенным, то есть либо для Android, либо для iOS. Это обусловлено уникальной спецификой каждой ОС и вытекающей отсюда сложностью внесения изменений в раннер.

Поэтому прямо сейчас мы работаем над Avito Runner, в котором хотим собрать все лучшие и зарекомендовавшие себя наработки и идеи. Ждите будущих анонсов!

На чем запускать тесты

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

1. Настоящий девайс.
   Плюсы. Покажет проблемы, специфичные для конкретных устройств и прошивок. Многие производители меняют Android под себя — как UI, так и логику работы ОС. И бывает полезно проверить, что ваше приложение корректно работает в таком окружении.
   Минусы. Необходимо где-то добыть ферму устройств, организовать специальное помещение под них — необходима низкая температура, нежелательно попадание прямых солнечных лучей и т. д. Кроме того, аккумуляторы имеют свойство вздуваться и выходить из строя. А еще сами тесты могут менять состояние устройства, и вы не можете просто взять и откатиться на какой-то стабильный снепшот.
2. Чистый эмулятор.
   Под «чистым» мы подразумеваем, что вы запускаете эмулятор у себя или где-то на машине, используя установленный на эту машину AVD Manager.
   Плюсы. Быстрее, удобнее и стабильнее настоящего устройства. Создание нового эмулятора занимает считаные минуты. Никаких проблем с отдельным помещением, аккумуляторами и прочим.
   Минусы. Отсутствие упомянутых выше device specifics. Однако зачастую количество тестовых сценариев, завязанных на специфику устройства, ничтожно мало, и они не высокоприоритетные. Но самый главный минус — это плохая масштабируемость. Простая задача залить новую версию эмулятора на все хосты превращается в мучение.
3. Docker-образ Android-эмулятора.
   Docker решает недостатки чистых эмуляторов.
   Плюсы. Docker и соответствующая обвязка в виде подготовки и раскатки образа эмулятора — это полноценное масштабируемое решение, позволяющее быстро и качественно готовить эмуляторы и раскатывать их на все хосты, обеспечивая их достаточную изолированность.
   Минусы. Более высокий входной порог.

Мы делаем ставку на Docker.
В сети есть разные Docker-образы Android-эмуляторов, мы рекомендуем обратить внимание на следующие:

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

Инфраструктура

Вы написали сотни UI-тестов. Часть из них вы хотите запускать в рамках PR, а значит, весь тестовый набор должен проходить в максимально короткие сроки, например, до 20 минут. Вот тут наступает настоящее масштабирование.

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

Итак, что вам примерно предстоит:

• Выбор между облачным решением, локальным решением с нуля и локальным решением на базе чего-то, если в компании есть своя инфраструктура по запуску тестов других платформ.
• Самое трудоемкое — это развертывание внутренней инфраструктуры с нуля. В этом случае необходимо подобрать железо, которое будет максимально использоваться автотестами. Придется измерять нагрузку на CPU/GPU/Memory/Disk, а еще пробовать разное количество одновременно запущенных эмуляторов и смотреть за стабильностью тестов. Это большая тема, по которой мы хотим провести современные замеры и поделиться с вами своими рекомендациями.
  Дальнейшая накатка необходимого ПО, встраивание в сети и прочее — это все за DevOps-инженерами.
• На выходе должен быть какой-то сервис, единая точка, которая отдает вам эмуляторы. Это может быть Kubernetes, может быть облачный сервис типа Google Cloud Engine или какое-то кастомное решение.
  В его настройке опять-таки помогают DevOps-инженеры.
• Связка полученного сервиса с Test Runner.
  Одна из задач Avito Runner — сделать такую связку максимально простой и прозрачной, а также предоставить точки расширения, которые помогут вам легко внедрить свой кастомный сервис.

В ближайшее время мы планируем выпустить Avito Runner и статьи, которые помогут настроить инфраструктуру.

Остальное

Не забывайте про такие немаловажные моменты, как:

• вывод отчета по прогону тестов (Allure);
• внедрение/синхронизация с TMS;
• интеграция в CI/CD;
• обучение разработчиков и тестировщиков;
• процессы — кто, когда, сколько и какие автотесты пишет.

Про все это мы еще обязательно поговорим.

Заключение

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

Источник