Комментарии интересны: кому какая обстановка нравится :)
Я вот сместил свой рабочий график ближе к утру. В офисе с 8:30, когда большая часть коллег подходит к 11. И в тишине сижу, и с коллегами общаюсь. Дома заставить себя работать намного тяжелее.
Присоединяюсь к вопросам о том, какая именно проблема решается :)
Похоже на то, что здесь повторён LoaderManager. В SDK он передаётся через метод onRetainNonConfigurationInstance, а здесь — через Binder в onSaveInstanceState.
Проблема стандартная, предложено ещё одно решение, за это спасибо.
Наглядно на то, что происходит, можно в любых классах Proxy и Stub, которые создаёт утилита aidl.
Java объекты перегоняются в обычный байтовый массив на стороне клиента (средствами Parcel-а и Parcelable-а), из которого вновь формируются объекты на стороне сервиса.
Здесь есть описание структуры транзакции. Помимо аргументов вызываемого метода (data.ptr.buffer), содержит идентификатор метода, который необходимо вызвать (code), идентификатор сервиса, в который всем этим данным надо отправиться (target.handle), и другие поля.
Все операции простые и быстрые (записать в массив — прочитать из массива), накладные расходы, конечно, есть, но вряд ли соизмеримы со стоимостью выполнения самой логики вызываемых методов. Сам замеров не делал :) Что-то похожее надо делать при любом межпроцессном взаимодейтсвии: «как есть» Java-объекты из одной виртуальной машины в другую не передать.
Проект не зарабатывал достаточное для поддержания свой жизнедеятельности количество денег
Привет! Если коротко, то сервис закрылся ~9 лет назад.
Привет! Как в итоге работа с Facebook SDK сделана? Написали модуль-обёртку над ним?
Спасибо за статью, познавательно.
Спросить нечего, так как подобные задачи ещё не решали :)
Я вот сместил свой рабочий график ближе к утру. В офисе с 8:30, когда большая часть коллег подходит к 11. И в тишине сижу, и с коллегами общаюсь. Дома заставить себя работать намного тяжелее.
Похоже на то, что здесь повторён LoaderManager. В SDK он передаётся через метод onRetainNonConfigurationInstance, а здесь — через Binder в onSaveInstanceState.
Проблема стандартная, предложено ещё одно решение, за это спасибо.
Тоже было такое желание. Но потом узнал, что экскурсия на ледоколе стоит около 500 000 рублей, и желание пропало :)
В целом завидую :)
Мне как-то даже выслали специальную сборку для диагностирования проблемы.
Java объекты перегоняются в обычный байтовый массив на стороне клиента (средствами Parcel-а и Parcelable-а), из которого вновь формируются объекты на стороне сервиса.
Здесь есть описание структуры транзакции. Помимо аргументов вызываемого метода (data.ptr.buffer), содержит идентификатор метода, который необходимо вызвать (code), идентификатор сервиса, в который всем этим данным надо отправиться (target.handle), и другие поля.
Все операции простые и быстрые (записать в массив — прочитать из массива), накладные расходы, конечно, есть, но вряд ли соизмеримы со стоимостью выполнения самой логики вызываемых методов. Сам замеров не делал :) Что-то похожее надо делать при любом межпроцессном взаимодейтсвии: «как есть» Java-объекты из одной виртуальной машины в другую не передать.