Огонь

тут, говорят, весело у вас

очень

вообще огонь, располагайся

хипстеры против олдскульщиков

Весь чат против Гриши

тут, говорят, весело у вас

Здаров, да очень.

Гриша пока что всухую ведет

Насчёт reified generics: если очень кратко – то для того, чтобы писать getComponent<MyComponent> вместо getComponent(MyComponent::class.java). А ещё дженерики, в отличие от параметров, могут инфириться, поэтому <...> вообще иногда можно не писать

гриша красавчик, вы че. активити пересоздавать тупейшая вещь

Там ещё и оверхэд есть

гриша красавчик, вы че. активити пересоздавать тупейшая вещь

Ну вот это вечный спор Андроидеров

можно про это книгу писать как придумать себе проблему и потом героически ее решать ретеинфрагментами

Насчёт reified generics: если очень кратко – то для того, чтобы писать getComponent<MyComponent> вместо getComponent(MyComponent::class.java). А ещё дженерики, в отличие от параметров, могут инфириться, поэтому <...> вообще иногда можно не писать

поведай плз про оверхед про который говорит @bvitaliyg . есть или нет и на сколько по твоему большой?

Насчёт reified generics: если очень кратко – то для того, чтобы писать getComponent<MyComponent> вместо getComponent(MyComponent::class.java). А ещё дженерики, в отличие от параметров, могут инфириться, поэтому <...> вообще иногда можно не писать

можешь кратко объяснить, почему функции должны быть именно inline?

А обрабатывать все возможные смены конфига утомительно.

Мы обсуждали, есть, небольшой. Ян считает, что это экономия на спичках

И да, местами Котлин быстрее джавы

можно про это книгу писать как придумать себе проблему и потом героически ее решать ретеинфрагментами

привет! :) ну вообще речь больше не о том, зачем гугл вообще придумал их пересоздавать по каждому чиху и нужно ли это. а в том, нужно или не нужно сохранять и востанавливать стейт активити. потому как прибить ее могут просто из-за нехватки памяти

если функция принемает объект, то можно сгенерить такую-же функцию, но условно нулевым параметром передавать Class

поведай плз про оверхед про который говорит @bvitaliyg . есть или нет и на сколько по твоему большой?

причем именно в контексте андроида, а не языка в целом

Оверхед, про который говорит @bvitaliyg, заключается в том, что мы в некоторые места вставляем ассёршны для того, чтобы проверить, не вернулось ли из Java нам null-значение туда, где должен быть non-null. Часть таких ассёршнов отключается, часть нет. С моей точки зрения, вред от этого минимален, @bvitaliyg так и смог представить мне никаких доказательств того, что код становится медленее на сколько-нибудь ощутимую величину :) Зато в стектрейсах становятся гораздо более осмысленными

к reified... Мне бывает удобно when(T::class) писать

Плюс у вас ещё везде итераторы в stdlib

Оверхед, про который говорит @bvitaliyg, заключается в том, что мы в некоторые места вставляем ассёршны для того, чтобы проверить, не вернулось ли из Java нам null-значение туда, где должен быть non-null. Часть таких ассёршнов отключается, часть нет. С моей точки зрения, вред от этого минимален, @bvitaliyg так и смог представить мне никаких доказательств того, что код становится медленее на сколько-нибудь ощутимую величину :) Зато в стектрейсах становятся гораздо более осмысленными

ок, спасибо )

Если говорить про андроид, то с какой-то там махровой версии вроде 2.3 dalvik умеет инлайнить простые методы, которые мы вызываем для чеков

Оверхед, про который говорит @bvitaliyg, заключается в том, что мы в некоторые места вставляем ассёршны для того, чтобы проверить, не вернулось ли из Java нам null-значение туда, где должен быть non-null. Часть таких ассёршнов отключается, часть нет. С моей точки зрения, вред от этого минимален, @bvitaliyg так и смог представить мне никаких доказательств того, что код становится медленее на сколько-нибудь ощутимую величину :) Зато в стектрейсах становятся гораздо более осмысленными

А как ты предлагаешь проверять частоту вызова GC и время его работы?

А причём тут GC вообще?

А как ты предлагаешь проверять частоту вызова GC и время его работы?

в андроиде в логах можно посмотреть

Про inline-функции - там всё просто, не создаётся отдельного фрейма в стеке вызовов функций. А если в inline-функцию передаётся лямбда, то объект для лямбды не создаётся, а её код инлайнится туда же, куда и сама функция

Ну это все таки не самый точный инструмент для тестов

Ну это все таки не самый точный инструмент для тестов

согласен, но хоть какой-то )

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

Про inline-функции - там всё просто, не создаётся отдельного фрейма в стеке вызовов функций. А если в inline-функцию передаётся лямбда, то объект для лямбды не создаётся, а её код инлайнится туда же, куда и сама функция

так а что мешало ложить функцию в стек вызовов?

Э-э, собственно, ничего не мешало, это нормальный режим работы jvm

Если про память говорить, мне кажется куда больше оверхеда в коллекциях, которые юзаются в ядре и всяких support library

А причём тут GC вообще?

Итераторы + мне интересно самому посмотреть, что там будет с константными обьектами строк на реальной вм

Э-э, собственно, ничего не мешало, это нормальный режим работы jvm

соре, все равно не понимаю, почему функции с reified не могут быть не inline

На самом деле, в некоторых планах относительной дальности есть поддержка InlineOnly-функций (точнее, поддержка уже есть, пользы пока нет). Суть в том, что если все usages функции заинлайнены, то эта функция в jar просто не нужна. Этим можно сэкономить количество методов в APK

Потому что как иначе передать функции типовой параметр?

в скале это как-то решили?

Насколько я понимаю, решили очень не до конца

А скоро релиз котлин 1.1?)

И их нельзя нормально поддержать без ощутимого overhead в рантайме, поэтому они у нас доступны только в inline-функциях, где тип явно известен

Весь чат против Гриши

двух Гриш =)

просто второй более тихий

✊

В этом году - маловероятно. Но feature freeze будет уже относительно скоро

делать из T => Unit функцию Class<T> => T=> Unit, когда это возможно.

когда аргумент именно передается...

В этом году - маловероятно. Но feature freeze будет уже относительно скоро

Будут ли корутины на андроид?

Да, их можно добавлять незаметно от пользователя в список параметров функции. Пока этого нет

В каком-то виде обязательно будут

inline fun <reified T> f(t: T) { helperF(t) } fun <T> helperF(t: T, slazz: KClass<*> = t::class) { }

inline fun лол

в вашем котлине слишком много всего смешного

в этом чате тоже)

привет! :) ну вообще речь больше не о том, зачем гугл вообще придумал их пересоздавать по каждому чиху и нужно ли это. а в том, нужно или не нужно сохранять и востанавливать стейт активити. потому как прибить ее могут просто из-за нехватки памяти

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

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

ну вот @grishka лоббировал, что это сложно и не нужно. просто отменяем пересоздание активити при смене конфигурации и дело с концом. я так его понял

гриша, а как у вас в вк состояние скролла в новостях сохраняется?

лучше так, наверное. @grishka

гриша, а как у вас в вк состояние скролла в новостях сохраняется?

в статик

ну как юзер могу посудить, что для большинства кейсов этого хватает) правда давно на девайсах с маленькой оперативкой не сидел. а сам пишу с сохранением в сейвединстансстейт и тещу с dont keep activities

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

ну как юзер могу посудить, что для большинства кейсов этого хватает) правда давно на девайсах с маленькой оперативкой не сидел. а сам пишу с сохранением в сейвединстансстейт и тещу с dont keep activities

вот авторы инстаграма даже со статиком решили не заморачиваться )

и вьюшки все реально пересоздаются, просто восстанавливается скролл?

и вьюшки все реально пересоздаются, просто восстанавливается скролл?

пересоздаются, конечно

ERROR: S client not available

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

при выходе из раздела все его вьюшки продалбываются

сообщения тоже лежат в статике (и в sqlite)

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

да, обычная тактика с меморикешем и дб кешем, это круто все

и для ленты там лежит только первый кусок подгрузки (20, что ли, постов) + инфа, чтобы грузить дальше

а для непересоздания при повороте. у меня как то был чуть разный лейаут для портрета и лендскейпа. и я не хотел пересоздавать активити. я даже написал вьюшку, которая из хмл брала не реальный размер из dimen в layout_width, а ссылку на ресурс в dimen, и в onMeasure брала актуальный getResources().getDimesionPixelSize() c этим ресайди. вот и гибкий лэйаут, и ничего не пересоздалось

+100 к уважению этому господину

(забыл пояснить что dimen в разных папках лежал разный, естественно)

Ради того, чтобы gc не нагружать?

а для непересоздания при повороте. у меня как то был чуть разный лейаут для портрета и лендскейпа. и я не хотел пересоздавать активити. я даже написал вьюшку, которая из хмл брала не реальный размер из dimen в layout_width, а ссылку на ресурс в dimen, и в onMeasure брала актуальный getResources().getDimesionPixelSize() c этим ресайди. вот и гибкий лэйаут, и ничего не пересоздалось

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

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

"результаты операции уходят в никуда" это легко решается с MVP допустим. а что еще?

И если при выпиле системой это не так критично(ну загрузится заново), то при повороте напрягает

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

и второй вопрос к тем, кто считает что запрет на пересоздание активити это "плохо". чем плохо?

"результаты операции уходят в никуда" это легко решается с MVP допустим. а что еще?

Как именно решает? Именно сам МВП, а не либа

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

Андрюха, ну не срывай покровы ?

потом ты просто понимаешь как это работает, принимаешь правила игры, выключаешь поведение по умолчанию и изменяешь только те параметры, которые тебе нужны, а не пересоздаешь нафиг все

потому что на самом деле у тебя поменялась ширина и высота, а не ВСЕ

Ну вроде как придумали кучу всего от лоадеров до разных RestApi Patern

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

ну по той же логике еще можно активити пересоздавать каждую минуту, а то вдруг юзер делает приложение часы и он просто в onCreate в текствью проставляет текущее время

а то мало ли

Вот так нормальный программист и должен делать. Знать систему изнутри и правильно настраивать её, а не надстраивать

Как именно решает? Именно сам МВП, а не либа

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

Мне кажется, что это главная тема для дискуссий и создания велосипедов в android разработке.

Как хранить и возвращать результат в убитое активити

А, снова кэш

Ок, логично

А, снова кэш

ну это в любом случае будет кеш. как ты это не назови. но реализовать его можно 100 и 1 способом )

Как хранить и возвращать результат в убитое активити

Это поначалу. Потом начинаются споры между правильным и быстрым кодом, например