AM
Ну, идеология мультиплатформы как раз обратная -- не пытаться переиспользовать весь код, оставив ту часть, где это совсем не резонно, на откуп платформенным реализациям.
Size: a a a
2019 November 20
AM
Использовать K/N в ведре больно. В первом вышеприведенном случае вам придётся через JNI доставать и пользовать джавовые классы из нативного кода, во-втором -- наоборот. И удобных решений для обеих задач пока нет.
AM
В третьем же, где у вас будет K/JVM, вам и реализация сокетов понадобится JVM-ная. Но лучше уж иметь такое, чем доставать всё ведро через ~ж~ JNI.
A
Использовать K/N в ведре больно. В первом вышеприведенном случае вам придётся через JNI доставать и пользовать джавовые классы из нативного кода, во-втором -- наоборот. И удобных решений для обеих задач пока нет.
На самом деле это core часть которая максимально изолирована от gui, фактически создаётся поток в котором крутится цикл обработки событий неблок сокетов. Взаимодействие с приложением через сокеты также. Сейчас под андроид все это крутится в сервисе
AM
Так, пажжи. Уже есть реализация под Android, так или иначе надо писать реализацию под iOS на platform.posix. Вопрос: зачем выбрасывать текущую под ведро, если проще будет просто их обе закрыть одними экспектами и одним набором тестов?
A
Так, пажжи. Уже есть реализация под Android, так или иначе надо писать реализацию под iOS на platform.posix. Вопрос: зачем выбрасывать текущую под ведро, если проще будет просто их обе закрыть одними экспектами и одним набором тестов?
Ну там достаточно сложная логика, и вести одновременно две версии, где минимальное расхождение может привести к фатальным последствиям чревато большими усилиями и болью
A
P2P приложение
AM
Ну, просто учитывайте, что вам придётся доставать это дело в ручном режиме JNI-ем из ведра. Возможно, вы правы, и так действительно будет проще.
AM
Я думаю, рано или поздно кто-нибудь таки доберётся и запилит неблокирующие сокеты в мультиплатформе, потому с немаленькой вероятностью ваше решение вполследствии на эти рельсы можно будет поставить.
AM
Так-то в Ktor были TCP/UDP, но они пока так и не стали публичным API.
A
Так-то в Ktor были TCP/UDP, но они пока так и не стали публичным API.
Я кстати на ktor начинал, но потом на nio портировал. Ktor не устроил
AM
Ну да, сокеты там пока явно не получили должной любви. 🙂
A
Собственно ещё тогда вопрос, можно как то один kt файл подставлять как разные actual версии под обе платформы. Ну кроме как копирование после изменений
AM
Там везут HMPP, но на данный момент лёгкого пути нет. Насколько я видел, обычно люди симлинками пользуются сейчас.
A
Там везут HMPP, но на данный момент лёгкого пути нет. Насколько я видел, обычно люди симлинками пользуются сейчас.
Ага понял
A
Спасибо большое
2019 November 21
BP
Aleksei🐈
Я кстати на ktor начинал, но потом на nio портировал. Ktor не устроил
а kotlinx.io не смотрели?
AM
Последний раз, когда я туда заглядывал, там не было непосредственно сетевого и файлового I/O.
BP
Aleksei🐈
Собственно ещё тогда вопрос, можно как то один kt файл подставлять как разные actual версии под обе платформы. Ну кроме как копирование после изменений
может стоит логику гтделить от реализиции, сделать прослойку/абстракцию. а вот остальную логику взаимодействия с сокетами переложить уже на кадлую платформу
BP
Последний раз, когда я туда заглядывал, там не было непосредственно сетевого и файлового I/O.
ну там вроде переделывали его, первый вариант который в кторе, а второй вроде недавно появился. @noraltavir сильней следит за ней