Продублирую тут, может, кому тоже пригодится: Можно добавлять первым параметром int , записывая туда версию объекта. Это позволит сделать миграцию, тк первым считываем версию, и уже от неё пляшем (например, записываем значение по умолчанию вместо считывания несуществующего в сериализованных данных поля). Кейс крайне редкий, но пару раз в жизни пригодилось )
1. ruclips.net/video/tko54cjc79U/видео.html стоит поправить Parcelizable на Parcelable 2. При чем Parcel к разбору Serializable объектов? 3. А замеры с кастомной сериализацией было бы неплохо увидеть, ведь мы же существенно уменьшаем рефлексию. Рассказано доступно, но за кадром осталось несколько нюансов связанных с наследованием и объектными типами полей, например: parcelable класс, унаследованный от non-parcelable класса, или parcelable класс с non-parcelable полями, содержащими приватные поля и т..п. Ну и аналогичная ситуация для Serializable классов
по первому пункту, согласен, проглядел; второй вопрос не совсем понимаю, я ведь рассказываю и за Parcelable тоже, а рассказывать за него в отрыве от Parcel не совсем правильно; под кастомной сериализацией понимается именно собственное решение по сериализации или какаято внутренняя история java/kotlin типа Externalizable?; про нюансы можно было бы рассказать, но тут как в казино, главное вовремя остановиться) тут больше ставил перед собой задачу рассказать за основы, и о причинах тех или иных решений, возможно в будущем подготовлю выступление раскрывающие все эти вопросы
@@user-bx6jf9lr3t Второй вопрос - это при рассказе про Serializable на картинке Parcel ruclips.net/video/tko54cjc79U/видео.html Кастомная сериализация - это когда мы создаем методы writeObject/readObject, в этом случае у нас остается доступ через рефлексию только к этим двум методам, а все остальные поля добавляются в поток без рефлексии и следовательно все должно работать гораздо быстрее.
@@user-sw9dc2is3i блин( там тоже опечатка( пропустили при прогонах( понял вопрос. так в таком случае мы получаем тоже самое что и Externalizable, а его мы замерили. Плюс в случае с writeObject/readObject нам обязательно надо использовать defaultReadObject/defaultWriteObject, и тут уже нет оптимизаций. Возможно мне так же следовало этот момент более ярче подсветить в презентации.
@@user-bx6jf9lr3t :) Объявляем все поля Transient, вызываем стандартные методы для записи метаданных класса, а потом пишем все данные в методе writeObjecе, ну и с чтением все точно также readObject. Да, про обязательный вызов дефолтных методов я подзабыл.
Наконец то я понял что это за магические классы, всегда откладывал этот вопрос, типа работает и пофиг. Хотелось бы еще видосик про анотацию @Serializable в котлине
Насколько знаю аннотация Serializable относится к библиотеке KotlinX Serialization, которая может сериализовать данные в различные форматы, например JSON
Да, я уже понял что есть ряд тем которых мне тоже стоит осветить. Они кажутся базовыми, но многие их упускают из-за того что считают слишком простыми. Потом ошибки глупые выходят. Спасибо Паши что своим таким разбором меня вдохновил на это
Большое спасибо за видео, радует что никаких изменений с 1.6 (а может и раньше) тут нет 11:33 - никогда не слышал такой оригинальной подводки к ClassLoader'ам). Интересно есть ли какая-то специфика тут по сравнению с Java SE?
Зачем нужны методы newArray(size: Int): Array и describeContents(): Int при реализации Parcelable? Документацию читал, но не понятно в каких сценариях их нужно использовать.
Parcelable нельзя только разрабам приложений хранить на диске. Системе можно. Ведь при той же смерти процесса данные из onSaveInstanceState запишутся на диск. А они Parcelable. Однако, единственный случай, когда поля посылки могут изменяться это переустановка приложения, а при ней все сохранённое состояние сбросится системой. Поэтому проблемы неправильной расшифровки Parcelable тут нет. Я правильно рассуждаю?
Нет. Нельзя сохранить данные в постоянное хранилище, чтобы когда их потом открыть. Система сохраняет эти данные временно. И при смерти процесса, не из-за нехватки ресурсов в системе, уничтожит все эти данные, что не приведёт к проблемам
@@AndroidBroadcast Видимо я плохо выразился, потому что ответ, что я рассуждал неверно, хотя по содержанию текста все сходится. Да, хранить хранить данные на диск через Parcelable, чтобы потом открыть нельзя. Но система так делает. И делает так только потому что у нее есть механизмы подтирания сохранённых на диск Parcelable, на случай, когда структура Parcelable класса изменилась. А изменится она может только при обновлении приложения. Именно тогда система и подчистит весь стейт приложения (происхождения onSaveInstanceState и типо того). В том числе подчистятся и все сохраненные Parcelable классы.
Надо будет про рефлексию отдельно почитать, а то определение знаю, а отличить не смогу. К примеру, считается за рефлексию такой вызов: this::class.java.simpleName?
Так как его формат привязан к версии прошивки. Если у вас она обновится, то не факт, что вы сможете прочитать эти данные. Parcelable сериализуется исключительно пока живет приложение и убивается когда вы его удаляете из recent или происходит обновление прошивки, обновление вашего приложения или всё другое что может повлиять на работу приложения
💰 Поддержать проект на Boosty bit.ly/3sratqQ или Patreon patreon.com/android_broadcast
🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast
🔗 Магазин мерча "Android Broadcast" clck.ru/YGGVT
Отличная подача, жду ещё видосов с этим автором)
Продублирую тут, может, кому тоже пригодится:
Можно добавлять первым параметром int , записывая туда версию объекта. Это позволит сделать миграцию, тк первым считываем версию, и уже от неё пляшем (например, записываем значение по умолчанию вместо считывания несуществующего в сериализованных данных поля). Кейс крайне редкий, но пару раз в жизни пригодилось )
Отлично. Не доконца понимал, что такого разного в этих классах. Вы всё объяснили кристально чётко. Огромное спасибо.
Очень комфортно и понятно разложено. Спасибо Кирилл. Зови ребят из Авито почаще 😉
Ждал до конца когда расскажут про потерянный int, вот что значит захватить внимание)
1. ruclips.net/video/tko54cjc79U/видео.html стоит поправить Parcelizable на Parcelable
2. При чем Parcel к разбору Serializable объектов?
3. А замеры с кастомной сериализацией было бы неплохо увидеть, ведь мы же существенно уменьшаем рефлексию.
Рассказано доступно, но за кадром осталось несколько нюансов связанных с наследованием и объектными типами полей, например: parcelable класс, унаследованный от non-parcelable класса, или parcelable класс с non-parcelable полями, содержащими приватные поля и т..п. Ну и аналогичная ситуация для Serializable классов
по первому пункту, согласен, проглядел;
второй вопрос не совсем понимаю, я ведь рассказываю и за Parcelable тоже, а рассказывать за него в отрыве от Parcel не совсем правильно;
под кастомной сериализацией понимается именно собственное решение по сериализации или какаято внутренняя история java/kotlin типа Externalizable?;
про нюансы можно было бы рассказать, но тут как в казино, главное вовремя остановиться) тут больше ставил перед собой задачу рассказать за основы, и о причинах тех или иных решений, возможно в будущем подготовлю выступление раскрывающие все эти вопросы
@@user-bx6jf9lr3t
Второй вопрос - это при рассказе про Serializable на картинке Parcel ruclips.net/video/tko54cjc79U/видео.html
Кастомная сериализация - это когда мы создаем методы writeObject/readObject, в этом случае у нас остается доступ через рефлексию только к этим двум методам, а все остальные поля добавляются в поток без рефлексии и следовательно все должно работать гораздо быстрее.
@@user-sw9dc2is3i блин( там тоже опечатка( пропустили при прогонах(
понял вопрос. так в таком случае мы получаем тоже самое что и Externalizable, а его мы замерили. Плюс в случае с writeObject/readObject нам обязательно надо использовать defaultReadObject/defaultWriteObject, и тут уже нет оптимизаций. Возможно мне так же следовало этот момент более ярче подсветить в презентации.
@@user-bx6jf9lr3t :) Объявляем все поля Transient, вызываем стандартные методы для записи метаданных класса, а потом пишем все данные в методе writeObjecе, ну и с чтением все точно также readObject.
Да, про обязательный вызов дефолтных методов я подзабыл.
@@user-sw9dc2is3i интересный подход)
20:23 в описании говорится, что "поле, НЕ помеченное ..., НЕ будет ...". Видится, что первое НЕ лишнее, иначе теряется смысл
Наконец то я понял что это за магические классы, всегда откладывал этот вопрос, типа работает и пофиг. Хотелось бы еще видосик про анотацию @Serializable в котлине
Насколько знаю аннотация Serializable относится к библиотеке KotlinX Serialization, которая может сериализовать данные в различные форматы, например JSON
О, колпачков
@@user-zi8zw3yf2t о здравствуйте Презентер
Завтра на собеседование это расскажу:)
прошел?)
Огонь, надеюсь, еще увидимся.
Спасибо большое, теперь все стало прозрачно
Класс, давайте больше такого контента!
Качественно.
Во, это реально было интересно посмотреть и послушать!
спасибо!))
Оч круто, впервые узнал про существование Externalizable. Мелкие помарки на видео - ерунда, докопаться можно до чего угодно
спасибо большое! ^^
Павел рассказал просто и полно о сложном. Спасибо!
Спасибо. Хороший формат.
Подробненько. Спасибо.
Спасибо, очень полезно и увлекательно!
Спасибо. Полезно
Круто, очень детально, спасибо!
Что насчёт @Parcelize, мне кажется, полезная вещь.
Побольше таких видео.
Да, я уже понял что есть ряд тем которых мне тоже стоит осветить. Они кажутся базовыми, но многие их упускают из-за того что считают слишком простыми. Потом ошибки глупые выходят.
Спасибо Паши что своим таким разбором меня вдохновил на это
Получилось интересно) на 20:20 ошибка в тексте, "поле, не помеченное..", не должно быть частицы "не"
Да сори( у меня там встречаются оговорки(
Огонь
Спасибо! ^^
Большое спасибо за видео, радует что никаких изменений с 1.6 (а может и раньше) тут нет
11:33 - никогда не слышал такой оригинальной подводки к ClassLoader'ам). Интересно есть ли какая-то специфика тут по сравнению с Java SE?
Класс. Спасибо.
Спасибо!
Спасибо, было очень интересно и полезно!👍
Спасибо большое!)
Круто, спасибо)
Было очень полезно! Спасибо!
Жалко, что нельзя поставить несколько лайков))
Спасибо
очень познавательно, спасибо.
Зачем нужны методы newArray(size: Int): Array и describeContents(): Int при реализации Parcelable?
Документацию читал, но не понятно в каких сценариях их нужно использовать.
newArray() надо чтобы не создавать массивы динамически. Уменьшение рефлексии
describeContents() использовал только в подклассах и уже не помню зачем
Паша, лапусик. Привет из fasten))
^^
Больше подобных видео
классное видео, немного отвлекает тема презентации с кляксами. хотелось бы более простую
Как по мне наоборот симпатично выглядит, примерно как ваше личико в аватарке 😏
очень интересная лекция. спасибо!
Супер
Вопрос от новичка: А где это должно пригодиться? В какой момент разработки приложения я пойму что мне нужно это? Подскажите пожалуйста
Любое сохранение состояния на диск связано с этими классами и будет полезно знать о них больше
@@AndroidBroadcast благодарю за ответ
класс
Было интересно и полезно
Отличный видос! Паша молодец! )
Спасибо!))
очень информативно, только айбайндер а не ибиндер, спасибо за контент
Круто, спасибо!)
топ контент 🔥
На 5:52 говорится, что с Parcelable мы не завязываемся на имена переменных, в отличие от Serializable. А как мы в Serializable завязываемся на имена?
Всё, понял😅
очень круто
Спасибо большое ^^
очень классный ролик, спасибо
Большое спасибо ^^
Хорош
Parcelable нельзя только разрабам приложений хранить на диске. Системе можно.
Ведь при той же смерти процесса данные из onSaveInstanceState запишутся на диск. А они Parcelable. Однако, единственный случай, когда поля посылки могут изменяться это переустановка приложения, а при ней все сохранённое состояние сбросится системой. Поэтому проблемы неправильной расшифровки Parcelable тут нет.
Я правильно рассуждаю?
Нет. Нельзя сохранить данные в постоянное хранилище, чтобы когда их потом открыть. Система сохраняет эти данные временно. И при смерти процесса, не из-за нехватки ресурсов в системе, уничтожит все эти данные, что не приведёт к проблемам
@@AndroidBroadcast
Видимо я плохо выразился, потому что ответ, что я рассуждал неверно, хотя по содержанию текста все сходится.
Да, хранить хранить данные на диск через Parcelable, чтобы потом открыть нельзя.
Но система так делает.
И делает так только потому что у нее есть механизмы подтирания сохранённых на диск Parcelable, на случай, когда структура Parcelable класса изменилась.
А изменится она может только при обновлении приложения. Именно тогда система и подчистит весь стейт приложения (происхождения onSaveInstanceState и типо того).
В том числе подчистятся и все сохраненные Parcelable классы.
Полезное видео
Спасибо!
@@user-bx6jf9lr3t благодаря такой подаче информации легче собрать этот огромный пазл, будем рады видеть новые видео от Вас!
Это байт на комменты? Числа не пропадают, а в бинарном формате хранятся.
Надо будет про рефлексию отдельно почитать, а то определение знаю, а отличить не смогу.
К примеру, считается за рефлексию такой вызов: this::class.java.simpleName?
Да
Хотя такой вызов может быть оптимизирован с помощью R8 и не будет рефлексии
@@AndroidBroadcast Спасибо
Захотел пройти собеседование в Авито. Спасибо за полезный материал.
P.S. на слайде с ручной сериализацией опечатка в описании аннотации
Будем ждать на собесах ^^
Я не очень понял, почему Парсэлабл нельзя хранить в ПЗУ
Так как его формат привязан к версии прошивки. Если у вас она обновится, то не факт, что вы сможете прочитать эти данные. Parcelable сериализуется исключительно пока живет приложение и убивается когда вы его удаляете из recent или происходит обновление прошивки, обновление вашего приложения или всё другое что может повлиять на работу приложения
@@AndroidBroadcast спасибо!
Ну как бы parcelable так же можно в файл сохранить
Сохранить - да, но в докладе рассказывается почем не стоит хранить долго и чем черевата ошибка
@@AndroidBroadcast прослушал этот момент
Продвигаем канал ;)
спс
первый раз слышу, чтобы reflection переводили как рефлексия. вы в слово вдумайтесь прежде , чем переводить
Как надо переводить?
@@AndroidBroadcast сорян. был не прав. оказывается, ее много где рефлексией называют))) хотя рефлекшн и рефлексия - это прям совсем не одно и то же
+
Просто коммент для продвижения
Спс