Еще один момент хотелось бы отметить, на мой взгляд он важен: сохранение состояния активити после ее убийства системой - это не сценарий по умолчанию, а ситуация, которую должен создать разработчик ручками (вызвать метод сохранения состояния), то есть сохранения может и не происходить и это не будет багом. На нашем проекте это не предусмотрено и на холодную запускается главный экран.
очень хорошая статья, спасибо. Подобные статьи с глубоким погружением в логику работы ОС очень редки и оттого ценны. Когда сам начал заниматься мобильным тестированием, то столкнулся с массой чек-листов по особенностям тестирования мобилок где было много сомнительных проверок, без технического обоснования их необходимости. Это же было (а может и есть) на некотоых популярных курсах. Начал копать эту тему и оказалось, что большинство из проверок на самом деле не нужны. Это касается всяких там "проверьте, что при получении смс ваше приложение не легло".
абсолютно согласен, если нормально разговаривать, а не наезжать друг на друга, то все почти всегда решаемо, а протупить может каждый - и тестер, и разраб.
понравился кейс с использованием map remote, раньше думал, что бесполезная штука без реального применения, а ситуация описанная в статье вполне рабочая, забираю себе в копилку.
очень сомнительная статья. С самого начала автор делает заявление, что за 10 лет ни разу не ошибся, а это уже звоночек. В психологии в разных тестах (например, тест Айзенка о типе темперамента) есть вопросы, которые проверяют честность респондента. Один из них звучит примерно так: "ошибаетесь ли вы?". И если человек отвечает, что нет, то это однозначно вранье, потому что так просто не бывает. Это как если тестировщик скажет, что за 10 лет работы не пропустил ни одного бага.
Собственно, остальная статья лишь подтвердила опасения. Изначально автор подходит к кандидатам как к лжецам, которые врут в резюме. Эта проблема отчасти существует, но не носит массовый характер, при этом она характерна для молодых специалистов без опыта. Для мидлов и синьоров эта ситуация если и бывает, то редко. Тем не менее у автора статьи изначально была обозначена проблематика (см. картинку лошади) - в резюме кандидат герой, на собесе бестолочь. В такой парадигме предвзятости и агрессии автора к кандидатам, любому специалисту, в том числе тому кто действительно профи и в резюме все ок, будет некомфортно общаться.
На протяжении всей статьи красной линией идет не желание найти хорошего кандидата, а отсеить плохих, везде плохие, ух какие плохие, надо из отсеять. Вспоминается Шариков из Собачьего сердца: "мы их душили, душили...".
Если говорить о пользе статьи, то советы соискателям либо банальны: "Пишите так, чтобы вы могли аргументировать написанное", либо спорные, например, про то, что надо писать достижения, которые якобы скажут что-то о профессионализме или совсем уж странный совет: "В резюме должен быть фактор недосказанности." - прямо как в девушке должна быть загадка, так и в резюме нельзя раскрывать все, а то сложно будет собеседующему придумывать вам вопросы. Не пишите все, облегчите жизнь собеседующему. А то, что такой подход недописанного резюме может кого-то раздражать как раз за то, что у представителя работодателя неполная информация о ваших навыках, автор статьи разумеется не учитывает.
Как всегда полезно, в закладки)
Просто шикарная статья, спасибо большое за такой развернутый туториал)
Еще один момент хотелось бы отметить, на мой взгляд он важен: сохранение состояния активити после ее убийства системой - это не сценарий по умолчанию, а ситуация, которую должен создать разработчик ручками (вызвать метод сохранения состояния), то есть сохранения может и не происходить и это не будет багом. На нашем проекте это не предусмотрено и на холодную запускается главный экран.
Да, пожалуй она и правда хуже.
У меня одного пригорело от первых двух видосов?) спасибо за статью, довольно познавательно)
очень хорошая статья, спасибо. Подобные статьи с глубоким погружением в логику работы ОС очень редки и оттого ценны. Когда сам начал заниматься мобильным тестированием, то столкнулся с массой чек-листов по особенностям тестирования мобилок где было много сомнительных проверок, без технического обоснования их необходимости. Это же было (а может и есть) на некотоых популярных курсах. Начал копать эту тему и оказалось, что большинство из проверок на самом деле не нужны. Это касается всяких там "проверьте, что при получении смс ваше приложение не легло".
хорошая статья, спасибо) актуально для относительно нового интерфейса logcat
весь цикл статей отличный, прочел/протыкал все три, спасибо!
абсолютно согласен, если нормально разговаривать, а не наезжать друг на друга, то все почти всегда решаемо, а протупить может каждый - и тестер, и разраб.
хорошая статья, новичкам зайдет. Все грамотно расписано, спасибо.
классный подход к тестированию качества поиска. Редкая, по-настоящему стоящая статья без банальностей, общих фраз, с конкретным алгоритмом. Спасибо
в очередной раз хорошая статья - коротко и по делу. Спасибо, жду материал про удаленный вызов процедур)
хорошая статья с уклоном прежде всего в тестирование, что особенно важно для тестировщиков, другие статьи по этой теме больше про технологию.
Отличная статья, спасибо. Одну цитату отправил в рабочий чат)
понравился кейс с использованием map remote, раньше думал, что бесполезная штука без реального применения, а ситуация описанная в статье вполне рабочая, забираю себе в копилку.
Написал вам личное сообщение по этому комментарию, посмотрите пожалуйста
кое-что забрал себе. Спасибо за подборку)
очень сомнительная статья. С самого начала автор делает заявление, что за 10 лет ни разу не ошибся, а это уже звоночек. В психологии в разных тестах (например, тест Айзенка о типе темперамента) есть вопросы, которые проверяют честность респондента. Один из них звучит примерно так: "ошибаетесь ли вы?". И если человек отвечает, что нет, то это однозначно вранье, потому что так просто не бывает. Это как если тестировщик скажет, что за 10 лет работы не пропустил ни одного бага.
Собственно, остальная статья лишь подтвердила опасения. Изначально автор подходит к кандидатам как к лжецам, которые врут в резюме. Эта проблема отчасти существует, но не носит массовый характер, при этом она характерна для молодых специалистов без опыта. Для мидлов и синьоров эта ситуация если и бывает, то редко. Тем не менее у автора статьи изначально была обозначена проблематика (см. картинку лошади) - в резюме кандидат герой, на собесе бестолочь. В такой парадигме предвзятости и агрессии автора к кандидатам, любому специалисту, в том числе тому кто действительно профи и в резюме все ок, будет некомфортно общаться.
На протяжении всей статьи красной линией идет не желание найти хорошего кандидата, а отсеить плохих, везде плохие, ух какие плохие, надо из отсеять. Вспоминается Шариков из Собачьего сердца: "мы их душили, душили...".
Если говорить о пользе статьи, то советы соискателям либо банальны: "Пишите так, чтобы вы могли аргументировать написанное", либо спорные, например, про то, что надо писать достижения, которые якобы скажут что-то о профессионализме или совсем уж странный совет: "В резюме должен быть фактор недосказанности." - прямо как в девушке должна быть загадка, так и в резюме нельзя раскрывать все, а то сложно будет собеседующему придумывать вам вопросы. Не пишите все, облегчите жизнь собеседующему. А то, что такой подход недописанного резюме может кого-то раздражать как раз за то, что у представителя работодателя неполная информация о ваших навыках, автор статьи разумеется не учитывает.
полезная статья, спасибо.
прямо остросюжетный триллер) спасибо за статью, познавательно)