valgreesh Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору deks Цитата: По мне - так FCL/RTL от FPC довольно скромные в сравнении с .NET/Cocoa В зачет FPC идет огромное количество сторонних компонентов и библиотек, в том числе портированых из мира дельфей. Плюс ко всему это реальная кросс-платформа, чего нет ни у дотнета (mono на каждой из поддерживаемых платформ выглядит чужеродным элементом) ни тем более у какавы. А без единой RTL разработчикам библиотек для оксиджена придется кропать свой переносимый аналог. Чего-то геморойно слишком...   Цитата: Вопрос в построении приложений - не верю, что можно переносить код без переписывания программы чуть меньше чем полностью! Это не вопрос веры Лазарус собирается и работает под несколькими ОС. Ну и довольно известные PeaZip и Transmission Remote GUI.   Цитата: Хотел бы посмотреть на пример таких приложений, которые и на телефоне, и на десктопном компе работают Игрушки более чем возможны. С приложениями других категорий это вряд ли вообще получится т.к. слишком уж разные в плане организации UX платформы. Всего записей: 292 | Зарегистр. 30-11-2011 | Отправлено: 18:00 05-06-2013

miwa Full Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору valgreesh Цитата: Игрушки более чем возможны. Хм. На 19-24" мониторе с управлением с мыши/клавы/джойстика и на 4-5" дисплее телефона одинаковая игрушка? Неужели шахматы? Всего записей: 455 | Зарегистр. 10-10-2004 | Отправлено: 18:17 05-06-2013

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору valgreesh   Я не говорю про то, что у FPC маленькая поддержка! Я указал на то, что она довольно блеклая в сравнении. И вы недооцениваете количество сторонних библиотек для Cocoa/.NEt - FPC, к сожалению, близко не валялся)) Например, найдите мне хоть один парсер для Markdown. Ну или скажите - что для FPC есть, чего нету для Cocoa/Java/.NET.   А еще я говорю о том, что кросс-платформенные приложения (multi-device) это такой сферический конь в вакууме! То есть как бы теориетически они есть, а практически сложно придумать для них нишу. Я еще верю в кросс-платформенные приложения между Win/OSX/Linux, хотя формочки переделывать придется, и Дельфи не поддерживает Win8/RT. Но при переходе от десктопа к мобильной платформе вообще многое придется переписать: начиная от схемы доступа к данным, кончая общей архитектурой классов (для экономии памяти, например). Также пока не видно возможности легко делать переход между мобильными ОС. Например, схема организации фоновых задач в iOS и Android оч разная. Также разный подход к передаче документов между приложениями - если на Андроиде традиционная файловая система, то в iOS файлами обмениваемся между приложениями (что нужно зарегистрировать в манифестах и сделать соответствующие обработчики). Я все это говорю, чтобы показать: разный дизайн приложения, мало места для разделяемого между платформами кода.   А какой код вы видите как разделяемый между платформами? На примере?     Добавлено: miwa   Ну - игры хотя бы будут иметь почти одинаковый GUI, просто разное управление. Также обычно переделывается графика, потому как на 27" и на 4" разное разрешение фигурок должно быть. И я бы сказал, что игры МОЖНО портировать, но все таки это - не КРОСС-ПЛАТФОРМЕННЫЙ код. Именно ПОРТИРОВАННЫЙ.     К тому же для игр есть небольшая обвязка с платформой - например,  GameCenter для iOS/OSX и iCloud сохранение игр. Для Android такого нету (пока, хотя на IO-2013 чего то показали аналогичное GameCenter).     Мое ИМХО - игры проще портировать, чем многие другие типы приложений. Но портировать все равно придется. Не слышал про write once - compile everywhere! Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 18:40 05-06-2013

alexgala Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору с небольшим шаманством смог поставать JEDI JVCL, по  этому принципу http://kutsoff.ru/2013/05/24/how-to-install-jcljvcl-on-delphi-xe4/ Всего записей: 93 | Зарегистр. 29-08-2011 | Отправлено: 19:45 05-06-2013

valgreesh Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору miwa Цитата: Неужели шахматы? Да ладно... Есть примеры.  И это растровая графика, с 3D должно быть проще.   deks Цитата: Например, найдите мне хоть один парсер для Markdown. В эту игру можно играть долго, но всегда с предсказуемым результатом. Не будем этого делать.   Цитата: (multi-device) это такой сферический конь в вакууме! А кто спорит? Речь о переносимости кода между близкими в функциональном смысле платформами Win/Lin/MacOS, ну и между мобильными, хотя там все сложнее.   Цитата: кончая общей архитектурой классов (для экономии памяти, например).   Это вообще странно... Лично я не занимаюсь проектированием в расчете на 16GB ОЗУ - не больше того, что требуется. Исходя из этого переделывать архитектуру не придется, однозначно. А исходя из того, что сегодняшние мобилы и планшеты по объему памяти не уступают вчерашним нетбукам говорить об экономии на спичках (а архитектура классов это спички, по сравнению с той же ретиной или FullHD) вообще смешно.   Цитата: А какой код вы видите как разделяемый между платформами? На примере? Любой библиотечный не имеющий привязок к платформе. Всегда лучше и удобнее и проще работать со знакомыми, хорошо изученными библиотеками, чем пытаться освоить что-то свое на каждой из платформ. Плюс код приложения в котором собственно и заключен функционал. Не, если прилага это что-то вроде Browse500, то тут спору нет, под каждую платформу можно ваять на родных тулах. Всего записей: 292 | Зарегистр. 30-11-2011 | Отправлено: 21:04 05-06-2013

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору valgreesh   Цитата: с предсказуемым результатом   К сожалению, Дельфи объективно на порядки менее популярный язык чем ObjC/Java/.NET. Как следствие - размер имеющейся кодовой базы. К сожалению, не в пользу паскаля!     Цитата: говорить об экономии на спичках Я лично мерил производительность FMX и iCL в приложениях с прокруткой обычного UITableView. Доложу вам что когда FMX потребляет 70-90% cpu на статическом списоке с 10 элементами, то лагает даже на iPhone5! А, на секунду, там стоит самый быстрый для iOS устройств процессор. А если на iOS лагает, то на Андроиде будет еще сильнее лагать (там все таки графика с приоритетом пользовательского уровня рисуется, а не привелигированная как на iOS).   Почему iCL не лагает? Потому как нативный TableView в iOS кэширует вообще все - он даже одинаковые элементы не создает (alloc/init), он их в пуле держит и инициализирует нужными данными по требованию. Каждый отрисованный участок экрана не перерисовывается самим iOS (CoreGraphics), а кэшируется в битмэп, который в OpenGL довольно шустро анимируется. Зачем? Потому как иначе не вытягивает мобильный процессор/GPU. К чему я это говорю? Что соврменнные мобильные устройства текущего поколения ПОКА ЕЩЕ не прощают слабо оптимизированный код. А вот без переделки классов и алгоритмов FMX не получится оптимизировать, .. По поводу retina - только усугубляет проблемы неоптимизированных программ!  Это i5/i7 и desktop-GPU FMX переваривают (и то слабо), а на мобильных даже от html5 народ отказывается - лагает..     Цитата: не занимаюсь проектированием в расчете на 16GB ОЗУ   На мобильных платформах есть куча других нюансов. Например, на iOS есть бэкап в iCloud. Важно кэшировать данные в специальную папку, которая не будет бэкапится (иначе у пользователя на ненужные данные будет уходить квота в iCloud, а там всего 5Gb бесплатно). А на десктопе в принципе пофиг куда кэш класть - не сложилось строгого разделения. Хорошо что не в program files щас .ini пишутся..   Цитата: Любой библиотечный не имеющий привязок к платформе   Скажите мне какая именно библиотека не имеет привязок к платформе? Ну из реально использующихся? Я вот только математику могу подумать - и то я их никогда не использовал. Ну пару примеров приведите? Мне лично в голову ничего не приходит!       Добавлено: Цитата: А кто спорит?   ЭМРО спорит. К сожалению, они как удила закусили: весь их твиттер в предложениях посмотреть на multi-device development! Marketing bullshit в полный рост, я почти привык. Беда, что мозги народу засирают. Интересно, кто то ж верит?!   Вот недавно ЭМРО написали что Дельфи - это true native! Не в пример всяким Xamarin и PhoneGap. Типа, Xamarin.iOS не нативный, типа он через VM исполняется, поэтому медленный! Miguel De Icaza (который Xamarin) оч удивился, даже поправил их - впрочем, на него никто внимания не обратил)) На самом деле, Xamarin.iOS как раз и является статическим компилятором. Поэтому не доступны всякие динамические возможности .NEt типа Reflection.Emit. Ну и на iOS запрещена динамическая компиляция чего-либо. Поэтому ЭМРО так слегка ввели людей в заблуждение и даже не порпавились! Не в первый раз, ага     Upd: нашел блогопост - _http://blogs.embarcadero.com/jtembarcadero/2013/04/18/true-native/ Картинку зацените, не поленились, нарисовали! Фантазеры)) Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 00:51 06-06-2013 | Исправлено: deks, 01:01 06-06-2013

valgreesh Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору deks Цитата: К сожалению, Дельфи объективно на порядки менее популярный язык чем ObjC/Java/.NET Что-то не попадаются россыпью приложения написанные под дотнет и жабу, ниша которых сосредоточена на серверной стороне темных энтерпрайзовых углов. А об обжективСи в контексте нашего разговора - мы ведь все еще о кроссплатформенной разработке говорим - вообще можно не говорить т.к. кроме макоси его просто нигде нет.   Цитата: Я лично мерил производительность FMX и iCL Не-не. Я не готов выступать адвокатом FMX т.к. говорил я о нормальном коде, а не о том ужасе, что творится в кишках обезьяны. Глядя просто на дизайн классов FMX уже ясно, что никакого проектирования, как отдельного этапа разработки, там просто не было. FMX это пример костылеобразования усугубленный перманентным дедлайном   Цитата: На мобильных платформах есть куча других нюансов. Например, на iOS есть бэкап в iCloud. Важно кэшировать данные в специальную папку, которая не будет бэкапится Мы же понимаем, что это лишь изменение пути в классе обеспечивающем работу кэша. Для этого вовсе не обязательно использовать платформенные тулы.   Цитата: Скажите мне какая именно библиотека не имеет привязок к платформе? Ну из реально использующихся? Примеров масса: SynEdit, DWScript, GLScene, THtmlViewer, Synapse, Indy, библиотеки доступа к БД, криптография... Тысячи их, перечислять можно долго. Привязка осуществляется к RTL и CL, при обеспечении портабельности которых обеспечивается и портабельность библиотек. Там где не хватает RTL и CL делается небольшой абстрагирующий слой с внутренностями из дефайнов.   Цитата: ЭМРО спорит. К сожалению, они как удила закусили: весь их твиттер в предложениях посмотреть на multi-device development! Marketing bullshit в полный рост, я почти привык. Беда, что мозги народу засирают. Эмбаркадеро таким образом, похоже, пытается просто выжить Всего записей: 292 | Зарегистр. 30-11-2011 | Отправлено: 11:55 06-06-2013

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Важно кэшировать данные в специальную папку, которая не будет бэкапится Интересно, iOS понимает, когда в папке лежит кэш, а не данные ?   http://www.brynosaurus.com/cachedir/spec.html Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 12:02 06-06-2013

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору miwa   Цитата: статистика   Рейтинг языков : http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html - Рейтинг именно Дельфи более чем в 20 раз ниже, например, Java.     Еще очень показательный - просмотр статистики по языкам репозиториев на GitHub, sf.net, Google.Code. С ходу не могу привести ссылок, но на каждом сайте где то есть. Ну например, гляньте что GitHub считает popular language в advanced search.     Arioch1   Цитата: iOS понимает, когда в папке лежит кэш, а не данные   Фактически, для приложения это выглядит просто как разные папки - типа, как User Documents и AppRoaming. Просто в iOS есть несколько типов папок: для iCloud данных (такой дропбокс от Эппла, только для приложений), для локальных данных (песочница) и для временных файлов. Папки доступны только приложению и не видны из другого приложения (sandboxing), кстати, это щас и в OSX внедряют. Ну и еще - например, когда дивайс видит, что место заканчивается, то iOS может самостоятельно потереть данные во временных папках приложений - поэтому там хранят только кэш, то есть те данные, которые можно откуда-то восстановить. Может iOS еще и iCloud трет, не в курсе.     valgreesh   Цитата: на серверной стороне темных энтерпрайзовых углов   RLY? Весь буржуйский ынтерпрайз - это Java в вариациях j2EE, EJB, TomCat, WebSphere, ... Почти все банки на java работают. На .NET тоже куча всего ынтерпрайзного, не даром девки активно в той степи работают - для них нынче VCL это legacy, а .NET это мейнстрим и продуктов для .NET у них больше гораздо.     Цитата: не обязательно использовать платформенные тулы   Для поддержки iCloud - обязательно. А хочешь Documents in iCloud, то еще и по специфическому протоколу, через UIDocument. У Андроида/Linux такго вообще нету. Похож только Dropbox Sync из SDK.   Цитата: SynEdit, DWScript, GLScene, THtmlViewer, Synapse, Indy, библиотеки доступа к БД, криптография     SynEdit, GLScene, THtmlViewer - это таки компоненты UI - не представляю их без привязки к платформе. К тому же кроме SynEdit на iOS они не нужны: GLScene не имеет смысла под iOS так как есть CoreGraphics (тот же OpenGL ES, но ускоренный аппаратно) + GLKit / SceneKit. Как только сделают SceneKit под iOS, вообще смысла в 3D фреймвоке даже среднего уровня пропадет - останутся только полноценные  игровые (не столько графические) движки высокого уровня (типа Cocos, Unity, etc) - с физикой, управлением, рисованным кастомным GUI, игровой механикой etc.   THtmlViewer на iOS смысла не имеет, есть свой крутой TWebView - это контрол с WebKit без JS-JIT-движка.     DWScript вообще нельзя по лицензии на iOS использовать внутри софта, так как это интерпретатор.     Сетевые тулзы типа Synapse/Indy плотно завязаны на сетевой стэк платформы, и я имхо  не вижу смысла в них без поддержки блоков/GCD на Cocoa: получается, что использовать нативные платформенные возможности удобнее. А для задач более высокого уровня есть куча всяких REST Kit, etc). Библиотеки доступа к БД - завязаны на сетевой стэк минимум. Ну и не принято к БД ходить с мобильных дивайсов. Есть локальная ORM CoreData (SQLite3 + отображение данных на классы) и куча фреймфорков для работы с сетевыми сервисами.     Из по-настоящему кросс-платформенного софта без привязки согласился бы с криптографией, хотя SHA1/MD5 должен быть в сетевых библиотеках платформы, также как и SSL/TLS (а значит и инфраструктура сертификатов-ключей). Шифрование прикладного уровня - да, всякие там BlueFish, BCCrypt или чего там еще есть. Upd: OpenSSL официально входит в состав OSX.         Добавлено: upd   Я так подробно пишу для того, чтобы показать - мобильные платформы имеют свою сильную специфику, и свою хорошую объектно-ориентированную плафторму. Не имеет смысла прикрывать эту платформу слоем "абстракции" сверху. Лишняя абстракция не добавляет удобства, а только мешает: все равно работать будет платформа, а значит в ней придется разбираться. Но для родных возможностей платформы есть куча документации, статей на stack overflow, примеров, библиотек и компонентов. А вот для "абстракции" ничего такого нет. А вот удобство, которое добавляет "абстракция" - спорное, потому как "абстрагированные" фичи платформы зачастую более убогие чем нативные.     Ну и при правильной архитектуре программы проще заменить "кросс-платформенный" код на имеющиеся на платформе нативные компоненты. Типа, нативный парсер JSON, нативный WebView и тп. Выигрышь будет по сопровождаемости (быстрый фикс багов) и быстрая адаптация новых версий.     Ну и финальный аргумент: вспомните историю "стокового андроида" (который на nexus идет) и кастомных "оберток" от вендоров - все вендоры лагали с выпуском апдейтов, у всех вендоров были дыры с безопасностью. Аналогия более чем прозрачна.     За сим я иссяк на предмет аргументов: свою позицию я донес, кто хотел - ее услышал)) Разделять ее я не призываю, все - имхо, Just мой взгляд на вопрос. Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 17:02 06-06-2013 | Исправлено: deks, 17:06 06-06-2013

valgreesh Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору deks Цитата: Рейтинг языков Пардон муа, но ценность этого рейтинга, как бы сказать помягше...   Цитата: Весь буржуйский ынтерпрайз - это Java в вариациях j2EE, EJB, TomCat, WebSphere Ну а я о чем говорю? В энтерпрайзах они и живут, популярного массового софта на них нет.   Цитата: не даром девки активно в той степи работают - для них нынче VCL это legacy А точнее VCL для них уже освоенная территория, а те края нет, поэтому денег там больше и работы много.   Цитата: Для поддержки iCloud - обязательно. Для поддержки специфической фичи платформы и только.   Цитата: SynEdit, GLScene, THtmlViewer - это таки компоненты UI - не представляю их без привязки к платформе И тем не менее они чудесно работают под виндами и линуксом. Ни синэдиту, ни хтмлВьюэру ничего кроме холста не требуется (мелочи вроде GDI+ несущественны т.к. из них используется лишь поддержка PNG, которая давно уже есть в pure pascal варианте). GLScene аналогично, от платформы требуется только обеспечить доступ к OpenGL API. Весь прочий их функционал, в котором и заключается основная ценность, к платформе не привязан совершенно.   Цитата:  GLScene не имеет смысла под iOS так как есть CoreGraphics Скорее CoreGraphics не имеет смысла в контексте разговора о портируемом коде.  Ну в самом деле, если у нас на руках проект основанный на GLScene, нам проще осуществить его перенос на новую платформу чем менять инструменты: язык, фреймвок и получать новый опыт разработки. Мне кажется это довольно очевидные вещи.   Цитата: THtmlViewer на iOS смысла не имеет, есть свой крутой TWebView - это контрол с WebKit без JS-JIT-движка Вообще говоря еще как имеет т.к. предоставляет возможности выходящие за рамки HTML - такие как внедрение сколь угодно сложных контролов (dbgrid например или тот же sceneViewer от GLScene) в HTML-документ благодаря поддержке кастомных тэгов. Кроме того, отображение html всегда и везде будет выглядеть одинаково и не будет зависеть от версии плтформенного движка.   Цитата: DWScript вообще нельзя по лицензии на iOS использовать внутри софта, так как это интерпретатор. Да вроде как можно. Достаточно условия соблюсти. Ну и потом, iOS не единственный вариант.   Цитата: Сетевые тулзы типа Synapse/Indy плотно завязаны на сетевой стэк платформы Вся их завязка это обертки над BSD-сокетами - тот самый абстрагирующий слой. Вся их ценность в предоставляемом функционале и куче подкапотной работы от которой они освобождают.   Цитата: получается, что использовать нативные платформенные возможности удобнее Не получается. Получается прибить себя гвоздями к единственной платформе. Чего-то мне эта идея не очень симпатична.   Цитата: Библиотеки доступа к БД - завязаны на сетевой стэк минимум Да ладно, обертка над библиотекой клиентского доступа знать ничего не знает ни про какой сетевой стек.   Цитата: Ну и не принято к БД ходить с мобильных дивайсов БД может быть использована в качестве локального хранилища. И не нужно про SQLite. Я предпочитаю FB/IB и не вижу причин отказываться от них (кроме случаев когда они на платформе не представлены).   Цитата: Есть локальная ORM CoreData (SQLite3 + отображение данных на классы) Твои ответы прямо пропаганда vendor lock-in   Цитата: хотя SHA1/MD5 должен быть в сетевых библиотеках платформы По собственному опыту могу сказать одно - хочешь беспроблемной миграции на новые версии ОС (а уж тем более при смене платформы) - все что можешь носи с собой. Поэтому если есть возможность не использовать системные возможности без видимых и ощутимых потерь я их использовать не стану - код будет иметь меньше зависимостей. Всего записей: 292 | Зарегистр. 30-11-2011 | Отправлено: 18:16 06-06-2013

alexgala Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Что за Update 1 xe4 вышел недавно? кто ставил? Всего записей: 93 | Зарегистр. 29-08-2011 | Отправлено: 06:53 07-06-2013

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору valgreesh   Цитата: ценность этого рейтинга Ну - просвятите про "правильный" и "ценный" рейтинг))   Цитата: популярного массового софта на них нет   Если "них" - это Java/.NET, то чем вам Андроид кажется малопопулярным?   Цитата: абстрагирующий слой   Ну вот и суть дискуссии - вам нравится использовать абстрагирующий слой, а я в них разочаровался. Нынче я верю только в такие слои, которые дают повышение абстракции (как давала VCL по сравнению с Win32API). А вам нравятся некие "транслирующие" слои, которые абстракцию не повышают, а просто платформенную абстракцию "транслируют" к некому кросс-платформенному API. Лично я такое не люблю, и предпочитаю сразу заюзать платформенное API. Вам это кажется полезным, что тоже ок - у кажого свой опыт и свои представления!))     Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 10:29 07-06-2013

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Oxygene Sugar - не пример такого "транслирующего слоя"  ? Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 10:54 07-06-2013

valgreesh Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору deks Цитата: Ну - просвятите про "правильный" и "ценный" рейтинг))   Беда в том, что таковых нет.   Цитата: Если "них" - это Java/.NET, то чем вам Андроид кажется малопопулярным? С Андроидом ситуация совершенно не показательна. Платформа фактически ставит вас перед выбором - либо жаба, либо NDK.   Цитата: Нынче я верю только в такие слои, которые дают повышение абстракции (как давала VCL по сравнению с Win32API). А вам нравятся некие "транслирующие" слои, которые абстракцию не повышают, а просто платформенную абстракцию "транслируют" к некому кросс-платформенному API. Лично я такое не люблю, и предпочитаю сразу заюзать платформенное API. То есть на виндах ты будешь дергать WideCharToMultiByte(), а на линуксах iconv()? Зачем? Не проще ли организовать абстракцию TEncoding и забыть о привязке к платформе, как о страшном сне? Я даже больше скажу, у меня в разработке большая библиотека, так вот для того чтоб она работала в разных версиях дельфей мне пришлось вводить небольшой абстрактный слой над RTL, иначе бы мой код утонул в дефайнах и ифдефах. Всего записей: 292 | Зарегистр. 30-11-2011 | Отправлено: 11:51 07-06-2013

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Arioch1   Цитата: Oxygene Sugar   Именно. Как слой абстракции - мне он нравится. С технической точки зрения, - это один из самых "легких" слоев, за счет использования mapped-типов. У mapped типов нет собственных данных,  методы-только inline, есть совместимость "по типу" с исходным mapped type (то есть  NSString = Sugar.String, можно Sugar.String пихать в Cocoa).   Но надобности в нем немного. Именно поэтому Sugar - это не RTL для Oxygene. Это просто опция для тех, кто любит "абстрактные" обертки))   valgreesh   Цитата: Не проще ли организовать абстракцию   Вот именно Win32/64 и Linux не имеют нормальных платформенных абстракций, у них не объектно-ориентированный API. Как вы помните, я ранее уже говорил, что VCL стала хорошим дополнением для Win, именно потому что VCL подняла уровень абстракции для Win32 API.     Но для других ОС ситуация качественно другая.     Для Win8 вроде как .NET (в части WinRT) теперь как родной. Для Java/Android и iOS/OSX есть вполне "взрослые" родные абстракции платформы.     А вот уже нормальную абстракцию я не вижу смысла "перепаковывать" в другую абстракцию. Поясню. ИМХО, почти во всех реальных случаях требуется особенности платформы минимум учесть, максимум - задействовать. ИМХО, "скрыться" от деталей реализации платформы получается только в тривиальных случаях: когда API на разных платформах делает одно и то же, просто называется по-разному. Именно об этом ваш пример с конвертацией.     Ну и что делать, когда схожее API на разных платформах делает немного разные вещи и немного по-разному работает? Типа, организации интерфейсных анимаций в WPF и Cocoa? Мы уже знаем, как делает в этом случае FMX - оно делает такие анимации само, делает это с глюками и медленно. Глюки поправимы, а вот "медленно" - может и не получится поправить. Потому как на Cocoa быстро - это когда все делает "системный" уровень, графическое ядро. А логика анимации FMX "не совместима" с логикой анимации Cocoa. Упс.   Добавлено: Гляньте - TMS прописалось про iCL. Оказывается это iOS Component Library! _http://www.tmssoftware.com/site/blog.asp?post=266 Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 18:59 07-06-2013

valgreesh Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору deks Цитата: Но надобности в нем немного. Именно поэтому Sugar - это не RTL для Oxygene. Это просто опция для тех, кто любит "абстрактные" обертки))   Без этой опции писать на кислороде после дельфей столько же смысла сколько его в том чтоб писать на шарпе или жабе. Все равно получаем привязку к конкретной платформе без малейшего шанса писать переносимый код, и все равно это другой язык. Я свой дельфийский код не смог перенести на оксиджен - не хватает языковых возможностей. В общем даже смысл рассматривать его как кандидата для миграции не большой.   Цитата: Вот именно Win32/64 и Linux не имеют нормальных платформенных абстракций, у них не объектно-ориентированный API. Это не совсем так. На виндах есть вполне себе объектные API - это COM, это реализация некоторых компонентов системы выполненная в виде COM-объектов но без поддержки инфраструктурой (Direct2D, XmlLite и другие). На линуксе также есть объектные API - это например GObject в GNOME. Мой пример с кодировкой можно было дополнить вполне себе объектной абстракцией IMultiLanguage присутствующей в виндах.   Цитата: А вот уже нормальную абстракцию я не вижу смысла "перепаковывать" в другую абстракцию. А я вижу смысл и смысл этот в написании переносимого кода. Это прекрасно демонстрирует LCL, работая над плоским win32 и объектными GTK2/Qt/Carbon/Cocoa.   Цитата: ИМХО, "скрыться" от деталей реализации платформы получается только в тривиальных случаях: когда API на разных платформах делает одно и то же, просто называется по-разному. А разве к гую это не относится? Кнопки они везде кнопки. Поля ввода они везде поля ввода. Минимальные отличия в поведении реализуются как раз на уровне абстракции. По моему Qt и LCL это хорошие примеры возможности писать переносимый софт с нативным гуем.   Цитата: Ну и что делать, когда схожее API на разных платформах делает немного разные вещи и немного по-разному работает? Типа, организации интерфейсных анимаций в WPF и Cocoa? Как раз для таких моментов и существуют слои абстрагирования. На уровне библиотеки это будет платформозависимый код, но на прикладном уровне думать об этом уже не придется.   Цитата: Мы уже знаем, как делает в этом случае FMX - оно делает такие анимации само, делает это с глюками и медленно Каково качество FMX мы так же знаем, поэтому сырую альфу вряд ли стоит рассматривать в качестве примера. Но у FMX (а точнее новой системной абстракции дельфей) есть кое что, о чем стоит упомянуть - поддержка сенсоров (в win32 присутствует в виде объектного API). Единообразная на всех платформах. Поддержка захвата и воспроизведения видео (это уже FMX) - единообразная на всех платформах, и более того - расширяемая. В этом и есть сила абстракций, мы можем писать прикладной код не беспокоясь что там творится под капотом.   Добавлено: Цитата:  TMS прописалось про iCL Мне не очень понятно, чего все так носятся с iOS и мобильными платформами вообще. Сколько на хабре было историй успеха на iOS - все сплошь игрушки/развлекашки (которым нативный гуй нужен как балерине кирзачи). На андроиде вообще не покупают нифига. Кто-то правда думает зарабатывать бизнес-приложениями на этих платформах? Всего записей: 292 | Зарегистр. 30-11-2011 | Отправлено: 21:28 07-06-2013

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору valgreesh Цитата: оксиджен - не хватает языковых возможностей Каких именно возможностей не хватило?     Цитата: А я вижу смысл Дело вкуса) Я ж говорю - у меня ничего путного не получилось, и не претендую на истину. Может, у вас получится!)   Цитата: Кнопки они везде кнопки .. но HIG разный, стилями поправить не всегда получается, почти всегда нужно перепроектирование GUI для каждой платформы. Но вы верите в возможность сделать все через слой абстракции - это ваше право) Смысла спорить нет: я просто не видел примеров когда это все хорошо работало!   Цитата: сырую альфу Если что, сырой альфой оно было когда у меня был KsDev Lifetime License, я тогда на нем под OSX пытался в Lazarus ваять)) А сейчас это уже ТЕРТИЙ мажорный релиз. просто он работает как альфа)) И как я уже приводит пример - не факт, что особенности работы всегда связаны с глюками. Иногда, как в примере с анимацией - это не будет вылечено НИКОГДА. Потому как либо анимацию быстро делает ядро ОС, либо медленно делает пользовательский уровень. Оптимизация FMX даст эффект в том, наксколько медленно будет происходить анимация. Пока - в FM3 слайд-анимация выглядит УЖАСНО с точки зрения визуальной, и жрет 90% cpu на самых топовых iOS дивайсах. Как выйдет iPhone5S (или как там его еще назовут) - проверю на нем))   Цитата: чего все так носятся с iOS и мобильными платформами вообще Потому что рынок или уже больше всех PC, или прямо в ближайшее время станет больше. И потенциал роста - колоссальный! Smart Watch, Smart Glasses - это все тоже будет под мобильными ОС. Думаю, все devices/embedded скоро переедет на Android c Linux (nas, router, media player, ...). Десктопные ОС переходят в роль "нишевого" продукта "для офиса".   Цитата: историй успеха на iOS Успех - это способ сделать что-то полезное широкому кругу посторонних людей. Не всегда это связано с именно продажей софта через магазин. Иногда достаточно возможности доступа через приложение с платформы! Я вообще зарабатываю недвижимостью и продажей пром оборудования для всякой Роснефти)) Но это не мешает мне заниматься разработкой ИТ-технологий/решений для своего бизнеса - я так развлекаюсь)) Но и конкурентное преимущество своего чбизнеса создаю!)) Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 16:39 08-06-2013

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Вопросы по Embarcadero RAD Studio XE4

Переход по форумам  Закладки   » Компьютеры Цифровое изображение Программы Microsoft Windows UNIX Другие OS Hardware В помощь сисадмину Прикладное программирование Игры Форумные игры   » Интернет Web-программирование В помощь вебмастеру Графика Хостинг Зацените-ка!   » Тематические Ikonboard v.2 Ikonboard v.3 Invision Board Другие форумы PHP-Nuke и другие порталы Мобила   » Общие Спорт Флейм Темы по региональным встречам Музыка и Кино Юмор Литература и Живопись   » Ru.Board Новости Помощь по форуму   » Андеграунд eBookz Варезник Раздачи и акции Мобильный варезник Андеграунд Игры и фильмы   » Специальные Тестирование