ВКонтакте 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. Многие методы еще не реализованы и если ты хочешь поучаствовать в проекте или нашел ошибки, то дай об этом знать через сайт.
    Какие категории методов реализовать дальше

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

    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 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
              О, спасибо! Как раз недавно задумал приложение по ВК, поискал библиотеку и не нашёл, пришлось писать самостоятельные велосипеды:)

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