2009-09-09 2 views
3

В проекте, ориентированном на максимально возможное количество телефонов-функций (Nokia 3110 Classic, Samsung E250, Motorola SLVR L7 и т. Д.), Как он должен быть разработан на высоком уровне с точки зрения структуры кода? Я не имею в виду поддержку на телефоне, потому что для этого мы используем польский.Хороший дизайн J2ME проекта

Я опытный разработчик C#, продвигающийся к разработке J2ME в моей компании. Несколько месяцев назад руководство наняло старшего разработчика J2ME, поскольку существующим разработчикам не хватало опыта J2ME. Теперь я присоединяюсь к этой команде с другим разработчиком C#, и у нас есть некоторые оговорки в отношении того, что мы видим. Хотя программное обеспечение работает и отвечает требованиям бизнеса, дизайн приложения кажется мне совершенно неправильным.

Вместо использования OO большая часть кода состоит из статических методов и констант и имеет как можно меньше классов (15, насколько я могу судить) из-за «ограничений памяти на мобильных телефонах». Некоторые из них составляют тысячи строк. По-видимому, ни один из встроенных элементов пользовательского интерфейса не используется, за исключением Canvas, поскольку они «не обеспечивают достаточного контроля».

Все формы/окна/страницы (не уверены в правильном термине) имеют статический метод в одном классе, в котором у нас есть код для настройки интерфейса этой формы/окна/страницы. Она заключается в следующем:

UiElement items[] = new UiElement[8 + (fieldCount * 4)]; 
int y = 0; 
items[y++] = new UiElement("name", UiElement.TYPE_TEXT_FIELD, "Name", TextField.ANY, true, "", true, null, -1, 0); 
items[y++] = new UiElement("address", UiElement.TYPE_TEXT_FIELD, "Mobile", TextField.PHONENUMBER, true, "", true, null, -1, 0); 
// ... 
items[y++] = UiElement.LINE; 
items[y++] = new UiElement("button", UiElement.TYPE_BUTTON, "Save", -1, false, "", true, null, UiElement.TYPE_LINK, ActionHandler.LINK_UPDATE_USER); 
items[y++] = new UiElement("", UiElement.TYPE_RED_BUTTON, "Delete user", -1, false, "", true, null, UiElement.TYPE_LINK, ActionHandler.LINK_DELETE_USER); 
items[y++] = UiElement.LINE; 
items[y++] = new UiElement("", UiElement.TYPE_LINK_ARROWS, "Back to choose category", 0, false, "", true, null, -1, ActionHandler.LINK_MC_SELECT_CATEGORY); 
items[y++] = UiElement.LINE; 

Главный конструктор UIElement является

public UiElement(String RMSref, int inputType, String displayText, int additionalInputType, boolean mandatory, String aditional, boolean selectable, Image img, int displayType, int actionLink) 

В конце этого, вызов сделан, чтобы сохранить массив элементов на класс, который расширяет Canvas. У этого класса есть метод рисования с огромным блоком переключения, разветвляющийся по типу ввода UiElement. Оттуда он переходит к статическому методу класса «графика», который имеет методы для каждого типа «управления» для обработки этой «контрольной» картины.

Фактически, кажется, что все это процедурно, когда это возможно, и использует только OO, когда это необходимо. Я спросил старшего разработчика, почему у нас нет базового класса Control, а затем подклассы этого, каждый с самодостаточной живописью, свойствами и т. Д., А не этот общий класс UiElement, и, по-видимому, это связано с тем, что множество классов используйте слишком много памяти. Мне также сказали, что на некоторых телефонах есть багги Java-времени, так что они не освобождают память правильно. Это также является причиной того, что существует только один холст.

В качестве другого примера, весь вывод текста выполняется с использованием растровых шрифтов, а не с помощью внутренней визуализации шрифтов телефона. Нам сказали, что это обеспечить равномерный рендеринг через мобильные телефоны, а не полагаться на их внутренние шрифты и размеры.

Это правильный способ сделать это? Правильно ли это сказано? Я надеюсь попытаться избежать этого превращения в представление TheDailyWTF.

+1

Я бы слушал вашего старшего разработчика J2ME, поскольку он звучит так, как будто он точно знает, что он делает для целевой платформы. И, надеюсь, он не видит этого, так как это действительно оскорбительно, чтобы сказать, что его дизайн, который является именно тем, что будет делать любой хороший J2ME, должен быть Daily WTF. – Fostah

+0

Подтверждая мой вопрос, он начал читать, как статья TDWTF, пропустив только типичную перфомансу «И никто не знал ничего лучше, пока не стало слишком поздно». Вот почему я спрашиваю - я честно не знаю ничего лучше и приветствую отзывы о том, является ли его образ правильным способом делать что-то. Я не имею в виду его, как копать его, и извините, если это произойдет именно так. – 2009-09-09 13:13:10

ответ

5

добро пожаловать в мир j2me.

Вещи улучшились немного по временам.Но то, что вы видите, на самом деле способ сделать вещи на самых старых телефонах (особенно Nokia 40 (поколение 1)) и древних samsung. Это факт, что добавленный класс добавит размер вашей банки. А поскольку некоторые телефоны накладывают ограничение на 64 Кбайт, подсчитывается количество байтов.

Если эти старые телефоны больше не нацелены, вы можете отпустить эту древнюю практику и пойти больше на путь OO.

Изображения с растровым изображением также верны. На каждом бренде телефона (даже на разных моделях той же марки) размеры шрифтов телефонов сильно различаются. На Motorola, если кто-то просит небольшой шрифт, получается огромный шрифт. Еще лучше, любой шрифт, запрошенный на мотороле, огромен и невозможен.

Достоинства и недостатки телефонных шрифтов: - Телефонные шрифты не стоят драгоценной памяти банка. Растровые шрифты стоят дорого - Растровые шрифты выглядят одинаково на любом телефоне - Телефонные шрифты могут быть нарисованы в любом цвете (растровые шрифты должны быть включены в два раза, если вы хотите иметь их в 2 цветах). - Новейшие телефоны Nokia на самом деле рисуют телефонные шрифты с использованием сглаживания, давая очень приятные результаты. Шрифты Bitmp никогда не будут сглажены, если это уже сделано в растровом изображении, а это значит, что вы можете использовать их только на одном цвете фона (один сглаженный тоже).

Во всяком случае, похоже, что у вас есть разработчик с большим опытом (багажом?) Кодирования j2me. Может быть, слишком много. Если нет необходимости ориентироваться на древние телефоны, то очистите код и сделайте его более современным.

+0

Растровый шрифт может быть палитрован, поэтому вы можете сохранить пространство Jar. Даже у не столь старого Blackberry 8320 есть много проблем, имея большое количество классов. Если вы прочтете свою документацию разработчика, u найдет такие вещи, как «Не использовать интерфейсы» – Azlam

+0

azlam: они могут, но это означает, что вам нужно изменить палитру в момент создания образа и в основном иметь 2 несжатых копии в памяти в то же время. Поэтому, если среда исполнения ограничена, этот подход также имеет свою долю проблем – Toad

2

В разработке J2ME У нас не может быть принципов OOP, лучший способ - сохранить все в одном классе, даже не имея пакетов для оптимального использования памяти. Но в программной перспективе мы идем на некоторый уровень концепций OO, таких как разделение кода на полезный набор классов и пакетов. Но тем лучше, что вы не идете на эту концепцию Sub classing. J2ME Polish действительно полезен при разработке приложений J2ME специально для общего. IMO вы идете по правильному пути, мы не можем использовать все ООП при разработке приложений J2ME из-за ограниченного размера кучи, особенно при переходе на универсальное приложение J2ME, касающееся большого количества устройств для мобильных телефонов.

1

Мой £ 0,02 стоит:

Встроенный компонент пользовательского интерфейса (LCDUI), как правило, отвратительное. Они могут быть полезны, если вы хотите, чтобы ваше приложение выглядело как «родное» приложение для телефона; однако у вас очень мало контроля над их внешностью. То, что выглядит красиво на одном телефоне, будет выглядеть ужасно и неуместно на другом. Очень сложно писать код с дружественным интерфейсом, используя LCDUI, и я бы избегал чумы.

Роллинг ваших собственных компонентов на основе полотна означает, что у вас гораздо больший контроль над их внешним видом и поведением на мобильных телефонах.

Что касается шрифтов, я лично не люблю беспокоиться о растровых шрифтах. Они медленные, тяжеловесные, громоздкие, и им может быть трудно выглядеть правильно, так как вам нужно реализовать свой собственный кернинг и т. Д., А также интернационализацию? Правда, некоторые шрифты для телефона являются отвратительными (старый Motos, в частности, как упоминал реяйер). Однако помните, что пользователь будет использовать их на этом телефоне, а тщательный дизайн пользовательского интерфейса (и реализация компонента) означает, что вы можете работать с любым шрифтом размером (обратите внимание, что причина, по которой старый Motos дает вам большой, если вы спросите для маленьких, состоит в том, что на самом деле у них есть только один шрифт).

Есть много, много непонятных ошибок в телефоне, которые вам нужно будет обойти, в зависимости от того, что делает ваше приложение. Да, некоторые телефоны имеют причуды на выделение GC/памяти, которые могут вас укусить.

Однако, если вы нацеливаете правильные телефоны с древней/низкой памятью, вам нужно перейти к полной «помещать все в один класс/метод». Любые усилия, которые вы поставили в этом отделе, будут спорными по сравнению с накладными расходами растровых шрифтов IMO.

HTH

0

I второй реестр сообщение здесь. Я хочу добавить, что строка, встроенная в код, является кошмаром обслуживания, лучше иметь их в чем-то вроде класса CustomStrings в качестве констант. То же самое с именами изображений/активов, их просто проще поддерживать.

Еще один момент, который я хочу сделать, - это начальная цель запуска для высокопроизводительных (более 64-разрядных размеров). Это так безболезненно. Позже вы можете добавить поддержку для низкоуровневой телефонной трубки.

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

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