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