Ну почти, да, методы вызываются автоматически, разработчик может не переопределить их и не обрабатывать сценарий сохранения-восстановления.
Но это не очень хорошая практика, такое возможно имеет смысл в играх, где проще с нуля запуститься, но если это обычное приложение, то это, скажем, не самый лучший для пользователя сценарий.
И можно так потерять пользователя, если он часто будет терять место, где он был, а на слабых девайсах убийство процесса довольно частое явление. Да и смена конфигурации не редкость.
Возможно стоит обсудить дополнительно необходимость обработки этих сценариев с продут овнером/менеджером. Если разработчик не захотел это делать ещё не значит, что он прав.
Привет, краткий ответ написан в заключении. Вы проверяте, что ваше приложение корректно сохраняет экран приложения и восстанавливает его - это введённые пользователем данные, открытые попапы, может точка скролла (зависит от бизнес требований) и т.д. всё что нужно сохранить, проверяете, что данные не пропадают и нет крашей.
Если прямо пример: вы ввели очень много текста в мессенджере, вы хотите найти подходящий мем, чтобы прикрепить к сообщению, заходите в браузер, скачивайте и возвращайтесь в мессенджер, а всё, что вы ввели стёрлось. Потому что система убила процесс приложения, а приложение не сохранило корректно своё состояние.
вот чтобы не прыгать по приложениям и гадать когда же система его убъёт, чтобы протестить эти сценарии, нужно использовать dka.
Тут выше комменты, что dka не полностью эмулирует убийство процесса, однако, для целей тестирования схранения-восстановления состояния этого достаточно
Да обычно в рамках стандартных сценариев тестирования достаточно dka, к убийствам процесса приходится прибегать чаще, когда пытаешься воспроизвести сложный баг и с dka он не воспроизводится.
Я помню ещё в начале карьеры был у меня такой баг, с dka не воспроизводился, а когда система сама убивала приложение воспроизводится. Вот бы мне тогда рассказали про эти команды и как они работают и различия между dka и убийством системой, а то приходилось для воспроизведения буквально запускать программы, чтобы они вытеснили моё приложение(
да, если приложение напрямую не работает с смс (например при авторизации), то смысла нет тестировать такой сценарий. Единственное всплывающее уведомление может перехватить фокус, но тут уже стандартный жц.
Я переписал, дополнил этот пункт, надеюсь стало лучше. Четче отметил разницу и отметил, что можно проверять тем и другим способом.
Только отмечу, что если цель проверить механизм сохранения/восстановления activity, то убийство процесса, когда приложение в фоне, также приводит к вызову того же кода, так что тут сильных противоречий не вижу.
Наверное даже, если посмотреть, то тестирование с kill предпочтительнее, так как это более реальный сценарий в системе.
Есть dka - вытеснение фоновых activity, и есть лимит фоновых процессов, второе я не упоминал в статье.
Про остальное да, это про процессы, но которые влияют на жц активити. Собственно ниже написал, что в контексте активити всё же лучше использовать dka. Рассматривал именно, что будут вызываться те же события жц, так как мы тестируем код за это отвечающий.
То что между ними есть разница вроде тоже написал)
Возможно не стоило, действительно, остальное писать, но хотелось охватить разные инструменты, которые можно использовать.
сжимаются и с 4090 очень хорошо, но для программиста (не игр и не ии) видяха в целом мощная и не нужна, достаточно встройки
а про ноуты - стандарт индустрии это макбуки, вот и здрасте "обрезано"
сейчас эппл вот iPad выпустила на самом мощном их чипе
а вы продолжате мыслить как "ноут это не системник" - это такой же пк, просто удобнее.
понятно что если мыслить как вы, то и суперкомпьютеры до сих пор занимают целые здания, ну да, только в ту же площадь умещается большая производительность, но такая огромная производительность не всем нужна. Точнее большинству не нужна.
Пример использования AirPods с ИК-камерой: пользователь смотрит видео с помощью Apple Vision Pro и новых AirPods и поворачивает голову, тогда источник звука в этом направлении может быть усилен.
Для этого не нужны специальные наушники, vision pro самостоятельно умеет определять, где вы в пространстве, собственно как и любые другие 3д очки.
не знаю, звучит как "мы считаем тестировщиков тупыми", доставка сборок конечно прикольно и удобно, но больше удивляет, что до этого разработчики были как посредник перекидывая сборки.
с андроид 9+ если речь именно о работе с тегами (потому что это просто Bluetooth) но понятно что не все обновятся и включат, но постепенно это будет внедрятся, плюс apple также поддерживает эту сеть они объявляли о кооперации с гуглом (но тут я не понял возможно ограничились только тем что андроид может сообщать о нежелательных airtag рядом и ios наоборот о тегах от гугла)
Ну почти, да, методы вызываются автоматически, разработчик может не переопределить их и не обрабатывать сценарий сохранения-восстановления.
Но это не очень хорошая практика, такое возможно имеет смысл в играх, где проще с нуля запуститься, но если это обычное приложение, то это, скажем, не самый лучший для пользователя сценарий.
И можно так потерять пользователя, если он часто будет терять место, где он был, а на слабых девайсах убийство процесса довольно частое явление. Да и смена конфигурации не редкость.
Возможно стоит обсудить дополнительно необходимость обработки этих сценариев с продут овнером/менеджером. Если разработчик не захотел это делать ещё не значит, что он прав.
Привет, краткий ответ написан в заключении. Вы проверяте, что ваше приложение корректно сохраняет экран приложения и восстанавливает его - это введённые пользователем данные, открытые попапы, может точка скролла (зависит от бизнес требований) и т.д. всё что нужно сохранить, проверяете, что данные не пропадают и нет крашей.
Если прямо пример: вы ввели очень много текста в мессенджере, вы хотите найти подходящий мем, чтобы прикрепить к сообщению, заходите в браузер, скачивайте и возвращайтесь в мессенджер, а всё, что вы ввели стёрлось. Потому что система убила процесс приложения, а приложение не сохранило корректно своё состояние.
вот чтобы не прыгать по приложениям и гадать когда же система его убъёт, чтобы протестить эти сценарии, нужно использовать dka.
Тут выше комменты, что dka не полностью эмулирует убийство процесса, однако, для целей тестирования схранения-восстановления состояния этого достаточно
Да обычно в рамках стандартных сценариев тестирования достаточно dka, к убийствам процесса приходится прибегать чаще, когда пытаешься воспроизвести сложный баг и с dka он не воспроизводится.
Я помню ещё в начале карьеры был у меня такой баг, с dka не воспроизводился, а когда система сама убивала приложение воспроизводится. Вот бы мне тогда рассказали про эти команды и как они работают и различия между dka и убийством системой, а то приходилось для воспроизведения буквально запускать программы, чтобы они вытеснили моё приложение(
Да, механизмы сложные, всёж согласен, стоит учитывать и то и другое.
Привет, спасибо)
да, если приложение напрямую не работает с смс (например при авторизации), то смысла нет тестировать такой сценарий. Единственное всплывающее уведомление может перехватить фокус, но тут уже стандартный жц.
Я тебя понял,
Я переписал, дополнил этот пункт, надеюсь стало лучше. Четче отметил разницу и отметил, что можно проверять тем и другим способом.
Только отмечу, что если цель проверить механизм сохранения/восстановления activity, то убийство процесса, когда приложение в фоне, также приводит к вызову того же кода, так что тут сильных противоречий не вижу.
Наверное даже, если посмотреть, то тестирование с kill предпочтительнее, так как это более реальный сценарий в системе.
а ещё возможно как-то непрозрачно получилось "как это тестировать" относится именно к убийству процесса системой, а не ко всей статье
Привет, спасибо)
Есть dka - вытеснение фоновых activity, и есть лимит фоновых процессов, второе я не упоминал в статье.
Про остальное да, это про процессы, но которые влияют на жц активити. Собственно ниже написал, что в контексте активити всё же лучше использовать dka. Рассматривал именно, что будут вызываться те же события жц, так как мы тестируем код за это отвечающий.
То что между ними есть разница вроде тоже написал)
Возможно не стоило, действительно, остальное писать, но хотелось охватить разные инструменты, которые можно использовать.
ну статья и не про китайцев
Как по твоему в тишине что-то продавать, если никто не знает, что у тебя есть крутой и дешевый аналог?
Ребята кажется забыли, что надо обязательно тестировать сам процесс обновления на релизной сборке.
сжимаются и с 4090 очень хорошо, но для программиста (не игр и не ии) видяха в целом мощная и не нужна, достаточно встройки
а про ноуты - стандарт индустрии это макбуки, вот и здрасте "обрезано"
сейчас эппл вот iPad выпустила на самом мощном их чипе
а вы продолжате мыслить как "ноут это не системник" - это такой же пк, просто удобнее.
понятно что если мыслить как вы, то и суперкомпьютеры до сих пор занимают целые здания, ну да, только в ту же площадь умещается большая производительность, но такая огромная производительность не всем нужна. Точнее большинству не нужна.
а почему не pwa тогда?
у вк слайды, вродь и так норм, кажется, что вообще на это не обращаешь внимание
мб есть смысл кратко в начале написать, что такое blink и какая там аудитория уже.
очень странно писать такой коммент, даже не попытавшись понять, что это за приложение
Для этого не нужны специальные наушники, vision pro самостоятельно умеет определять, где вы в пространстве, собственно как и любые другие 3д очки.
Если как веб-разработчик, то проект же слабенький, ничего супер хитрого. Если пойдёт в какой-нить маркетинг то мб, вирусные идеи генерить.
не знаю, звучит как "мы считаем тестировщиков тупыми", доставка сборок конечно прикольно и удобно, но больше удивляет, что до этого разработчики были как посредник перекидывая сборки.
с андроид 9+ если речь именно о работе с тегами (потому что это просто Bluetooth) но понятно что не все обновятся и включат, но постепенно это будет внедрятся, плюс apple также поддерживает эту сеть они объявляли о кооперации с гуглом (но тут я не понял возможно ограничились только тем что андроид может сообщать о нежелательных airtag рядом и ios наоборот о тегах от гугла)