Что такое вообще платформы, что такое мультиплатформенные приложения?
Платформы - база, на которых работают наши приложения. Это может быть компьютер, телефон, планшет или даже часы. Каждая из этих "баз" имеет свою операционную систему, такую как Windows на компьютерах или iOS на iPhone.
Когда разработчики хотят создать приложение, которое будет работать на всех этих устройствах и операционных системах, они создают то, что называется мультиплатформенным приложением. Это приложение, которое можно установить и запустить на разных устройствах, не создавая новую отдельную версию для каждого из них.
Основные платформы, на которые разработчики обычно ориентируются:
PC: это включает в себя операционные системы, такие как Windows, macOS и Linux.
Мобильные устройства: это включает в себя Android (на большинстве смартфонов и планшетов) и iOS (на iPhone, iPad).
Веб: это интернет-браузеры, такие как Chrome, Firefox, Safari и другие.
Носимые устройства: такие как умные часы на базе Wear OS (от Google) или watchOS (от Apple).
Телевизоры и приставки: например, Android TV или Apple TV.
Чтобы создать мультиплатформенное приложение, разработчики используют специальные инструменты и технологии, которые позволяют им писать код один раз, а затем адаптировать его для разных платформ.
Зачем это вообще нужно?
Долгое время я, как разработчик, следовал простому правилу: работаю там, где платят. Но однажды понял, что слишком завяз на Apple. Пришло время расширить горизонты.
Многие системы, такие как Blackberry и Symbian, ушли в прошлое. Linux пока держится на плаву благодаря корпорациям, а BSD продолжает жить благодаря энтузиастам. Plan9? Это скорее для гиков. А активно развиваются платформы от Google, Apple и Microsoft.
А почему так произошло? Главная причина – деньги. Программисты писали свои приложения для тех платформ где платят, а остальные великолепные платформы все это время были в стороне, в результате какие-то платформы выжили, какие-то нет.
Что бы этого избежать, я для себя принял решение изменить принцип. Работаю где платят, но не забываю про остальные платформы. Т.е. на словах это безболезненное дополнение изначально принципа, к которому я призываю и всех остальных разработчиков.
Окей, с чего начать, с Golang?
Я активно программировал на Go и решил исследовать возможности создания GUI на этом языке. Одно из преимуществ Go — его мультиплатформенность. Он отлично компилируется под любые платформы прямо с целевой машины, без необходимости заморачиваться с контейнерами или кросс-компиляцией, как в случае с C/C++. Это позволяет мне с минимальными усилиями создавать приложения для любой платформы, прямо из командной строки. Такая себе простота и удобство...
При поиске инструментов для создания GUI на golang я столкнулся с рядом библиотек: вроде бы неплохие GXUI и shiny, но они больше не поддерживаются. NanoGUI-Go, переписанная с C++, всё равно требует исходного C++ и кросс-компиляции. Есть и go-astilectron — адаптация Electron, но снова не без C++. Можно использовать связку с QT, но кроссплатформенная сборка представляет сложности. Среди активно развивающихся библиотек есть Fyne и Gia, но и они имеют ограничения по платформам и предоставляют несистемный интерфейс.
Итак, удивительно, что для такого гибкого кроссплатформенного языка, как Go, создать универсальный GUI оказалось непростой задачей.
Что вообще удалось выяснить?
Когда речь идет о GUI, есть несколько ключевых моментов:
Системные библиотеки: GUI часто создается на основе системных библиотек. Это может быть напрямую через OpenGL или через специфические библиотеки операционной системы, предоставляющие элементы интерфейса.
Зависимость от C/C++: Большинство библиотек для создания GUI, к сожалению, требует использования C/C++. Это может создавать дополнительные сложности по кросс компилляции так и другие проблемы связанные с зависимостями от других библиотек, которые в свою очередь могут ограничить круг ОС/платформ за счет платфром спецефических инструкций и т.д.
Ограничения по платформам: Некоторые библиотеки ориентированы исключительно на десктопные или мобильные платформы, не предоставляя гибкости в выборе.
Нативность интерфейса: При использовании OpenGL интерфейс может не выглядеть "родным" для конкретной операционной системы. Такие приложения либо полагаются на свой уникальный дизайн элементов, либо пытаются эмулировать стандартные элементы ОС. С другой стороны, библиотеки, стремящиеся к нативному отображению, чаще всего базируются на C/C++.
Отсутствие IDE для создания интерфейсов: Не все но многие не имеют такой возможности. Т.е. создавать интерфейс придется кодом.
С учетом всего вышеуказанного, создание GUI на Golang может стать довольно сложной задачей, особенно если вы ищете кроссплатформенное решение без использования C/C++.
Что дальше, попробуем Rust?
После того как я столкнулся с проблемой отсутствия удобной GUI-библиотеки для Go, я решил пойти дальше. Моя мысль была такова: если необходимо использовать C/C++, почему бы не обратить внимание на что-то более безопасное, например C# или Rust, но при этом эффективное. Выбор пал на Rust, я даже приобрел книгу по этому языку.
Однако при изучении возможностей Rust в области GUI я столкнулся со следующим:
Druid - устаревшая библиотека.
egui - интересный вариант, но использует собственные виджеты.
orbtk - также полагается на свои виджеты и устарел.
iced - опять-таки свои виджеты и ограниченная кроссплатформенность.
dioxus - имеет большую кроссплатформенность, но, к сожалению, виджеты не системные.
tauri - по сути, легковесный аналог Electron с сопутствующими проблемами.
К тому же, я понял, что Rust не освобождает от проблем с кросс-компиляцией. Многие библиотеки включают в себя элементы на C/C++, что усложняет процесс сборки приложения.
В целом, задача создания кроссплатформенного GUI оказалась не такой уж и простой, даже с учетом многих современных инструментов.
Хмхм, что же, посмотрим на C# и .NET?
После разочарования в возможностях Rust, я решил обратить внимание на C# и экосистему .NET. И здесь был небольшой просвет!
C# с .NET оказался довольно перспективным вариантом, хотя и не лишен некоторых проблем, особенно касающихся поддержки различных платформ и архитектур процессоров. Однако, среди доступных GUI-библиотек для .NET я обнаружил Avalonia UI. Это действительно интересный и мощный инструмент, позволяющий создавать кроссплатформенные приложения. Но, как и у многих других решений, у Avalonia свои виджеты, которые, к сожалению, не выглядят нативно на всех платформах.
Кстати, для меня удивительным оказалось что .NET действительно хорошо развивается и движется в направлении кроссплатфореммности, однако на данный момент, проблемы всё те же.
Итак, взглянем на Python?
После всех моих путешествий по миру быстрых языков программирования, я решил остановить свой взгляд на чем-то менее быстродействующем. Почему бы не Python? Этот язык известен своим огромным количеством библиотек и универсальностью.
Да, я не новичок в Python. И я знал, что с его помощью можно "упаковать" код в самостоятельный исполняемый файл. Инструменты типа PyInstaller или cx_Freeze позволяют создавать так называемые "бинарники", которые можно запускать, не имея Python на компьютере.
И почему это так важно? Потому что, например, для AppStore на iOS приложения могут быть представлены только в виде бинарников. Так что язык, не способный предоставить такую возможность, не может рассматриваться как истинно мультиплатформенный.
Теперь к главной части: GUI на Python. Оказывается, создать GUI приложение на Python действительно возможно. Но здесь я столкнулся с уже знакомой мне проблемой: большинство библиотек для создания GUI снова полагается на C/C++. Некоторые из них используют OpenGL для отрисовки, другие полагаются на C/C++ на разных этапах разработки.
Окей, а что там с java?
С Java моё путешествие стало особенно увлекательным. Я знаком с Java еще со времен создания игрового сервера для Red5. Немного погуглив, быстро наткнулся на фреймворк SWT для GUI, и мгновенно собрал приложение с действительно нативным интерфейсом. SWT под капотом имеет статические библиотеки для работы с элементами операционных систем, что дает возможность его расширения для нестандартных ОС.
Кстати Java можно с помощью GraalVM собрать в бинарник.
Скажу сразу, что каждый раз погружаясь в очередной язык для выяснения как на нем сделать GUI, я шел в чаты в телеге по конкретному языку и спрашивал у профи, что они думают, чем помогут, что подскажут.
И в чате по Java мне подсказали, что Java уже по сути скорее мёртв, чем жив. Ибо после скандала компании Оракл с Гуглом появился Kotlin. Язык совместимый с Java и имеющий Kotlin/Native технологию по преобразованию кода в бинарный вид. Плюс есть и GUI Compose Multiplatform, который однако имеет свой набор витжетов не похожих на системные, именно похожих. Также увы, но не все платформы поддерживаются.
Что дальше, Flutter, react native, haxe?
Когда то давно, когда я еще писал чат на ActionScript в Badoo, и смерть ActionScript уже маячила на горизонте, появился Haxe, как универсальный язык про который я тоже вспомнил. Xamarin/Flutter/ReactNative я решил тоже посмотреть и проверить заодно. Если посмотреть на них и почитать спецификации они покрывают лишь часть платфром, либо только мобильные, либо только декстопные, либо немного тех немного других.
-
Flutter:
Создан Google и в основном используется для мобильной разработки.
Имеет собственную систему виджетов, которая выглядит одинаково хорошо на различных платформах.
Поддерживает десктопные и веб-приложения, хотя это все еще в бета-версии (на момент последнего обновления моих знаний в 2021 году).
Основан на Dart — языке, созданном Google.
-
React Native:
Создан Facebook для создания мобильных приложений на iOS и Android с помощью JavaScript и React.
Отлично подходит для разработчиков, знакомых с React.
В отличие от Flutter, React Native использует системные компоненты, что делает его приложения ближе к нативному внешнему виду и ощущению.
Есть возможность встраивания нативного кода, что увеличивает гибкость.
-
Haxe:
Это высокоуровневый язык программирования с возможностью кросскомпиляции в множество различных языков и платформ, включая JavaScript, C++, C#, Java и другие.
Имеет ряд фреймворков для разработки GUI, таких как OpenFL и Kha.
Особенно популярен среди разработчиков игр.
А xamarin по факту это уже рассмотренный ранее C# .NET от микрософт.
Может быть все таки Electron и аналоги?
Сам электрон считается универсальным средством для разработки приложений, более того имеются и более легковесные аналоги:
NW.js (ранее node-webkit): Подобно Electron, позволяет разрабатывать настольные приложения на основе веб-технологий.
Tauri: Легковесная альтернатива Electron. Использует Rust в качестве бэкенда и значительно сокращает размер исходного файла приложения.
Proton Native: Предлагает создавать настольные приложения с помощью компонентов React, но без использования веб-технологий.
Да, по сути электрон это браузер который пытается прикинуться приложением. Проблем у такого подхода хватает. более того, как бы не хотелось многим, но electron и аналоги закрывают лишь базовые платформы, и так же как остальные решения интерфейс в таких приложениях не является нативным без специальных оптимизаций, под каждую платформу. И тут встает вопрос, зачем тогда все это может просто использовать web?
Так может просто web, PWA (Progressive Web Apps), Webassembly??
PWA, это тренд направленный на будущее, представляющий истинную кросплатфроменность, НО, не дающий нативного интерфейса системы, не дающий доступа к файловой системе, имеющий достаточное количество ограничений для того что бы не использовать его в своих проектах, покрайней мере пока.
Производительность: Нативные приложения могут предоставлять лучшую производительность, особенно для графически интенсивных задач.
Доступ к API: Хотя браузеры предоставляют все больше и больше API для доступа к аппаратному обеспечению, некоторые вещи все еще доступны только для нативных приложений.
Магазины приложений: Если ваша цель - распространить приложение через App Store или Google Play, вам все равно потребуется нативная оболочка или решение вроде Cordova/PhoneGap.
Конечно, первый пункт можно побороть и повысить производительность создав webassembly код, но получить доступ к системным API всё равно пока не выйдет.
Что в итоге, Lazarus?
В итоге я совсем отчаялся найти хоть что то действительно мультиплатформенное, легко собираемое, не требующее C/C++, имеющее IDE для отрисовки нитрефейса, как вдруг здесь же на хабре мне не посоветовали посмотреть на некий Lazarus.
Как оказалось, Lazarus — это интегрированная среда разработки (IDE) для языка программирования Free Pascal. Он предоставляет визуальное проектирование форм и компонентов, что делает его похожим на старые версии Delphi. Основное преимущество Lazarus — его кроссплатформенность. С его помощью можно создавать приложения для различных операционных систем, таких как Windows, macOS, Linux, и даже для мобильных платформ.
Основные особенности и преимущества Lazarus:
Нативные приложения: Lazarus компилирует код в нативные исполняемые файлы для каждой поддерживаемой платформы.
Визуальный дизайнер: Позволяет легко создавать интерфейсы перетаскиванием компонентов.
Богатый набор компонентов: Включает в себя большое количество стандартных и дополнительных компонентов.
Открытый исходный код: Это свободное программное обеспечение, и его исходный код доступен всем.
На паскале я писал еще во времена обучения в МИРЭА. Ну и в школьные годы балуясь турбоси, я погладывал и на паскаль.
Первое с чем пришлось столкнуться с тем что среда никак не хотела видеть путь к Xcode билиотекам, я позадавал вопросы в профильном чате но результат в итоге пришлось гуглить. Второй проблемой оказалось то что для некоторых вещей пришлось пересобирать IDE их исходников.
В остальных вопросах это оказалась довольно дружелюбная среда разработки, на которой я в данный момент и остановился.
Комментарии (71)
mmarch777
27.08.2023 08:58+4Tcl/Tk пробовали?
svanichkin Автор
27.08.2023 08:58+2да, под iOS приложение пока например собрать проблемно плюс тач работать не будет, собственно здесь например об этом явно говорится: https://wiki.tcl-lang.org/page/iOS
korvint
27.08.2023 08:58+7Как это "... и почему из тысяч языков программирования он выбрал Delhi"?
Теперь мы знаем почему :-)
p.s.: лично я Delphi уважаю,и регулярно использую.
Lando
27.08.2023 08:58Ещё есть отдельная тема в кроссплатформе это единый бинарник для разных платформ. Можете посмотреть в сторону Cosmopolitan libc библиотеки.
svanichkin Автор
27.08.2023 08:58Интересно, да, по сути аналог Rosetta 2 от Apple. Но опять же я вижу что библиотека ограничена лишь десктоп платформами.
anayks
27.08.2023 08:58+3И тут встает вопрос, зачем тогда все это может просто использовать web?
Зависит от постановки задачи же? При подходе кросс-платформенности и не зависимости от ОС — достаточно браузера
Но что будет, если Вы захотите как-то начать взаимодействовать с ОС? Записать/изменить файлик в файловой системе, поменять реестр, пообщаться с консолью? Даст ли Вам это браузер с его конскими ограничениями? (Я не считаю их неправильным, просто ограничения там наоборот делаются для безопасности)
UPD: не касаясь мобильных устройств, возможно еще можно было бы взглянуть на sciter
lil_master
27.08.2023 08:58+2Вы реально считаете Лазарус более подходящим для кроссплатформенной разработки, чем Flutter или Qt?
HemulGM
27.08.2023 08:58+2Delphi тоже позволяет создавать полноценный кроссплатформенный софт под основные платформы (Windows, macOS, Linux, iOS, Android). Имеет куда большие возможности (сравнение идет с Лазарусом) по работе с GUI и даже кодом (инлайн, анонимки и т.д.)
Преимущество у Лазарус заключается в том, о чем вы в абзаце с ним даже не упомянули.
В Лазарусе "нативная GUI кроссплатформенность". Т.е. все основные контролы берутся из ОС (для Win, Mac, Linux (Qt или GTK). Т.е. вид приложения полностью зависит от версии ОС (или от версии ДЕ). Это главное преимущество, помимо OpenSource.В Делфи же GUI работает на GPU (DirectX, OpenGL, OpenGLES, Metal, Skia, ...) и следовательно контролы там полностью рисуются самим фреймворком (хотя есть возможности использовать нативные контролы, частично). В Delphi, касательно кроссплатформы используется похожий на CSS подход. Когда есть код, есть представление в виде контрола и есть визуальное представление этого контрола. При этом, визуальное представление контрола, в отличие от CSS, создается тоже визуально (из других контролов).
Например, так может выглядеть стиль для отдельного элемента списка
А так, стиль кнопки
При этом стиль любого контрола можно поменять в любой момент в рантайме
svanichkin Автор
27.08.2023 08:58я искал кроссплатформменую либу именно нативно отрисовывающую интерфейс, об этом говорится почти в каждом абзаце... именно поэтому откидывал все остальные либы.
Tuxman
27.08.2023 08:58Увы, это вас и сгубило.
Кстати, если вы таки возьмётесь за C/C++, или через обёртку на Python или чего там ещё, то Qt Вам явно не зайдёт, а вот wxWidgets окажется весьма.svanichkin Автор
27.08.2023 08:58+1ну вообще QT я поковырял, у них очень странные лицензии на мой взгляд и очень конский ценник если брать полноценную версию. QT на сайте бесплатынй что бы скачать надо постатраться, но даже не только в этом дело. C/C++ я очень люблю, но писать на них сейчас после того как избалован современными языками мне просто влом, тем более делать кросскомпиляцию под все 100500 платформ. Но, даже если закрыть на это глаза и сделать подвязку к QT тогоже Go, от тех же проблем это не избавит, для Go придется делать cgo, со всеми вытекающими и т.д... на мой взгляд это просто костыль.
Далее если смотреть на сам QT он выглядит как буд-то только что из 86 года, такой же интерфейс, такое же юзабилити... Я ничего не хочу сказать плохого или обидеть, но после Xcode он просто ужасен ???? Lazarus оказался намного более современным нежели QT, как это не пародоксально звучит.
ThreeDogNight
27.08.2023 08:58А как насчёт JavaFX? Не могу ничего сказать насчёт мобильных ОС, но на трёх основных десктопных (WIndows, Linux, MacOS) работает прекрасно.
Очень странно слышать что java скорее мертва, чем жива с учётом того, как она развивается последние лет 5 и как много проектов и компаний её используют)
svanichkin Автор
27.08.2023 08:58-1это только десктопы... ну и в профильных чатах говорят что да java скорее мертва чем жива при котлине, многие проекты потихоньку переводят на котлин, он совместим целиком и т.д.
ThreeDogNight
27.08.2023 08:58+1Возможно речь идет о Java на Android? Если да, то полностью согласен, но на бэкенде ситуация скорее обратная.
oldd
27.08.2023 08:58+1Да какая она обратная.. Трей уже 10 лет никак сделать не могут, приходится из swt использовать. Плюс непонятные глюки с QuantumRenderer, когда ни с того, ни с сего, одно ядро процессора кушается полностью и навсегда, до перезагрузки приложения.
PlatinumKiller
27.08.2023 08:58Хорошее упоменание)) если правильно помню это изначально развитие ES версии
Sly_tom_cat
27.08.2023 08:58+2Расскажу свой опыт.
Нет у меня даже не было нужды сделать мультиплатформенно. Я хотел на golang для Linux, но что бы это был индикатор в панели, а не полноценное GUI приложение.
И вот когда я копнул в эту тему (в 2017), то нашел только две разной меры кривости библиотеки для GTK и QT. Для QT там был жутковатый байндинг и собиралось это с С/С++ (т.е.забудьте про быструю компиляцию golang). Для GTK тоже был касок кода на C, но там хотябы объем был небольшой (сборка заметно медленне golang но всеже за разумное время). Проблема была только в том, что там в 2017 не было подменю в том меню, что может показать индикатор. А мне оно надо было. Пришлось самому дописывать в форке.
Но вот в прошлом году я глянул, а оказалось не только подменю появились в той библиотеке, что я для GTK использовал, но она вообще переползла на использование интерфейса индикаторов через D-bus. С одной стороны это дало возможность всю кодовую базу держать в go (быстрая сборка), а с другой - в теории это полная отвязка от GUI библиотек.
Я конечно загорелся, переполз на новую версию либы..... и погряз в куче косяков, с которыми реализуются те самые приложения, что обеспечивают серверную часть сервиса D-bus (т.е. те, тто отвечают за отрисовку GUI).А к чему я это?
Да к тому что даже на таком, казалось бы маленьком месте (иконка в панели) и даже при наличии "универсалной" шины доступа (доспной практически в любом linux с GUI), но даже тут - косяк на косяке и косяком погонят.
С одной стороны кажется, что такие шины типа D-bus как раз и могли бы позволить MULTI (в моем случае MULTI_DE всего). Но когда за реализацию серверной части отвечают несколько компаний/команд/или вообще никто, вся эа заммечательная концепция разваливается.
quverty
27.08.2023 08:58+6У меня был некоторый опыт с десктопными приложениями под Delphi/Lazarus которые успешно переделывались под различные версии Windows и Linux. Но когда я попытался переделать их под смартфон с Android, то тут сразу встал вопрос с интерфейсом. Принципы его построения отличаются от того, что было при выводе на монитор. Отношение сторон может сильно отличаться, да ещё и положение экрана может быть как вертикальное, так и горизонтальное. Так что по поводу «не создавая новую отдельную версию» - не особо получается. Кроме того, версия Lazarus для Android выглядит пока достаточно «сырой».
svanichkin Автор
27.08.2023 08:58+1ну в защиту могу сказать, что конечно адаптация интерфейса будет нужна, как же без этого, но сам факт что это будет нативно и это соберется из твоего кода без доработок это дорогого стоит...
Например у меня есть в AppStore несколько приложений, они чудесным образом работают на macOS/iPadOS/iOS, как? Очень просто такая же адаптация интерфейса, для айфона левая менюшка выступает в качестве основного меню, при нажатии на пункт показывается окно выбранного меню. На macOS же меню слева всегда есть, ну и правое окно с результатом тоже.
savostin
27.08.2023 08:58+4А как Вы сайты под мобильные и десктопы делаете? Точно так же - разные стили и даже возможно разметка. Ничего страшного. Во многих проектах сам GUI занимает много меньше, чем сама бизнес-логика, которую при наличии реального кроссплатформенного фреймворка переписывать не требуется.
haword
27.08.2023 08:58+6Лазарь под андроид это попытки что то сделать на коленке авось запустится ну и интерес пропал у разработчика. Лазарь под Андроид в данное время можно даже не рассматривать. Из паскаля только файрманки и все. Но интерфейс на нем уступает в скорости нативным приложениям. Лазарь только десктопы сейчас. А то что файрманки рисует свои элементы так это и плюс, можно своих наделать кучу.
svanichkin Автор
27.08.2023 08:58Надеюсь допилит, главное что уже что то есть ???? хотя конечно забавно, 2023 год и единственный нативный кроссплатформенный это pascal лазарус
HemulGM
27.08.2023 08:58Fgx забыл. Это фреймворк на делфи для создания нативных приложении для иос и андроид. Там со скоростью отрисовки все супер
george3
27.08.2023 08:58-2Тоже страдал от отсутствия норм web, desktop GUI, только еще и не хотел учить новый gui фреймворк для каждого языка. понял, что надо сделать самому, чтобы меньше кушать гуаны.
разработал протокол, по которому без привязки к языку работает GUI, фронт, который сначала был универсальный на flutter, бэки для Python и Go. flutter фронт пришлось закопать, Web поддержка была отвратительной. написал на VUE-quasar , отчего стал у меня чистый web.
Go не поддерживаю, потому как основное для меня AI, так что универсальный мой фреймворк счас только под Python.)
Hidden text
svanichkin Автор
27.08.2023 08:58Мое почтение за проделанную работу, но как я понимаю это просто веб морда для сервера?
Roman_Hand
27.08.2023 08:58+2Изучал Lazarus на 2 курсе колледжа, никогда не задумывался о его потенциале в кросс платформенность, спасибо за статью!
poulch
27.08.2023 08:58c++ и wxwidgets. но он не может мобильные ос. а так цитата:
wxWidgets is a C++ library that lets developers create applications for Windows, macOS, Linux and other platforms with a single code base. It has popular language bindings for Python, Ruby, Lua, Perl and several other languages, and unlike other cross-platform toolkits, wxWidgets gives applications a truly native look and feel because it uses the platform's native API rather than emulating the GUI. It's also extensive, free, open-source and mature.
И то не все так просто в дизайне интерфейса для кроссплатформенности если приложение сложное. нужно накладывать на себя ограничения в полете фантазии.
NeoCode
27.08.2023 08:58+5PC: это включает в себя операционные системы, такие как Windows, macOS и Linux.
Мобильные устройства: это включает в себя Android (на большинстве смартфонов и планшетов) и iOS (на iPhone, iPad).
Веб: это интернет-браузеры, такие как Chrome, Firefox, Safari и другие.
Носимые устройства: такие как умные часы на базе Wear OS (от Google) или watchOS (от Apple).
Телевизоры и приставки: например, Android TV или Apple TV.
А зачем нужна такая мультиплатформенность? Это же принципально разные аппаратные платформы. У разных классов устройств разное предназначение, разные аппаратные интерфейсы, и совершенно отличающиеся способы использования. Я понимаю кроссплатформенность для конкретного типа аппаратных платформ с разными операционными системами - это да, полезно. Десктоп для Windows/Linux/MacOS. Мобильное приложение для Android и iOS. Веб для любого браузера (впрочем в вебе это уже давно стандарт). Но вот зачем все это смешивать? Чтобы получить нечто формально запускающееся, но неюзабельное ни на какой платформе? ИМХО даже планшеты с десктопами смешивать нельзя. Кнопка для нажатия пальцем и кнопка для нажатия мышью - это две разные кнопки, и сам дизайн приложений должен быть совершенно разным. А если унифицировать - оно конечно заработает, но вот выглядеть будет совершенно неэстетично.
svanichkin Автор
27.08.2023 08:58ну как бы в статье речь как раз об этом... что кроссплатформенность нужна именно с нативным интерфейсом
Tuxman
27.08.2023 08:58Приложение для десктопа и для часов, из одного сорца, и чтобы нативно интерфейс показывался? Наверное Вы что-то перепутали.
svanichkin Автор
27.08.2023 08:58+2Адаптивный интерфейс, есть такая штука... например сайты с адаптивным интерфейсом, или например все мои приложения в сторе, которые как на айфоне, так и на планшете и на десктопе выглядят нативно.
HemulGM
27.08.2023 08:58+1Вот простой пример, который работает на Win, Linux, MacOS, iOS, Android. Работает и на десктопе и на планшетах и на мобилках одновременно.
Десктоп
Win11 
Linux, Garuda 
Linux, Debian 
Linux Mint, WSL 
MacOS Мобилки
iOS 
Android На планшетах скрины не нашёл у себя. Но работает и выглядит примерно как на десктопе, однако меню слева можно скрывать
DBalashov
27.08.2023 08:58это всё хорошо на максимально простых интерфейса типа "текстовое поле и кнопка".
HemulGM
27.08.2023 08:58+2Нет, это не совсем так. Я не спорю, что существуют некоторые уникальные и привычные для конкретной платформы (а точнее для форм-фактора) элементы управления. К которым все привыкли, да и в целом оправдано имеют место быть на той или иной платформе, однако это довольно редкие случаи. Действительно редкие.
Попробуйте сами предложить пример приложения, который удобен только на мобильных или наоборот, такое приложение, которое имеет место быть на мобилках, но не возможно реализовать его почти так же как на десктоп.
А пока, вот вам ещё пример.
Приложение для просмотра панорам.
Андроид 
Win11 Прошу прощения, Хабр забаговал и не дает вставить картинку в спойлер.
Это одно и то же приложение. На телефоне 2к, на десктоп FHD.
Десктоп для этого приложения, на самом деле, не был целевой платформой. Целью были планшеты, которые находятся в торговых центрах Леруа. Но как видно, приложение отлично работает и на мобилках, и на десктоп. И само-собой на планшетах.
PlatinumKiller
27.08.2023 08:58На интерфейсах где ресайз везде все хорошо обычно везде и всюду уже подход уже другой, а вот как отобразить там танцы с бубном размерностей вагон
DBalashov
27.08.2023 08:58+2Вот да. Зачем натягивать кроссплатформенность там, где она не нужна? Все эти платформы имеют большие различия - как в плане интерфейса так и в плане внешних сенсоров (тач скрин к примеру один из них). Запиливая кроссплатформенное приложение под все платформы сразу - ты получаешь пересечение множеств возможностей и тебе надо либо пользоваться ограниченным набором (который есть везде) либо подпиливать костыли под каждый конкретный девайс.
Как видица кроссплатформенность между носимыми устройствами (часами) и PC? У них кардинально разные подходы к UI, несовместимые друг с другом, просто потому что это очень разные кейсы использования.
Кроссплатформенность может быть между сходными по возможностям и кейсами использования устройствами - планшет/телефон (разные ОС), телевизор/приставка, с натяжкой - планшет/PC. Вот тут можно подумать над кроссплатформой между Android/iOS например.
svanichkin Автор
27.08.2023 08:58вот уж проблем адаптации интерфейса под телефон/планшет/десктоп давно нет...
HemulGM
27.08.2023 08:58+4На самом деле, различия между мобильными и десктоп устройствами минимальные. Основное отличие - ориентация экрана по умолчанию. Мульти тач, сенсоры есть не только в мобильных устройствах и всё это прекрасно укладывается в абстракции в фреймворке. Т.е. реализовать работу с мультитачем, движениями или сложными жестами можно и там и там. Адаптировать отображение меню в зависимости от размера приложения - тоже (при чем, это полезно не только на мобилках).
Запиливая кроссплатформенное приложение под все платформы сразу - ты получаешь пересечение множеств возможностей и тебе надо либо пользоваться ограниченным набором (который есть везде) либо подпиливать костыли под каждый конкретный девайс.
Не нужно забывать, что всё это зависит от того, как реализован фреймворк. Платформа может или не может поддерживать ту или иную функцию, и если её нужно использовать, если она есть, то можно проверить, имеется ли такая поддержка или нет.
Например, работа с буфером обмена. (далее будут примеры на Delphi + FMX)
Код
var ClipBoard: IFMXClipboardService; if TPlatformServices.Current.SupportsPlatformService(IFMXClipboardService, ClipBoard) then begin ClipBoard.SetClipboard(MemoCode.Text); ShowUIMessage('Coppied'); end else ShowUIMessage('Clipboard error');Мы просто спрашиваем, поддерживает ли наша платформа работу с буфером обмена. Да - копируем текст, нет - выводим ошибку.
Либо работа с заставкой (IFMXScreenService), либо работа с Drag&Drop (IFMXDragDropService) и так далее. Всё это легко обрабатывается, а большая часть вещей вообще уже имеет обертку, которая позволяет избежать подобного кода на проверку.
При запуске или вообще при сборке мы может разграничить те или иные визуальные части, которые не подходят для платформы. В этом нет сложности.
Сейчас в Делфи имеется бесшовная работа на всех платформах с мультитачем, геолокацией, ориентацией, блютузом, биометрией
Камерой, микрофоном, звуком, встроенными картами, платежами, адресной книгой и т.д.
Есть специальные контролы, которые адаптируются сами под платформу, например, то же меню (на винде оно слева, на андроид и иос оно плавающее). Комобоксы на винде выпадают вниз, а на мобилках нативное модальное окно со списком. Поля ввода на мобилках имеют точки выделения текста и окно с увеличением того, что под пальцем. Списки по умолчанию имеют жесты смахивания элементов.
И всегда есть возможность обратиться напрямую к API платформы и обработать действительно нестандартное действие.
Всё это я к тому, что нужно найти подходящий для вас инструмент, который реализует всё более менее удобно и не ограничит вас.
Ну и посмотрите на сайты. Они зачастую не имеют отдельную мобильную версию. Хотя, тут пример так себе. Большинство "адаптивных" сайтов не удобны для десктоп с их огромными пустыми пространствами и элементами управления. Но так или иначе, нужен подходящий инструмент.
Что касается разработки под часы или телевизор, то тут всё просто. Как правило, точно такой же функционал для часов не требуется, а для телевизора просто следует хорошо подойти к работе с клавиатурой и управлением стрелками, это тоже может быть реализовано ко всем платформам сразу (он же Tab/Shift+Tab). Однако, и для разработки одновременно под часы может тоже быть реализована механика.
На этом скрине показан механизм, позволяющий реализовать разный вид "окна" для разных форм-факторов. Т.е. чисто технически, можно без проблем адаптировать форму под часы независимо от формы для десктопа или телефона. Или просто посмотреть как она будет выглядеть или скрыть, переместить элементы управления.
PlatinumKiller
27.08.2023 08:58-2В рамках одной платформы это так и есть( а вот если взять реальность то там все по швам трешит даже на уровне iOS/iPadOS суть чтобы не только чтоб раотало но и было удобно, я про реализации сплит решений одного приложения
svanichkin Автор
27.08.2023 08:58наверно смотря как делать...Но, если что, сплит контроллер из коробки позволяет адаптивный интерфейст сделать для iOS/iPadOS
savostin
27.08.2023 08:58+1Ну, сайты для разных платформ делают разные и не плачут (почти). Почему софт нельзя делать так же?
Tuxman
27.08.2023 08:58PC: это включает в себя операционные системы, такие как Windows, macOS и Linux.
Скорее всего имелось ввиду Desktop, а не PC.
У тебя PC, а у меня Mac, так обычно говорят.PlatinumKiller
27.08.2023 08:58Возможно он имел OS, Так как его перечисление не сходится нигде кроме OS
Tuxman
27.08.2023 08:58Программисты писали свои приложения для тех платформ где платят
Дофига, конечно, платят за какой-нибудь DosBox, а также там, где у людей есть ностальгия и своя собственная мотивация.
PlatinumKiller
27.08.2023 08:58MAUI.NET тут был?
svanichkin Автор
27.08.2023 08:58Приложения пользовательского интерфейса мультиплатформенных приложений .NET (.NET MAUI) можно создавать на следующих платформах:
Android 5.0 (API 21) или более поздней версии.
iOS 10 или более поздней версии.
macOS 10.15 или более поздней версии с помощью Mac Catalyst.
Windows 11 и Windows 10 версии 1809 или более поздней с помощью библиотеки пользовательского интерфейса Windows (WinUI) 3.
PlatinumKiller
27.08.2023 08:58-1А к черту до JavaES кастуемся и не паримя вон кофеварка в дум на нем умеет
Tuxman
27.08.2023 08:58-1Таки шо вы так все боитесь, что C/C++ из-коробки не собирается под все платформы? Избалованы golang GOOS/GOARCH опцией?
Я под маком собираю под.. мак (нативный clang, или самый современный clang 16.0.6, или самый современный gcc 13.1.0), под вин (MinGW-64bit 13.2.0), или под линукс (gcc 13.2.0).
Ещё под маком я могу какой-нибудь flutter собрать подо всё, но это отдельная тема.
svanichkin Автор
27.08.2023 08:58+1можно и пешком весь мир обойти, но на самолете быстрее... весь вопрос в том сколько своего времени вы готовы потратить
pentela
27.08.2023 08:58+2Я правильно понял что единственная претензия к джаве это то, что некое комьюнити в большинстве своем перешло на котлин?
Они скорее всего до этого на скалу переходили все повально.
Сомневаюсь что джава (даже якобы мертвая) намного менее поддерживаемая чем избраный автором Free Pascal.
Проекты на джаве прекрасно собираются в андроид студии, а целевой уровень апи как был, так и остался (скорее всего) девятнадцатым - киткат. То есть спокойно можно писать приложения так же, как это делали еще до появления котлина.
Другое дело что писать на джаве может просто не нравиться, и товарищ автор искал повод от нее отказаться. Но если цель найти такой язык, на котором можно написать кучу логики и адаптировать под тучу платформ - кажется что лучше и мощнее чем джава ничего найти не получится.
Вот что действительно умерло - так это джава апплеты, так что для браузера писать gui на джаве уже не получится. А так бы был полный фарш.
svanichkin Автор
27.08.2023 08:58+1Ну для начала если внимательно почитать, то на Java я писал и раньше, и была идея даже взять именно его в основу со сборкой в бинарники (хотя это уже и устарело). И была идея расширять SWT библиотеку самостоятельно. Но, как мне объяснили в профильном чате, есть решние посвежее в виде Котлина. И на нем я тоже посмотрел все что есть на данный момент, включая компиляцию в бинарник и GUI библиотеки. Никто не спорит что Oracle пытается держаться на плаву, но против Google им стоять сложно. Старые проекты переводят по тихоньку на Котлин например.
svanichkin Автор
Если в статье не упоминается какая то библиотека, значит она не умеет в кроссплатформу либо не имеет нативного интерфейса. Я так же пробовал смотреть tcl/tk аналоги переписанные на go например. И многие либы переписанные с C/C++. В любом случае все что имеет хоть какой то вес, упомянуто в статье.
ababo
Fyne для Golang (собственные виджеты на OpenGL, но библиотека зрелая и качественная).
PlatinumKiller
Да тут другая проблема, человек прошел весь путь))) а вот что было вечно веселым так JavaES не знает, не знает Symbian и кучу его вариаций, но он прошел все пути и этапы про JavaME(Мой личный ад) ни слова
svanichkin Автор
Java была неплохим вариантом, я об этом написал ???? я было даже думал расширить SWT библиотеку своими статическими либами под экзотические платформы