Не нужен.

может ты и прав

а я тут пишу приложеньку на 4 экрана

но запихнул в нее mvp+clean, databinding, retrofit2, rx - и все это на котлине

^___^' так что я бы с тобой не согласился

прикольно же - оттачивать мастерство

прикольно же - оттачивать мастерство

Ты чтото попутал. Если бы ты написал мини версии этих фреймворков - это было бы мастерство.

ну, для меня пока мастерство - это внедрять эти вещи в проект, чтобы нормально все работало и было понятно

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

кто юзал sparkjava со спрингом

кто юзал sparkjava со спрингом

в одном проекте? они разве не самодостаточны?

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

я прост не пойму как спринг конфиги врубить в нем

зато спринг большой, и мешать его с кем-то я смысла не вижу.

это просто замена громоздким контроллерам

как будто джек не отключил или ява еще 8-я

compileOptions { sourceCompatibility JavaVersion.VERSION_1_7 targetCompatibility JavaVersion.VERSION_1_7 incremental true } jackOptions { enabled false }

эх, я пропустил)

зовите, если что)

А реально как то попапку, который появляется от setError() сказать "как" именно встать?

Типа сверху там а не снизу

Кто может посоветовать, как лучше хранить данные (какую ORM использовать)? Критерии такие: - довольно сложная схема данных (более 20 таблиц, есть справочники) - удобство маппинга Json-ов из API на схему данных - много вложенных сущностей и большой уровень вложенности, удобство работы с такими сущностями - мало инсертов, много селектов - объём данных небольшой (скорее всего) - возможность удобно сериализовать массивы, хешмапы, итд Сейчас использую OrmLite, в целом всё работает, но приходится писать очень много бойлерплейта, на каждую сущность - кучу кода для каскадного создания/удаления. Неудобно хранить вещи типа ArrayList<Integer>, HashMap<String, Data> - нужно либо сериализовать в блоб, либо создавать по таблице на каждую коллекцию. Блобы потом неудобно смотреть в редакторе бд, они не human-readable. Также есть сложности с сериализацией final классов, у которых не имплементирован Serializable Кроме того, есть проблемы производительности, видимо из-за большого числа вложенных коллекций, похоже тянутся все связанные сущности по foreign-аннотациям. Присматриваюсь к Realm, есть смысл?

realm не orm, а отдельная БД

nosql

Со своими заморочками, с которыми придется разбираться

По орм из применяемых понравилась GreenDao - основана на кодогенерации много бойлерплэйта писань не нужно

Коллега iOSник говорит что у него попроще с этим, там львиную долю всех рутинных операций разруливает CoreData и маппилка, у нас есть что-то подобное?

нет

По орм из применяемых понравилась GreenDao - основана на кодогенерации много бойлерплэйта писань не нужно

в сравнении с orm lite или просто понравилась?

в сравнении с orm lite или просто понравилась?

нет лайт не использовал, до этого щупал sugarorm - но там вообще мамонт :)

Просто ответил на твой пункт о бойлерплэйт

спасибо а как у неё дела с сохранением массива интов например? это будет блоб или что-то более удобное?

Если SQL то GreenDAO лучше имхо

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

но и у гриндао есть большой минус, котороо нет у того же ормлайта

Например пришел json List<Object> и в Object еще один <List> то он н добави все сразу автмоатически и связи не сделает. Нжно сначала доабвить одно, потом другое и так для всего

Ну и удаление в таком же виде. DeeleteBuilder'a нету и подобного. Нужного сначала одно удалить, потом удалить колелкции все поочереди

Может стоит nosql попробовать?

Народ, кто работал с Yandex Speech Kit? Почему-то очень тихо говорит голос. Есть какие-нибудь text-to-speech либы кроме гугла?

Может стоит nosql попробовать?

я с ормлайта на реалм перешел, доволен как слон :D

я с ормлайта на реалм перешел, доволен как слон :D

о, это интересно в чём больше всего удобство проявляется?

может вообще как-то можно сделать при старте приложения один отдельный поток для сети и бд и делать в нём всё синхронно без коллбэков и всяких проблем многопоточности типа рейс-кондишнов/дедлоков?

Например что с бд можно работать прям из UI треда и оно не будет содавать лаги при скроллинге и прочим. Реалм через прокси обьекты работает

ERROR: S client not available

и листенеры что в бд поменялось есть

а если будет запись одновременно из ui треда и из асинктаска ?

из любого потока

там сильно быстро запись происходит, ты не заметишь даже )

я огроменные джсоны в него сувоал за пару секунд

там сильно быстро запись происходит, ты не заметишь даже )

с записью надо очень осторожно )

там есть одно но

с ui треда не стоит запись делать

Я про простые записи с UI треда

которые там меньше 1мс занимают

если в фоне буде паралельно другая транзакция, то она заблочит все другие транзакции

транзакции атомарные

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

нельзя один бэкграунд тред создать и в нём все делать? или так никто не делает?

при старте аппы например

Это так не работает :)

У реалма обьекты между потоками не шарятся

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

да, реалм не thread safe

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