нет-нет, это понятно. Речь о том, что по эджайлу юзер стори/таск не может быть длиннее спринта; по окончании спринта все бранчи д.б. слиты в дев. Т.е., указанная проблема с долгими бранчами просто отсутствует
Если у вас одна фича == одной юзер стори, и она длиннее спринта, это прямое нарушение принципов А.
Любое изменение кода может нести в себе импакт.
Ну так надо стремиться чтоб таких ситуаций было поменьше. Они ж все про одно и то же — сильно связанный код, изменение вместо добавления и так далее.
А то будет, как один мой коллега в возрасте говорит — «Программирование — это тяжелый труд»
Ну да, с его классами по 5 тыс строк и функциями по 600-1000 строк это безусловно тяжелый труд
есть такая штука — git flow
Если у вас scrum/agile и прочее, то как у вас таск/юзер стори может быть длиннее спринта (так, что нужно долго держать бранч)?
ну и если нельзя добавить фичу, не внеся опасных изменений в остальные куски кода — это не очень хороший код.
А можно ссылочку, где говорится, что ActivityManager держит инстансы для убитых процессов? Или шаги, которые надо сделать, чтоб получить в тестовом приложении подобное поведение. Сиречь, запустить приложение, убить процесс, запустить его снова и получить валидный savedInstanceState
Я не выдумываю эти проблемы, я, повторюсь, смотрю на баги, которые идут от клиентов. При помощи флага они отлично отлаживаются. Т.е., у клиентов возникают ситуации, когда активити уходит в destroy, и потом восстанавливается в том же процессе из saved instance state.
Подозреваю, подобное можно получить, например, создав активити с 2-мя лейаутами, для портрета и ландскейпа, и потом просто поворачивать телефон. Сам не пробовал, да:)
UPD. Ага, почитал. Действительно, система не убивает отдельные активитиз из-за недостатка памяти. Спасибо за наводку
Тем не менее, активити таки может быть уничтожена, и потом восстановлена, так что, вуходит, от savedInstance все равно никуда не деться
?
У меня есть баг в трекере. Запускаем отладку, с включенным флагом. Делаем, как я описал выше. Активити уходит в onDestroy, процесс остается в памяти, в отладчике это прекрасно видно. Какие логи я неправильно интерпретирую?
Кроме того, если процесс прибивается, где хранится savedInstance?
Мы уже столько багов словили на этом, словами не передать:)
Так что вполне воспроизводится, по крайней мере клиентами. Но у нас и приложение тяжелое в плане использования памяти, так что может поэтому.
Ну и к вопросу о статье — я, имхо, не очень понимаю, зачем хранить состояние приложения, если прибился сам процесс. Разве что какие-то уже введенные и сохраненные данные (сохраненные по ходу, или по кнопке save, грубо говоря)
В этом случае ни о каких parcelable и речи не идет, это в базу/облако/етц
Начиная с 4.0 (по-моему), Android никогда не убивает Activity по одиночку, только вместе с процессом целиком.
Ну так сделайте простой тест
1. Включите флаг,
2. запустите приложение на 8ке, например,
4. поставьте break на onDestroy, и
5. попереключайтесь между другими запущенными приложениями.
Выпадете в onDestroy, а приложение, вот сюрприз-то, останется в памяти
Если душа на работе нет, можно обтираться влажным полотенцем. Вернее, даже нужно — в течение рабочего дня оставшийся на коже пот (а он останется, несмотря на спорт. одежду) начнет вонять, и лучше его убрать.
Я раньше так и делал (до работы было 23 км, потел так или иначе), очень приятно получалось.
А сейчас на работе есть душ:)
А почему нет? Единственно верной стратегии нету; жава, к примеру, вернет нул, с++ — добавит элемент с таким ключом и дефолтным value и вернет его, с# выбросит исключение
Иными словами, не очень понятно, почему отсутствие определенного ключа в мапе — это исключение, ведь ваш мап возвращает значение — нулл, и его надо как-то обработать.
дык, использование обьекта из java кода с оператором!!! — это единственный случай, когда выбрасывается такое исключение, насколько я понимаю.
Во всех остальных будет либо IllegalCastException, либо ничего не будет.
Это далеко не только мой личный опыт, это помогает в ассимиляции, ассимиляция нужна, если вы живете в другой стране.
Это довольно внятно, на мой взгляд, высказано в дискуссии. Под «живете» я имею в виду постоянное проживание, минимум 2/3 каждого года. Я, собственно, вообще не понимаю, с чем тут спорить, это очевидные вещи
Судя же по вашим ответам, вы не иммигрант, и не живете в другой стране постоянно. И тогда мне не совсем понятно, как вы можете делать какие-либо выводы.
Это вы явно с горяча ляпнули — не подумав (точнее прочитав по быстрому некое определение и посчитав, что оно данное господом раз и навсегда).
Ассимиля́ция (лат. assimilatio — уподобление) в социологии и этнографии — потеря одной частью социума (или целым этносом) своих отличительных черт и их замена на позаимствованные у другой части (другого этноса). В целом, это этнокультурный сдвиг в самосознании[1] определённой социальной группы, ранее представлявшей иную общность в плане языка, религии или культуры.
При чем тут бог? Это вполне обычное социологическое определение
Ключевое слово здесь — придуманы — для солидности упоминается собственный опыт и какой-то абстрактный опыт других иммигрантов
Не придуманы, испытаны на себе и других
Опыт не абстрактный, а совершенно конкретный.
Кроме того, следует определиться с понятием иммигрант — в моем понимании, это человек постоянно и б0льшую часть своего времени проживающий в другой стране.
Но вот беда — опыт «других иммигрантов» совершенно определенно противоречит моему личному опыту (в общей сложности я живу на чужбите с 1999-го года)
1. У понятия «ассимиляция» вполне определенное значение, особых разночтений не допускает.
2. Инструкции придуманы на собственном опыте и опыте других иммигрантов — как положительном, так и отрицательном.
Переехать в другую страну и не пытаться понять, кто они и что они — по-моему, глупость. В смысле, с точки зрения собственного душевного здоровья. Это я как иммигрант и эксперт мирового класса говорю. Путешествовать, ездить по стране — обязательно надо. Это местным не надо, они и так все знают.
А в штатах, да и в сев. америке вообще с общественным транспортом очень так себе, без машины никуда.
вообще, прикольно, та же жава когда-то создавалась именно с прицелом на мультиплатформенность за счет подмены системных вызовов вызовами к виртуальной машине. И еще тогда мы знали, какой это гемор, компилять нативный С++ под разные платформы, даже безо всякого UI.
А тут, бац, оказывается, будущее мультиплатформенности — это именно нативные приложения.
Очень странно. У меня такое ощущение, что менеджмент (самый разнообразный) никак не может расстаться с мыслью, что мультиплатформенные приложения — это миф
нет-нет, это понятно. Речь о том, что по эджайлу юзер стори/таск не может быть длиннее спринта; по окончании спринта все бранчи д.б. слиты в дев. Т.е., указанная проблема с долгими бранчами просто отсутствует
Если у вас одна фича == одной юзер стори, и она длиннее спринта, это прямое нарушение принципов А.
Ну так надо стремиться чтоб таких ситуаций было поменьше. Они ж все про одно и то же — сильно связанный код, изменение вместо добавления и так далее.
А то будет, как один мой коллега в возрасте говорит — «Программирование — это тяжелый труд»
Ну да, с его классами по 5 тыс строк и функциями по 600-1000 строк это безусловно тяжелый труд
Если у вас scrum/agile и прочее, то как у вас таск/юзер стори может быть длиннее спринта (так, что нужно долго держать бранч)?
ну и если нельзя добавить фичу, не внеся опасных изменений в остальные куски кода — это не очень хороший код.
Наверное, good.getPrice()*amount, не?
Но вообще, боже мой, GRASP паттерны! Я их еще в 2001м году учил:) Хуже они не стали, конечно.
Я утверждаю простую вещь — система может прибить активити без убиения процесса. Собственно, об этом в activity lifecycle написано, секция onDestroy:
developer.android.com/guide/components/activities/activity-lifecycle#ondestroy
И для этих случаях ноленс воленс нужно сохранять состояние.
Я не выдумываю эти проблемы, я, повторюсь, смотрю на баги, которые идут от клиентов. При помощи флага они отлично отлаживаются. Т.е., у клиентов возникают ситуации, когда активити уходит в destroy, и потом восстанавливается в том же процессе из saved instance state.
Подозреваю, подобное можно получить, например, создав активити с 2-мя лейаутами, для портрета и ландскейпа, и потом просто поворачивать телефон. Сам не пробовал, да:)
UPD. Ага, почитал. Действительно, система не убивает отдельные активитиз из-за недостатка памяти. Спасибо за наводку
Тем не менее, активити таки может быть уничтожена, и потом восстановлена, так что, вуходит, от savedInstance все равно никуда не деться
У меня есть баг в трекере. Запускаем отладку, с включенным флагом. Делаем, как я описал выше. Активити уходит в onDestroy, процесс остается в памяти, в отладчике это прекрасно видно. Какие логи я неправильно интерпретирую?
Кроме того, если процесс прибивается, где хранится savedInstance?
Так что вполне воспроизводится, по крайней мере клиентами. Но у нас и приложение тяжелое в плане использования памяти, так что может поэтому.
Ну и к вопросу о статье — я, имхо, не очень понимаю, зачем хранить состояние приложения, если прибился сам процесс. Разве что какие-то уже введенные и сохраненные данные (сохраненные по ходу, или по кнопке save, грубо говоря)
В этом случае ни о каких parcelable и речи не идет, это в базу/облако/етц
Ну так сделайте простой тест
1. Включите флаг,
2. запустите приложение на 8ке, например,
4. поставьте break на onDestroy, и
5. попереключайтесь между другими запущенными приложениями.
Выпадете в onDestroy, а приложение, вот сюрприз-то, останется в памяти
Я раньше так и делал (до работы было 23 км, потел так или иначе), очень приятно получалось.
А сейчас на работе есть душ:)
Иными словами, не очень понятно, почему отсутствие определенного ключа в мапе — это исключение, ведь ваш мап возвращает значение — нулл, и его надо как-то обработать.
Во всех остальных будет либо IllegalCastException, либо ничего не будет.
А как иначе жить в обществе?
Это довольно внятно, на мой взгляд, высказано в дискуссии. Под «живете» я имею в виду постоянное проживание, минимум 2/3 каждого года. Я, собственно, вообще не понимаю, с чем тут спорить, это очевидные вещи
Судя же по вашим ответам, вы не иммигрант, и не живете в другой стране постоянно. И тогда мне не совсем понятно, как вы можете делать какие-либо выводы.
Ассимиля́ция (лат. assimilatio — уподобление) в социологии и этнографии — потеря одной частью социума (или целым этносом) своих отличительных черт и их замена на позаимствованные у другой части (другого этноса). В целом, это этнокультурный сдвиг в самосознании[1] определённой социальной группы, ранее представлявшей иную общность в плане языка, религии или культуры.
При чем тут бог? Это вполне обычное социологическое определение
Не придуманы, испытаны на себе и других
Опыт не абстрактный, а совершенно конкретный.
Кроме того, следует определиться с понятием иммигрант — в моем понимании, это человек постоянно и б0льшую часть своего времени проживающий в другой стране.
И где же вы живете с 1999 года, если не секрет?
2. Инструкции придуманы на собственном опыте и опыте других иммигрантов — как положительном, так и отрицательном.
Переехать в другую страну и не пытаться понять, кто они и что они — по-моему, глупость. В смысле, с точки зрения собственного душевного здоровья. Это я как иммигрант и эксперт мирового класса говорю. Путешествовать, ездить по стране — обязательно надо. Это местным не надо, они и так все знают.
А в штатах, да и в сев. америке вообще с общественным транспортом очень так себе, без машины никуда.
А тут, бац, оказывается, будущее мультиплатформенности — это именно нативные приложения.
Очень странно. У меня такое ощущение, что менеджмент (самый разнообразный) никак не может расстаться с мыслью, что мультиплатформенные приложения — это миф
Да вывод-то простой — звездное небо над головой есть, а морального закона внутри — нету