Как бы я обменивался чатом / набросками в реальном времени на Android?

Question

Как бы я обменивался чатом / набросками в реальном времени на Android?

1

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

Эскиз на сенсорном экране должен быть довольно простым, также предоставляя пользователю выбор цвета/кисти, ластик и т.д. Мне нужно будет записывать ввод пользователя в какие-то сообщения, каждый из которых будет описывать действие эскиза, которое потребуется для повторного воспроизведения на удаленном участнике.

Но как бы эти два пользователя обменивались данными? Я думаю о JSON + AppEngine + XMPP.

Я бы сериализовал действия эскиза из client A в JSON и ввел их в AppEngine, чтобы их хранить. Этот подход - хранить материал на сервере - лучше, чем соединение P2P? Возможно, это приведет к значительному отставанию от телефона A- > AppEngine- > телефона B в оба конца.
Как client B получить сообщение? Я не могу иметь постоянного открытого подключения к AppEngine. Есть что-то о push-уведомлениях в этом вопросе. Если XMPP не работает, нужно ли было бы опросить сервер?

Axarydax 28 дек. 2010, в 18:34

Источник

0

Я думаю, что каждый клиент может хранить историю на сервере или события рисования (описано в JSon и т. Д.). В каждом случае рисования это будет выдвигать новую информацию на сервер. Между тем, каждые N секунд клиент будет извлекать версию последних операций рисования из других клиентов и, если они различаются, загружать их. Похоже, хороший проект, дайте мне знать больше :)
Sebastian Roth 28 дек. 2010, в 17:53

Теги:

android

google-app-engine

chat

xmpp

2 ответа

2

Это очень широкий вопрос, который имеет много разных ответов. Если бы это было до меня, я бы, наверное, пошел с опросом. Вы не хотите, чтобы постоянное соединение и использование чего-то вроде Google Cloud2Device могло быть немного переборщиком для чего-то подобного. Я бы предположил, что это будет выглядеть примерно так:

Клиент A и Клиент B инициируют соединение друг с другом. Они оба получают токен сеанса.
Клиент A рисует что-то на экране. Выделенные точки отправляются на центральный сервер и сохраняются вместе с токеном сеанса.
Клиент B проверяет центральный сервер на наличие новых точек, проходя через его токен сеанса.
Полученные точки отображаются на экране клиента B.
Предыдущие сохраненные точки удаляются.
Повтор.

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

Jason L. 28 дек. 2010, в 16:35

1

API «облако на устройство» идеально подходит для этого. Я не вижу, что делает это «излишним».
Nick Johnson 05 янв. 2011, в 02:02
0

@ Ник да, Cloud to Device выглядит именно так, как мне нужно для уведомления клиентов. +1 за комментарий
Axarydax 09 янв. 2011, в 11:03
0

@ Ник - Честно говоря, у меня нет веских причин для этого комментария. Я предполагаю, что все сводится к тому, как я использовал C2D API, который был для полного администрирования на уровне устройств сотен устройств. Я всегда просто чувствовал, что для одного человека одному человеку существуют «более простые» решения. Я могу ошибаться, как известно, случалось :)
Jason L. 09 янв. 2011, в 14:08

Показать ещё 1 комментарий

Ещё вопросы

Я думаю, что каждый клиент может хранить историю на сервере или события рисования (описано в JSon и т. Д.). В каждом случае рисования это будет выдвигать новую информацию на сервер. Между тем, каждые N секунд клиент будет извлекать версию последних операций рисования из других клиентов и, если они различаются, загружать их. Похоже, хороший проект, дайте мне знать больше :)
API «облако на устройство» идеально подходит для этого. Я не вижу, что делает это «излишним».
@ Ник да, Cloud to Device выглядит именно так, как мне нужно для уведомления клиентов. +1 за комментарий
@ Ник - Честно говоря, у меня нет веских причин для этого комментария. Я предполагаю, что все сводится к тому, как я использовал C2D API, который был для полного администрирования на уровне устройств сотен устройств. Я всегда просто чувствовал, что для одного человека одному человеку существуют «более простые» решения. Я могу ошибаться, как известно, случалось :)

Peter Recore · Accepted Answer · 2011-01-01T00-07-00.000Z

Если вы планируете использовать App Engine, вы, вероятно, будете использовать API канала, как описано здесь.

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

К сожалению, нет Android-клиента для API канала (хотя вы могли бы взломать веб-представление для передачи сообщений)