типа такого чет

Ну, вообще, еслить верить товарищу. Gerc-у, то от rx производительность только просядет из-за кучи аллокаций по ходу работы

Не машинная производительность мне интересна ) а человеко чесы потраченые на работу ))

А, ок

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

То есть, скажем, если ниже 10-15%, то не бегать в сеть, например

смысл от приложения тогда

если оно будет мне протухшие данные показывать

если я в него зашел, значит я отдаю себе отчет

Оки-доки. А диалог, типа, не хотите ли, благородный дон, дать зарядке подольше пожить, тоже не имеет смысла ?

батарейку один фиг экран только сильно жрет

бред

Ну, такое, сокеты, например, открытые тоже жрать будут немало

Есть тут кто хорошо шарит в использовании MVVM с Data Binding?

еще раз, если я зашел в тг мне всеравно сколько батарея

я хочу тг

так пусть он работает а не задает глупые вопросы

Realm realm = Realm.getDefaultInstance(); User realmUser = realm.where(User.class).findFirst(); if (realmUser != null) { user = realm.copyFromRealm(realmUser); } realm.close(); return Observable.just(user);

Странный метод ) но спасибо за совет ) А может есть какие книги или статейки почитать или проект где код можно глянуть?

за тебя и так доз все решит

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

Есть тут кто хорошо шарит в использовании MVVM с Data Binding?

Такое дело - для Activity есть ActivityViewModel, но там есть RecyclerView у которого каждый айтем так же сделан с помощью биндинга. Как по вашему, лучше в него передавать тот же ActivityViewModel и всю логику обработки событий в нем реализовывать или создать ItemViewModel отдельный и в нем? В первом случае приходится передавать в адаптер ViewModel, а во втором случае получается лишние объекты модели и пр.

так пусть он работает а не задает глупые вопросы

оки

Опять пусто

Вообщем, создал вопрос на SO: http://stackoverflow.com/questions/43708240/android-annotation-with-kotlin

Тебе же написали в ероре See log for more details. А ты смотрел что там в логах грейдл консоли было?

А вот Realm - да, говорят, быстрее

Быстрее чем кто? В sqlite скорость работы улучшали тоже. И если в проект затянуть sqlite из последних версий, то она тоже неплохо работать будет. В то время как в различных бенчмарках, как правило, юзают коробочные базы, которые не обновлялись давно.

Быстрее чем кто? В sqlite скорость работы улучшали тоже. И если в проект затянуть sqlite из последних версий, то она тоже неплохо работать будет. В то время как в различных бенчмарках, как правило, юзают коробочные базы, которые не обновлялись давно.

Простите, а Вы о версиях SQLite говорите ? Просто вроде бы вы, кроме как с c++ кодом никак не поработаете с конкретной версией SQLite в андроиде

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

Ну так и реалм нейтивными сошками тянется

так и sqlite можно затянуть.

Быстрее чем кто? В sqlite скорость работы улучшали тоже. И если в проект затянуть sqlite из последних версий, то она тоже неплохо работать будет. В то время как в различных бенчмарках, как правило, юзают коробочные базы, которые не обновлялись давно.

Realm быстрее за счет lazy и адекватаня миграция есть. Можно нормально колонку удалить/переминвоать и не геморостя как в скалйте

так и sqlite можно затянуть.

Это очень, очень плохая идея.

Почему?

Почему?

not worth

Как минимум потому, что на девайсе есть SQLite конкретной версии

Для меня sqlite умер после перхеода на realm ^)

not worth

ну и да, если вас так прям радует наличие тонн кода на плюсах...

ну и да, если вас так прям радует наличие тонн кода на плюсах...

SQLITE тоже на плюсах написан

Гораздо больше профита будет, если вы от Gson откажетесь в пользу Flat Buffers

Как минимум потому, что на девайсе есть SQLite конкретной версии

и что? почему тянуть реалм хорошо, а свой sqlite - плохо? В чем разница?

SQLITE тоже на плюсах написан

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

Тебе же написали в ероре See log for more details. А ты смотрел что там в логах грейдл консоли было?

Ага, в комменты добавил

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

ну и зачем, когда есть клевый реалм:)

ну и зачем, когда есть клевый реалм:)

Я не верю, что вам не хватает производительности SQLite

Я нег оворю что не хватает. Realm в целом удобнее

Гораздо больше профита будет, если вы от Gson откажетесь в пользу Flat Buffers

Вот тут разница, к слову, реально будет видна, только вот никто особо не заморачивается. А гемора будет гарантированно меньше, чем с SQLite

Нету ограничения на cursor window size, нормалньая миграция(ни один орм не дает такой для sqlite), можно блоб 16мб сохранять. Есть автообновление

Я нег оворю что не хватает. Realm в целом удобнее

На вкус и цвет

Зачем хранить в БД blob на 16мб ?

Зачем это другой вопрос, есть такая возможность

Ваше приложение за пару-тройку таких записей удалят, как только объем дисковой памяти увидят, которое оно занимает

а в sqlite макисмум что может выплюнуть запрос это 2мб

Зачем это другой вопрос, есть такая возможность

не, не ответ. Бесполезная фича

не, не ответ. Бесполезная фича

лол, ясно все с вами, диалог можно не продлжать :)

w: /home/lionzxy/JavaProject/JetBrainsIntership/app/build/tmp/kapt3/stubs/debug/ru/lionzxy/jetbrainsintership/MainActivity.java:4: warning: Element ru.lionzxy.jetbrainsintership.MainActivity invalidated by EActivityHandler w: w: public final class MainActivity extends android.support.v7.app.AppCompatActivity implements ru.lionzxy.jetbrainsintership.fragment.SearchFragment.FragmentCallbacks { w: ^ w: /home/lionzxy/JavaProject/JetBrainsIntership/app/build/tmp/kapt3/stubs/debug/ru/lionzxy/jetbrainsintership/fragment/SearchFragment.java:9: warning: Element mSearchView invalidated by ViewByIdHandler w: w: private com.arlib.floatingsearchview.FloatingSearchView mSearchView; w: ^ w: /home/lionzxy/JavaProject/JetBrainsIntership/app/build/tmp/kapt3/stubs/debug/ru/lionzxy/jetbrainsintership/fragment/SearchFragment.java:11: warning: Element mRecyclerView invalidated by ViewByIdHandler w: w: private android.support.v7.widget.RecyclerView mRecyclerView; w: ^ w: warning: The following options were not recognized by any processor: '[kapt.kotlin.generated]' w: :app:kaptDebugKotlin FAILED Чо ему не нравиться то

если фича для вас бесполезная, это не значит, что она бесполезная для всех. Для меня например является абсолютно бесполезной реализация Cursor :)

ну и да, если вас так прям радует наличие тонн кода на плюсах...

Что realm, что sqlite на плюсах. Обе базы тянуться через сошки. Обе из-за этого добавляют размер к апк, особенно если не сплитить. Так почему же первую тянуть хорошо с собой, а другую, по вашим словам, очень плохая идея? В чем разница?

лол, ясно все с вами, диалог можно не продлжать :)

Если приведете пример приложения, которое оправданно будет делать записи с blob-ами на 16мб, буду признателен. Хотя бы одно

Что realm, что sqlite на плюсах. Обе базы тянуться через сошки. Обе из-за этого добавляют размер к апк, особенно если не сплитить. Так почему же первую тянуть хорошо с собой, а другую, по вашим словам, очень плохая идея? В чем разница?

Я про обе говорил. Есть стандартные компоненты, которых хватает, зачем еще что-то то ?

Если приведете пример приложения, которое оправданно будет делать записи с blob-ами на 16мб, буду признателен. Хотя бы одно

Хранить в бд файлы, к которым не желательно чтобы юзер имел данные. А базу реалма шифрованного довольно сложно расковырять

Хранить в бд файлы, к которым не желательно чтобы юзер имел данные. А базу реалма шифрованного довольно сложно расковырять

SQLCipher

SQLCipher

и привет 2мб

и на некоторых девайсах даже 1

Изи ковырять же

от аднроида зависит

Довериться на 100% нельзя клиенту 100%

Я бы еще спросил конечно, как вы храните ключи так, что не расковырять...

ERROR: S client not available

Довериться на 100% нельзя клиенту 100%

Да, но это лучший вариант

но ладно

Собствено, в чем тут-то проблема: w: /home/lionzxy/JavaProject/JetBrainsIntership/app/build/tmp/kapt3/stubs/debug/ru/lionzxy/jetbrainsintership/MainActivity.java:4: warning: Element ru.lionzxy.jetbrainsintership.MainActivity invalidated by EActivityHandler w: w: public final class MainActivity extends android.support.v7.app.AppCompatActivity implements ru.lionzxy.jetbrainsintership.fragment.SearchFragment.FragmentCallbacks { w: ^ w: /home/lionzxy/JavaProject/JetBrainsIntership/app/build/tmp/kapt3/stubs/debug/ru/lionzxy/jetbrainsintership/fragment/SearchFragment.java:9: warning: Element mSearchView invalidated by ViewByIdHandler w: w: private com.arlib.floatingsearchview.FloatingSearchView mSearchView; w: ^ w: /home/lionzxy/JavaProject/JetBrainsIntership/app/build/tmp/kapt3/stubs/debug/ru/lionzxy/jetbrainsintership/fragment/SearchFragment.java:11: warning: Element mRecyclerView invalidated by ViewByIdHandler w: w: private android.support.v7.widget.RecyclerView mRecyclerView; w: ^ w: warning: The following options were not recognized by any processor: '[kapt.kotlin.generated]' w: :app:kaptDebugKotlin FAILED

Да, но это лучший вариант

опять же, пожалуйста, обосновывайте подобные утверждения

Что он хочет от меня :<

Что значит лучший

опять же, пожалуйста, обосновывайте подобные утверждения

лол, ты тут не привел ничего в защиту sqlite, крмое как ко-ко-ко оно же встроено и можно свой, зачем вам бесоплезные фичи

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

Биндинги в джаву можно написать как бы

Точнее, они уже написаны

Что realm, что sqlite на плюсах. Обе базы тянуться через сошки. Обе из-за этого добавляют размер к апк, особенно если не сплитить. Так почему же первую тянуть хорошо с собой, а другую, по вашим словам, очень плохая идея? В чем разница?

Ну, я так понимаю, как минимум - притянув новую версию SQLite в приложение - стандартные обертки андроида на нем могут не завестить и придется либо писать свои, что огромный гемор, либо работать с sqlite напрямую в сях, что тоже для многих гемор.

Я про обе говорил. Есть стандартные компоненты, которых хватает, зачем еще что-то то ?

эту идеологию можно продлить на "зачем нужны либы?" все есть в стандартных компонентах ;)

эту идеологию можно продлить на "зачем нужны либы?" все есть в стандартных компонентах ;)

Ну, приближаюсь к этому, вообще ;)

Это как, зачем юзать List когда есть array

А так же зачем нужна андроид сдк, можно все и в ндк делать

или Iterable

А так же зачем нужна андроид сдк, можно все и в ндк делать

Чтобы четыре процессорные архитектуры не поддерживать по-отдельности. Засчитано ?)

видимо потому что удобно? :)

Ну, я так понимаю, как минимум - притянув новую версию SQLite в приложение - стандартные обертки андроида на нем могут не завестить и придется либо писать свои, что огромный гемор, либо работать с sqlite напрямую в сях, что тоже для многих гемор.

Можно один раз написать и юзать везде. Можно взять уже готовое.

Так вы пишите портабельный код, не будет проблем)

Чтобы четыре процессорные архитектуры не поддерживать по-отдельности. Засчитано ?)

можно исклчюить либы при сборке и оставить х86 и арм и будет работать везде

можно исклчюить либы при сборке и оставить х86 и арм и будет работать везде

Супер. Вперед.

Супер. Вперед.

Уже сделано и в проде больше года

Realm не забудьте подключить только ;)

Еще можно сделать разные апк для разных архитектур

И гугл плей сам все разрулит

Realm не забудьте подключить только ;)

У меня Realm только с двумя либами и я не тащу все либы. Две достаточно чтобы покрыть все кроме MIPS

Можно один раз написать и юзать везде. Можно взять уже готовое.

И где гарантия, что ваша реализация будет работать лучше чем реалм или встроенный sqlite?) Они хотя бы уже проверенны огромным кол-вом проектов)

И где гарантия, что ваша реализация будет работать лучше чем реалм или встроенный sqlite?) Они хотя бы уже проверенны огромным кол-вом проектов)

Так свой sqlite писать не нужно. Он написан давно. Просто гугл его не обновляет. Можно пользоваться старым. А затащить новый - это от тех же разработчиков, только более свежая версия.

https://sqlite.org/android/doc/trunk/www/index.wiki

Уже все готово

Так свой sqlite писать не нужно. Он написан давно. Просто гугл его не обновляет. Можно пользоваться старым. А затащить новый - это от тех же разработчиков, только более свежая версия.

Я и говорю - а где гарантия, что с новым лайтом обертка стандартная заработает?

Хотя лично по мне совершенно все равно что тащить в проект