2009-06-22 5 views
4

Я нахожусь на начальных этапах проекта Blackberry/J2ME - и наряду с другими ограничениями, которые приходят с этой замечательной платформой, отсутствие поддержки для размышлений и уровень 1,3 уровня означает, что подавляющее большинство существующих контейнеров IoC непригодны для использования , (Google имеет Guice для Android без AOP, но даже это требует поддержки аннотаций).Охота на J2ME-дружественный контейнер IoC включен!

Таким образом, пространство контейнеров IoC на J2ME довольно ограничено. Единственная структура, которая привлекла мое внимание, называется Signal Framework, и это выглядит довольно многообещающе. Он пытается оставаться концептуально близким к IoC Spring Framework, реализуя небольшое подмножество его функциональных возможностей, и делает это, не полагаясь на модификацию байт-кода или на выполнение разбора xml-времени выполнения. Вместо этого он обрабатывает конфигурационные XML-файлы во время сборки для создания Java-кода, который реализует эту функциональность IoC.

Вообще говоря, генерация кода во время сборки кажется очень мудрым подходом к мобильным приложениям - и если мое приложение должно делать меньше XML-парсинга на устройстве пользователя, это тоже здорово!

Итак, что случилось с внедрением IoC на J2ME/CLDC и как вы могли погасить этот горький вкус во рту?

ответ

0

Signal Framework есть.

Обновление: к сожалению, сигнал очень недушен прямо сейчас, поэтому я собираюсь с Israfil IOC с пользовательскими дополнениями.

2

В J2ME вам необходимо уменьшить количество классов, которые вы используете, насколько это возможно, чтобы уменьшить размер файлов jar. Это приводит ко многим компромиссам дизайна, в том числе к гибкости.

Нелегко приспособиться к разработке J2ME, когда вам нужно бросить все то, что вы научились (и очень цените) об OO из окна. По правде говоря, если вы хотите, чтобы приложения, которые можно запускать на большом количестве телефонов, вам нужно очень чувствительно к ограничениям устройств.

Как таковой, я не думаю, что структура IoC будет соответствовать потребностям многих людей в разработке J2ME.

+0

Danke shön для вашего понимания, Grouchal :) Я согласен с вашими мыслями о необходимости отложить некоторые предпочтения в дизайне приложения на J2ME. Однако причина, по которой я могу позволить себе использовать инфраструктуру IoC, заключается в том, что приложение, которое я разрабатываю, будет нацелено на более мощные устройства на базе CLDC, такие как последние Blackberry и J2ME на S60 (а также Android, с некоторыми моды). –

+0

Идея ограничений, налагаемых CLDC 1.0, была фантастической в ​​то время, когда задумывался CLDC 1.0; сегодня, однако, похоже, что большинство устройств, представляющих интерес, намного мощнее и имеют больше памяти. Поэтому вопрос о том, можем ли мы передавать хорошие методы развития, такие как использование IoC для мобильной разработки Java, является довольно естественным. И, как я уже сказал, если это можно сделать с помощью генерации кода времени сборки, а не во время выполнения, и это приведет к резкому улучшению ясности организации кода - почему бы не использовать его? –

1

Возможно, вас заинтересует выезд FallME. Несмотря на то, что я не использовал его лично, это похоже на отсутствие не-смысловой структуры, созданной специально для платформы J2ME.

+0

спасибо парацикла, я посмотрю! –

1

Я наткнулся на Spring ME во время голландской конференции JUG (не имейте опыта с этим вообще).

3

Мы использовали Spring ME в TomTom. Это получилось очень хорошо.

 Смежные вопросы

  • Нет связанных вопросов^_^