roboforum.ru

Ну вообще-то Java тут ни при чем, это концепция ООП. По идее, именно с изучения ООП и нужно начинать. Лучше описать задачу конкретнее, и тогда возможны и другие варианты При грамотной архитектуре вполне возможно, что классу B совсем необязательно понадобится вызывать методы класса А

Ну что за детский сад? Датчики расстояния по 5 евро дороговатые...

Наверное ООП. Но у явы есть только ООП без всяких альтернатив. ООП поддерживается практически во всех современных языках, включая C++ и VB, с которыми я хорошо знаком. Но нигде таких трудностей не возникало.
Конкретнее. Допустим, есть класс TTS, который предназначен для воспроизведения речи, в нем есть метод для запуска синтезатора и событие по окончанию воспроизведения. Из другого класса мы должны запустить воспроизведение и получить подтверждение об его окончании, чтобы двигаться дальше. Как это лучше организовать?

Добавлено спустя 49 секунд:

А где там 5? 19 вроде.

Listener'ы на события. Послать событие запуска плейера, получить событие окончания звука. Кстати, оч быстро так приедешь в архитектуру ROS.


На маусере _пара_ датчиков, уже распаянных на платки - 15 евро.
там же, сам чип, в партии 10 шт - 5 евро/шт.

Слушатель и так есть, в классе TTS, теперь он хочет поделиться этим событием с другими классами. В т.ч. и с тем, который его запускал. Что-то я туплю с этой явой. Вот есть 2 объекта, которые хотят общаться друг с другом. Что тут сложного? Но, как это просто и прозрачно сделать без всяких хелперов и меседжей. Хоть в одном классе всю прогу пиши. Видимо я до ООП еще не дорос

Да ничего. Либо как тебе раньше сказали, создал оба класса, потом друг другу их проставил через сеттеры. Нормальный ООПшный подход, но оч быстро таких классов и сеттеров станет с перебором, так что лучше сразу мессаджами(эвентами). Если впадлу самому писать поддержку сообщений, возьми гуаву, там уже оно есть.

Ну пиши, через полдня получишь спагетти, который сам уже не разберешь:)

Может и так.

и на том спасибо...

кстати, если четко уверен, что твоих классов тебе надо по одной штуке ровно, сделай через статические методы. Будет тебе не ООП.
Но это плохой совет, потом поймешь почему:)

Дык статические методы только со статическими данными работают.
Короче сделал так:
Сначала в активити создал экземпляры всех вспомогательных классов через их конструкторы,
Последним создал экземпляр диспетчера (с выдачей ему ссылок на все вспомогательные классы), который работает в основном потоке и будет со всеми общаться,
Раздал на него ссылку всем вспомогательным классам, чтобы они могли ему отвечать,
Диспетчер на прямую выполняет методы из вспомогательных классов (типа "сказать фразу"),
Возникающие во вспомогательных классах события, посылают сообщения диспетчеру в его хендлер.

Возможно грубо и тупо, но работает. Хотелось бы все-таки узнать, как это делают нормальные люди.

Ну я тебе уже рассказал:) Лучше "туда" тоже через диспетчер и события. Хотя бы из соображений, что вдруг "говорилок" будет больше одной.

Вот, скажите мне лучше такую вещь, если кто-то из читающих разбирался с распознавалкой речи под андроид, т.к. мне кажется, что я столкнулся с неразрешимой проблемой…
После долгого гугленья и экспериментов, я сделал для себя следующие вывод:
Гугловский движок не рассчитан на возможность непрерывного распознавания. Обычный сеанс проходит так: вызвали распознавалку, появилось окошко с микрофоном одновременно со звуковым оповещением и через пару секунд пошла запись. Если в течении 5 секунд ничего не услышано, либо не удалось ничего распознать, то появится соответствующая объява с предложением повторить сеанс распознования.
Нам такой вариант не подходит, т.к. робот должен слушать эфир непрерывно, когда сам не говорит. И тыкать ему пальцами в экран не предполагается. Т.е. сервис надо все время автоматически перезапускать.
От гугловских окошек с микрофонов удалось избавиться с помощью RecognitionListener. От писка, оповещающего о начале процесса распознавания избавиться не удается, можно только его приглушить, отключив звук на время писка. Факт в том, что движок распознавалки делает секундную паузу после запуска, перед тем, как начать слушать. Получается цикл 5 секунд слушает, 1 секунду глухой. Время в 5 секунд теоретически можно увеличить. Однако на практике ничего не меняется, по крайней мере в моем телефоне.
Отношение 5:1 конечно не маленькое, но на практике куски фраз часто пропадают, если начал говорить в ту злосчастную секунду.
Как решение этой проблемы записывать речь во FLAC и отправлять на онлайн распознавалку. Но, это значит сделать робота полностью интернетозависимым, чего не хотелось бы.
У кого-нибудь есть мысли по этому поводу?

Распознавалка и так инет-зависмая ЕМНИП.
Все время слушать и распознавать тоже не вариант - а)будет жрать батарею по-дикому, б) он тебе там нараспознает и навыполнят - рад не будешь. Не зря же они свой "окей, гугл" придумали

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

Похоже я тут один остался.
Для затравки хочу попросить протестировать «умника» на разных смартфонах на предмет синтеза/распознавания голоса. Желательно разными голосами, на разных расстояниях. Чтобы сделать выводы, стоит ли игра свеч.

Издеваисси? Ты выложи куда-нибудь .apk, а здесь штрих-код и короткую ссылку положи. А то ведь это аццкий геморрой с форума через zip в телефон загонять.
Ты, кста, не один. Я тут подумал - наверное постараюсь забабахать аппаратную платформу. И датчики те на пробу закажу. Но вот твои архитектурные подходы меня совсем не радуют. Поэтому молчу.

ЗЫ. нужна идея по моторам. простые, дешевые, с энкодерами, под 3В питания, со внятной надежностью.