Самое глупое, что государство вынуждено (или делает это из вредности/зависти) защищать менее успешную компанию с менее успешным (и вероятно менее удобным/качественным) продуктом. В итоге мы имеем ограничения на успешном/удачном продукте, а на рынке (условно говоря) ликуют левые/платные/дорогие/неудобные продукты. Впрочем не похоже, что большая череда судебных исков против Google как либо пошатнёт их политику.
Как мне кажется здесь уже идёт нестыковка идей защиты компаний от крупных монополистов и текущих реалий. Что-то рано или поздно придётся менять и я надеюсь что законы будут подстраиваться под действительность, а не действительность подгоняться под существующие (иногда не самые удачные) законы, как это зачастую любят делать.
Т.е. если маленькой компании нужно как-то выживать и продвигать свой продукт на фоне схожего продукта крупной компании — нужно не судебными исками давить другую компанию, а скорее лучше заботиться о качестве предоставляемого продукта. Так или иначе на коммерческие продукты всегда есть спрос даже при наличии бесплатных аналогов.
Вообще в своё время я подумывал о таком хранении данных из приложения (просто сливать сериализовать все нужные компоненты в файлы и потом считывать), но по весьма весомым причинам, приведённым выше, я ушёл от данного «брутального» способа хранения.
Вы правы, что помимо данных таблицы при такой сериализации сливаются ещё и:
— выделение в таблице
— все изменения размеров колонок
— сортировка колонок
и пр. мелочи.
Ну, что тут можно сказать, никто не мешает отдельно или даже вместе с данными хранить (и обновлять при изменении) информацию о выделении/колонках/сортировке. Мы именно так и поступили.
И ещё одна небольшая мелочь — мы решили уйти от стандартной сериализации объектов и стали широко использовать библиотеку XStream, которая умеет легко и быстро (а также с тонной опций) переводить сериализуемые объекты в читаемые XML файлы. Советую попробовать — останетесь довольны результатом.
P.S. Если интересно — могу более подробно описать XStream/наши варианты сохранения таблиц и пр. информации.
Только есть одна проблема при сериализации Swing-компонентов, описанная прямо-таки в исходнике каждого J-компонента:
* Warning:
* Serialized objects of this class will not be compatible with
* future Swing releases. The current serialization support is
* appropriate for short term storage or RMI between applications running
* the same version of Swing. As of 1.4, support for long term storage
* of all JavaBeansTM
* has been added to the java.beans package.
* Please see {@link java.beans.XMLEncoder}.
В общем, кратко говоря, ваши данные в таком виде могут неожиданно стать нечитаемыми при переходе на более новые версии Java. А возможность сериализации подобных компонентов добавлена лишь для кратковременного хранения/передачи компонентов между Java приложениями.
Полностью защищённых систем может и нет, но достаточный уровень защиты на серверной стороне обеспечить вполне реально (без критических дыр, открывающих доступ ко всему и вся).
В любом случае, я всё веду к тому, что стоит разумно ограничивать себя при защите приложения, а так же разумно подходить к выбору платформы/языка на котором оно пишется, основываясь не только на защищённости клиента от той же декомпилляции. Всегда есть множество вариантов и защиты и взлома приложения — от всего не уберечься.
Впрочем я лично не занимаюсь написанием банковского софта и точно не знаю как у них принимаются подобные решения. Возможно причина вообще не в том, о чём мы думаем…
Сомневаюсь что из-за простоты разбора. Если только на этом базируется выбор апплетов — банковские разработчики весьма недалёкие люди.
Да, действительно, некоторые платные обфускаторы (которыми мы тоже пользуемся в своих проектах) и даже бесплатные умеют прилично запутать код, обрезать все названия, слить классы в одну большую кишку и сделать множество прочих пакостей для любителей покопаться в исходниках. Но проблемы это не решает — код по прежнему можно разобрать при должной усидчивости и терпении, коими «серьёзные» взломщики, уверен, обладают. Именно поэтому делать ставку на то, что в обфусцированном коде никто ничего не поймёт и можно воротить всё что нравится — крайне неверно. Поймут, найдут и сломают, если для них из этого будет профит (а может даже и просто из любопытства).
При корректной реализации любых банковских операций и должной защите на серверной стороне, как мне кажется, не важно какой будет клиент. Ну увидят исходники и что дальше? Если лазеек в серверной стороне нет — злоумышленники ничего и не смогут сделать.
Если какие-то взломы и происходят, то скорее по вине пользователей (увели логин/пароль от аккаунта, к примеру). От этого сложно защититься. Впрочем именно для этого и созданы различные подтверждения операций через sms, привязка к IP/машине и прочие средства защиты от постороннего доступа/проведения операций.
Не буду спорить, что многие вещи будет проще/быстрее реализовать в апплете, обладающем практически всеми возможностями полноценного десктоп-приложения на Java. Остальные же преимущества апплетов я считаю весьма необоснованными или, как минимум, спорными.
P.S. Или может я не о тех банковских клиентах думаю?..
Собственно, о чём я и говорил — в некоторых отдельных случаях действительно есть смысл пользоваться апплетами. Да и то, думаю, это больше зависит скорее от предпочитаемых разработчиками технологий, а также от поставленных им задач.
Я и не спорю что это дело можно автоматизировать :)
Просто говорю о том, что это дополнительная задача при работе с апплетами.
А если в целом об апплетах — они конечно могут быть использованы в некоторых отдельных случаях, но мне кажется что они себя практически изжили. Их конечно продолжать поддерживать браузеры, как и многие сайты до сих пор поддерживают древний IE6, но это скорее из уважения к немногим пользующимся. Дело даже не в самих апплетах, а в том, что намного проще сейчас написать приложение со схожей функциональностью на html/js, ведь их возможности уже давно перешли за грань «простых скриптиков». Подобное приложение будет работать на порядок быстрее чем апплет и не будет зазря грузить браузер и ресурсы компьютера, а так же не будет иметь проблем со совместимостью с разными платформами.
Возможно единственный более-менее востребованный вариант применения — быстрый перенос своего Swing-приложения в онлайн. Впрочем там есть свои подводные камни…
Всё верно (ну по мелочам замечания уже сделали выше), только это можно отнести не только к разработке апплетов. В принципе — разницы между апплетами и полноценными приложениями на Java достаточно мало. Скорее есть некоторые нюансы, которые стоит учитывать при написании апплетов. К примеру то, что на все нетривиальные вещи придётся прописывать дополнительные пермиссии апплету и спрашивать «дозволение» у пользователя. Также дополнительная морока с подписыванием jar'ов для апплетов…
Так или иначе фикс выборщика будет в ближайшем обновлении библиотеки. Там же я выложу и технические подробности использования библиотеки в десктоп-приложениях.
Также будет ещё несколько небольших вкусностей в 9-patch редакторе, которые уже тестируются и будут доведены до ума к релизу.
Очень сильно радует, что под разными ОС программа выглядит одинаково красиво (спасибо вашей библиотеке!)
Большая часть оформления десктопных Swing элементов уже приведена к общему для всех ОС стилю, осталось лишь сгладить некоторые углы и немного поработать над производительностью компонентов, чем я сейчас и занимаюсь :) Ну а также добавить побольше функционального «сахара», которого так нехватает при разработке разных интерфейсов.
Выложил очередное обновление — редактор приведён к более-менее итоговому виду.
Осталась последняя проблема — с выборщиком файлов. Она будет устранена с выходом новой версии Web Look and Feel библиотеки (о чём я также уведомлю в этом посте).
Загрузить новую версию можно по старым ссылкам в статье либо здесь: Запускаемый jar
Также полезно иметь под рукой свой продукт (полностью готовый и упакованный) на случай если придётся куда-то поехать и презентовать его, скажем, на чужой машине. Но это вряд ли имеет отношение к людям, работающим непосредственно в тех поддержке.
Да ладно вам, добрая половина всех офисов ИТ компаний выглядит так же. Уверен даже у того же гугла есть подобные офисы — не всё же они с помпой украшают. Просто некоторые может вообще этим не занимаются или, как минимум, не выставляют на показ — сотрудники довольны (ну или просто не показывают своего недовольства), а большего и не надо.
Насчёт столов соглашусь — недавно меняя офис также поменяли и столы на более глубокие, а также не прямые (как на фотографиях в топике), а «угловатые», чтобы на них можно было удобно работать не держа руки на весу круглые сутки.
Просто вероятно специфичные отступы (если таковые вообще понадобятся) будут задаваться уже при написании приложения в отдельных случаях. Вряд ли вам потребуется их проставлять при предварительном редактировании фона в данном редакторе — ими вы скорее всего озадачитесь только при составлении итогового интерфейса приложения.
Но для разных экранах скорее всего будут использованы и разные ресурсы (ldpi/mdpi/hdpi), впрочем согласен что могут быть и иные случаи (даже множество случаев) когда нужно указывать специфичный отступ для одного и того же исходного ресурса.
В общем — отдельно добавлю настройку задания отступов от содержимого, которые будут обсчитываться в дополнение к отступам, предоставляемым 9-patch файлом.
Насчёт цвета текста — сейчас его можно быстро переключить кликнув по итоговой картинке в просмотре. Это, впрочем, действительно неочевидно и предлагает только 2 варианта цвета. Добавлю возможность выбора цвета текста в ближайшем обновлении.
Насчёт отступов я думал немного иначе — вы же задаёте область содержимого на изображении (правой и нижней линиями) — они фактически и указывают на отступы от краёв до содержимого — они же и учитываются в предпросмотре. Можете попробовать потягать линии содержимого и увидеть как они влияют на минимальный размер изображения в предпросмотре с разными вариантами содержимого.
Впрочем непосредственно с Android проектами я мало работал и точно даже не уверен, есть ли там возможность (точнее, используется ли) задания дополнительного отступа для содержимого от «краёв», задаваемых 9-patch ресурсом. Если действительно есть и часто используется — вероятно стоит добавить подобную возможность и в предпросмотр.
Как мне кажется здесь уже идёт нестыковка идей защиты компаний от крупных монополистов и текущих реалий. Что-то рано или поздно придётся менять и я надеюсь что законы будут подстраиваться под действительность, а не действительность подгоняться под существующие (иногда не самые удачные) законы, как это зачастую любят делать.
Т.е. если маленькой компании нужно как-то выживать и продвигать свой продукт на фоне схожего продукта крупной компании — нужно не судебными исками давить другую компанию, а скорее лучше заботиться о качестве предоставляемого продукта. Так или иначе на коммерческие продукты всегда есть спрос даже при наличии бесплатных аналогов.
Вы правы, что помимо данных таблицы при такой сериализации сливаются ещё и:
— выделение в таблице
— все изменения размеров колонок
— сортировка колонок
и пр. мелочи.
Ну, что тут можно сказать, никто не мешает отдельно или даже вместе с данными хранить (и обновлять при изменении) информацию о выделении/колонках/сортировке. Мы именно так и поступили.
И ещё одна небольшая мелочь — мы решили уйти от стандартной сериализации объектов и стали широко использовать библиотеку XStream, которая умеет легко и быстро (а также с тонной опций) переводить сериализуемые объекты в читаемые XML файлы. Советую попробовать — останетесь довольны результатом.
P.S. Если интересно — могу более подробно описать XStream/наши варианты сохранения таблиц и пр. информации.
В общем, кратко говоря, ваши данные в таком виде могут неожиданно стать нечитаемыми при переходе на более новые версии Java. А возможность сериализации подобных компонентов добавлена лишь для кратковременного хранения/передачи компонентов между Java приложениями.
В любом случае, я всё веду к тому, что стоит разумно ограничивать себя при защите приложения, а так же разумно подходить к выбору платформы/языка на котором оно пишется, основываясь не только на защищённости клиента от той же декомпилляции. Всегда есть множество вариантов и защиты и взлома приложения — от всего не уберечься.
Впрочем я лично не занимаюсь написанием банковского софта и точно не знаю как у них принимаются подобные решения. Возможно причина вообще не в том, о чём мы думаем…
Да, действительно, некоторые платные обфускаторы (которыми мы тоже пользуемся в своих проектах) и даже бесплатные умеют прилично запутать код, обрезать все названия, слить классы в одну большую кишку и сделать множество прочих пакостей для любителей покопаться в исходниках. Но проблемы это не решает — код по прежнему можно разобрать при должной усидчивости и терпении, коими «серьёзные» взломщики, уверен, обладают. Именно поэтому делать ставку на то, что в обфусцированном коде никто ничего не поймёт и можно воротить всё что нравится — крайне неверно. Поймут, найдут и сломают, если для них из этого будет профит (а может даже и просто из любопытства).
При корректной реализации любых банковских операций и должной защите на серверной стороне, как мне кажется, не важно какой будет клиент. Ну увидят исходники и что дальше? Если лазеек в серверной стороне нет — злоумышленники ничего и не смогут сделать.
Если какие-то взломы и происходят, то скорее по вине пользователей (увели логин/пароль от аккаунта, к примеру). От этого сложно защититься. Впрочем именно для этого и созданы различные подтверждения операций через sms, привязка к IP/машине и прочие средства защиты от постороннего доступа/проведения операций.
Не буду спорить, что многие вещи будет проще/быстрее реализовать в апплете, обладающем практически всеми возможностями полноценного десктоп-приложения на Java. Остальные же преимущества апплетов я считаю весьма необоснованными или, как минимум, спорными.
P.S. Или может я не о тех банковских клиентах думаю?..
Просто говорю о том, что это дополнительная задача при работе с апплетами.
А если в целом об апплетах — они конечно могут быть использованы в некоторых отдельных случаях, но мне кажется что они себя практически изжили. Их конечно продолжать поддерживать браузеры, как и многие сайты до сих пор поддерживают древний IE6, но это скорее из уважения к немногим пользующимся. Дело даже не в самих апплетах, а в том, что намного проще сейчас написать приложение со схожей функциональностью на html/js, ведь их возможности уже давно перешли за грань «простых скриптиков». Подобное приложение будет работать на порядок быстрее чем апплет и не будет зазря грузить браузер и ресурсы компьютера, а так же не будет иметь проблем со совместимостью с разными платформами.
Возможно единственный более-менее востребованный вариант применения — быстрый перенос своего Swing-приложения в онлайн. Впрочем там есть свои подводные камни…
Также будет ещё несколько небольших вкусностей в 9-patch редакторе, которые уже тестируются и будут доведены до ума к релизу.
Большая часть оформления десктопных Swing элементов уже приведена к общему для всех ОС стилю, осталось лишь сгладить некоторые углы и немного поработать над производительностью компонентов, чем я сейчас и занимаюсь :) Ну а также добавить побольше функционального «сахара», которого так нехватает при разработке разных интерфейсов.
Осталась последняя проблема — с выборщиком файлов. Она будет устранена с выходом новой версии Web Look and Feel библиотеки (о чём я также уведомлю в этом посте).
Загрузить новую версию можно по старым ссылкам в статье либо здесь:
Запускаемый jar
Обновлённый интерфейс выглядит вот так:
А так в общем и целом masenka всё верно сказала.
Насчёт столов соглашусь — недавно меняя офис также поменяли и столы на более глубокие, а также не прямые (как на фотографиях в топике), а «угловатые», чтобы на них можно было удобно работать не держа руки на весу круглые сутки.
Сделаю другие важные исправления и выпущу очередную версию.
В общем — отдельно добавлю настройку задания отступов от содержимого, которые будут обсчитываться в дополнение к отступам, предоставляемым 9-patch файлом.
Скоро добавлю возможность выбора цвета.
Насчёт отступов я думал немного иначе — вы же задаёте область содержимого на изображении (правой и нижней линиями) — они фактически и указывают на отступы от краёв до содержимого — они же и учитываются в предпросмотре. Можете попробовать потягать линии содержимого и увидеть как они влияют на минимальный размер изображения в предпросмотре с разными вариантами содержимого.
Впрочем непосредственно с Android проектами я мало работал и точно даже не уверен, есть ли там возможность (точнее, используется ли) задания дополнительного отступа для содержимого от «краёв», задаваемых 9-patch ресурсом. Если действительно есть и часто используется — вероятно стоит добавить подобную возможность и в предпросмотр.