Никак не разберусь с сабжем. Чистка кеша x/c не даёт результата. Если эху в список я добавил после первого забора сообщений с ноды, то не получаю в неё ничего. При получении списка эх с ноды имею в конце эху null.

Как всё это пофиксить.

AL> Есть ли возможность экспорта/импорта конфига?

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

btimofeev> А если в настройках ноды выставить галку на "качать индекс дальше, если все сообщения новые", не помогает?

В этом случае получается поведение равнозначное отключенной поддержке x/c и он начинает сосать всё, до чего дотянется.

btimofeev> У меня было несколько раз, что в ноду, в которую никто ничего давно не писал, клиент зачем-то начинает скачивать старые сообщения. Хотя вышеназванная настройка выключена.

Вот такого не наблюдал пока.

UPDATE: А вот как только значение x/c для эхи на узле меняется, он начинает выкачивать сообщения из новых эх. Поведения для меня совершенно загадочное. Ещё при изменении количества сообщений для забора он не забирает пока не изменится x/c для каждой эхи.

2vit01: А почему ты не сделал что-то типа как у меня в мейлере к цезию? Чтобы он получал все x/c по подпискам и сравнивал с кешем для минимизации индекса? Или я опять что-то не уловил?

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

А если в настройках ноды выставить галку на "качать индекс дальше, если все сообщения новые", не помогает?

У меня было несколько раз, что в ноду, в которую никто ничего давно не писал, клиент зачем-то начинает скачивать старые сообщения. Хотя вышеназванная настройка выключена.

AL>> При получении списка эх с ноды имею в конце эху null.
vit01> Ничего необычного. В конце list.txt сервер наверняка выдал пустую строку, а клиент посчитал её за настоящую. Могу починить, если критично.

Эта ситуация вполне обычная и тянется ещё с ii-03. Я имел в виду, что почему сюда не присобачить фильтр?

AL>> В этом случае получается поведение равнозначное отключенной поддержке x/c и он начинает сосать всё, до чего дотянется
vit01> Включай принудительную обрезку индекса (в Цезии это включено по умолчанию, в сабже - нет)

Это несколько неочевидно.

AL>> А почему ты не сделал что-то типа как у меня в мейлере к цезию? Чтобы он получал все x/c по подпискам и сравнивал с кешем для минимизации индекса? Или я опять что-то не уловил?
vit01> Выражайся яснее, пожалуйста. Совсем не понял, что здесь имеется в виду. База данных у меня единая, кэша индекса нет.

Я ж уже объяснял тебе эту фичу. Берём x/c с ноды, берём локальный x/c. Вычисляем максимальную разницу между каунтерами и её передаём в расширенный u/e. Если новая эха и в локальном x/c по ней информации, то выставляем длину индекса на умолчальную, если максимальная разница меньше.

AL> Чистка кеша x/c не даёт результата. Если эху в список я добавил после первого забора сообщений с ноды, то не получаю в неё ничего.

Вот это странно. Скорее всего, баг.

AL> При получении списка эх с ноды имею в конце эху null.

Ничего необычного. В конце list.txt сервер наверняка выдал пустую строку, а клиент посчитал её за настоящую. Могу починить, если критично.

btimofeev>> А если в настройках ноды выставить галку на "качать индекс дальше, если все сообщения новые", не помогает?
AL> В этом случае получается поведение равнозначное отключенной поддержке x/c и он начинает сосать всё, до чего дотянется

Включай принудительную обрезку индекса (в Цезии это включено по умолчанию, в сабже - нет)

AL> UPDATE: А вот как только значение x/c для эхи на узле меняется, он начинает выкачивать сообщения из новых эх. Поведения для меня совершенно загадочное. Ещё при изменении количества сообщений для забора он не забирает пока не изменится x/c для каждой эхи.

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

AL> А почему ты не сделал что-то типа как у меня в мейлере к цезию? Чтобы он получал все x/c по подпискам и сравнивал с кешем для минимизации индекса? Или я опять что-то не уловил?

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

AL> Есть ли возможность экспорта/импорта конфига?

Да, есть, уже было сказано ранее

vit01> Если вы все помните, я обещал поправить все баги в клиенте как можно скорее, когда куплю замену к процессору для сдохшего компа.
vit01> Реальность оказалась гораздо хуже: сдох не процессор, а сама материнская плата. Это значит, что писать андроид-софт через IDE я больше не могу. А нетбук, в свою очередь, студию не потянет.

Голимо. Всё таки раньше в этом плане было лучше. Братья фидошники выручали и железом на поюзать. А сейчас я донатнуть даже не могу толком - ремонт не за горами.

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

Реальность оказалась гораздо хуже: сдох не процессор, а сама материнская плата. Это значит, что писать андроид-софт через IDE я больше не могу. А нетбук, в свою очередь, студию не потянет.

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

Если найдётся какой-нибудь дельный совет, готов принять во внимание.

Сегодня на компе с андроид-студией заменили блок питания, и он снова рабочий! И что это значит?

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

Итак, в новой сборке клиента:

1. Исправлена недоработка с пустыми строками в list.txt
2. Фетчер теперь не валится, если были ошибки парсинга некоторых сообщений
3. Экспорт и импорт бандлов теперь учитывает избранные! Так что можно не бояться переустанавливать клиент и экспериментировать с ним: вся годнота при переносе БД сохраняется и подлежит восстановлению.

Скачать APK: http://ii-net.tk/ii/files/app-debug.apk

Замечание насчёт фичи под пунктом 3: используется стандартный механизм тегов ii, который совместим со всеми реализациями. Так что пользователи клиентов и тулз для работы с бандлами (ii-db-utils, idec-utils) этих изменений даже не заметят.

А ещё я смог настроить Emacs для разработки под андроид. Так что в экстренных ситуациях уже могу работать с этим делом и на своём нетбуке, без андроид-студии.
Посмотрите на этот милый скриншот, кто его ещё не видел: https://ii-net.tk/files/screen-emacs-01.png

P.S. Серьёзные баги чиню только на выходных

AL> Я ж уже объяснял тебе эту фичу. Берём x/c с ноды, берём локальный x/c. Вычисляем максимальную разницу между каунтерами и её передаём в расширенный u/e. Если новая эха и в локальном x/c по ней информации, то выставляем длину индекса на умолчальную, если максимальная разница меньше.

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

Режим "максимальной экономии через /x/c" надо бы тоже реализовать, только наиболее прозрачно для настройки.
Думаю просто галочку прикрутить вроде "минимизировать запросы индекса" и выставить её по умолчанию для включённого /x/с

Добавил себе в TODO: https://github.com/vit1-irk/idec-mobile/projects/

AL>>> При получении списка эх с ноды имею в конце эху null.
vit01>> Ничего необычного. В конце list.txt сервер наверняка выдал пустую строку, а клиент посчитал её за настоящую. Могу починить, если критично.

AL> Эта ситуация вполне обычная и тянется ещё с ii-03. Я имел в виду, что почему сюда не присобачить фильтр?

Раньше никогда не задумывался о такой проблеме (с пустой строкой). Окей, прикручу проверку. Добавил в TODO.

AL> Голимо. Всё таки раньше в этом плане было лучше. Братья фидошники выручали и железом на поюзать. А сейчас я донатнуть даже не могу толком - ремонт не за горами.

Да ладно, не преувеличивай. Мне для разработки хватит даже самой простой виртуалки с VNC+ssh, ни в каких донатах необходимости нет.

Что-нибудь придумаю. Может быть, сделаю "раздельный процесс" вроде написания кода в емаксе и сборки APK вручную. Это будет занимать гораздо больше времени и телодвижений, зато можно будет кое-как работать.

Из фич IDE, которые сильно сокращали время, могу отметить дизайнер интерфейсов (эксклюзивная штука, которая очень нужна и которой нигде больше нет), Instant Run, "прибитую гвоздями" интеграцию с ADB (с подсветкой ошибок, через обычный cli-запуск ADB так вроде нельзя), прекрасное автодополнение по куче фишек конкретно андроида, мгновенный lint по коду и умный подсказыватель, который определяет deprecated-методы и даёт советы по обратной совместимости кода между версиями ОС.

В новой сборке клиента:

1. Изменил способ запроса статистики из БД на списке эх, чтобы тот не дёргался при прокрутке. Теперь он синхронный (как в Цезии). Помню, Андрей мне несколько раз говорил про этот баг. По ощущениям отзывчивость клиента поуменьшилась, но проблема должна уйти.

2. При отсутствии интернет-соединения клиент чётко даст об этом знать, а не просто напишет, что зафетчил 0 сообщений (о баге сообщил Борис)

Качать APK по прежней ссылке

Теперь на ноде наконец-то обрезаются длинные сообщения ("Читать далее").

И ещё в админке (sysop.php) стало удобнее удалять содержимое эх да чистить базу по ЧС

Peter> Клиент хорошо бы исправить все-равно, имхо. Стандарт вроде не нарушен.
Peter> Эха:счетчик:пустое описание

Исправил клиент, обновляйся
Ещё, кстати, поправил пиктограмму для уведомлений

> Посмотрел список эх на станции и всё понял. Парсер не хочет съедать пустые описания.
> Так что пусть либо сисоп заполнит описания, либо я выпущу обновление, либо ты выставишь нужные эхи в клиенте вручную.
Там это кодом генерится, подправил, чтоб в качестве названия была сама эха. Так норм?
http://club.syscall.ru/list.txt

Не могу прицепить клуб http://ii.club.syscall.ru/ к idec mobile. Вроде все поля заполнил, а оно пишет чот не может получить список эх. Памагити!

Клиент хорошо бы исправить все-равно, имхо. Стандарт вроде не нарушен.
Эха:счетчик:пустое описание

Да, так должно заработать. Но вообще странно как-то
Всегда вроде вручную заполняли описания

Kerbal> Вроде все поля заполнил, а оно пишет чот не может получить список эх. Памагити!

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

vit01>> Ещё, кстати, поправил пиктограмму для уведомлений

btimofeev> Ты её кажется не закоммитил, программа теперь из-за этого не собирается.

Всё, теперь закоммитил, должно заработать

// Теперь при загрузке через /x/file размер загруженного файла отображается адекватно, через 1.5 секунды

vit01> Ещё, кстати, поправил пиктограмму для уведомлений

Ты её кажется не закоммитил, программа теперь из-за этого не собирается.

Добавил в Navigation Drawer кнопку для загрузки обновления. Она просто открывает браузер, чтобы скачать APK

Это на будущее, чтобы мне не писать постоянно ссылку на клиент в своих сообщениях