Потихоньку переношу свой код на java.

Сперва попробовал выводить в список целиком весь текст всех сообщений, но получилось не очень производительно (на большом кол-ве сообщений иногда подвисает на секунду при скроллинге, тестирую на tf101, кастом 4.4.3 по-моему).

Сейчас есть два пути, выбор будет в сторону более производительного:
1) Оставить прежний формат вывода (т.е. все сообщения в длинном списке), но выводить только первую строчку сообщения, целиком текст будет доступен при нажатии на элемент списка (в новом окне, грубо говоря).
2) Сгрупировать сообщения по теме и выводить список тем. При нажатии на тему будет открыто новое окно с сообщениями из этой темы. На мой взгляд наиболее рациональный вариант, хоть и потребует ресурсов на группировку, но появится возможность отслеживать новые ответы.

Мета-информация, разумеется, будет выведена в любом случае (от кого, кому, тема, время)

Если у кого-то есть предложения по юзабилити, пишите.

>Потихоньку переношу свой код на java.

О, ништяк! А то я уже вебклиетом озаботился.

Можно протестировать, пожалуйста! У меня у самого CyanogenMod 11 на 4.4.3, qpython неудобно запускать, поэтому родной клиент удобнее будет.

>Можно протестировать, пожалуйста! У меня у самого CyanogenMod 11 на 4.4.3, qpython неудобно запускать, поэтому родной клиент удобнее будет.

Пока еще нечего тестить, но как только - так сразу:)

nightly-debug-билд

https://yadi.sk/d/DdoT9BbcTxPB7

Что можно:
* Читать сообщения из эх, список которых есть в /echo
* На данный момент загружаются только последние 120 сообщений из эхи.

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

Стабильность не гарантирую, но читать можно.

> nightly-debug-билд
По-моему, очень хорошо.

>nightly-debug-билд

Ща затестю

Второй nightly-debug-build.
Ссылка: https://yadi.sk/d/DdoT9BbcTxPB7

Изменения:
* Примитивная обработка ошибок. Клиент больше не будет крешится, если отсутствует или вдруг пропало подключение к интернету
* Добавлена возможность отвечать на сообщения, а так же писать новые
* Добавлена поддержка хранения настроек параметров клиента
* Добавлен механизм обновления сообщений (пока что при нажатии на кнопку)
* Немного повышена производительность
* При отсутствие подключения к интернету в момент запуска, программа завершает своё выполнение (т.к. не её выполнение имеет смысла, локально ничего не сохраняется)
* Теперь при первом запуске клиента открывается окно настроек, в котором на текущий момент доступен один пункт "Общее". При нажатии на элемент списка, пользователю предлагается ввести адрес сервера, auth-токен и список, откуда будут браться эхи (то, что выводится списком слева).
Необходимо ввести следующее:
http://irk38.tk/ii/ii-point.php?q=/u/
ваш токен
http://irk38.tk/ii/echo

Клиент великолепный (с него пишу), но откуда появилась идея брать список эх из echo/?
Я ведь сделал это просто для удобства, это не входит в стандарты, а подписываются на эхи обычно вручную.

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

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

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

> Когда я делал клиент, я не знал какие эхи есть на ноде, чтобы подписаться нужны имена, я не знал откуда их брать. поэтому появилась идея выводить пользователю список эх из бона, /echo и еще там как-то можно, забыл как)
Просто /echo не входит ни в какой стандарт. Когда я хотел скрыть полный список эх у себя на ноде, то добавил заглушку. А потом просто туда написал бонные эхи. Если хочется автоматически подцеплять с сервера бонные эхи, то лучше это делать из bone.14, потому что она, по крайней мере, гейтуется всеми узлами.

> С точки зрения юзабилити было бы неплохо, если бы нода умела сообщать клиенту список общедоступных эх с их описанием.
А с точки зрения простоты реализации это неразумно. Эх может быть неограниченное количество. Не бывает несуществующих эх, бывают те, в которых 0 сообщений. Если хочется автоматически брать список эх, то есть bone.14, ну и bone.15, когда наступит следующий год.

По-моему с точки зрения простоты реализации как раз это очень разумно.
Клиент запрашивает, допустим, /u/echolist/, а сервер возвращает ему список эх из *текущего* бона.
Иначе как программно узнавать откуда брать эхи? числа в боне меняются в зависимости от года, так тогда на локальное время нельзя полагаться, у меня может стоять 12 год, а bone.12 не существует.

Клиент вообще ничего не должен знать про боны и прочее, он должен уметь отправить один запрос и проанализировать ответ. Подчеркиваю: я говорю о том, что сервер должен уметь отдавать список *общедоступных* эх, например im.100 или какие-то гостевые. Если у ноды нет общедоступных эх, тогда возвращается пустая строка, либо какой-нибудь 404. Я не говорю, что надо отдавать список всех эх, это глупо, но почему нельзя отдавать тот же im.100, ii.dev.14, чтобы новый пользователь сразу смог начать общаться? Не обязательно релизовывать это так, как я привел в примере, но я считаю, что общий для всех нод механизм получения списка эх необходим. Причем, это все отлично впишется в качестве расширений, о которых я писал ранее.

Посмотрите на эту проблему с точки зрения простого пользователя, который никогда не пользовался ii. Он вообще ничего не знает про бон, про /echo, и т.д., но он хочет общаться. Ну правда, я когда садился писать клиент, у меня первый вопрос был: а откуда я узнаю вообще какие там есть эхи? Мне сказали "для этого служит бон". Какой бон, что за бон? Ну потом понял, что это bone.14.

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

Много воды написал.
Суть: нужен какой-то общий запрос вида /u/echolist, который будет возвращать эхи из текущего бона (то есть bone.14 для 2014 года и автоматически bone.15 для 2015 года)

это ареафикс :)

в моей версии был /list.txt, с эхами текущей станции

дык именно что в твоей версии, а надо чтоб везде единообразно было:)
тогда можно одним клиентом ходить на несколько станций.

Очередное обновление.

https://yadi.sk/d/DdoT9BbcTxPB7

Изменения:
* В настройках добавлен пункт меню "Подписки". В этом пункте меню можно включить или выключить использование подписок
* Добавлена поддержка управления подписками на эхи. Управление подписками осуществляется через настройки.
* Добавлена возможность переключения между получением списка эх от сервера и собственным списком подписок.
* При отсутствии источников списка эх теперь отображается соответствущее сообщение.
* Теоретически, появилась возможность создавать новые эхи (путем добавления подписки на новую эху и отправке туда сообщения, не тестировалось)

Там небольшой косяк с грамматикой в настройках, поправлю в следующем билде

Как там правильно вбить урлы сервера и списка эх?

В общем, я решил, что нам это нужно. В качестве api лучше взять /x/echolist (u/трогать не надо). Эхи надо будет добавлять туда вручную: не обязательно бонные, а любые, которые вообще есть.

В адрес прописываешь http://irk38.tk/ii/ii-point.php?q=/u/
В Auth-токен свой ключ

Далее либо во вкладке "Подписки" сам вводишь имена эх, которые тебя интересуют (и которые будут выводиться слева), либо прописываешь в "Общих настройках" третью строчку (адрес URL со списком эх) http://irk38.tk/ii/echo

Без лишних пробелов, разумеется:)

/u/ я лишь в качестве примера написал:)

ну да, там выводить основные эхи, чтобы было с чего начать

Заработало :)

Пишу с телефона.

Мои поздравления:) Как полет?

Надо добавить время к сообщениям. Без него не так прикольно.
Еще бы было хорошо сортировку по тредам прикрутить :)

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

а можно нормальную страницу с нормальным урлом, чтобы всегда новую версию можно было найти, сделать?

а то я запулю ветку в твитер, и будут все старой версией пользоваться.

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

В общем, сейчас я расскажу, как всё это было.

Конечно, были варианты "опрашивать наличие разных способов", но кроме бытовых вопросов (когда? при подключении? при каждом коннекте? раз в день?), было ещё желание не делать кучу разных версий с разными стандартами.

Поэтому я решил оставить так:

/m и /e - есть всегда, это основа, собственно сети - для разных sh-скриптов, для мелкой обработки, для кормления напрямую в js и так далее (возможно, надо бы и json/jsonp сделать, но я его, наоборот, убрал. возможно, в свою реализацию и верну :).

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

но потом все ноды стали жить сами по себе, и теперь каждый клиент и сервер - сам агроном своему суслику. :)

для odii у меня будут свой клиент и свой сервер, там у меня есть и list.txt и блеклист и прочее, если хочешь - сделай и поддержку odii (но там будут не только сообщения, это распредпортал :), можно ли это всё всунуть в андроид-клиент - я не знаю. у тебя там plain-text? а то я ещё не решил, каким форматом форматировать текст, если твоему клиенту интересно - давай исходить из его текущих возможностей).

хотелось бы простой http-ссылки.

кстати, есть же всякие f-droid - туда мож положить?

> У меня нет аккаунта разработчика в гуглплее,
Гугл плей проприетарный и от гугла. Используйте свободные магазины приложений типо F-Droid. И да, лучше выложить исходники.

в общем, по возможности буду перекладывать на http://apk.51t.ru

вдруг самому понадобятся :)

Не вижу в проприетарности гуглплея ничего плохого)

Исходники будут после рефакторинга кода, выкладывать в текущем не вижу смысла

>Гугл плей проприетарный и от гугла.
Зато там пользователей очень много. Можно скинуться и купить аккаунт.

>Используйте свободные магазины приложений типо F-Droid.
А это можно вместе с гуглоплеем сделать.

>И да, лучше выложить исходники.
Поддерживаю.

> Не вижу в проприетарности гуглплея ничего плохого)
Видимо, меня одного тут Столлман покусал? =)

Меня Столлман не кусал, но проприетарность - это плохо, причём однозначно. Конечно, если думать не только о сегодняшнем дне, а хоть чуть-чуть вперёд. Если не думать, то http://nz.51t.ru/1Cor.15:32 :)

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

можно сделать банально /x/api , которая вернет, например:
/e
/m
/u

В этих данных клиент ищет знакомое для себя апи и использует его. Проверяется при первом коннекте к ноде (Когда создается сущность клиента, рассуждаю в рамках ооп).

смысл этого в том, что, если нода умеет отдавать таймстампы, тогда вместо выкачивания /e/echoname он будет запрашивать таймстамп, сверять свой с полученным и если есть новые сообщения то уже будет запрашивать /e/echoname
Если не умеет - будет выкачивать все.

Ломать ничего не надо, но добавить возможность сообщать какие протоколы сервер поддерживает имхо надо

Я просто к этому спокойно отношусь )

Ты имеешь ввиду прямую ссылку на apk? Посмотрю что можно сделать.

В F-Droid надо выкладывать с сорцами насколько я знаю. Как будут в опрятном виде - выложу.

Кому как, для себя я даже в самой дальней перспективе не вижу ничего плохого. Мне ехать, а не шашечки:)

> Кому как, для себя я даже в самой дальней перспективе не вижу ничего плохого. Мне ехать, а не шашечки:)

Свобода - это не шашечки.

Весь вопрос идёт от непонимания "откуда берутся программы". :) Кто их пишет ДЛЯ ТЕБЯ, и зачем. Почему такой порядок вещей, а не иной. Могло бы быть лучше, или хуже? И что ты МОЖЕШЬ сделать, а что НЕ МОЖЕШЬ.

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

моя цель была использовать максимально простую реализацию. чтобы не было разночтений, чтобы каждый клиент соблюдал набор правил, и чтобы при этом мог их соблюдать. и чтобы каждый мог легко написать эталонную ноду, которая бы подходила к любому клиенту. поэтому вариант "несколько стандартов существуют вместе" - исключён сразу, не нужны реализации, при которых один одход от сервера и один отход от клиента - и полученные клиент и сервер уже не взаимодействуют. не нужно никакое переусложнение, никакие внешние проверки, потому что потом, для соблюдения стандарта, их придётся тащить ВСЕМ! даже тем, кто не особо понимает, что это такое :)

> В этих данных клиент ищет знакомое для себя апи и использует его.

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

и чтобы эталонную реализацию можно было объяснить на пальцах, при минимальном количестве вилок "или/или".

> смысл этого в том, что, если нода умеет отдавать таймстампы, тогда вместо выкачивания /e/echoname он будет запрашивать таймстамп, сверять свой с полученным и если есть новые сообщения то уже будет запрашивать /e/echoname
> Если не умеет - будет выкачивать все.

два запроса сложнее одного :) официальный клиент keep-alive не умеет :) а преимущество - сомнительно. как и сама фича таймстампов.

да просто проверяй на наличие /x/ и всё. либо один раз, либо раз в сутки, либо при каждом коннекте. или, как это задавалось у меня - схемой... http://XXXX.ru/u/ - это одно. xxxx.ru/z/ - это другое. от последних трёх символов зависит протокол - (как от первых с :// - протокол доставки).

> Ломать ничего не надо, но добавить возможность сообщать какие протоколы сервер поддерживает имхо надо

так тебе в любом случае, хоть с мета-списка, хоть вручную, надо брать имя сервера. там оно и задаётся - кто-то помечен /u/, кто-то - /x/

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

если выкладывать в репозиторий, нужна

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

b. метанода. которая автоматом подписывает юзера на определённую ноду и определённые эхи там. чтобы сразу были контент и жизнь, а не после того, как он через кучу всего пройдёт - иначе он даже проходить через кучу всего не будет :)

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

Вся простота разбивается о то, что теперь при каждом (!) обновлении списка сообщений мобильник должен выкачивать по 700+ хэшей сообщений. Зачем?

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

А наркоторговля - свобода жить хорошо. :)

Это "Теория пастбищ". Пока ты пасешься на чужом - ты сыт и доволен, и не думаешь, откуда берётся трава. Вот это то и оно, что ты не думаешь, откуда берётся трава. :) И на каких условиях. :)

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

Это вообще полная подмена понятий. И исхождение из неверных предпосылок. А в указанном случае - это вообще больше похоже на паразитирование "тут лишь бы лучше сейчас, там лишь бы лучше сейчас, а последствия меня не волнуют". Вообще, такие люди, если называть вещи своими именами - враги. Они, вместо того, чтобы поддерживать рост светлого будущего, тянут в тёмное прошлое. Да ещё снабжают тех, кто тянет, деньгами, ресурсами, юзербазой. Когда одни стригут лохов и у них сто тысяч миллиардов денег и ресурсов, а другие не стригут, и у них десять миллиардов - это неравный бой. Зато, если бы свободное отставало хотя бы в 1000 раз по ресурсам, оно бы на голову превосходило - это раз, и давало все преимущество свободного - это два. И когда одни делают так, чтобы было лучше всем, другие или равнодушно помогают врагам, или намеренно помогают врагам. А потом ещё говорят "а свободное хуже!". Это гениальное заявление. Типа, кто-то всю жизнь помогал деньгами, решениями и юзербазой проприетарному, вместе с другими, а сами ходят на Поле Чудес чтобы посмотреть "а как там выросло свободное?". Как будто оно само вырастет.

Впрочем, несмотря на всё перечисленное, свободные проекты за последние 10 лет преодолели огромное расстояние, тенденции у них гораздо лучше, чем у проприетарное. Да и выгоды, которые дают свободные программы, очевидны становятся многим. Поэтому некоторые проприетарщики будут просто вылетать из бизнеса. И вот когда они вылетят, а программу без исходников... впрочем, о чём я говорю, уже есть стон "моя любимая программа без XP не работает, в XP её никто не переписал, потому что автора нет, а другие не могут"... вот тогда многие подумают, зачем они ели зерно, предназначенное на посадку.... но будет уже поздно. :)

Для программы все равно сколько запросов. Почему и говорю, что надо сделать *расширение*
пусть кто хочет, тот лепит свои велосипеды и пилит классы для клиента, в рамках которых будет эта поддержка. модульность же