Получается, что поле, объявленное как val, поменяло значение в процессе исполнения кода. Почему так? Думаю, что это недочёт компилятора Kotlin, и в будущем, возможно, такое не скомпилируется, но на сегодняшний день всё так, как есть.
Вышло, даже, немного забавнее, похоже и вправду баг.
class TestA {
constructor()
init {
immutableString = "44"
}
val immutableString = "42"
}
class TestB() {
init {
immutableString = "44"
}
val immutableString = "42"
}
TestA компилируется, TestB — нет. Если верить просмотрщику байткода в IDE, байткод генерируется одинаковый.
Может, стоит зарепортить на youtrack.jetbrains.net/issues/KT?
Если же где-то удерживается контекст Activity, то как только Activity уничтожается сборщиком мусора, всё остальное тоже уничтожается.
Кажется, так не бывает.
По-моему, в оригинале говорится о том, что если мы храним объект в контексте Application, то этот объект будет храниться вечно, пока жив процесс (если мы не уберем ссылку на объект руками); если же мы храним объект в контексте Activity, то этот объект будет собран GC в тот момент, когда сама Activity станет недостижимой от GC root, что в рамках приложение должно случаться чаще.
А можете немного подробнее рассказать про автоматизированное тестирование?
1. Кто занимается написанием новых тестов (функциональные тестировщики, или отдельная команда автоматизации, или разработчики)?
2. Кто занимается развитием и поддержкой инфраструктуры для автоматизации?
3. Если в других командах (iOS, Web) тоже есть автоматизация тестирования, стараетесь ли унифицировать (в рамках возможного) с ними наборы покрытых тестами тест-кейсов, или у каждой команды свои наборы сценариев?
4. Автотесты запускаются только на одном из этапов жизненного цикла релиза (например, при сборке свежего билда), или чаще?
5. Тестировщики запускают тесты самостоятельно, или они запускаются автоматом на определенных этапах жизни задачи/релиза?
Попробовал на своем Desire — либо не дотягиваюсь до противоположного ребра так, что бы устойчиво держать телефон, либо возвышением большого пальца делаю ложные нажатия на экран. Иметь короткие пальцы — неудобно.
У меня раньше был Rocket Player (если не ошибаюсь), потом что-то там произошло, и я поставил себе MX Player. Вполне приятный, mkv играет. Правда, на работу с субтитрами я его не проверял — было видео только с хардсабами, но, кажется, внешние субтитры он умеет подхватывать.
Когда держал его в магазине, тоже таким образом пальца хватало дотянуться почти до противоположного угла. Минус такого хвата только один — если как-то тряхнёт (например, в трамвае) — телефон может выбить из рук.
Хотя, все равно, чем больше пальцы, тем лучше.
А чем так плох HTC? Хожу три года с Desire, и единственной причиной его поменять вижу просто физическое отсутствие возможности поставить на него свежий (и при этом нормально работающий) Android. Ну и мизерное хранилище и морока с app2sd.
Единственное, что удерживает меня от хотения этого телефона — это качество его сборки.
Я думал, на известном форуме люди утрируют о щелях и прочих огрехах в сборке устройства, но когда сам пощупал аппарат в двух разных магазинах — как-то сразу расхотелось его покупать. И это печально, потому что устройство вышло очень достойное.
Есть несколько замечательных книг М.В. Ульянова, там в т.ч. затрагивается и тема оценки вычислительной сложности алгоритмов.
В частности, там описан метод получения оценки временных затрат на выполнение алгоритма от размера данных. Были весьма забавные результаты, вплоть до почти 100%-го попадания прогнозируемого времени выполнения в реальное :)
Было очень круто. Спасибо!
Вышло, даже, немного забавнее, похоже и вправду баг.
TestA компилируется, TestB — нет. Если верить просмотрщику байткода в IDE, байткод генерируется одинаковый.
Может, стоит зарепортить на youtrack.jetbrains.net/issues/KT?
Кажется, так не бывает.
По-моему, в оригинале говорится о том, что если мы храним объект в контексте
Application, то этот объект будет храниться вечно, пока жив процесс (если мы не уберем ссылку на объект руками); если же мы храним объект в контекстеActivity, то этот объект будет собран GC в тот момент, когда самаActivityстанет недостижимой от GC root, что в рамках приложение должно случаться чаще.1. Кто занимается написанием новых тестов (функциональные тестировщики, или отдельная команда автоматизации, или разработчики)?
2. Кто занимается развитием и поддержкой инфраструктуры для автоматизации?
3. Если в других командах (iOS, Web) тоже есть автоматизация тестирования, стараетесь ли унифицировать (в рамках возможного) с ними наборы покрытых тестами тест-кейсов, или у каждой команды свои наборы сценариев?
4. Автотесты запускаются только на одном из этапов жизненного цикла релиза (например, при сборке свежего билда), или чаще?
5. Тестировщики запускают тесты самостоятельно, или они запускаются автоматом на определенных этапах жизни задачи/релиза?
Хотя, все равно, чем больше пальцы, тем лучше.
Я думал, на известном форуме люди утрируют о щелях и прочих огрехах в сборке устройства, но когда сам пощупал аппарат в двух разных магазинах — как-то сразу расхотелось его покупать. И это печально, потому что устройство вышло очень достойное.
В частности, там описан метод получения оценки временных затрат на выполнение алгоритма от размера данных. Были весьма забавные результаты, вплоть до почти 100%-го попадания прогнозируемого времени выполнения в реальное :)