Кто сохраняет, в какие файлы? Что за жесть?)

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

Ребят, а javascript, показываемый в webview, закэшировать можн? Как-нибудь там библиотеки подтягивающиеся подтянуть в офлайн

Да, WebViewClient или WebChromeClient может перехватывать запросы, делал так предзагрузку картинок из веб-страницы.

Да, WebViewClient или WebChromeClient может перехватывать запросы, делал так предзагрузку картинок из веб-страницы.

и каков алгоритм действий - хранить либу локально?

и каков алгоритм действий - хранить либу локально?

Ну, я парсил документ на наличие ссылок на файлы, которые мне нужно закешировать.

Вообще не могу представить себе ситуацию, в которой оверхед от кривоватого компилятора Котлина ощутим.

drawableCollection.forEarch { it.draw(canvas); } И создай список из таких вьюх

благословляю тебя

благословляю тебя

Спасибо!

drawableCollection.forEarch { it.draw(canvas); } И создай список из таких вьюх

И во что оно развернётся? Мне кажется, в банальный for.

А ты знаешь, чем плох банальный for?

А ты знаешь, чем плох банальный for?

For бывают разные. Банальный for восхитителен, потому что это одна из базовых конструкций языка.

А ты знаешь, чем плох банальный for?

У foreach с Iterable есть проблема, да.

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

Так там for или foreach?

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

а о чем спор идет? Как сэкономить микросекунды?

Так там for или foreach?

Так это ж надо в байт-код смотреть.

Можно просто в исходники

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

И автобоксинг тоже замечателен. При правильном применении.

Короче говоря, там foreach, который создает итератор

Вот именно, что нужно знать и понимать, как в языке и что работает

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

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

это высказывание применимо к любому языку, фреймворку и библиотеке

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

Ну, это такое себе. Я выбрал из-за системы типов.

это высказывание применимо к любому языку, фреймворку и библиотеке

Именно так. Поэтому вначале надо разбираться в основах, а потом уже лезть в эти библиотеки и языки. Люди зачастую говорят, что Rx знают, а сами не понимают, зачем SparseArray нужен

Я уже устал от таких товарищей :(

Проблема Котлина в том, что он не дает вам больше никаких средств итерации из коробки.

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

И проверки эти, которые экономят миллисекунды, в большинстве случаев можно(и нужно!) делать на этапе компиляции. Или хотя бы давать юзеру возможность выбрать.

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

Именно так. Поэтому вначале надо разбираться в основах, а потом уже лезть в эти библиотеки и языки. Люди зачастую говорят, что Rx знают, а сами не понимают, зачем SparseArray нужен

Я охренел оттого, что у меня на собеседованиях ни разу не спросили *Sparse*Array или *ArrayMap.

Я стараюсь в первую очередь эти основы и проверять :)

И проверки эти, которые экономят миллисекунды, в большинстве случаев можно(и нужно!) делать на этапе компиляции. Или хотя бы давать юзеру возможность выбрать.

Вообще можно указать параметры компилятору и на "каждый чих" не будет генерится, то что генерится обычно - там все ок)

Нельзя

Можно взять исходники компилера и форкнуть их

И в этом случае да, Котлин таки превращается в быстрый язык

Нельзя

Да можно же, презентацию видел и там четко сказали, что если хотит оставить все в compile time то пожалуйста

Если написать свои extension-functions для итерации коллекций

Да можно же, презентацию видел и там четко сказали, что если хотит оставить все в compile time то пожалуйста

Они говорят, что можно, но этот флаг только для нескольких кейсов их отключает

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

В lateinit они все ещё остаются, например

Они говорят, что можно, но этот флаг только для нескольких кейсов их отключает

на Null проверки выпиливает все точно

Да просто итерировать drawable в onDraw

И будет нехилый fps drop при скролле

Да подставит он обычный индекс если сможет, тоже норм с этим

а для чего свои onDraw в рядовом приложении?

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

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

+

Если где-то медленно - напиши на Java кусок и не беспокойся)

Да подставит он обычный индекс если сможет, тоже норм с этим

Не подставит, там итератор

См. исходники

У них даже объяснение есть этому, это безопаснее(в этом они правы)

Но выбор у юзеров должен быть

В Котлине огромная часть стдлибы использует итераторы

Попробуйте с наскока сказать, какая

Collections.kt? :)

а для чего свои onDraw в рядовом приложении?

А сколько ты вообще пишешь? Почти всегда в приложениях нужно писать кастомные drawable и Views.

Collections.kt? :)

И не только :)

Если где-то медленно - напиши на Java кусок и не беспокойся)

Если на языке нельзя писать быстрый код, зачем он нужен?)

ERROR: S client not available

А сколько ты вообще пишешь? Почти всегда в приложениях нужно писать кастомные drawable и Views.

два с половиной года писательствую и ни разу не использовал свой onDraw

См. исходники

Как-то не нахожу. :| https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/src/kotlin/collections/Collections.kt

Если на языке нельзя писать быстрый код, зачем он нужен?)

в корне не верное утверждение

Ну видимо тебе с приложениями везло, не знаю :)

Если на языке нельзя писать быстрый код, зачем он нужен?)

Можно. Там полно быстрых штук — тот же lazy, который в Java задрочишься реализовывать.

Если на языке нельзя писать быстрый код, зачем он нужен?)

Да и в Java очень легко нарваться на итераторы?

.

У них даже объяснение есть этому, это безопаснее(в этом они правы)

Можно ссылку?

Ну видимо тебе с приложениями везло, не знаю :)

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

в корне не верное утверждение

Ну и пиши приложения, которые аццки лагают на большинстве устройств. У тебя ведь топовый девайс. Вы забываете, что вы пишете в первую очередь для юзеров. Хоть у кого-то есть приложение, которое работает в 60 fps? Как айфон или Телеграм.

Можно ссылку?

Они в личку писали, увы :)

Но вообще из логика понятна, итератор и правда безопаснее

Мы почти договорились получить альтернативную stdlib с индексами :)

Может и сделают скоро, они согласились с идеей

Но вообще из логика понятна, итератор и правда безопаснее

Чем? (в однопоточном окружении)

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

Не для всех коллекций доступ по индексу быстрее будет

Не у всех коллекций такое вообще есть :)

Ну и многопоточность

Ну и пиши приложения, которые аццки лагают на большинстве устройств. У тебя ведь топовый девайс. Вы забываете, что вы пишете в первую очередь для юзеров. Хоть у кого-то есть приложение, которое работает в 60 fps? Как айфон или Телеграм.

Думаю, утверждение заключалось не в том, что «буду писать на чём вздумается», а в том, что утверждение так себе: у многих языков / компиляторов есть быстрые / медленные места (если не это медленный груви, например).

У Котлина есть только одно место, где он быстрее :)

Ну и многопоточность

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

Не для всех коллекций доступ по индексу быстрее будет

if (something is RandomAccess)

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

Вот это жёстко, да.

Думаю, утверждение заключалось не в том, что «буду писать на чём вздумается», а в том, что утверждение так себе: у многих языков / компиляторов есть быстрые / медленные места (если не это медленный груви, например).

нет, суть была в том, что писать можно на чем угодно, главное понимать, где тебя поджидает западло. А если следовать логике "чем быстрее язык, тем лучше" - то прямая дорога писать на С

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

У Котлина есть только одно место, где он быстрее :)

Какое же? Вообще, меня иногда печалят нопы и мёртвый код, который он за собой оставляет :|

Инлайн лямбд