в 2016 странно это не знать

Кстати, зайди и почитай, что Котлин генерирует

читаю

"и чо"

я думаю там генериться не хуже моего говнокода )

архитектура компов не менялась уже лет 30, почему должны меняться способы разработки

Ну это как посмотреть

Там генерится безопасный код

архитектура компов не менялась уже лет 30, почему должны меняться способы разработки

это как? мобильных 30 лет назад не было

Но при этом не всегда достаточно быстрый

Вьюшки я бы точно не стал на нём писать

Я даже компилятор Котлина для этого патчил когда-то

это как? мобильных 30 лет назад не было

но принцип-то тот же, разница только в энергопотреблении копмонентов, их размерах и других устройствах ввода

не правда, все время растут требования к точности, к скорости и тд, отсюда надо искать новые подходы разработки, менять, пробовать, обновлять

ага, а ещё процессоры становятся мощнее, и для того, чтобы это компенсировать, мы используем фреймворки

когда писали под одно ядро - все ок, потом под 10 - уже новое, но ок, теперь по 100000000 - думаешь старые варианты работают также?

когда писали под одно ядро - все ок, потом под 10 - уже новое, но ок, теперь по 100000000 - думаешь старые варианты работают также?

если тебе не нужна параллельность, то на ядра пофиг

синхронизация, тот же ВК, биг дата, он невероятно круто работает

ага, а ещё процессоры становятся мощнее, и для того, чтобы это компенсировать, мы используем фреймворки

вот этого не понял

в том смысле, что тратим процессорное время на всякую лишнюю хероту, без которой можно было бы обойтись

например, на пересоздание активити при повороте экрана

или на dependency injection

например, на пересоздание активити при повороте экрана

Ну раз Гугл так сделал, и еще не поменял, значит есть на это причины

http://xkcd.ru/i/664_v1.png

неужели тебе не интересно выяснить, какие именно там причины?

я вот так вот не могу принять на веру, мне всегда надо докопаться до истины

суть ооп не в этом

я вот так вот не могу принять на веру, мне всегда надо докопаться до истины

Ну, надо или идти в Гугл или копать в сорсах

неужели тебе не интересно выяснить, какие именно там причины?

так разве не то, что в ландшафтной ориентации может быть другой layout?

Ну раз Гугл так сделал, и еще не поменял, значит есть на это причины

то есть погоди, ты сохраняешь и восстанавливаешь состояния только потому что гугл так сказал??

так разве не то, что в ландшафтной ориентации может быть другой layout?

ну так таких случаев один на миллион

а если гугл скажет с крыши спрыгнуть и вот это вот всё

ЛОЛ

тоже Григорий и тоже дело говорит ??

ну так таких случаев один на миллион

а никто и не спорит =)

а никто и не спорит =)

дааааа, но зачем все пересоздают активити тогда, когда это не требуется? :)

ну его фреймворк пересоздает вообще-то. а нам приходится искать выход из этого дерьма

=)

вы пишете свои велосипеды, которые экран на 90 градусов вертит?

вот в ВК активити аудиоплеера пересоздаётся при повороте, потому что там действительно сильно разный лэяут, но она достаточно лёгкая

ну его фреймворк пересоздает вообще-то. а нам приходится искать выход из этого дерьма

выход есть, одна строчка в манифесте

вы пишете свои велосипеды, которые экран на 90 градусов вертит?

у тебя часто меняются лэйауты/ресурсы в зависимости от ориентации?

вот и ответ

вот да

повторю, в приложении ВК таких экранов аж целый один из, наверное, сотни

бесспорно такие кейсы есть, но они не повсеместно

выход есть, одна строчка в манифесте

это тебя не защищает от поворота и как правильно сказал @punksta не позволяет таки сделать поворот экрана

это тебя не защищает от поворота и как правильно сказал @punksta не позволяет таки сделать поворот экрана

в смысле блин не защищает, активити поворачивается, она просто РЕСАЙЗИТСЯ

так разве не то, что в ландшафтной ориентации может быть другой layout?

Пусть себе перезапускают лайфсайкл

прикиньте, активити можно ресайзить без пересоздания!

breaking news

филосовский спор )

Но зачем инстанс-то гробить

хорошо, ок. но где гарантия что она не пересоздастся? есть куча случаев когда это может произойти

прикиньте, активити можно ресайзить без пересоздания!

тише-тише, сейчас пацаны поймут, что оказывается можно обработать изменение конфигурации так как хочется!

можно на них забить - согласен. но кто-то просто не хочет это делать

Мы Гриши, и мы не любим делать лишнее

можно на них забить - согласен. но кто-то просто не хочет это делать

казалось бы, не пересоздавать активити (и не сохранять-восстанавливать состояние) проще, чем это делать

казалось бы, не пересоздавать активити (и не сохранять-восстанавливать состояние) проще, чем это делать

ну так не все хотят чтобы приложение теряло стейт каждый раз когда андроид прибил активити в фоне из-за нехватки памяти

можно на них забить - согласен. но кто-то просто не хочет это делать

особенно те ребята, у которых нет лэйаутов и ресурсов под отличные от дефолтной конфигурации.

ну так не все хотят чтобы приложение теряло стейт каждый раз когда андроид прибил активити в фоне из-за нехватки памяти

ну так интент тебе всё равно потом дадут тот же, которым запускали, а что ещё надо?

а стейт то ты не сохранил

а если сохранил и умеешь восстанавливать, то код вообще одинаковый в обоих случаях )

далеко не всегда стейт можно сложить в bundle

ща дойдем до onRetainNonConfigurationInstance?

далеко не всегда стейт можно сложить в bundle

ну это сильно частный случай

если у меня там куча каких-нибудь сложных объектов с объектами внутри с объектами внутри с объектами внутри с объектами внутри, то это нельзя просто так взять ? и "сохранить стейт"

пример из реальной жизни — объект поста в том же ВК

ERROR: S client not available

о, видимо дошли

можно, просто геморно

А вот кстати, расскажите, что вы используете для передачи результата асинхронной операции после уничтожения активити

Какие вообще есть решения?

У вас

пример из реальной жизни — объект поста в том же ВК

(хотя именно он умеет себя сериализовать, на самом деле)

пример из реальной жизни — объект поста в том же ВК

и что в нем такого сложного?

Только без лоадера, он для БД

Только без лоадера, он для БД

например rx это умеет из коробки через оператор cache

А вот кстати, расскажите, что вы используете для передачи результата асинхронной операции после уничтожения активити

можно делать бродкаст, желательно на всю систему

А, то есть кэш, ок

можно делать бродкаст, желательно на всю систему

Оверхэд

с другой стороны, если активити уничтожена и пересоздана, то откуда она будет знать, что ей вообще когда-то в прошлой жизни был нужен этот результат? =)

Много кода

Оверхэд

это была шутка

А, то есть кэш, ок

если это тупо данные, то можно просто их положить в бд и потом прочитать, когда надо. если это объекты в памяти, то rx очень легко решает

А там нет проблем с тем, что лямбды активити старую держат?

если это тупо данные, то можно просто их положить в бд и потом прочитать, когда надо. если это объекты в памяти, то rx очень легко решает

Я понял уже

смотря как напишешь )

придержать активити дело не хитрое ))

А как надо? Любая лямбда же будет ссылку на активити держать

ну их gc и убьет вмести

Вы их в статике пишете, что ли? Или там ссылки слабые?

некорневые циклы очищаются

если это тупо данные, то можно просто их положить в бд и потом прочитать, когда надо. если это объекты в памяти, то rx очень легко решает

ещё я слышал, что некоторые так работают с апи: 1. сделать запрос 2. распарсить ответ 3. положить результат в базу (!) 4. прочитать из базы обратно (!!) 5. отобразить в интерфейсе

очевидно же

а, да, и для отображения в интерфейсе ещё обязательно прокинуть курсор от базы в активити/фрагмент и читать из него прямо в момент биндинга данных в вьюху ??

Ну так целый адаптер есть

ну их gc и убьет вмести

не убьет, если у тебя обзервабл во вне активити сохранен

ну кек, не надо так)

А как надо? Любая лямбда же будет ссылку на активити держать

ну не делай лямбду )

ну кек, не надо так)

а как получать потом кэш будешь?