21 марта 2014 в 12:38

ВКонтакте API для .Net

image
Добрый день, друзья!

Хочу рассказать вам о своём небольшом open source проекте, а именно реализация ВКонтакте API для .Net. В общей сложности пилю его уже полтора года. Сделано еще не всё, а что сделано под катом.

Полный список реализованных методов можно посмотреть в документации. Коротко, практически все методы из следующих категорий:
  • пользователи;
  • друзья;
  • статусы;
  • сообщения
  • группы
  • аудио
  • видео
  • данные вк
  • служебные
  • закладки
  • стена (немного).

Небольшой пример как с этим работать. К примеру, давайте попробуем послать сообщение «привет, друг!» пользователям из сообщества Хабрахабр (проверки убраны). Данный пример показан только для демонстрации работы библиотеки.
static void Main(string[] args)
        {
            int appId = 1234567; // указываем id приложения
            string email = "example@example.ru"; // email для авторизации
            string password = "qwerty123"; // пароль
            Settings settings = Settings.All; // уровень доступа к данным

            var api = new VkApi();
            api.Authorize(appId, email, password, settings); // авторизуемся

            var group = api.Utils.ResolveScreenName("habr"); // получаем id сущности с коротким именем habr

            // получаем id пользователей из группы, макс. кол-во записей = 1000
            int totalCount; // общее кол-во участников
            var userIds = api.Groups.GetMembers(group.Id.Value, out totalCount); 
            foreach (long id in userIds)
            {
                api.Messages.Send(id, false, "привет, друг!"); // посылаем сообщение пользователю
            }
        }}


Скачать можно с сайта проекта или загрузить через Nuget.

image

P.S. Многие методы еще не реализованы и если ты хочешь поучаствовать в проекте или нашел ошибки, то дай об этом знать через сайт.
Какие категории методов реализовать дальше

Проголосовало 538 человек. Воздержалось 308 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Антон Жидков @azhidkov
карма
22,0
рейтинг 0,0
Похожие публикации

Комментарии (17)

  • +3
    Жаль, что нацелено на 3.5. Получается никакого async. :-(
    • +6
      Согласен. Было бы неплохо, если бы добавили асинхронку хотя бы в старом варианте, по типу BeginInvoke — EndInvoke.
      P.S. Потенциал неплохой, я бы посоветовал портировать на WP8 и Xamarin, думаю, что будет популярно в Xamarin Store ;)
      • +1
        Поддерживаю портирование на WP8.
    • +3
      Самое забавное, что async отлично можно завести и на .NET 2.0, достаточно нужные классы из Mono вытащить и скомпилировать в dll-ку. У меня где-то ещё валялась версия такой библиотеки и для .NET 4, работающая без KB, требуемого решением от мелкомягких.
    • +2
      А это востребовано? Могу попробовать отделить API из своего VK unO
      apps.microsoft.com/windows/uk-ua/app/vk-uno/87dc7d15-1241-4e75-b7c9-a0aa802714d6
      • +2
        Если уж реализовывать современный api-клиент на .net, то с async, конечно. Но это моё личное мнение.
        Так-то понятно, что для почесывания левой пятки по пятницам вполне ОК.
    • 0
      А в чем проблема использовать Task.StartNew(() => {...}).ContinueWith(t => {...})?
      Можно свой или сторонний TaskHelper какой-то взять на вооружение. Через тот-же хелпер можно прикрутить стандартное логгирование ошибок.
      • +1
        Наверное, в том, что HTTP запросы IO-Bound и Task.StartNew будет кушать ресурсы без необходимости. SO.
        • 0
          Насколько я понял, в комментарии, на который я ответил, автор раздосадован, что не сможет задекорировать свой метод аттрибутами 'async — await'. Если я прав, то Ваш пример о том же, о чем я написал, а именно обойтись без сахара async-await и использовать TPL.

          Насколько я понял, преимущество Вашего примера в том, что не занимается поток из Tread Pool. Я правильно понял?
          • +1
            Да, но не совсем.

            Независимо от того, как реализован метод в библиотеке (с async или без) его результат можно await'ить в своем методе, если он возвращает Task.

            Мой пример о том, что если метод в библиотеке реализует IAsyncResult паттерн, то эффективнее будет использовать Task.FromAsync, чем оборачивать синхронный метод в Task.StartNew.

            А проблема в библиотеке в том, что, она не реализует ассинхронное API ни каким образом. Т.е. придется использовать Task.StartNew, что в свою очередь будет не так эффективно.

            Надеюсь так понятнее.
            • 0
              Да. Понятно.
              Получается, если в Tread Pool имеется ограничение в 30 потоков, то невозможно будет даже при монопольном захвате пулла запустить больше 30 параллельных запросов IO/Web.
  • +1
    А почему без async и только .NET 3.5? По-моему мало актуально. Я для Meridian (https://github.com/Stealth2012/meridian) использую самописную Portable-библиотеку, которая поддерживает async и может использоваться в проектах NET4.5/WP8/Win8.
    • +1
      А вы в каждый аккаунт добавляете год его создания?
      • +2
        Да.
        • 0
          Забавно. А это просто ради прикола, или имеется скрытый смысл? Может, как-то анализируете потом или еще какое-то прикладное применение?
  • 0
    О, спасибо! Как раз недавно задумал приложение по ВК, поискал библиотеку и не нашёл, пришлось писать самостоятельные велосипеды:)

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