vit01> Нормально установилось и запустилось. Ну а тестировать мне не на чем.

Спасибо за помощь. Мне просто надо было знать не вылетает ли оно, а то там внутри аналитика и крэш-репорты от Google Firebase. Сейчас просто в Яндекс сторе видел кучу плохих отзывов на приложение BlaBlaCar, люди пишут что без гуглосервисов оно вылетает.

btimofeev> Подскажи, а у тебя телефон без play сервисов?

Да. ОС 7.1.1
Уже давно приспособился жить совсем без гугла.

btimofeev> Если так, то не мог бы ты посмотреть работает ли вот эта версия моего приложения

Нормально установилось и запустилось. Ну а тестировать мне не на чем.

Подскажи, а у тебя телефон без play сервисов? Если так, то не мог бы ты посмотреть работает ли вот эта версия моего приложения https://github.com/btimofeev/UniPatcher/releases/download/0.13/UniPatcher-0.13.apk

AL> Вот меня как раз может ожидать работа с pdf, но из питона. И там может оказаться тоже весьма весело.

Своего бота я как раз на питоне писал, а тулзу запускал через subprocess.Popen, и никаких проблем.
Если нужна работа в read-only (например, любой парсинг или анализ), то тут граблей быть не должно, библиотек куча рабочих как для питона, так и для других языков.

vit01> Услышав "PDF", я порадовался и подумал, что "для него уж точно кучу всего написали, проще некуда, найду что-нибудь". Но не тут-то было!

Вот меня как раз может ожидать работа с pdf, но из питона. И там может оказаться тоже весьма весело. По крайней мере беглое гугление показало, что граблей с PDF до сих пор много где есть, что на мой взгляд очень странно.

vit01> Где же, наконец, простое и рабочее решение для автозаполнения PDF-форм?

vit01> Вот оно: https://sourceforge.net/projects/pdfformfiller2/?source=directory
vit01> Использует библиотеку iTextPdf 5 версии, написано на Java.

Спасибо за наводку. Вполне допускаю отдавать данные сторонней штуке.

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

Услышав "PDF", я порадовался и подумал, что "для него уж точно кучу всего написали, проще некуда, найду что-нибудь". Но не тут-то было!

Поискав на Гитхабе, нашёл оригинальную библиотеку pdf-fill-form, написанную на NodeJS. Потратил достаточно времени на разборки с тем, дабы заставить её работать, но ничего хорошего из этого не вышло. Русские символы никак не отображались. Вместо них - кракозябры, либо пустота.

Посмотрел в сети, и выяснилось, что проблема библиотеки - в зависимости от libpoppler. Баг в poppler'е затрагивает многие другие приложения, например, Evince. И проблему в последнем до сих пор можно увидеть без особых усилий.

https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1288182
Представьте себе, баг по этой ссылке висит с 2008 года, но так и не исправлен!

----------

Идём по Гитхабу дальше. Все остальные репозитории с нужным мне делом представлены обёртками для программного пакета pdftk.

pdftk имеет множество фич. Можно даже сказать, что это самая популярная вещь для автоматической обработки. Он может "инспектировать" PDF-файлы, декомпилировать их, изменять внутренности и так далее. Работает на основе файлов FDF и XFDF (XML-версия формата). Туда записываются данные для заполнения в декларативном виде, затем скармливаются pdftk, и тот выдаёт заполненный результат.

Но здесь я опять потерпел неудачу. Кириллица снова отказывается отображаться. В багтрекере уже появлялись люди с похожими проблемами, но их мягко посылали. Были люди, которые предлагали обходные пути вроде дополнительных параметров, но здесь они не помогли.

В чём же проблема с ним?

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

-----------

Где же, наконец, простое и рабочее решение для автозаполнения PDF-форм?

Вот оно: https://sourceforge.net/projects/pdfformfiller2/?source=directory
Использует библиотеку iTextPdf 5 версии, написано на Java.

Установка после распаковки zip-а:

1. Требуется OpenJDK 7 или 8
2. Надо скачать iTextPdf отсюда: https://github.com/itext/itextpdf/releases/tag/5.5.10
3. Затем распаковать jar-файлы и положить их в lib/ к pdfformfiller-у
4. Компилируем обёртку
javac -d . -cp lib/itextpdf-5.5.10.jar PdfFormFiller.java

5. Делаем скрипт для запуска утилиты
java -classpath .:lib/itextpdf-5.5.10.jar PdfFormFiller.PdfFormFiller $1 $2 $3 etc

Всё, готово к использованию. Программа принимает в качестве ввода файл с названиями полей ввода и внешний шрифт (в формате ttf), которым надо их заполнять. Может брать данные в том числе из stdin.

Кстати, насчёт остального. Для выяснения, какие шрифты есть в документе, пригодится cli-утилита pdffonts из состава poppler.
Чтобы узнать id полей ввода в документе, можно использовать pdftk file.pdf dump_data_fields, либо сам pdfformfiller, в котором это предусмотрели (см. справка).

Итак, за что проголосует народ? Может быть, есть, что предложить получше?

Подумал тут насчёт продумывания сабжа и зашёл в тупик.

Есть несколько вариантов:

1. Как в ServerListener. Поступление новых сообщений отслеживается через /x/c. Если они имеются, то выводится уведомление: "Новых сообщений: <число>", но при этом ничего на устройство не скачивается. Когда пользователь жмёт на оповещение, то запускается фетчер.

Плюс подхода - избежание "неожиданных ситуаций". Предположим, в эхе ii://pipe.2032 решил нагадить бот/спамер и закинул туда 50000 сообщений. Пользователь смотрит на оповещение и думает: "Ага, что-то тут нечисто!". Потом идёт проверять станцию, а база на телефоне остаётся в чистоте от мусора.

Либо по-другому: любители разного чтива закинули куда-нибудь в ii://lit.14 сразу 50 огроменных рассказов. У пользователя на мобильном интернете остаётся мало трафика, и он осознанно решает не фетчить сообщения до прихода домой, чтобы сэкономить несколько мегабайт.

Минус подхода - использование /x/c. Не все ноды его поддерживают, а фичу хочется для любых станций сразу.

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

Плюсы - универсальность для всех нод и относительная простота реализации.
Минусы - незащищённость базы от спама и от большого трафика.

3. Смесь первого и второго подхода. Делаем проверки не по /x/c, а по индексу, то есть по /u/e.
// Можно даже сделать так, чтобы ноды c /x/c проверялись именно по нему, а ноды без /x/c - по индексу.

Плюсы - поддержка всех нод и защита от спама
Минусы - глюкавость при изменении настроек станций (особенно с расширенным /u/e); постоянный жор трафика независимо от наличия новых сообщений; надо где-то хранить и запоминать индекс вне базы; будет сложнее реализовать этот хитрый алгоритм.

btimofeev> Я исправил тот самый баг с удалением свайпом в черновиках (сделай пулл) и добавил поясняющую иконку на фон при удалении. Можно еще и undo реализовать будет.

Ура! Это очень круто, спасибо! Пересобрал только что и очень доволен.

Undo, наверное, будет лишним.

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

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

В фетчере я вообще ничего не менял, он работает по-старому, поэтому пока вот так:

1. Какие у тебя настройки были для каждой станции?
2. Увеличивал ли ты лимит /u/e, использовал ли автоконфигурацию?
3. Включал галочку "Качать сообщения дальше"? Не очень я это доработал, так что здесь косяк может быть.

Я залил в твой репозиторий небольшой багфикс (вчера не досмотрел). Сделай у себя git pull.

Среди вас кто-нибудь использует на работе или в собственных проектах технологии или наработки на основе нейронных сетей?

Если да, то какие именно? Что интересного можете припомнить в этой практике?

Как раз читал недавно новый холивар на Хабре на эту тему.

Мой главный аргумент, почему табы рулят - это то, что когда хочешь нажать Backspace/Delete для удаления пустого места, то надо сделать это всего 1 раз, а не 4.

В Emacs мне удалось частично побороть эту проблему на пробел-конфигурациях, но только лишь частично.
Просто некоторые major-modes для языков могут насильно сбивать настройки написанных костылей.

В Android-studio (хоть и не на 100%) возню с пробелами компенсирует функция "code beautifier'а".

В очередном треде tabs vs. spaces было обнаружено прекрасное:

butlerpcnet * 5 years ago

YES! Another strong win for us Tab people! Thank you :) another disadvantage of space-indented code is what I call the "asshole" principle. If I were using spaces to indent? I could be an asshole and indent with 1 space per level! Any normal person thah opens the file would have to make sure his/her IDE or text editor is configured correctly to convert the spaces, and convert back (like you said with committing). It's just a mess.

butlerpcnet * 3 months ago

Comming back to reverse my opinion! I'm now a 4-spaces indenter!! Python 3 standard is 4 spaces, and PHP PSR-2 standard is also 4 spaces. Go away tabs!!

Если будет удача в исправлении багов, с конца следующей недели планирую выкладывать APK для тестирования.

Текущий прогресс:

1. Сделал дизайн куска сообщения и впихнул его в EchoView-Activity
2. Написал топорный xml для полного просмотрщика сообщений

В планах:

1. Реализовать фрагмент и заодно отдельную активити для просмотрщика сообщений
2. Впихнуть его внутрь ViewPager, чтобы переключать сообщения свайпом
3. Сделать "бесконечную прокрутку" для уже более-менее рабочего RecyclerView
4. Приукрасить всё, чтобы более-менее прилично выглядело (нескучные иконки)
5. Починить баги с DebugActivity, с поиском в БД и c запросом одного отдельного сообщения

Не наступаю ли на где-нибудь на грабли? Можно ли сделать лучше? Вот особенно для пункта 3 сомнения.

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

btimofeev> По поводу версий sdk и библиотек: ты не можешь использовать buildtools выше 23.0.1? Support библиотеки 24 версии тоже не работают? Просто чтобы не получилось что я обновлю версии, а у тебя компилироваться не будет.

buildtools точно не получится.

Support-библиотеки (support, design, appcompat) только что поменял на 24 ради эксперимента. IDE сказала, что, дескать, неправильно разные build-tools под разные библиотеки ставить, но проект пересобрался и вроде работает.

На гитхаб оно только что ушло, посмотри build.gradle

// в джаббер тебя добавил, но ты вроде как оффлайн

По поводу версий sdk и библиотек: ты не можешь использовать buildtools выше 23.0.1? Support библиотеки 24 версии тоже не работают? Просто чтобы не получилось что я обновлю версии, а у тебя компилироваться не будет.

И у тебя есть jabber или что-то подобное, возможно некоторые вопросы было бы удобнее в чате решать. (мой jabber btimofeev@jabber.ru)

Хорошо, делай на своё усмотрение.

Кстати, RecyclerView, насколько видно по документации, довольно неплохая штука.
Попробую прикрутить его после того, как кое-какие свои баги наисправляю.

vit01> Дал тебе RW-доступ в репозиторий; коль желание есть, можешь прикрутить самостоятельно.

Хорошо, займусь этим. Но я буду использовать библиотеку Material Drawer, вместо реализации из библиотеки Design, она проще в использовании, кода меньше, никаких xml файлов и она использует библиотеку Android-Iconics для отображения векторных и шрифтовых иконок (последнее оказалось удобной штукой, не нужно качать кучу иконок разных размеров, просто указываешь имя иконки в шрифте, а библиотека сама масштабирует).

btimofeev> Сегодня попробовал Instant Run в Android Studio. Это офигительная штука!

Без неё вообще никак. Правда, есть баги: когда изменений всего на пару строк, то IDE может сообщить, что никаких изменений вовсе и не было. Тогда приходится нажимать "rebuild project" и ждать положенные несколько минут.

Так, перейдём сюда, чтобы людей не смущать. Как раз эхотаг.

btimofeev> А в чем проблема с SharedPreferences (я с ними никогда не работал)?

1. Чтобы хранить вложенные значения, нужны костыли. Например, люди предлагают всё тот же JSON
2. PreferenceActivity, который работает в связке с этим делом, имеет скудный набор виджетов (например, те же кастомные списки для эхолиста не сделать вообще)
3. Надо реализовывать всё через PreferenceFragment; это довольно небыстро (для кодинга в том числе) и заставляет пользователя дольше кликать, чтобы добраться до нужной настройки

btimofeev> А с json просто работать через библиотеку https://github.com/google/gson

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

Сегодня попробовал Instant Run в Android Studio. Это офигительная штука! Перекомпиляция, загрузка на телефон и перезапуск приложения занимает около двух секунд. Раньше на это у меня в районе минуты уходило. Здорово время экономит когда нужно делать много мелких правок и постоянно смотреть на результат.

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

Увы, видимо, придётся через пару лет точно так же поступать.

vit01> Мой рабочий SDK 24.0.0 с build-tools и platform-tools 23.0.1

Спасибо за помощь, но у меня оно так и не заработало. Проблему решил более кардинальным образом: покупкой новой материнской платы, процессора и памяти (правда всё бюджетное). Теперь у меня 64 разрядный проц и даже эмулятор андроида более-менее нормально работает, так что буду свою прогу портировать под планшетные разрешения экрана.

vit01> Мой рабочий SDK 24.0.0 с build-tools и platform-tools 23.0.1

Напиши, пожалуйста, свои версию gradle плагина, и что ты пишешь в compileSdkVersion и в buildToolsVersion. Чего-то с твоим сдк у меня всякие разные ошибки валятся: то он обнаруживает что в папке с 24 build tools лежат 23, то когда я симлинк удалил gradle не может найти библиотеки firebase (думаю, может они не поддерживаются старым плагином).

btimofeev> Если не сложно выложи пожалуйста.

Мой рабочий SDK 24.0.0 с build-tools и platform-tools 23.0.1

http://ii-net.tk/ii/files/sdk-24-tools-23.tar.xz