среда, 7 мая 2014 г.

CLR и Windows Runtime (WinRT)

С выходом Windows 8 разработчикам стала доступна новая библиотека классов - Windows Runtime. Компоненты WinRT могут использоваться в приложениях Windows Store и настольных приложениях; в неуправляемом коде C/C++, в JavaScript, а также в C# и Visual Basic.

Метаданные Windows Runtime

На внутреннем уровне компоненты WinRT представляют собой компоненты COM (Component Object Model), для описания API которых теперь используются метаданные. Эти метаданные хранятся в файлах с расширением *.winmd и представляют собой обновленную версию метаданных .NET, которые кодируются в соответствие с правилами раздела №2 (Metadata Definition and Semantics) стандарта ECMA-335. Поскольку обычные сборки .NET Framework кодируются с помощью этого же стандарта, это говорит о том, что вы можете использовать знакомые средства (такие как ildasm.exe, Object Browser) для просмотра содержимого этих файлов.
По большей части, просмотр WinMD файла с помощью утилиты ildasm.exe очень похож на просмотр стандартной управляемой сборки. Есть несколько различий, которые могут быть видны - в первую очередь то, что WinMD файлы, в общем, не содержат никаких Intermediate Language (IL) инструкций. Вместо этого, эти файлы описывают API, предоставляемые Windows Runtime. Реализация этих интерфейсов может быть полностью отделена от их определения, и по сути, может быть записана в машинном коде. Тем не менее, для разработчиков управляемых приложений, детали реализации WinRT API не имеют значения, потому что управляемый код должен видеть только определения API, которые он вызывает. За кулисами, Common Language Runtime (CLR) и операционная система Windows соединяют для вас определения API и их реализации.
Например, в файле метаданных Windows.Foundation.winmd (находится в каталоге %WinDir%\System32\WinMetadata) вы можете обнаружить следующий тип Windows.Foundation.Collections.PropertySet, конструктор которого не содержит тела, потому что тип реализуется в native code.

Тем не менее, метаданные, которые описывают этот тип позволяют CLR получить экземпляр реализации при вызове конструктора класса.
При просмотре Windows Runtime метаданных можно также заметить, что определения типов и сборок используют новое ключевое слово WindowsRuntime.


Это ключевое слово является контекстно-зависимым и по разному интерпретируется в зависимости от того, где оно применяется. Например, если ключевым словом помечено определение типа (TypeDef), то этот тип подчиняется правилам системы типов Windows Runtime и вызов этого типа следует рассматривать как вызов WinRT API.

воскресенье, 27 октября 2013 г.

Асинхронная загрузка данных с индикацией

Я как-то уже затрагивал тему асинхронной загрузки данных в своей статье TaskExtensions в помощь. Однако, используя такой подход, код со временем начинал обрастать огромным количеством callback'ов и командами. Чтобы оптимизировать данный процесс для своих нужд я сделал класс, которым и хочу поделиться. Ничего нового в нем нет, однако, он позволил сократить огромное количество кода и на мой взгляд является весьма интересным.
Суть класса такова: предоставить пользователю коллекцию динамических данных с выдачей уведомлений при обновлении, а также обеспечить механизм индикации загрузки данных, при этом выбор источника данных предоставить потребителю.
Самый классический сценарий для UI-девелопера: список объектов и кнопка "Обновить". Я решил совместить это в одной коллекции:

public sealed class AsyncObservableCollection<T> : ObservableCollection<T>, ICommand
{
    private readonly Func<Object, Task<IEnumerable<T>>> factory;

    public AsyncObservableCollection(Func<Object, Task<IEnumerable<T>>> factory)
    {
        this.factory = factory;
    }
}

четверг, 26 сентября 2013 г.

Совершенный код



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

четверг, 29 августа 2013 г.

Атлас Москвы

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





















четверг, 25 июля 2013 г.

Barley-Break Update!

Сегодня обновил дизайн своего первого приложения в Windows Store - Barley-Break. Вроде неплохо получилось! :)


Сохранение настроек приложения в изолированном хранилище

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

Что из себя представляют настройки приложения? Это коллекция пар ключ/значение. То есть это некоторый IDictionary<TKey, TValue>, где в качестве ключа выступает, как правило, строковый параметр, а в качестве значения, в идеале, может быть любой объект. Если внимательно посмотреть на пространство имен System.IO.IsolatedStorage, то можно обнаружить, что класс с таким функционалом уже есть - это IsolatedStorageSettings. Однако он доступен только для Silverlight и Silverlight for Windows Phone. А для настольных приложений доступен только класс IsolatedStorageFile, который представляет область изолированного хранения, содержащую файлы и папки. То есть разработчики настольных приложений здесь несколько обделены функционалом. Собственно этот пробел я и решил заполнить.

Идея до безобразия проста: ключ - это файл в изолированном хранилище, в котором хранится значение этого ключа в виде сериализованных двоичных данных. Однако, если ключ будет состоять из символов, которые не могут содержаться в имени файла (\/:*?"<>|), возникает проблема. Решение, в принципе, такое же простое - хранить значения оригинальных ключей в отдельном служебном файле и каждому такому значению сопоставлять уникальный идентификатор, по имени которого будет создаваться файл для хранения значения оригинального ключа. Если не совсем понятно, то надеюсь рисунок все прояснит:

(info.dat - служебный файл, Key - оригинальный ключ, Guid - уникальный идентификатор)