А я могу как-то настроить proguard что бы он не обфусцировал data class? Я к тому что data class в байткоде ничем не отличаются от др классов и мне по идеи их надо каждый прописывать или чем-то аннотировать.

никак, только аннотациями, либо именем, либо пакетом

никак, только аннотациями, либо именем, либо пакетом

Да пожалуй раскидаю им Serializable, это же вроде норм.

нет, там для прогуарда же есть специальная аннотация

нахера костыли делать

нет, там для прогуарда же есть специальная аннотация

В смысле, почему не норм? Я в прогуарде добавлю игнор всего что имплементит serializable.

есть android.support.annotation.Keep в андроиде

и если конфиг прогуарда настроен правильно в градле proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'project_custom_file.pro' то все заведется как надо. proguard-android-optimize.txt - этот файл автоматом должен подтянуться, он идет с android sdk

просто иплементить serializable, чтобы прогуард не трогал - это жесть

есть android.support.annotation.Keep в андроиде

Но у меня кроссплатформенная игруля и весь код лежит в чистом Java SE модуле. И не понимаю почему "обвешивать весь код Android аннотациями" - меньшая жесть

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

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

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

Где это я про синглтоны говорил?

а object - это не синглтон в котлине что ли?

а, там речь шла про data, сорян

а object - это не синглтон в котлине что ли?

И про object я тоже не писал. Я говорил только про data class.

Ну, обвешать @Keep определённо лучше, чем Serializable.

Ну, обвешать @Keep определённо лучше, чем Serializable.

Чем?

Serializable тоже не требует ничего имплеменить

тем, что аннотация явно говорит нахрена она тут нужна

Чем?

Тем, что @Keep чётко показывает, что класс не будет выпилен, а Serializable, во-первых, намекает на сохранение сохранение класса лишь косвенно, и, во-вторых, втаскивает функциональность, которая может быть не нужна.

тем, что аннотация явно говорит нахрена она тут нужна

Очень спорно и мне скорее всего придется пилить свою аннотацию (что бы протащить на desktop/ios) А это data class я заодно смогу и между активитей гонять (в будущем).

между активитей не надо классы гонять

Очень спорно и мне скорее всего придется пилить свою аннотацию (что бы протащить на desktop/ios) А это data class я заодно смогу и между активитей гонять (в будущем).

Ну запили свою. Гонять Serializable в Android между активитями не нужно.

между активитей не надо классы гонять

Чувак ты полон стереотипов/предубеждений

Чувак ты полон стереотипов/предубеждений

хм...

Чувак ты полон стереотипов/предубеждений

размер IPC Binder’a мал

хм...

А пруф что Гонять Serializable в Android между активитями не нужно.?

А пруф что Гонять Serializable в Android между активитями не нужно.?

от гугла подойдет?

А пруф что Гонять Serializable в Android между активитями не нужно.?

Сериализация — долго и громоздко, об этом есть в мануалах.

размер IPC Binder’a мал

Ну мы же говорим про простые объекты с парой-тройкой полей. Где то я видел примеры как в гугл Bitmap гоняли между активитей.

ой, да че они только не делали

Ну мы же говорим про простые объекты с парой-тройкой полей. Где то я видел примеры как в гугл Bitmap гоняли между активитей.

Так Bitmap — Parcelable.

Ну мы же говорим про простые объекты с парой-тройкой полей. Где то я видел примеры как в гугл Bitmap гоняли между активитей.

ну ты же на написал что хочешь там ганять

parcelable тоже не надо гонять

parcelable тоже не надо гонять

Почему же?

Так Bitmap — Parcelable.

Меньше он от этого не становится (если мы говорим про размер bundle )

от гугла подойдет?

Давай

ну объекты с 1-2 полем еще можно простить, но лучше id в бд и на новой активити из бд дергать

Меньше он от этого не становится (если мы говорим про размер bundle )

Становится, потому что сериализация втаскивает описание класса.

ну ты же на написал что хочешь там ганять

Ну так и не надо давать "общие советы", не знаю специфики

ну объекты с 1-2 полем еще можно простить, но лучше id в бд и на новой активити из бд дергать

Не все объекты хранятся в БД. Хороший пример — BluetoothDevice.

Становится, потому что сериализация втаскивает описание класса.

Я иммел ввиду в сравнение с классами данных

#1

Можно ссылку

Можно ссылку

https://realm.io/news/romain-guy-chet-haase-developing-for-android/

Chet Haase

чет отошли от темы

в общем я бы не стал делать serializeble только ради сохранения прогуардом

а дальше дело автора :)

#1

Там еще много крутых советов которым никто не следует. В общем всегда надо искать компромисы.

Там еще много крутых советов которым никто не следует. В общем всегда надо искать компромисы.

36 минута

Там еще много крутых советов которым никто не следует. В общем всегда надо искать компромисы.

Так это уже личное дело каждого, последовать советам или написать приложение типа фейсбука :)

Там еще много крутых советов которым никто не следует. В общем всегда надо искать компромисы.

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

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

Ну да, как обычно - мы сделали все криво, отдувайтесь разработчики.

Ну да, как обычно - мы сделали все криво, отдувайтесь разработчики.

не ной )

Да я уже привык (правда за столько лет уже тошнит от это "архитектуры")

Ну да, как обычно - мы сделали все криво, отдувайтесь разработчики.

Кривота, несомненно, присутствует, но это отнюдь не значит, что Serializable — лучший способ сохранить класс и передать объект.

Кривота, несомненно, присутствует, но это отнюдь не значит, что Serializable — лучший способ сохранить класс и передать объект.

Лучше по старинке настрою proguard-rules.pro (все таки это чисто android проблемма), чем засорять кросплатформенный код аннотациями и интерфейсами.

Ребят, а я пользуюсь Gson'ом для сериализации/десериализации каких-то моделей и передачи их в качестве аргумента в интент или фрагмент. На сколько это хуже, чем парсел?

Ребят, а я пользуюсь Gson'ом для сериализации/десериализации каких-то моделей и передачи их в качестве аргумента в интент или фрагмент. На сколько это хуже, чем парсел?

Это занимает больше памяти, но парсится не намного медленнее (за исключением первого раза), если использовать тот же экземпляр Gson'а.

Это занимает больше памяти, но парсится не намного медленнее (за исключением первого раза), если использовать тот же экземпляр Gson'а.

тоесть реально есть смысл держать object, как холдет экземпляра Gson?

тоесть реально есть смысл держать object, как холдет экземпляра Gson?

Конечно, Gson имеет кеши и синхронизирован.

гуд, спасибо

ERROR: S client not available

есть ли какой-то способ сделать чтобы объявленный в котлине метод был с точки зрения Java статическим и при этом не было дополнительного внутреннего индентификатора для доступа к нему? т.е. SomeClass.staticMethod() вместо SomeClass.INSTANCE.someMethod()

@JvmStatic

class Some { companion object { @JvmStatic fun test() { } } }

спасибо!

а тоже самое для внутреннего статического класса существует?

@JvmStatic можно только к методу применить

А зачем внутренний именно? Можно просто сделать класс

А зачем внутренний именно? Можно просто сделать класс

допустим есть класс на Java SomeClass в нем есть внутренний статический SomeStaticClass. И Есть код на Java которые использует SomeClass.SomeStaticClass. Теперь при конвертации SomeClass на котлин ломается весь код который использовал SomeStaticClass. А это как-то не очень. В моем случае это внутри проекта, могу поправить, но в общем случае может же стать проблемой

Ну так это просто class SomeClass { class SomeStaticClass {

Ну так это просто class SomeClass { class SomeStaticClass {

да, действительно просто =) спасибо.

Привет, кто-то уже юзает корутины ?

А то я вроде включил а они не пашут

А то я вроде включил а они не пашут

Код покаж и что значит "не пашут"?

Код покаж и что значит "не пашут"?

Идея говорит мол, нет таких функций

Идея говорит мол, нет таких функций

Это устаревший синтаксис, сейчас там по другому

а, понял, сейчас погуглю

а, понял, сейчас погуглю

ты вообще что юзаешь для асинков (completablefuture / rx)?

ты вообще что юзаешь для асинков (completablefuture / rx)?

пока ничего, я нуб еще

пока ничего, я нуб еще

Выбираешь любой из https://github.com/Kotlin/kotlinx.coroutines Я к примеру написал свои для CompletableFuture из https://github.com/streamsupport/streamsupport (по шаблону из kotlinx.coroutines)

корутинки уже активно юзаете в проде?

корутинки уже активно юзаете в проде?

Пока не получается. Пытаюсь скрестить с монадой Reader, но пока не получается.

Это устаревший синтаксис, сейчас там по другому

Ну технически так они могут работать, просто сейчас либа просит контекст явно передавать на вход async

Ну технически так они могут работать, просто сейчас либа просит контекст явно передавать на вход async

Блин, по текущей реализации коррутин можно отдельную книгу выпускать "Async in Kotlin 1.1" (такие они стали сложнее)

Я вот после релиза сел посмотреть, и мне показалось все даже проще и логичнее чем было в первой реализации

Ну и гибче при этом стало

Я вот после релиза сел посмотреть, и мне показалось все даже проще и логичнее чем было в первой реализации

Юзать или писать свои? Теперь уже в самой std lib больше 10 файлов связанных с корритинами и десятки (сотня) классов в "kotlinx.coroutines"

Ну и гибче при этом стало

Ну гибче это несомненно

Юзать или писать свои? Теперь уже в самой std lib больше 10 файлов связанных с корритинами и десятки (сотня) классов в "kotlinx.coroutines"

Ну я скорее про писать

Ну я скорее про писать

Ну хз, как по мне стало менее тривильно. Сейчас не могу разобраться с CoroutineContext - какой юзать если я хочу синхронно выполнение (там больше 20 реализаций)? EmptyCoroutineContext - это заглушка или дефолтная реализация?