Допустим есть у меня форма с кнопками и текстовыми полями. Одна из кнопок формы должна вывести на экран новые кнопки и текстовые поля. Какова логика этого действа? Мне нужно создать две формы и поочередно выводить их на дисплей?

Да, именно так. Создаешь класс - наследник Form и реализуешь в нем интерфейс CommandListener (например, . В его конструктор передаешь из другой формы (которая вызывает данную) объект Display ). Где Displayable d - объект вызывающей формы. Далее в MyForm создаешь метод (например, show()) в котором должно быть примерно следующее:
Первая команда ассоциирует слушатель событий с объектом MyForm, вторая - позволяет отобразить MyForm на мониторе. Этот метод надо вызвать в вызывающей форме, к примеру, как реакцию на нажатие в ней какой-нибудь кнопки, после чего MyForm и отобразится. CommandListener может понадобиться при возврате обратно в вызывающую форму:

Добавлено через 3 минуты и 59 секунд
ой, опечатался! В методе show надо писать

Добавлено через 7 минут и 56 секунд
В принципе, можно даже в вызывающе форме создать объект myForm класса MyForm и там же вызвать метод display.setCurrent(myForm) - результат будет тот же, но тогда  надо писать в конструкторе MyForm.

Спасибо за подробный и доступный ответ! Я только начал осваивать Java и JavaME в том числе, так что думаю эта веточка форума еще оживится в самое ближайшее время. 

А еще лучше общий Listener в мидлете  чтоб ловил и  команды и Displayable(от какой Form пришла команда)

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

Ведь действительно часто нужно по кнопке BACK вернуть предыдущую форму.

А значит этот listener должен знать не только какая форма открыта сейчас, но и какая была открыта перед ней,
чтоб обеспечить возврат. А значит нужно как-то продумывать, чтоб он всегда знал о смене текущей формы...

Можно, но излишних сложностей много.

Это сообщение отредактировал(а) oxigen - 9.2.2012, 18:30

допустим у вас формы-поля в мидлете :frm1,frm2,....,frmN.
(также все они являются потомками "деда" Displayable)
в обработчике (один ! на все формы) мидлета после каждого уловленного события вы знаете от кого пришло событие по параметру Displayable d,а также по параметру Command c что за команда.
вы же фильтруете в мидлете ,скажем 

вуаля все как на ладони никакой "статики" все "закапсулированно"...
я не пойму как еще проще организовать,тем более что такая схема была предложена
 у Пирумяна,вспомните...

Это сообщение отредактировал(а) PiyodaiSiyo - 19.2.2012, 01:44

Простой пример.
Есть 2 формы frm1 и frm2. У каждой в меню есть пункт "settings" по которому показываем форму settingsFrm.
В форме settingsFrm есть пункт "back", по которому вы должны вернуться на ту форму, из которой была открыта settings

И как это реализовать?



Да, конечно мы можем в листенере по нажатию на settings сохранять текущую форму и восстанавливать по back именно ее.

Но:
- это как раз излишняя сложность - хранить в листенере дополнительные данные о предыдущей форме. (это в простом примере только об одной)
- это будет работать ТОЛЬКО если settingsFrm будет открываться через меню. А она может и по какому-то событию открываться.




Это сообщение отредактировал(а) oxigen - 22.2.2012, 12:59

Ух! - вернулся. Получилось так что с последнего поста Джаву я забросил. Но, теперь я вновь с вами!  Почитал все что написано выше. Не знаю что я понял в моем посте от 12.1.2012, но то что написано я не сделал.  Если Pawl приведет полный пример, думаю я смогу понять. ) Пока сделал по своему. Работает. Ниже я приведу код всей программки, которая реализует навигацию по формам с одним общим слушателем и алгоритмом возврата на предыдущую форму. Это мой первый код на ООП после "Hello World!", так что судите СТРОГО! До этого я писал скрипты на процедурном, скриптовом языке AutoIt. Что я хочу? Покажите мне мои ошибки. Что я считаю за ошибку? Излишне громоздкий код, занимающий больше ресурсов чем мог бы. Плюс стиль письма и логика кода. Код должен быть максимум лаконичен, красив, быстр. Касательно логики, я решил каждую форму и все связанные с этой формой действия поместить в отдельный класс - что об этом думаете? 

oxigen, я не знаю какие Вы увидели сложности. Я реализовал возврат на предыдущую форму с помощью стека - логика придельно проста. В коде ниже можно посмотреть. 
P.S. Если переход на следующую форму идет по какому-то событию, а не через меню формы, то это же событие и будет запихивать информацию о текущей форме все в тот же стек.

Все классы находятся в пакете newpackage:

файл Midlet.java (главный класс)


Файл Stra.java


Файл Stra2.java


Файл Stra3.java


Это сообщение отредактировал(а) Kalisnik - 27.2.2012, 16:13

Сложность будет в сложном приложении.
Тут у Вас фактически паттерн MVC (Model-View-Controller) используется. 
Model - стек
View - Stra* классы
Controller - мидлет.

А MVC нужно использовать очень аккуратно и только когда без этого уж никак.
Потому что он имеет нехорошее свойство - Controller разростается с дикой скоростью и очень быстро становится категорически нечитаемым.
Сам однажды столкнулся с таким приложением. Само приложение было не то чтоб сильно сложным, но в контроллере метод переключения между формами перевалил за пол-тысячи строк и имел 5 или 6 уровней вложености.

Ну да ладно, для простых приложений это не существенно.

По поводу ООП:

1. Три абсолютно одинаковых класса  Stra, Stra2 и Stra3. Это не нужно.
Достаточно одного.



2. Никогда не обращайтесь напрямую к полям класса.

За такое будут больно бить по рукам. Все поля класса всегда должны быть объявлены как private (иногда protected - при использовании наследования) и доступ к ним только через геттеры и сеттеры.
Объяснить зачем это не так просто, просто примите это. Как то, что дорогу можно переходить только на зеленый свет.



3. Классы Stra* нужны ли вообще? Обертка вокруг формы, которая ничего по сути не делает. Тут больше подойдет наследование.





Это сообщение отредактировал(а) oxigen - 29.2.2012, 15:42

oxigen, огромнейшее спасибо! Ваш крайний пост содержит бесценную информацию для моего дальнейшего понимания Java и вообще концепции ООП. Все изложенно крайне доступно, лаконично, ни чего лишнего. По Вашим постам лекции читать можно.  

Ну и немного конкретики. Я тоже обратил внимание, что слушатель мой берет на себя всю нагрузку со всего приложения, что уже интуитивно мне не понравилось - расценил как слабое место видимо. Как же правильно переделать мой код, что бы избежать MVC? Делать для каждого класса свой контроллер (на каджый класс по слушателю)? Т.е. по сути вместо одного MVC на все приложение, создаем и инкапсулируем кучку мелких MVC'тиков?  Действительно, MVC для простых приложений не принципиально... но лучше уж сразу учится правильному коду, чем потом переучиваться. Ведь и приложения будут расти пропорционально с ростом опыта.

По поводу пункта №1. Как истенно ленивый человек, любящий подумать, я все больше понимаю красату принципов ООП.

По счет пункта №2. Получается, для каждого поля мне нужно писать свои get и set методы? А если эти поля в классе исчисляются десятками? Спрашиваю со ссылкой на первый пункт.  Хотя если серьезно, по этому поводу я немного читал. Второй пункт, если я не ошибаюсь, и есть инкапсуляция. Обращаясь к полям через методы мы обеспечиваем большую безопастность, стабильность с одной стороны, а с другой получаем больший контроль над кодом. Все верно?

И пункт №3. Комментарий "Потому что Stra теперь и есть Form" окончательно уложил и утрес мои знания о наследовании классов. До меня дошло, что наследовать можно ведь ни только свои, но и классы библиотеки Java. И то, что хоть класс и наследник, это ему ни как не мешает заниматься своими собственными делами, даже порой отличными от наследуемого класса. 

Как ни крути, очень информативный для меня пост. Еще раз спасибо!

Это сообщение отредактировал(а) Kalisnik - 29.2.2012, 23:58

MVC по своей сути нарушение инкапсуляции.
Принцип инкапсуляции можно сформулировать так: Если что-то возможно сделать внутри класса, то это нужно делать внутри класса.
Нажатие на кнопку происходит внутри формы, значит и слушать и максимально обрабатывать его нужно внутри формы.

Если есть 3 статичных формы, то хранить их можно где-то отдельно. В классе мидлета, и запрашивать по необходимости. 



С back вопрос неоднозначный на самом деле. Стек более гибкое решение, позволяет возвращаться сразу на N шагов назад и класть в него одну и ту же форму несколько раз. 

По счет пункта №2. Получается, для каждого поля мне нужно писать свои get и set методы? А если эти поля в классе исчисляются десятками? 

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

Обращаясь к полям через методы мы обеспечиваем большую безопастность, стабильность с одной стороны, а с другой получаем больший контроль над кодом. Все верно? Так и есть. Сеттер может выполнять проверку значения на допустимость. Може писать в лог. Даже если сейчас это не нужно - то предсказать, понадобится ли это в дальнейшем невозможно.
Кроме того методы доступа позволяют изменять реализацию класса не меняя его интерфейс.
Допустим сейчас есть



и вдруг понадобилось хранить этот field как Integer(автоупаковки в ME нет) или вовсе как String.
Достаточно добавить пару строк в методы доступа. А не искать по всему коду, где используется прямой доступ к полю.
Остальной код вообще не узнает о том, что тип field изменился.

Это сообщение отредактировал(а) oxigen - 1.3.2012, 18:38

А вот пример выше не совсем понятен. Если я не ошибаюсь, класс использующий какой-либо интерфейс должен в обязательном порядке реализовывать все методы используемого интерфейса. В примере выше интерфейс CommandListener реализует класс Midlet, но не реилизует метод commandAction. А в классе Stra все с точностью наоборот. Поскольку Stra не реализует интерфейс CommandListener, метод commandAction работать не должен(?). Разве что сделать наследование, либо того, либо другого класса.

З.Ы. Кстати, что-то не проверял, возможно ли множественное наследование в Java?

Это сообщение отредактировал(а) Kalisnik - 1.3.2012, 18:20

Сорь, невнимательно скопипастил.

Множественно наследовать можно только интерфейсы, но не реализацию.

Получается в каждом из обектов stra* будет свой отдельный слушатель? Эти слушатели слушают если форма не активна?

З.Ы. т.е. вопрос касательно затрат ресурсов.
З.З.Ы. Хотя с таким вопросом я наверно маху дал ))) Ок. Спасибо! На сем наверно пока все. Пойду открывать новую тему. 

Это сообщение отредактировал(а) Kalisnik - 1.3.2012, 19:02

Угу. Слушатель ничего не слушает в фоне.
Это всего лишь метод, который будет вызван после нажатия на пункт меню.
И по затратам ресурсов абсолютно неважно, в каком классе этот метод находится.