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

Микола Питерскийвадяа зачем пользоваться ajax , когда есть более лучший инструмент- websocket?
на андроиде работает без проблем, трафик минимальный, сообщения можно посылать как на сервер, так и с сервера.
Я не пользуюсь ajax - это был мой класс, который я просто назвал так т.к. использую ajax в JavaScript. Про websocket не слышал - но просто обычно то что есть меня не удовлетворяет - мне нужно было сделать обмен с малым временем таймаута именно из-за этого я и "изобретал велосипед", также в моем варианте есть "уровни" для последовательной передачи сообщений, после успешного предыдущего т.к. все крутится в отдельных потоках - уверен что этого в существующих компонентах нет.
я сделал websocket сервисом в андроиде - время таймаута -минимально. отдал данные ws , он их отправил в своём потоке, можно отдавать данные в любой последовательности из любых потоков.
серверу надо отослать данные - он отсылает любому потоку на андроиде. можно даже сделать обмен сообщениями между потоками через сервер.
автор Про websocket не слышал
почитай, счас появилось много инфы. я получаю какф от их использования. это после ajax, comet, jax-ws...

гыы
какф ==> кайф

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

авторВ общем так:
-пункт №1
библиотека называется Web сокет, а Web сервер никогда не сохраняет соединение открытым - т.е. веб сервер отдал данные и сразу же закрывает соединение сам без запроса клиента - т.е. тот кто называл так эту библиотеку понятия не имеет как работает вэб сервер.
-пункт №2
Web сервер не может так сделать т.к. соединение каждый раз теряется и http протоколе сервер никогда не может вызывать сам клиента
-пункт №3
А вот это полнейшая чушь - если держать соединения открытыми - то скоро сервер не сможет вообще подключить новые соединения
т.к. число одновременных подключений к Web серверу всегда ограничено.

Эта либа работает не по HTTP а по своему протоколу - естественно объем передачи данных ниже намного, но она не имеет никакого отношения к веб серверам, а если поставить ее поддержку на Вэб сервер то она его положит уже после первой сотни одновременных подключений. Это обычные сокетные TCP клиент и сервер со своим протоколом работы, но никакого отношения к Вэб серверам она не должна иметь вообще. Так что это локальный очередной "велосипед", который назвали громким словом Вэб.
это вызывает смех.
потому как использую. и никто не лежит. даже ie внедрили ...
ну нравится название - не используй. а по мне позволяет упростить, улучшить - значит надо использовать.
хочеш подробнее узнать как работает и через что - https://github.com/TooTallNate/Java-WebSocket
и для сервера и для андроида
у меня сервер работает и с андроидом и с браузером. по одному протоколу. я могу с браузера через сервер послать сообщение, и время будет минимально. никто ничего не ожидает. нет никаких запросов от клиента на сервер о наличии данных для него.
видел демку: два компа, браузеры, на одном чел рисует, на другом тут же появляется этот рисунок.
повторюсь - клиент подключился и всё. пока специально не разорвёшь соединение - оно действует.
и в любой момент сервер может слать на клиента всё что хочет, вне зависимости от того послал ли клиент на сервер что-то.
число подключений может и ограничено, только я не знаю чем у ws. 65535?

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

вообще каждое подключение характеризуется InetSocketAddress, так что ограничения это 65000 на один IP.
и если у тебя 65000 клиентов и все захотят иметь информацию в реальном времени - они просто положат сервер пустыми запросами, на которые сервер должен ответить.
в ws сервер будет отдыхать. потому как будет работать только когда для данного клиента есть данные.

авторПопытка применить такой протокол на высоконагруженном вэб сервере ни к чему хорошему не приведет - он гарантированно ляжет после первой сотни подключений.
ну кто тебе это сказал? по каким причина он ляжет? подключение и нагрузка здесь не связаны.
у меня была в коде ошибка и на сервер шла куча подключений по ws - никакой нагрузки на сервер небыло.
на сервере простой слушатель порта и всё.
всё преимущества в том , что клиентам не надо слать запросы о наличии данных!!!! сервер сам , по своей инициативе, при необходимости, при наличии данных, отправит сообщение клиенту.
нет такой необходимости - тишина в эфире, сервак спит. нет никакой причины для нагрузки

авторА теперь вопрос - будет ли засынать устройство, если там такой постоянно открытый сокет и ждущий read - уверен что нет, соответственно высаженная батарея и байки о том что андроид - это жрущее га-но.
у всего свои области применения, у меня телефон терпимо жрал батарею года я его использовал как трекер.
ну а реально - когда я отлаживал трекер, иногда забывал выгрузить сервис с ws и ничего страшго не происходило, через 3g работало как ни в чем не бывало, батарея не сильно садилась.
ну а wi-fi в режиме приёма не много кушает, а планшет без wi-fi, на производстве мало кому нужен, он будет включен используешь ты ws или нет.
а т.к. передатчик включается только при необходимости отослать данные, а не проверять сервер о их наличии, то энергоёмкость ws намного меньше любого другого варианта. а если планшет только для отображения данных с сервера, то пердатчик работает только на момент соединения. :)

a если тебя волнуют потребление - можно разорвать канал с определённым кодом и сервер будет просто накапливать сообщения, подключаешься и сервер шлет все сообщения. -- этот вариант для параноиков...

везде делают демки - чаты на ws, я думаю что лучшая демка это трекер, передаём кординаты с андроида на карту в браузере.

автор- там тоже пользователя можно уведомить о событии в базе данных. Долго пользовался Firebird - лет 15 и НИРАЗУ мне не понадобилась эта технология.
я счас пользую вовсю и с ужасом вспоминаю ajax и jax-ws...
события в субд и события сервера две большие разницы.

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

несколько напоминает историческую фразу "... не читал, но осуждаю!".
и из недавнего "В Советском Союзе секса нет!"
у меня смарфон прекрасно спал.

wadmanПосмотрел вебсокет... Это обычная обертка над сокетами, ничего выдающегося нет. И клиент и сервер - ява-приложение, а Миколе вроде как нужна серверная часть в виде web/http. Так что ему это не подойдет.

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

очень хорошая замена для ajax в браузерах, с возможностью однотипной реализации связи и браузера и андроида с сервером.
Микола изобрёл свой велосипед, но может просто взять готовый?

Микола Питерский который я просто назвал так т.к. использую ajax в JavaScript.
я понял, что ему нада канал связи с сервером, типа ajax. поэтому и предложил.
ws готовая реализация и для сервера идля андроида и для браузера.
у Миколы в дальнейшем возникнет потребность отображать информацию в планшетника в браузере и наоборот. с его велосипедом придется повозиться.
П.С. При таком раскладе смарт не должен уходить в deep sleep. Чтобы в него полноценно уходить, нужно использовать push, но тогда пострадает скорость доставки клиенту.
в его реализации после обмена связь обрывается до следующего обращения клиента к серверу - о какой скорости доставки сообщений от сервера клиенту может идти речь?

по поводу потребления - у меня сервис с ws болтался на смартфоне несколько дней и с включенным wi-fi и 3g и с выключенными.
никаких изменений в потреблении я не обнаружил. при обрыве сети - есть обработка с набором кодов можно их обрабатыать и либо снова пытаться пдключиться либо требовать действия от оператора - сообщив ему причину разрыва.
всё стандартизовано, описано.
если автоматом подключаться постоянно - то влюбом случае будет нагрузка на батарею. тут надо делать реализацию по месту, по задачи.
есть и вариант с шифрорванием - wss.
в отличие от ajax - нет пустой нагрузки на сервер, если в ajax 100 клиентов хотят иметь оперативную информацию , они должны постоянно опрашивать сервер. 100 запросов в секунду или чаще... - это ли не нагрузка на батарею андроида, для сервера вроде не много, но если сравнивать с 0 - то прилично.
при оперативности канала ws можно и с планшетника управлять процессами в реальном времени.

авторЕсли в либе есть "ждущее" подключение то соответственно при обрыве соединения приложение будет пытаться самомостоятельно его восстановить, а в мобильном устройстве таких обрывов связи за день может быть сотни, соотвественно это будет жрать батарею и выжирать мобильный трафик и в чем тут экономия? Эта библиотека может и хороша для жавы - но никак не подходит для андроида.
ты делаешь выводы не посмотрев, не изучив, только на предположения "если..."
а в твоём варианте для оперативности инфы на андроиде надо слать запросы на сервер - в чем тут экономия? а запросы - чем оперативнее тем чаще.

ну вы блин даёте!!!
прежде чем ругать и прочее, прочитали бы, погуглии....
http://learn.javascript.ru/websockets
всё многократно описано и на русском.
я не врубался как там организована проверка на обрыв сети, но при обрыве никакой задержки нет- событие тут же отрабатыает.
вот тут пишут вот ели б было это и это...
да уже всё есть, стандартизовано, работает. почиайте http://www.websocket.org/