воскресенье, 7 апреля 2013 г.

Интересная идея

NakeyMonkey

http://roman.yankovsky.me/?p=372

Со своим отношением к ней - я честно говоря так пока и не определился. Согласен со всеми названными плюсами и минусами.

У меня есть немного другие соображения про FM. Связанные скорее со скоростью. Но это надо пока конкретно замерять.

Насколько я помню историю своего знакомства с VGScene - там основные проблемы были с утечками ресурсов и с частым распределением /убиванием маленьких объектов типа TPosition и TTransform.

С этим удалось вполне себе безболезненно локально побороться.

Как в FM2 дела обстоят - ещё не знаю. Не замерял.

Ну и есть у меня ещё свои 5-ть копеек по поводу того, что не надо Widget'ы полноценные создавать. Количеством 500+. Надо делать объекты-заместители. Я у себя так делаю.

Ну и что до RichEdit - то я думаю, что его стоит с нуля писать. Я бы кстати занялся бы - если бы был уверен, что это востребовано и что авторы www.trichview.com меня не обгонят.

Ну а уж за 20 тыс долл...  600 тыс руб - если не ошибаюсь. Нормальный такой гандикап. Назову оценку "с потолка" - это человеко-год. Не в штатах конечно же. За указанное время с озвученным проектом по-моему - более-менее реально уложиться.

Жаль только у меня времени "свободного" - практически нет. Я вообще не понимаю - когда люди успевают заниматься ещё и "любительскими" проектами.

P.S. Кстати компоненты VGScene можно было запросто смешивать с VCL. Так что проблема может быть не в технической плоскости?

5 комментариев:

  1. За RichEdit я уже потихоньку взялся. Может быть и получится. Главная проблема - время, конечно же.

    ОтветитьУдалить
  2. У авторов trichview не интересовались случайно их планами?

    ОтветитьУдалить
  3. Александр,

    На момент Firemonkey 2, технология ОЧЕНЬ сырая. Все публичные попытки писать на FM (описывая это в блогах) напоминают хождение по граблям. Покажите мне пример хоть одного сколько нибудь успешного приложения под iOS или MacOS написанного на Firemonkey.

    Давайте вспомним времена появления VCL.
    Продуманный , надежный, красиво написанный VCL создал основу для компоненто писателей.
    Никогда VCL не была такой глючной как Firemonkey.
    Сейчас Firemonkey как основа не годится.

    А вот за доказательством сырости Firemonkey далеко ходить не надо:
    Обсуждение примера US Capital Trivia который EMB опубликовало на AppStore
    https://forums.embarcadero.com/thread.jspa?messageID=545107

    Простейшая форма > 20 mb приложение. Использование памяти: (real memory 257Mb, virtual memory - 640Mb).

    А тут по русски опытом делятся (там как раз про свежайший Firemonkey обсуждение):
    http://forum.ru-board.com/topic.cgi?forum=33&topic=13387&start=900

    IMHO проблема в недостаточности финансовых и людских ресурсов EMB.
    Серьезным знаком этого явлется не способность рождать технологии в EMB самостоятельно, вместо это идет скупка или исходников из opensource коммьюнити(PNG lib, FastMM, Freepascal) или покупают технологии у независимых вендоров (VGScene/DXScene, AnyDac).
    Самое печальное что купленные технологии, если они требуют доводки и полировки EMB НЕ способно довести и дополировать, а это уже полный epic fail.

    Для чего Firemonkey МОЖЕТ (хотя бы в будущем) быть применена:
    1. Кросс платформенные десктопные _бизнес_ приложения (MAC OS, WIN, Linux не поддерживаетcя)
    2. Кросс платформенные мобильные _бизнес_ приложения (iOS, Android не поддерживаетcя).
    Почему может получится - для бизнеса не так важно native look and feel (см. компоненты Java). Только вот на этом поле тогда прийдется соревноваться с Xamarin и PhoneGap.

    Где Firemonkey нет места:
    1. Коммерческие приложения (как раз которыми сторы в основном заполнены) под мобильные платформы.
    2. Коммерческие десктопные приложения.
    Причина почему пункты 1 и 2 не взлетят - требуется нейтивность контролов и скорость отрисовки на порядок лучше чем сейчас.

    Игорь.

    ОтветитьУдалить
  4. Спасибо за столь развёрнутое мнение!

    ОтветитьУдалить
  5. >>> Простейшая форма > 20 mb приложение. Использование памяти: (real memory 257Mb, virtual memory - 640Mb).

    ИМХО - я знаю в чём там проблемы.

    ОтветитьУдалить