try finnaly

так в json может быть сотни разных сущностей

у меня все модели определны четко

вот так проверяю

пиздец у тебя цвета

ты себе глаза не уничтожил?

у вас в одном json у вас может быть только одна сущность?

тут тг пожал

у меня много, но с одного эндпоинта мне приходит листом одна сущность, в которой много других

мне главное чтобы основной обьект не задваивался

все таки 2 минуса у реалма я заметил, не может сохранять колекцию стрингов (дада такую элементарную весчь не может делать) и не поддерживает наследование

Есть какие-нибудь гайды по интерфейсам, когда 1 стейт можно менять несколькими способами, при этом результат изменения отложенный. В моем случае карта: ее можно двигать, можно запрашивать gps, а можно выбирать места из подсказок. 2 последних изменения работают через исинхронные запросы

все таки 2 минуса у реалма я заметил, не может сохранять колекцию стрингов (дада такую элементарную весчь не может делать) и не поддерживает наследование

это легко обойти

какие правила обработки каллбеков приняты?

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

мне главное чтобы основной обьект не задваивался

понятно, придется чекать сущности, в которых айди меняется

public class RealmString extends RealmObject { private String val; }

и делаешь List<RealmString>

так же и для Map

да э

это все понятнятно я так и делал но это както через жопу получается

разрабы описывали почему стринга нет

у них сейчас realm core не позволяет это сделать

возможно в будущем будет

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

ormA быстрее

я чесно говоря не понимаю как он сторит объкты там у себя внутри явно не скл

и нету времени разобраться(

ormA быстрее

посл раз я смотрел по тестам риалм обгоняет даже чистый скл

за счет кешей и прочего

но + 5mb к апк сразу же

посл раз я смотрел по тестам риалм обгоняет даже чистый скл

У ормы тесты реалма обгоняют

но + 5mb к апк сразу же

Можно выкинуть либы все. Оставить одну арм и одну х86

Будет работать на всех устройствах

ObjectAnimator.ofFloat(button, "alpha", 1, 0, 1); Так можно

Спасибо! намного элегантнее)

Можно выкинуть либы все. Оставить одну арм и одну х86

без x86_64 ?

У ормы тесты реалма обгоняют

Удобство плюс скорость. Сравнивать тот же гриндао. Он быстрый да, но он не так удобен, как реалм

без x86_64 ?

Ога, х86 работает на 64

http://prntscr.com/ddjwfp

Там отличие что оптимизации под каждуб архитектуру

Но оно не значительно

Я оставил v7a и х86

А мипс это вообще не надо, только если не телевизор на андроиде)))

а когда придется писать миграцию на риалме?

если поменяется тип поля, или новые поля добавятся?

Когда в модель поменяешь или тип или аннотацию

Или что-то удалить добавшь

Там очень просто в миграции

Можно делать что угодно

schema.get(Audit.class.getSimpleName()).removePrimaryKey(); schema.get(Audit.class.getSimpleName()).addIndex("id"); вот когда они запретили менять праймари ид, то так сделал

товарищи, подскажите, как сделать чтобы notification не закрывались по нажатию?

autoCancel false

неа

все равно закрывается

builder.setOngoing(true);

кто-то использовал urban airship?

Что за реалм и риалм? Релм! амер. |relm|, брит. |rɛlm|

У ормы тесты реалма обгоняют

они хитро делают, отключат механизм релма lazy loading

они хитро делают, отключат механизм релма lazy loading

Где?

для теста

Ну правильно. Ведь орма не может в лази

Ну правильно. Ведь орма не может в лази

это не проблемы релма

эту фичу для того и делали, чтобы было быстро

И на записи орма быстрее

как по мне, лучше чистый SqLite

товарищи, подскажите, как сделать чтобы notification не закрывались по нажатию?

думаю можно посмотреть в сторону Foreground Service

Ну ормы и есть чистый

Ну ормы и есть чистый

SqLite без врапперов я имел ввиду

SqLite без врапперов я имел ввиду

Без враперов медленнее в скорости и нужно следить за многопоточностью

Без враперов медленнее в скорости и нужно следить за многопоточностью

скорость на сколько? 20-30 мс? 100?

пробовал еще GreenDao 3

неплохо

знаю что @FuriousSeraphim использует requery

Без враперов медленнее в скорости и нужно следить за многопоточностью

Как это без враперов быстрей?) Они же всё-равно работают со всё тем же курсором. Только добавляют немного своего универсального оверхеда

Как это без враперов быстрей?) Они же всё-равно работают со всё тем же курсором. Только добавляют немного своего универсального оверхеда

Ну вон у ормы быстрее получилось

Ну вон у ормы быстрее получилось

Так а как? Всё-равно без курсора никак же (орма - ormlitem, так ведь?) cursor.getInt будует по определению всегда быстрей чем создать объект и сложить в него всё тот же cursor.getInt

actualLocation = location != null && System.currentTimeMillis() - location.time < 15000 так можно определять актуальность локации?

Так а как? Всё-равно без курсора никак же (орма - ormlitem, так ведь?) cursor.getInt будует по определению всегда быстрей чем создать объект и сложить в него всё тот же cursor.getInt

https://github.com/gfx/Android-Orma/raw/master/benchmark-v3.0.png

https://github.com/gfx/Android-Orma/raw/master/benchmark-v3.0.png

Я конечно не спец, но не может orm быть быстрее cursor. Первая вспомнившаяся статья https://habrahabr.ru/company/sebbia/blog/245299/

да при чем курсор, я про запись

в два раза быстрее ОРМА вставляет

в два раза быстрее ОРМА вставляет

бред

орм использует те же sql запросы

голый sql быстрее 100%

ибо всё остальное под капотом использует его

орм использует те же sql запросы

ORMA https://github.com/gfx/Android-Orma вы все путаете с просто термином орм

ORMA https://github.com/gfx/Android-Orma вы все путаете с просто термином орм

ну неважно, голый sql в любом случае быстрее

пздц

голый sql быстрее 100%

Не всегда

Не всегда

как оно может быть не быстрее, если все эти обертки под капотом использует голый sql ?

ну или как минимум также

как оно может быть не быстрее, если все эти обертки под капотом использует голый sql ?

не все же)

Ты можешь допустить ошибку или не оптимально составить запрос, ORM же иногда может сделать оптимизацию, где-то bulk-insert или еще что, то до чего ты бы вот так не додумался или бы не сделал под нехваткой времени

если не жопой писать запросы, конечно.

Пример GreenDao который в некоторых случаях вырывает)

Ты можешь допустить ошибку или не оптимально составить запрос, ORM же иногда может сделать оптимизацию, где-то bulk-insert или еще что, то до чего ты бы вот так не додумался или бы не сделал под нехваткой времени

ну, лол. Это уже проблема в разработчике, который запросы так пишет

Нет, нельзя знать все и быть готовым ко всему

ORM же может в течении долгого времени впитывать такие фичи