был у меня тетрис…

Сегодня совершенно случайно обнаружил, что книга OpenGL Programming Guide: The Official Guide to Learning OpenGL, Version 4.3 (8th Edition), так же известная как The Red Book, наконец-то вышла в свет. Лично для меня это издание особенно ценно тем, что в нем более не содержится информация об устаревшей части API, что больше не будет отвлекать от современных подходов. Так же, в нем целиком рассмотрен язык шейдеров OpenGL — GLSL, для которого ранее была выделена отдельная книга — OpenGL Shading Language (The Orange Book).

Блог Interoperability @ Microsoft сообщает о том, что в будущей версии библиотеки JQuery 2.0 (первого марта была вторая бета) появится полная поддержка создания приложений для Windows 8. Над вкладом в самую популярную JS-библиотеку работала инициативная группа appendTo при технической поддержке подразделения Microsoft Open Technologies, Inc. (MS Open Tech). В связи с чем, как сообщается, разработчики получать уникальную возможность создавать программы для Windows Store в привычной среде и с использованием уже существующего JS-кода.

Также отмечается, что на данный момент для создания Windows 8-приложений уже можно использовать ряд других фреймворков — backbone.js, Knockout.JS, YUI — поэтому добавление к этому арсеналу такой популярной вещи как JQuery, должно сказаться положительно на мотивации разработчиков. При этом, конечно, Microsoft обеспечивает полный доступ ко всем возможностям WinRT API.

Чтобы не оставить программистов один на один с новыми возможностями, в Microsoft позаботились о том, чтобы добавить на net.tuts мануал, правда, очень краткий и не для начинающих — сразу рассматриваются довольно специфические особенности разработки под Windows 8.

В итоге все разработчики, владеющие HTML+JS, призываются к созданию программ для новой системы от Microsoft, тем более, что для этого не надо осваивать новые «тяжёлые» инструменты, такие как С++ или C#.

[Источник]

Я хотел бы рассказать о своем опыте разработки под Windows 8. VKNews — уже второе приложение, которое мы выпустили для Windows Store и оно, как и Я водитель, попало в топ 100 магазина.

С чего начиналось

Начало было положено на осеннем хакатоне. Тогда за три дня был разработан простой класс для общения c VK API, и реализован мессенджер. Главной фичей приложения был морфоанализатор, который отвечал за удаление нецензурных слов из переписки. Очень помогли консультации экспертов Microsoft, которые много рассказали о платформе WinRT. Золота на хакатоне мы не взяли, что обидно, но начало было положено и бросать уже имеющуюся платформу не хотелось.
Главным вопросом был: в какую сторону направить свои усилия? Месенджер уже существовал, а полноценный клиент мы бы тогда не потянули. Среди всех вариантов было решено сделать упор на новостную ленту. Она позволит предоставить пользователю новый функционал и избежать конкуренции с уже имеющимся приложением.

Что использовали

Когда вся команда учится в Москве, а живет в разных концах Московской области, важна система контроля версий. Для нас более чем достаточно было возможностей Team Foundation Service, благо за время хакатона удалось заработать статус BizSpark и пользоваться сервисом практически неограниченно. Основным плюсом этого решения было минимизация работ по администрированию сервера и простота в развертывании. Позже нам понадобился багтреккер. На момент разработки, готовых решений для Windows 8 не было, и пришлось быстро соорудить свой.

Прототипирование релизом или метод проб и ошибок

Мы не профессиональная студия, а три студента и обеспечить себя качественными прототипами дизайна и моделью использования приложения мы не можем. Не потому, что не умеем, а потому, что в сутках 24 часа, а помимо разработки нужно не забывать про учебу. Приходилось создавать версию, пользоваться и делать выводы.

Эволюция интерфейса была длительной. В одной из первых версий была попытка разделять новостные ленты для друзей и групп, потом от этого было решено отказаться. Следующие версии интерфейса были неким гибридом новостной ленты Вконтакте и элементов ModernUI.

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

Такой подход добавил проблем с отображением новостей.
Вконтакте позволяет делать посты непредсказуемой высоты. Судите сами, новость может состоять из текста произвольной длины, 10 фотографий, видеозаписей и неограниченного числа аудиозаписей. Все это прекрасно укладывалось в вертикальную прокрутку, но в горизонтальном исполнении высота поста была ограничена высотой экрана. Тут два варианта: либо обрезать пост, либо давать ему возможность расширяться в ширину. Вариант с расширением поста был отброшен из-за потенциальной возможности занять все место на экране. Была еще идея вертикальной прокрутки внутри поста, но такой список невозможно прокручивать ни мышью, ни пальцем. Значит нужно было обрезать пост. Но как? Решили обратиться к гайдлайнам по Windows 8, и обнаружили надпись Do more with less, которая и стала подсказкой. Теперь среди всех элементов была установлена иерархия согласно которой они попадали в превью поста. К примеру, при наличии видео и картинки отобразится только видео. Для текста изначально выделяется все место в превью, но оно уменьшается, если пост содержит другие элементы, но не менее двух строк. Конечно помимо превью был расширенный просмотр, где ничего не вырезалось.

Откуда ноги растут

Со временем мы стали обнаруживать в логах ошибки, связанные с неправильной обработкой результатов запросов к Вконтакте. Связано это было с самим сервисом, который очень активно, но молча меняет свое API. Приходилось экстренно делать заплатку и выпускать релиз. Одной из самых неожиданных для нас проблем стало всеобщее отключение приложения через 2-3 дня использования. Виной тому оказался срок действия токена.
Самым неприятным ударом стал выпуск неработающего приложения. Оптимизатор кода вырезал циклы ожидания. Выявить баг при дебаге было невозможно, так как при подключении дебагера, оптимизация кода отключалась. Провести полноценной тестирование опять же не позволяли ресурсы. Правда после этого случая пришлось взять за правило как минимум день тестировать приложение на устройстве.

Апдейты и новые фичи

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

• Острая нехватка времени.
• Отсутствие у пользователей желания использовать новые фичи операционки.

Если первая причина вполне понятна, то вторая требует более подробного объяснения. Windows 8 внесла множество новых возможностей для пользователя, но все они скрыты и многие до сих пор не догадываются об их наличии. Не каждый знает о кнопке share, позволяющей пересылать контент из любого приложения, поддерживающего этот контракт. На многих новостных ресурсах была информация о времени адаптации пользователя к системе: 3 месяца. Что подтвердил фидбек от пользователей, которые начали просить поддержку возможностей операционки только к началу февраля 2013. Первой фичей, которую мы использовали, стала живая плитка, которая позволила значительно повысить частоту использования приложения.
Таким образом мы постепенно наращивали функционал, до тех пор пока не поняли, что приложение с каждым релизом теряло стабильность. Основа, которая была заложена на хакатоне дала трещину и больше не могла быть использована. Решением было провести рефакторинг с целью заменить десериализатор ( перейти с xml на json) и уменьшить централизацию кода, который к тому моменту всецело зависел от класса для общения с VK API. В итоге рефакторинг затянулся на 4 недели.

Путь в топ.

Путь к славе начинается с сертификации приложения. Для приложений Российских сервисов этот путь тернист и не прост. Мы проходили 5 раз сертификацию, до тех пор пока не нашли нужный рецепт. Для приложений, нуждающихся в аккаунте необходимо выкладывать логин и пароль для тестирования и писать инструкцию. Как оказалось, для зарубежного тестеровщика оказалось проблематично зайти в приложение и сервис. Итогом трех неудачных попыток стало написание подробнейшей инструкции по входу в сервис. Чего оказалось мало. Понадобилось подробное описание работы. Где появится пост, когда вы шарите его на стену, в каком месте должен тестер увидеть свой статус и так далее. В итоге, полный текст инструкции занял страницу А4.
Как я уже говорил, первая версия была весьма куцей в отношении функционала, но именно она заложила основы продвижения в Windows Store. Вполне очевидно, что в отсутствии прямых конкурентов приложение быстро взлетело до третьего места в категории Social. Скачивания росли, аудитория пользователей пополнялась, что обеспечило нам за месяц 12 место в Top 100 бесплатных приложений магазина. Что вывело наше приложение в промо акцию.

Работа с аудиторией

Работа с аудиторией и тесное взаимодействие – важная часть поддержки приложения. Опыт выпуска первого приложения показал, что необходима поддержка в виде группы вконтакте. Она важна потому что позволяет:

• Поддерживать контакт с пользователем,
• Получать подробный фидбек
• Отводить негатив из комментариев.

Как показала практика, пользователь мало пользуется фидбеком по почте, который позволяет отсылать Windows Store. Вместо этого пользователь пишет о баге в комментарии, что портит рейтинг и снижает загрузки. Сбор фидбека через группу помог нам выявлять желания потребителя и быстрее реагировать на баги. Другой важной частью взаимодействия с аудиторией были комментарии к приложению. У разработчика всегда есть возможность добавить или изменить комментарий к своему приложению, после чего обновленная версия появляется первой в списке. Что позволяет более подробно описывать нововведения, а главное извещать пользователей о проблемах в приложении до их устранения. Такой прием позволил нам избежать негативных отзывов, когда по ошибке было выпущено нерабочее приложение.

Что дальше?

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

Так что, если хотите участвовать в разработке приложения из TOP 100 Windows Store — приходите к нам!

У вас проект на .NET 4.0 и вам надоела «лапша» из колбеков? Вы бы хотели использовать async/await в своем проекте, но тимлид грозит небесной карой за смену платформы? Если установка патча на фреймворк и студию для вас являются допустимым решением, то вам сюда. Если нет, то существует другое решение.

Немного теории

Async-метод это сопрограмма, которая выходит на каждом await, и восстанавливается с этой точки по завершению ожидания(автор знает, что выполнение не всегда прерывается на await и что «ожидать» можно не только экземпляры Task). Итак, начиная со второй версии дотнета можно легко создавать сопрограммы с помощью ключевого слова yield. Этим инструментом мы и воспользуемся.

Концепт

Хочется писать как на C# 5.0, и при этом не ставить никаких языковых расширений. К сожалению так не получится. Но есть вот такой вариант:

private IEnumerable Login(...) {              // ...              // get user id, if not specified             if (string.IsNullOrEmpty(uid))             {                 var getUserIdTask = сlient.GetUserId(...); yield return getUserIdTask; // await                 uid= getUserIdTask.Result.uid;             }              // login             var loginTask = сlient.Login(...); yield return loginTask; // await             var sessionId = loginTask.Result.SessionId;              // getting user's profile             var getUserInfoTask = сlient.GetUserInfo(...); yield return getUserInfoTask; // await             var userInfo = getUserInfoTask.Result;                         // ...                          yield return userInfo; // return } 

Всё что возвращается через yield return и не является наследником Task считается результатом исполнения async-метода.

Реализация

Код лежит тут.
Механизм работы простой:

1. Создаем корневой Task и возвращаем вызывающему
2. Вращаем итератор
3. Если вернулся Task, то ждем его завершения через ContinueWith с переходом к шагу №2
4. Если вернулась ошибка, то выставляем Exception для коневого Task
5. Если вернулось значение, то завершаем коневой Task с данным результатом
6. Если итератор кончился, то завершаем коневой Task со стандартным результатом

Во всех вариантах завершения на итераторе будет вызван Dispose, что приведет к освобождению ресурсов в блоках using и try/finally.

Начать новую асинхронную задачу можно вызвав метод FromIterator:

private IEnumerable Login(...) { ... }  Task loginTask = TaskUtils.FromIterator(this.Login(...)); // или с возвращаемым значением Task<UserInfo> loginTask = TaskUtils.FromIterator<UserInfo>(this.Login(...));  

Опционально можно указать:

• state — состояние, которое попадет в Task.AsyncState
• creationFlags — TaskCreationOptions для корневой задачи. Установка TaskCreationOptions.LongRunning говорит о том что вы очень не хотите блокировать текущий поток и вся работа должна быть выполнена в другом потоке
• cancellationToken — токен прерывания процесса исполнения async-метода, передается вглубь везде, где это возможно

Заключение

Плюсы:

• Компактненько и чисто
• Можно не бояться за unmanaged ресурсы, using, try/catch работают
• Не требует патчей и доп. библиотек
• Будет работать в Mono

Минусы:

• Async-метод возвращает IEnumerable, а не Task. Иногда приходится создавать дополнительный метод, который возвращает Task.
• «Ожидать» можно только экземпляры Task
• Ошибки «ожидаемых» задач нельзя обработать через try/catch(можно через ContinueWith). При ошибке в ожидаемой задаче, у корневой задачи выставляется Exception и поток исполнения больше не посещает async-метод.
• Внутренний класс реализации(TaskBuilder) не порождает ссылок на себя, кроме тех случаев когда подписывается на ContinueWith в ожидаемых задачах, и есть вероятность сборки его GC

Большую часть минусов можно побороть тем или иным способом.

Ошибки по тексту можно направлять в ЛС.
Исходный код.