Я редко занимаюсь чем-то «низкоуровневым». Мой примерный рабочий день состоит из разработки мобильных приложений для бизнеса и кучи разноплановых менеджерских штук. Само собой, иногда хочется отвлечься. Получается это редко, и, наверное, поэтому, доставляет особое удовольствие. В этот раз отвлечься было решено с помощью набора «Амперка. Тетра», который предназначен для детей и с помощью которого можно узнать основы схемотехники, названия всяких сенсоров, и попробовать попрограммировать что-то, работающее в реальном мире, а не на экране компьютера. В общем, когда ты взрослый бородатый мужик — вообще самое оно.

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

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

Swift — значит быстрый. Быстрый — значит понятный, простой. Но достичь простоты и понятности непросто: сейчас в Swift скорость компиляции так себе, да и некоторые моменты языка вызывают вопросы. Тем не менее возможность перечислений (enum'ов), про которую я расскажу (associated values — присоединяемые значения) — одна из самых крутых. Она позволяет сократить код, сделать его понятнее и надёжнее.

Представим себе экран обычного мобильного приложения с уже заполненным списком ячеек. С сервера приходит другой список. Нужно посчитать разницу между ними (что добавилось/удалилось) и проанимировать UICollectionView.

«Простой» подход — полностью заменить модель с последующим вызовом reloadData. К сожалению, при этом теряются анимации и могут возникать другие нежелательные эффекты и тормоза. Куда интереснее редактировать списки аккуратно, анимированно. Попробовав это сделать несколько раз, я убедился, что это неимоверно трудно.

Раз проблема встретилась в нескольких проектах, нужно её обобщить и работать дальше с обобщённой реализацией. Интересная задача! Несколько дней борьбы с документацией, здравым смыслом, багами реализации таблиц в iOS, и получился код с достаточно простым интерфейсом, адаптирующийся к широкому кругу задач, про который я хочу рассказать.

Я писал про KTV, но одно дело — придумать что-то непонятное, другое — попробовать это использовать. Помимо стилевой системы S2 я планирую использовать KTV для работы с сервером вместо JSON. Планов завоевать мир у меня нет, но разобраться, удобнее получилось или нет, хочется. Для того, чтобы общаться было легко, нужно уметь парсить объекты из ktv-файлов, и сериализовывать обратно в них же.

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

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

Если кто видит, как можно проще или лучше решить указанные задачи, пишите. С удовольствием узнаю ещё варианты, так как все, что перечислены ниже, в той или иной степени — костыли. Вдруг есть что-то более приятное.

Когда требуется ещё один велосипед?

Ангстрем, безусловно, если смотреть на выполняемую функцию, велосипед. Сколько способов преобразовать единицы? Много. Можно пользоваться гуглом, можно одним из сотен приложений для iOS или Android.

Но, вместе с тем, ни один способ не решал одну проблему. Как мне получить результат конвертирования, когда я смотрю сериал? Конкретно, Mythbusters. Они там всегда общаются между собой про футы и фунты. Сколько это? Большая ли квартира, 500 ft²? (не очень, как оказалось) Много ли это, 27 psi (угу, дофига)? И, наконец, скажите им, что Фаренгейты — вообще никому не понятны!

С обычными конверторами приходится останавливать видео, выяснять, какая это категория, «psi», потом искать там этот самый «pounds per square inch», вспоминать, какое число нужно ввести, понять, во что её перевести (чтобы осознать масштаб проблемы). Делать это хочется с тем устройством, которое под рукой, желательно без интернета.

И вот эту проблему не решить ни одним конвертером. Я перепробовал, наверное, сотню. Она решается гуглом, но это тоже медленно (запустил браузер, ввел что-то в строке, гугл не понял, или понял не так...).

Так что велосипед ли Ангстрем? Вроде бы нет.

Поглядим теперь на сложности, которые пришлось решить при его разработке. Технические сложности, программерские.

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

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

Что такое Ångström Style System?

В обычном мобильном приложении интерфейс — одна из самых сложных и самых важных частей. То, что видят пользователи, что оценивают в первую очередь заказчики, при приёме работы.

Даже если дизайн рисуется до разработки, в процессе создания первой версии всё-равно появляется огромное количество изменений. Тут кнопочку перекрасить, тут подвинуть, там шрифт увеличить/уменьшить, потому что не поместилось и так далее. Каждое из этих изменений требует доработки. Часто таких доработок бывает несколько сотен или даже тысяч, если не получается сразу подобрать правильные параметры.

В такой ситуации очень выгодным получается отделить настройки дизайна от самого интерфейса и настраивать независимо. Эту задачу должна решать система стилей, идеологически — как CSS для HTML.

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

В своём развитии мне пришлось пробежаться по нескольким этапам в нескольких направлениях: Java → Objective C → Swift, Web → Enterprise → Mobile, XML → JSON. Этим путём я шёл на протяжении более 15 лет, подолгу и внимательно задерживаясь на каждом этапе. Нужно идти дальше. За мобильными приложениями можно придумать что-то (наверное, пока не хочется), языков вообще пруд-пруди, ничего интереснее JSON'а не придумали. А зачем его менять?

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

Сразу должен отметить, что не рассматриваю KTV, как замену JSON. И ни в коем случае не рассматриваю его для использования в JavaScript'е. Это будет неудобно и неправильно. С другой стороны, ситуация, когда система описания объектов JavaScript'а используется в других языках для работы с типизированными данными — тоже странная, и её хочется поправить.

Если вам интересно, что послужило изначальной причиной создания такого формата — можно почитать про S2 и про причины создания формата KTV

(картинка с сайта developer.apple.com)

Что это такое?

В середине 2013 года Apple на конференции для разработчиков внезапно рассказала, что они приготовили новую технологию, предназначенную для навигации внутри помещений, что они начали создавать карты музеев, торговых центров и других интересных мест и вообще, всё круто. Поверив на слово крупной компании, многие стали предлагать «решения» по навигации внутри помещений, но мало у кого получилось что-то работоспособное. Оказалось, что в реальности применять эту технологию достаточно непросто.

Я также принял активное участие в исследовании технологии. Удалось развернуть сеть биконов на мероприятиях GeekPicnic в Москве и в Санкт-Петербурге, протестировав возможности технологии. После чего я написал библиотеку, которая, используя небольшое количество маяков, достаточно хорошо позволяет определять местоположение внутри помещений.

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

Что это за приложение?

iTrace — это мобильное приложение для того, чтобы научить детей писать буквы. Электронные прописи на iPad. Сейчас она используется в нескольких странах мира (в основном в США) для обучения детей письму. Придумал и организовал всю работу по проекту Миша Богорад, а мне довелось участвовать в проекте разработчиком всяких внутренностей, главным образом, отрисовкой букв и анализом качества их рисования.

Идея, сложности

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


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