Всем привет, хочу спросить совет. пишу GUI (javaFX) програмку для себя, и для работы с БД решил попробывать Exposed (давненько хотел), и там есть 2-а подхода, DSL и DAO, главное отличие что во втором варианте есть модели, я уже к ним привык, но проблема в том что мне нужно делать модели и для FX, в итоге 2-е модельки. Вот думаю какой подход выбрать, ведь модельки из DAO обновляють бд ?

Так, тему замяли, но бампну-ка я этот вопрос. Тоже интересно, кто что практикует.

Насчет "любой" не уверен, я скорее про пользовательские говорил. Еще пример: Пишу на F# + ReactNative и тоже перегуружаю пользовательский код на лету. Тк F# функциональный язык и тоже располагает к написанию функций без состояния. Тут база, что под капотом динамические райнтаймы, которые позволяют это делать, но мы сглаживаем возможные проблеммы - минимизирую стейт. P.S. И теоритически никто не мешает на Kotlin писать так же.

> F# > React Native F# на бекенде?

Так, тему замяли, но бампну-ка я этот вопрос. Тоже интересно, кто что практикует.

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

Так, тему замяли, но бампну-ка я этот вопрос. Тоже интересно, кто что практикует.

Я работаю с JavaFX, но без баз данных. Во-первых, я рекомендую использовать не чистый JavaFX, а модели из TornadoFX. Они по-моему снимают часть вопросов.

Насчет "любой" не уверен, я скорее про пользовательские говорил. Еще пример: Пишу на F# + ReactNative и тоже перегуружаю пользовательский код на лету. Тк F# функциональный язык и тоже располагает к написанию функций без состояния. Тут база, что под капотом динамические райнтаймы, которые позволяют это делать, но мы сглаживаем возможные проблеммы - минимизирую стейт. P.S. И теоритически никто не мешает на Kotlin писать так же.

В такой ситуации перегрузка публичных функций эквивалентна вызову публичных методов в ООП.

Я работаю с JavaFX, но без баз данных. Во-первых, я рекомендую использовать не чистый JavaFX, а модели из TornadoFX. Они по-моему снимают часть вопросов.

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

У меня нет личного опыта, но если моделей много, можно напороться. Все изменения надо будет делать в двух местах. Лучше сделать DSL генератор, который будет сам генерить и View и DB-модель и обойтись без орма.

У меня нет личного опыта, но если моделей много, можно напороться. Все изменения надо будет делать в двух местах. Лучше сделать DSL генератор, который будет сам генерить и View и DB-модель и обойтись без орма.

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

просто тулза для автоматизации

У меня нет личного опыта, но если моделей много, можно напороться. Все изменения надо будет делать в двух местах. Лучше сделать DSL генератор, который будет сам генерить и View и DB-модель и обойтись без орма.

я бы сделал модели-интерфесы, в котлине же можно роперти в интерфейсах, как такой подход ? не дурацкий ?

По-моему, это не будет работать. Но я не уверен

По-моему, это не будет работать. Но я не уверен

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

Явовские рефлекты поля котлиновского интерфейса видеть не будут

Да и вообще какая-то химера получается

Можно использовать всеми не любимые класс делегаты

А в anko-sqlite ктo-нибудь делал composite primary key?

По тому что не нужен ?‍♀️ rx.Single очевидно заменяется базовыми корутинами, а observable каналами

Каналы которые ниошные?

Моки это вообще зло (и rx тоже ?)

Чем рх зло то?)

Каналы которые ниошные?

https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md#channels

Каналы которые ниошные?

А, увидел ниже

Спасибо

Прочитал. Ну, нормально. Для простых флюксов подойдёт. Один момент - корутины в каналах же нормальные hot корутины? То есть начинают работать с момента send?

Зачем делать флаг, если он уже на треде есть по умолчанию? Что касается автоматического цикла, так он ресурсы будет жрать, зачем надо?

Потому что работа с интерраптед флагом требует офигенной внимательности и удержании в памяти разработчика всех методов которые сбрасывают флаг и которые этого не делают, а в многопоточных программах и так хватает мест про которые нужно подумать,по этому, имхо, конечно, но просто добавить volatile флаг много проще и удобнее.

Зачем делать флаг, если он уже на треде есть по умолчанию? Что касается автоматического цикла, так он ресурсы будет жрать, зачем надо?

А про автоматическиий цикл я имел в виду что-то вроде foreverLoop(::doSomething) и чтобы его можно было прервать, при этом прервётся так же на очердной итерации

Чем рх зло то?)

Имхо если не понятно чем рх зло, то для тебя он и не зло)

Имхо если не понятно чем рх зло, то для тебя он и не зло)

Для меня отличная технология. Просто сейчас модно стало его поносить, но никто нормально не может сказать, что с ним не так.

да ты меньше слушай эти вбросы и не обращай внимания)

Для меня отличная технология. Просто сейчас модно стало его поносить, но никто нормально не может сказать, что с ним не так.

Я могу нормально сказать и поносил его до того, как это стало мейнстримом. Точнее, не его самого, а повальное его использование для асинхронности в Android.

Rx, может, и крутая штука, но для решения очень узкого круга задач. И он вовсе не про ту асинхронность, которая нам нужна в андроиде.

class Dependency { var someString: String? = null } class Foo(val dependency: Dependency) { val bar = dependency.someString } val dependency = Dependency() dependency.someString = "string 1" println(dependency.someString) val foo = Foo(dependency) println(foo.bar) dependency.someString = "string 2" println(dependency.someString) println(foo.bar) // expected "string 2 кто может подсказать почему переменная получает значение по геттеру только во время инициализации класса, а не при каждом запросе к переменной? даже есть установить var а не val

хз реактор ахуенный

Для меня отличная технология. Просто сейчас модно стало его поносить, но никто нормально не может сказать, что с ним не так.

Я лично до сих пор предпочитаю императив вместо декларатива (модно поносить и императив)

Прочитал. Ну, нормально. Для простых флюксов подойдёт. Один момент - корутины в каналах же нормальные hot корутины? То есть начинают работать с момента send?

Cold в разработке.

Прочитал. Ну, нормально. Для простых флюксов подойдёт. Один момент - корутины в каналах же нормальные hot корутины? То есть начинают работать с момента send?

Каналы это же просто "синхронная" очередь сообщений

class Dependency { var someString: String? = null } class Foo(val dependency: Dependency) { val bar = dependency.someString } val dependency = Dependency() dependency.someString = "string 1" println(dependency.someString) val foo = Foo(dependency) println(foo.bar) dependency.someString = "string 2" println(dependency.someString) println(foo.bar) // expected "string 2 кто может подсказать почему переменная получает значение по геттеру только во время инициализации класса, а не при каждом запросе к переменной? даже есть установить var а не val

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

Cold в разработке.

То есть пример с инфинит "стримом" очень быстро вынесет память по oom?

Я могу нормально сказать и поносил его до того, как это стало мейнстримом. Точнее, не его самого, а повальное его использование для асинхронности в Android.

Это надо бомбить на людей. Технология тут причем, особенно когда она хорошая.

То есть пример с инфинит "стримом" очень быстро вынесет память по oom?

Нет, корутина саспендится, если из канала никто не читает.

Это надо бомбить на людей. Технология тут причем, особенно когда она хорошая.

Положим, отличная технология. Но в андроиде она нахрен не нужна.

Положим, отличная технология. Но в андроиде она нахрен не нужна.

Отлично ложиться на многие места:)

Нет, корутина саспендится, если из канала никто не читает.

Сразу? То есть если отправить просто send 10 раз, то 10 раз корутина не отработает?

Отлично ложиться на многие места:)

Отлично ложится процессинг стримов. А вот асинхронщину проще гнать чем-то еще

Сразу? То есть если отправить просто send 10 раз, то 10 раз корутина не отработает?

У тебя она на первом же заснёт, если никто не читает с другой стороны (или если ты не поставили явно размер буфера)

Сразу? То есть если отправить просто send 10 раз, то 10 раз корутина не отработает?

Зависит от конкретного канала. Если он с буфером на 10+ элементов, то сразу, если нет -- нет.

А, понял

Для асинхронщины просто корутины, которые стартуют сразу. Если параллельная обработка, то send нужное количество раз и подписаться на receive и при первом receive стартанут все 10 корутин в канале, так?

Для асинхронщины просто корутины, которые стартуют сразу. Если параллельная обработка, то send нужное количество раз и подписаться на receive и при первом receive стартанут все 10 корутин в канале, так?

Каналы априори последовательно принимают и последовательно отдают элементы. Если ты запустишь 10 корутин, каждая из которых сделает receive -- то будет тебе 10 асинхронных операций (сколько конкретно параллельных -- зависит от контекста корутин).

Отлично ложиться на многие места:)

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

Для асинхронщины просто корутины, которые стартуют сразу. Если параллельная обработка, то send нужное количество раз и подписаться на receive и при первом receive стартанут все 10 корутин в канале, так?

Там пример с round-robin был по ссылке -- это оно как раз.

Каналы априори последовательно принимают и последовательно отдают элементы. Если ты запустишь 10 корутин, каждая из которых сделает receive -- то будет тебе 10 асинхронных операций (сколько конкретно параллельных -- зависит от контекста корутин).

А, то есть вообще никакого параллелизма из коробки. Ну как rxjava с флетмапом обсерваблов костылем

Reactor с .parallel() наше всё

Там пример с round-robin был по ссылке -- это оно как раз.

Спасибо, вечером изучу детальнее

А, то есть вообще никакого параллелизма из коробки. Ну как rxjava с флетмапом обсерваблов костылем

Корутины изначально об асинхронности, за параллелизм отвечает контекст, на котором стартуют корутины. Контекст (точнее, диспетчер) можно создать, например, из экзекьютора с нужными параметрами по потокам, а можно обеспечить контекст, привязанный к конкретному UI-потоку для Android, JavaFX, etc. Можно сделать себе несколько разных диспетчеров -- отдельный под I/O, отдельный под вычисления тяжёлые, и будет тебе аналог шедулеров из рх.

Корутины изначально об асинхронности, за параллелизм отвечает контекст, на котором стартуют корутины. Контекст (точнее, диспетчер) можно создать, например, из экзекьютора с нужными параметрами по потокам, а можно обеспечить контекст, привязанный к конкретному UI-потоку для Android, JavaFX, etc. Можно сделать себе несколько разных диспетчеров -- отдельный под I/O, отдельный под вычисления тяжёлые, и будет тебе аналог шедулеров из рх.

Вот кстати IO диспатчер явный признак хреновости платформы (Андроид), тк нормальное io должно быть из коробки асинхронным (nio в джаве)

Вот кстати IO диспатчер явный признак хреновости платформы (Андроид), тк нормальное io должно быть из коробки асинхронным (nio в джаве)

Ждём kotlinx.io, который поможет эти кишки скрыть.

Хотя NIO ж вроде есть в ведре, если я не ошибаюсь, пусть и без NIO2.

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

спутал присваивание с геттером, позор на мою голову, спасибо.

А, то есть вообще никакого параллелизма из коробки. Ну как rxjava с флетмапом обсерваблов костылем

Есть, если просто делать запуск launch иди async несколько раз, то они по умолчанию выполняются параллельно (как уже было сказано, в зависимости от диспатчера). Просто каналы не про это.

спутал присваивание с геттером, позор на мою голову, спасибо.

Распространенная ошибка. Я так периодически накалываюсь. Там немного путает, что функция работае одинаково и с присвоением, и с телом. а проперти нет.

Ну, если прямо надо, то просто луп корутин и foreach await().

Вот кстати IO диспатчер явный признак хреновости платформы (Андроид), тк нормальное io должно быть из коробки асинхронным (nio в джаве)

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

Ну, если прямо надо, то просто луп корутин и foreach await().

Правильнее делать цикл с запуском корутин, а результаты скидывать в канал и дальше делать все преобразования в виде map-reduce на каналах. Но можно и await в цикле.

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

Так надо развиваться, а он стагнирует. А обратную совместимость при этом не уважает.

Много там всего слишком. Собственно та же проблема, что и в яве. Надо заново все переписать, отказаться от R и еще много чего, но во-первых дорого, во-вторых, сколько времени пройдет, пока кто-то начнет на этом писать?

ERROR: S client not available

Хотя есть довольно положительный опыт перехода Эплов на свифт. Там тоже боялись, что не пойдет.

Хотя есть довольно положительный опыт перехода Эплов на свифт. Там тоже боялись, что не пойдет.

В смысле что вместе с приложением носить половину рантайма ?

В смысле что вместе с приложением носить половину рантайма ?

Как будто андроид с саппорт-либами к этому не идёт.

А мне нравится, был же robovm со своей JVM в комплекте на ios

В смысле что вместе с приложением носить половину рантайма ?

Шаред либы - это страх и мрак, но видимо рано или поздно их надо будет вводить. Вообще, если учесть, что gradle сильно пустил корни в андроид разработку, почему не пойти дальше и использовать его для менаджмента шаред либ андроиде.

Положим, отличная технология. Но в андроиде она нахрен не нужна.

>не нужна нахрен, нахрен не нужна, потому что ....

>не нужна нахрен, нахрен не нужна, потому что ....

Потому что для простой асинхронщины всё есть во фреймворке. Если интересен развёрнутый длинноответ, напомни вечером, после работы перешлю.

>не нужна нахрен, нахрен не нужна, потому что ....

Как я понял потому что реакак это не асинхроное программирование, а его именно используют так

Потому что для простой асинхронщины всё есть во фреймворке. Если интересен развёрнутый длинноответ, напомни вечером, после работы перешлю.

А что ты предлагаешь для долгоиграющих фоновых задач использовать? Сервисы с лоадерами в чистом виде?

Потому что для простой асинхронщины всё есть во фреймворке. Если интересен развёрнутый длинноответ, напомни вечером, после работы перешлю.

Я на андроид лишь с любопытством поглядываю, мне было интересно лишь немного более подробной аргументации (всё есть во фреймворке - (андрюше т/е?) - достаточно). Хотя могу предположить, rx декорирует удобно и унифицировано.

А что ты предлагаешь для долгоиграющих фоновых задач использовать? Сервисы с лоадерами в чистом виде?

а что, rxJava как-то помогает выполнять долгие фоновые задачи?

Я на андроид лишь с любопытством поглядываю, мне было интересно лишь немного более подробной аргументации (всё есть во фреймворке - (андрюше т/е?) - достаточно). Хотя могу предположить, rx декорирует удобно и унифицировано.

В Android есть Java 1.6+, в т. ч. Executors

А что ты предлагаешь для долгоиграющих фоновых задач использовать? Сервисы с лоадерами в чистом виде?

Ну rx вообще будет работать только пока работает процесс. И когда процесс будет убит...

А что ты предлагаешь для долгоиграющих фоновых задач использовать? Сервисы с лоадерами в чистом виде?

WorkManager ??????

Ну rx вообще будет работать только пока работает процесс. И когда процесс будет убит...

Да, я не подумал об этом. Тогда и правда экзекьюторы уместны.

WorkManager ??????

Вязаться на плейсервисы для планирования задач — ну не знаю, никогда этого не понимал.

Вязаться на плейсервисы для планирования задач — ну не знаю, никогда этого не понимал.

Ну значит не боролся ещё с бэкграунд лимитами

Вязаться на плейсервисы для планирования задач — ну не знаю, никогда этого не понимал.

ну Evernote android-job

Ну значит не боролся ещё с бэкграунд лимитами

Не боролся. Я и ведром уже сто лет не занимался, к счастью.

Не боролся. Я и ведром уже сто лет не занимался, к счастью.

Ну ща там мало вариков, если надо что то действительно в бэкграунде делать, а не в другом потоке покуда приложение открыто =)

ну Evernote android-job

Он же под капотом все равно вяжется на play services если хочешь его использовать на 4ках, разве нет?

Он же под капотом все равно вяжется на play services если хочешь его использовать на 4ках, разве нет?

не шарю, если честно ?

есть ещё вот такая шняжка https://github.com/Doist/JobSchedulerCompat

на 4ках вроде наоборот там алармменеджер

на 4ках вариантов тока два аларм и через плейсервисы

интересно, а... ой, блин, мы ж не в андроидном чате

А так, я вот в тока начавшемся проекте заюзал workmanager (с надеждой что оно не будет сломанно в будущем =))) и доволен как слон пока что

через год что нибудь новое придумают и обьявят его deprecated ?

Тoваpищи, стoлкнулся с интеpеснoй дилеммoй: есть priority-job-queue, в кoтopoй нужнo в jobах испoльзoвать тoлькo Serializable паpаметpы пo oчевидным пpичинам. И вoт есть у меня oдин такoй job, в кoтopый идет Either<UpdateModel, CreateModel> гpубo гoвopя. Мoжете пoделиться свoим мнением, наскoлькo плoхая затея делать Either: Serializable ?

через год что нибудь новое придумают и обьявят его deprecated ?

не исключенно, но я всё равно чот то похожее каждый раз мучу =)