Импортозамещение - 3.

 Продолжаем изучение возможностей обходиться без "фирменных" элементов в UWP-программках. Такие элементы иногда вполне неплохие, но вот "фирмы" бывают разными - к примеру, могут внезапно присоединиться к санкциям против государства, в котором тебя угораздило родиться и жить. Много чего могут…

На нынешнем этапе в деле замены на open-source пришла очередь контрола RadDataGrid фирмы Telerik. Ничего плохого не могу сказать про саму фирму, но политика есть политика - рано или поздно она за тобой придёт.

В качестве кандидата на замену выступает DataGrid из пакета Windows Community Toolkit. Несомненным преимуществом контрола является его бесплатность и открытsq код. Остальные его недостатки можно преодолеть путём высказывания некоторых магических слов в адрес разработчиков, сопровождаемое плотным сидением за монитором и клавиатурой. В процессе выяснилось, что отсутствие у контрола врождённой встроенной сортировки по колонкам исправляется буквально десятком строк кода. Отсутствие у колонок типа (они все там DataGridTextColumn) и параметров форматирования (типа CellContentFormat или FormatString) вполне компенсируется конвертером FormatStringConverter из того же Community Toolkit. Также на достаточно приличном уровне находится способность контрола автоматически выставлять ширину колонок. Конечно, среди отображаемых данных обязательно найдётся строка большой длины и вся табличка станет шире монитора, но программа при этом не валится.

На совершенно аховом уровне  - внешний вид контрола. Для раскраски совершенно не воспринимаются никакие "тематические" цвета наподобие {ThemeResource SystemChromeHighColor}, только константы типа White, Gray и т.п. В результате раскрасить строки в альтернативные цвета не получается, только "вырвиглаз" или смена цвета шрифта на серый (всякий другой выглядит плохо при смене темы dark/light). Про раскраску границ ячеек и всего контрола - только магические слова.

Но с получившимися табличками жить можно:

Импортозамещение-2

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

Вторым шагом эпопеи стала НИР по замене контрола SfDataGrid для табличного вывода данных. Контрол с первого взгляда неплохой, до накопления в программе довольного большого количества данных (500-1000 строк в таблицах) работал сравнительно быстро. Со временем работа заметно замедлилась, а на слабых компьютерах стала и вовсе раздражать. Никакие предложенные производителем способы ускорения работы так и не помогли. Дополнительно выяснилось, что с увеличением сложности вёрстки страницы, на которой расположен контрол, отключается сортировка по столбцам, что сильно сказывается на возможности анализа данных пользователем. Да ещё и "санкции"… В общем, сильно захотелось попрощаться с контролом.

Кандидатов на замену нашлось ровно два - DataGrid из пакета Windows Community Toolkit и RadDataGrid от болгарской фирмы Telerik. Оба денег не просят и по уровню функциональности  показались примерно одинаковыми, однако контрол из ToolKit'а при тестировании оказался совсем уж примитивным и из соревнований выбыл. 

Болгарский RadDataGrid после приложения некоторых усилий по доведению внешнего вида до приемлемого (что-то, правда, так и не удалось сделать, но дарёному коню даже в зубы не смотрят, а тут пришлось бы сосем уж в неприличные места залезать…) был установлен на страницы программы и сборка отправлена в магазин. 

Главное, функциональность (сортировка и фильтрация в колонках таблицы) контрола не отключилась при переносе с простой страницы для тестов на сложные страницы программы. Ура, победа!

 

Попал под санкции или импортозамещение.

Где-то лет пять-семь назад "американская" фирма Syncfusion предложила бесплатную пожизненную  community-лицензию на свой пакет контролов для UWP. Ну, бесплатно же, отчего бы не взять.

По ходу дела выяснилось, что не так уж у них с контролами и хорошо, как в демо-роликах. Пришлось даже поучаствовать в доработках некоторых из них - во время общения с конторой стало понятно, что фирма, скорее, индийская. В частности, поэтому стал присматриваться, чем заменить их контролы, которые использовал в своих программках. В итоге к последнему времени таких контролов оставалось три: SfDataGrid для табличного вывода данных, SfChart для отображения графиков и  SfTimePicker для выбора периода времени.

Пару недель назад "фирма" не пустила меня на свой сайт за обновлениями под предлогом, что она американская, а я – российский, а санкции… В принципе, ходить на сайт уже года два приходилось через прокси и впн, но теперь, похоже, решили забанить по профилю, в котором, вероятно, сказано про Россию. Что ж, хозяева своему слову - дали лицензию, назад забрали, хоть и комьюнити. Ну и ладно, жили как-то раньше без этой "американской" фирмы, и дальше проживём. Другие американские выручат, надеюсь.

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

Первым контролом к замене стал SfTimePicker. Очень криво сделанный и плохо работающий (только в светлой теме, на планшете пальцем проворачивать список значений - изматеришься), но единственный, который удалось приспособить для выбора и редактирования данных типа TimeSpan для интервалов времени – с часами, минутами и секундами. Было как-то странно при поисках - довольно много народу интересуется такими контролами, а к использованию никто ничего не предлагает.

Пришлось городить самому, без особых затей, но со всеми нужными свойствами. В итоге получился контрол, отображающий промежуток времени по заданному формату с всплывающим редактором значения. Можно использовать диапазон времени от нуля до 33 дней 23 час. 59 мин. 59 сек. Редактор, построенный на комбобоксах, работает несравненно быстрее и легче "американского", хоть и не такой "красивый”.

Приключения с Windows 10, визуально-студийные–2 или про гамбургер…

С момента первых приключений вышли кое-какие материалы – методические, описательные и т.д. – по разработке интерфейса программ под Windows 10. Пытаются в этих материалах сподвигнуть на использование стандартизованных элементов, способов навигации и т.п. Собственно, так же было с программами под Windows 8.1/WinPhone 8.1, но, похоже, новая команда разработчиков решила, что и интерфейс должен быть новым. Как обычно…

Во всех новых программах, как правило, интерфейс строится вокруг кнопки-гамбургера, но, как сказал в каком-то докладе Константин Кичинский, никакого гамбургера там и нет. Звучало забавно, но при внимательном рассмотрении SDK и примеров становится не до шуток – его и вправду нет. Мало того, нет и элемента меню, которое при нажатии на гамбургер появляется и скрывается… Всё изготавливается “вручную”, на базе других элементов, как фантазия и умения позволяют:

Почему RadioButton, почему изображение в Tag? Ну, вот такая фантазия у разработчиков приключилась. Радости добавляет использование вместо иконок символов шрифта “Segoe MDL2 Assets”, которые выбрать можно только при помощи системной “Таблицы символов” (тоже занятие не для слабонервных),



а XAML-редактор Студии изображать их не умеет. В итоге текст программы выглядит примерно вот так:

И как, интересно, через пару недель разгадать, как они, эти символы, изображаемые здесь крючочками, выглядят? Хотя, конечно, работает это при отрисовке быстрее, чем иконки. Наверное.

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

Игрушечка-8 или Windows 10

Как всё прогрессивное человечество, скачал и установил на виртуалку то, что все давно ждали – очень универсальную ОС Windows 10. Поудивлялся, что не “9”, но не долго (хозяин – барин, мой рояль, куда хочу, туда и ставлю). Установил из магазина свою программку и решил посмотреть, как использующиеся в ней разные технологии работать будут.
На втором же шаге выяснилось, что одна из SettingsFlyout, использующихся для настроек программы, не желает работать - другие вполне себе работают, а эта молча не показывается вовсе.
После запуска программки на windows 10  под отладчиком на проблемной страничке прямо в конструкторе получаю ошибку с сообщением "XAML parsing failed.". Вот и здрасьте...
Бля!!! Дело оказалось в задании значений для комбобокса:
<x:Int32>50</x:Int32>
<x:Int32>100</x:Int32>

Заменил целые на строки, и всё стало работать:

 <x:String>50</x:String>
<x:String>100</x:String>

Пришёл к выводу, что в дальнейшем такие вещи надёжней делать в коде, хоть в конструкторе XAML и удобней иногда. Мало ли, какие ещё глюки в XAML-парсер добавят. И как оно там будет, когда эту “универсальную” ОСь на телефон поставят…

Игрушечка-7 или Локализация-2

Предыдущая “Локализация” была про нехватку стандартных средств XAML для локализации. Нынешняя – про то, что не всегда можно делать так, как кажется логичным.

У элементов интерфейса есть два атрибута – x:Name="MyControl" и x:Uid="MyControl". Первый используется в коде как имя переменной, обозначающей этот элемент, второй – в ресурсах со строками для локализации как префикс имени нужной строки (напр., MyControl.Text и т.д.). Нигде значения этих атрибутов не пересекаются и, по логике, вполне могут иметь одинаковые значения – удобно же, особенно, когда контролов много, оперировать с одинаковыми именами.

Но у изобретателей XAML-парсеров своя логика… До некоторого уровня сложности (количества нагромождений элементов разметки, методов и свойств объектов в программе) она совпадает с моей – всё компилировалось, загружалось на телефон и десктоп, запускалось, локализовалось и работало. С какого-то момента, запустив программку на эмуляторе телефона, получил сообщение о необработанном исключении при парсинге XAML в методе InitializeComponent(). При этом, естественно (метод-то не мой, хоть и можно Студией залезть) внутри него толком ничего узнать не получается. Сообщается, что ошибка в такой-то позиции такой-то строки. И поди догадайся, что строку надо искать в файле, который генерит препроцессор XAML… Вот тут-то, при разглядывании этого файла, и рождаются подозрения, что атрибутам x:Name и x:Uid нужно обязательно задавать разные значения… И действительно, после изменения одного из них XAML начал успешно парситься.

Где это говорилось про одну ОС на всех устройствах? Пускай бы парcер XAML одинаковый был, это, вроде, попроще…

Игрушечка-6 или Списки значений

В программку добавил поддержку работы с базой данных. SQLite, конечно, других-то для “универсальных программ” и нет (что, конечно, весьма удивительно – всегда же был SQL Server compact edition). Цель, собственно, была простая – при отсутствии связи с сервисом Last.fm сохранить на время информацию о треке, чтоб потом её отправить повторно. Так, собственно, известные мне клиенты сервисов и делают. Рефлексы не позволили делать ненормализованную таблицу треков, в результате появились таблицы-справочники названий треков и альбомов, а также имён исполнителей. Ну, и чтобы добро не пропадало, сделал пополнение этих справочников при каждой отправке данных на сервис.
Хорошо, но мало: справочники растут, а пользы от  этого никакой. Первая мысль – сделать на их основе автодополнение для ввода в форме программы. Ура! Одна малость – подходящих под эту задачу контролов как-то не наблюдается ни среди стандартных, ни среди розданных на халяву фирмой Terlerik. Пришлось сооружать такой контрол самостоятельно. Контрол получил гордое имя “TextBoxWithList”:

После ввода с клавиатуры нескольких символов список заполняется подходящими значениями из справочника и выводится на дисплей:

Windows 8.1.	WinPhone 8.1

В основной форме пришлось помещать элементы в Canvas, без чего получалась мешанина:

Собственно, всего этого достаточно, если бы не одна малость – на телефонах работает как задумано только на 6” устройствах. На меньших экранах с третьим полем формы случается неувязка: выпадающий список практически полностью перекрывается находящейся в этот момент на экране клавиатурой. Для других полей список перекрывается частично и это не мешает им воспользоваться:

Сразу же возникает мысль использовать suggestions клавиатуры, однако обращение к собратьям эту мысль на время похоронило. Не придумал ничего лучшего, как при появлении списка сдвигать все элементы вверх, для чего пришлось прикрутить к контролу событие VisibilityListChanged, в обработчике которого и двигаются элементы формы:

Вариант с рисованием списка выше поля ввода мне не нравится – и сам контрол надо переделывать, и основная форма ещё больше станет станет различаться в вариантах Windows/WinPhone, от чего Студия свихнётся окончательно...

Игрушечка-5 или Локализация

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

Второй интересный вопрос – где брать локализованные строки. В смысле, чем переводить…Если с русско-английским переводом сильно больших проблем не возникает – программка Babylon Translator (переводчики Google и Bing переводят гораздо смешнее) помогает вполне пристойно, то с переводом на украинский хуже. Babylon делает очень смешно – переводит русские строки на английский, результат уже переводит на украинский. В итоге получаем смесь украинских и английских слов. Хорошо, что существует специальный ресурс pereklad.online.ua, который умеет переводить напрямую, без английского.
На результаты, поставленные рядом (по жизни их рядом нигде не видно, даже в магазине)  смотреть довольно забавно:
Страница с описаниями -  здесь, программы можно взять в магазинах:

   

Игрушечка-3 или Универсальные приложения.

Модное направление - как бы из одного кода получать приложения как для Windows 8.1 - десктоп, планшет – так и для смартфонов под Winphone 8.1.

Что называется, уговорили, черти красноречивые… Пришлось запустить вторую версию программки, теперь в технике “универсального” приложения. 

Microsoft для изготовления таких приложений выпустила специальное обновление для Студии 2013, которое, в общем-то, нормально в работе помогает - шаблоны проектов, ссылки на общие файлы, конвертация предыдущих проектов и т.п.

Самое большое, что пришлось переделывать – это вызов страниц типа “About program”, “Settings” и т.п. В предыдущей версии (для Windows) программы для этого использовались страницы типа SettingsFlyout с вызовом через системные средства:

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

Самое крупное, до чего не додумались почему-то в Microsoft – это условная компиляция XAML, наподобие #if … #endif в C#. Очень скоро выяснилось, что без этого жить сильно сложно - внешний вид в win- и wp-приложениях может (иногда и должен) сильно различаться: расположение и оформление контролов, даже разный их набор… Можно, конечно, разрулить кодом, но тогда зачем XAML?

Хорошие ребята, всё же, до нужного решения додумались - XAML Conditional Compilation. C этим решением возможны конструкции наподобие такой:

Студия, правда, не сильно это понимает, талдычит об ошибках там и сям и неправильно рисует внешний вид страниц в конструкторе. Иногда приходится по-разному называть контролы - по мнению Студии, имена используются дважды… Увеличивается количество строк в ресурсах для локализации… При сборке приходится дополнительно запускать очистку решения - но эти неудобства перекрываются тем, что не нужно писать массу "художественного" - для отрисовки - кода (которого и без этого хватает).
Выяснились некоторые другие проблемы отрисовки на телефоне некоторых элементов – AppBarButton, ComboBox.

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

В случае надписей “при полях ввода” достаточно установить стандартный стиль:

 

 

Для “заголовков”, которые хочется видеть “пожирнее”, стили нужны разные:

 

 

В итоге получается достаточно пристойно на разных устройствах. Становится хуже, если начать крутить в настройках телефона размер шрифта - можно на максимуме получить наползающие друг на друга строки и т.п. Как с этим бороться - ХЗ. Скорей всего, и не стоит: которые крутят на максимум - ССЗБ.

 

В связи с малыми размерами телефонов пришлось добавить ещё один способ ввода регулярных выражений – загрузку из текстового файла (попытка набить с клавиатуры закончилась на втором переключении на спецсимволы…). Файл со всеми актуальными - известными мне на сегодня - выражениями повесил на сайт с описанием программы. И с планшета, и с телефона получилось этот файл загрузить на устройство и прочитать текст.

 

Гораздо смешнее оказалась ситуация с получением данных о проигрываемой музыке от других программ. Этот режим стал для меня лично основным режимом использования программы: слушаю на планшете, например, калифорнийское джазовое радио через турецкую программу RADYO,  периодически нажимаю кнопку шаринга и отправляю данные на Last.fm. Буквально 4 движения-нажатия. Набралось несколько и других программ, через которые иногда слушаю музыку.

Во второй, универсальной, версии, расширил перечень принимаемых при обмене форматов в попытке получить дополнительную информацию. Получилось извлечь нужную информацию из данных от программ  jamendo и 22tracks, в которых тоже есть неплохая музыка. Но всё это в Windows-окружении.

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

Те программы, аналоги которых на Windows работают как требуется, для телефонов либо отсутствуют, либо обмениваются только “текстом” с адресом страницы. Обмен в "нормальном" виде, с информацией о треке - только с Твиттером и Фейсбуком, чистый хардкод.

В принципе, для телефонов есть пара клиентов Last.fm, передающих информацию о проигрываемых треках, однако не все проигрыватели пользуются стандартными средствами и скробблеры их не понимают. Так что, для статистики на last.fm они потеряны.

 

Из функций программки, в итоге, телефону достаются только ручная набивка данных в форме и скробблинг по файлам на диске. До появления программ, разработанных под WinPhone 8.1, вовсе не обязательно “универсальных”.

 

Страница с описаниями -  https://sites.google.com/site/dyakovkm/lastfmuniwrite

 

Программы можно взять в магазинах:

 

  

Sharepoint и Windows Store - 3

Буквально через три дня после предыдущего поста на эту животрепещущую тему  обнаружилась прекрасная наводка от Mark Racley на решение проблемы использования CSOM-библиотек для подключения к удалённому серверу Sharepoint. Действительно, Windows Runtime Component с подключёнными SP-сборками выполняет подключение к ферме, запрашивает и отдаёт данные:

 

Сборки использовались от Sharepoint 2013, 2010-е использовать невозможно из-за конфликта версий .NET (очень уж древней оказалась версия, использованная в SP-2010). Сам компонент стандартным образом подключается в проект для Windows Store:

Код для доступа к удалённым SP-узлам тот же, что в утилите SpfExplorer. Были некоторые сомнения относительно передачи и использования в CSOMWinRTComponent делегатов из SPExplorerCSOM Win8 (CS) (всё же, версии framework’ов, вроде бы, разные). Но всё обошлось, делегаты передаются и узлы деревьев благополучно рисуют.

Следующее возникшее сомнение – при выборе средств построения пользовательского интерфейса. Вариантов, собственно, два – C# + XAML или HTML + JS

При использовании C# нужно бороться с ужасной хренью в виде XAML с его жуткой моделью элементов интерфейса. "Стандарты" в виде студийных проектов предполагают использование MVVM с биндингом данных. В случае же "деревянных" данных, как в SP, слабо представляется, что и как там надо привязывать. Да и дерева там, собственно, нет, все советуют реализовывать его самостоятельно…

При использовании JS есть надежда, что борьбу с ним можно ослабить при использовании TypeScript, а строить дерево на HTML когда-то все умели… Правда, при внимательном рассмотрении выясняется, что и на HTML программы предлагается делать так же, как на XAML (через специфические атрибуты). Может, конечно, и "обычный" HTML пойдёт, но экспериментировать с этим как-то не сильно хочется…

В итоге, с учётом всех мнений, выбран вариант C# + XAML, дерево для вывода данных – собственного изготовления. После долгих кровопролитных сражений с XAML (о ходе и результатах сражений как-нибудь попозже в отдельных постах) получилась программка, пригодная для эксплуатации на планшете с использованием пальцетыканья. Нормально подключается к серверам SP-2010 и SP-2013 и выводит данные в виде дерева:

Следующая, совсем отдельная задача – размещение программки в магазине Windows 8 (а другого официального способа распространения и нет, вроде бы). Здесь вовсе уж цирк – проверка в Студии на соответствие требованиям не проходит:

Собственно, уговорить разработчиков Sharepoint исправить ситуацию с использованием “не того” API (а список неправильных вызовов довольно длинный) я не могу, остаётся только удивляться, почему это некоторый вызов “не поддерживается для данного типа приложений”, если в программке он наверняка используется и вполне себе работает… Щас отправлю пакет, поглядим…