На заре программирования и до совсем недавнего времени программа была чем-то законченным, полностью готовой к употреблению самостоятельной единицей, которая выполняла свои функции и только их.
Однако с появлением мобильных устройств, веб сайтов с богатой логикой и социальных сетей все стало меняться. Сейчас программы, которые не выходят в сеть, не умеют что-то выкладывать в фейсбуки и вообще работают сами в себе, практически не имеют права на жизнь. Даже професcиональные инструменты, такие как, Microsoft Office 2013, стали поддерживать облачные хранилища для обмена документами.
Мир меняется. Теперь, чтобы заработать денег на продаже софта, необязательно писать свою собственную операционную систему или антивирус, потратив кучу времени и ресурсов. Достаточно просто попросить свою жену и вдвоем разработать мировой хит. Поэтому многие сегодня мечтают создать своих злых птичек или кат-зе-роуп, изучая разработку под iOS, Android, Windows Phone.
Допустим, вы написали свое приложение и опубликовали его в каком-то из магазинов. Все отлично, вы получаете прибыль, но хочется больше. Вы понимаете, что надо писать приложения еще и для других платформ, чтобы расширить пользовательскую базу. Здесь-то и кроется первая засада — как минимизировать количество кода, который вы пишете, если приложения будут работать по большей степени одинаково и отличаться будут только внешним видом (и то не факт) и языком программирования?
Ответом на этот вопрос станет старичок ООП, облачившийся в модные шмотки и сменивший имя. Если вынести общую логику из кода приложения в некий общий сервис и расположить этот сервис в интернете, чтобы все приложения могли к нему подключаться, тогда для реализации мобильного приложения на конкретной платформе вам останется лишь написать код отображения данных с сервера. Звучит знакомо, не так ли? Это очень похоже на паттерн MVC. Здесь Model — это сервис в интернете, который получает и отдает данные, а View и Controller реализуются на мобильном устройстве и могут быть максимально упрощены. В качестве модели устройства подобного сервиса сегодня все чаще стали использовать так называемый RESTful API — программный интерфейс, к которому можно обращаться через стандартные HTTP методы.
И все вроде бы выглядит хорошо и уже кажется, что решение найдено. Однако проблемы начинаются, когда вы станете самостоятельно развертывать сервис бекенда на сервере. Я — программист, и когда дело доходит до установки и настройки сервера, мне сразу становится не по себе. Во-первых, это абсолютно новые знания, которые надо изучить, чтобы все работало как надо. Во-вторых, чтобы все работало действительно как надо и не упало при возросшей нагрузке или атаке, надо курить маны еще больше и упорнее. Можно попробовать найти такого хостера, который избавит вас от возни с серверами и предустановит PHP и/или что-то еще. Но тогда останется проблема того, что нужно будет самостоятельно реализовывать все необходимые обработчики событий сервера для реализации полноценного REST API. А это опять же отнимает ваше полезное время и тратит его на ненужные вещи.
К чему я это все?
Я сам долго время мучился вопросом, а как же мне организовать свой серверный бекенд для приложения. Сначала писал что-то свое, используя WCF сервисы. Потом появился ASP.NET Web API, который довольно неплохо упростил жизнь. Но сегодня я хочу поведать о другом. Я как любитель простых в использовании вещей не мог пройти мимо относительного нового сервиса, который появился в облачной платформе Windows Azure. Имя этого сервиса — Windows Azure Mobile Services Custom API.
Данный сервис, наряду с другими полезными возможностями Windows Azure Mobile Services, является PaaS решением и предоставляет возможность быстро развернуть облачный RESTful API, к которому может получить доступ программа на любом языке и платформе. В основу этого решения легла уже не новая, но довольно популярная технология Node.js. Custom API является полностью функциональным Node.js приложением со всеми вытекающими последствиями — это полноценное решение без компромиссов. А с учетом того факта, что для работы с ним написаны нативные SDK для всех трех популярных мобильных платформ, это решение становится еще интереснее.
Далее в этой части я хочу рассказать о том, как создать и начать пользоваться облачным бекендом в Windows Azure и обращаться к нему с мобильного устройства. Не переключайтесь!
Создание облачного бекенда
Создание облачного бекенда, как и любого другого сервиса в Windows Azure, происходит из портала управления облаком. Сперва надо создать мобильную службы, придумав ей какое-то вменяемое название:
Увеличить
Далее вам необходимо выбрать SQL базу данных, в которой будут храниться данные мобильной службы. Есть вариант создать бесплатный экземпляр на 20Мб. Для тестирования возможностей — хватит за глаза. А если понравится, то всегда можно проапгрейдиться на более серьезные решения.
После нажатия на стрелку далее и ввода параметров сервера БД (создать новый или использовать существующий логин/пароль администратора и прочая скукота), новый мобильный сервис начнет создаваться в облаке. Обычно это происходит крайне быстро, меньше чем за минуту. Когда служба создастся и вы зайдете в нее, то увидите что-то вроде этого окна:
Увеличить
Запомните его, оно нам еще пригодится далее.
Создание API
Чтобы создать свой первый облачный API, просто перейдите на вкладку API и нажмите кнопку Create a Custom API:
Увеличить
Если вы ранее работали с мобильными службами Windows Azure, то следующее окно будет вам знакомо. В нем необходимо задать название будущего API, а также один из четырех уровней доступа к различным его методам. Оставим все по умолчанию, тогда к нашему API смогут подключаться только те клиенты, у которых есть параметр авторизации:
Увеличить
Как только новый API создался, мы можем приступить к его редактированию. Изначально вы должны увидеть скрипт, похожий на этот:
Увеличить
В образовательных/тестовых целях я предлагаю слегка его изменить, чтобы получилось вот так:
Увеличить
Основным изменением в данном случае стало то, что в обработчике POST-запросов стали возвращаться данные в виде простой строки, а в GET добавилась переменная, и у ее объекта есть более одного поля. Я сделал так для наглядности, чтобы проиллюстрировать различные возможности работы с данными.
Использование API
Для данной статьи мы воспользуемся тестовым приложением, которое нам любезно предоставляет Windows Azure Mobile Services. Для этого вернемся на страницу Quick Create (это та самая, с облачком и молнией на пиктограмме), выберем Windows Phone 8 (хотя обратите внимание на богатый выбор) и нажмем Create A New Windows Phone App:
Увеличить
Создав нужную табличку (TodoItem) и скачав приложение по кнопке Download, откроем его в Visual Studio.
В первую очередь нас интересует две вещи. В файле App.xaml.cs есть строка примерно такого вида:
public static MobileServiceClient MobileService = new MobileServiceClient(
"https://mva-test-api.azure-mobile.net/",
"тут_набор_непонятных_символов"
);С помощью этого поля мы будем общаться с нашей новоиспеченной мобильной службой. Набор непонятных символов — это ApplicationKey, индивидуальный ключ вашей службы, хольте его и лелейте.
Давайте запустим приложение и посмотрим хотя бы, как оно выглядит:
Ну не хит апстора, но для начала неплохо. Давайте наделим его дополнительной логикой и вызовем наши API методы. Идем в файл MainPage.xaml.cs. От него я хочу добиться того, чтобы при нажатии на кнопку Save происходило обращение к сервисам, после чего полученный результат просто писался в консоль отладки. Для этого в конец метода InsertTodoItem добавьте следующий код:
// Обращение к POST
var result = await App.MobileService.InvokeApiAsync("CoolAPI", null, HttpMethod.Post, null, null);
Debug.WriteLine(result.StatusCode);
var stringData = await result.Content.ReadAsStringAsync();
Debug.WriteLine(stringData);
// Обращение к GET
var resultJson = await App.MobileService.InvokeApiAsync("CoolAPI", HttpMethod.Get, null);
Debug.WriteLine(resultJson);Главным методом в этом коде можно назвать InvokeApiAsync. Он отвечает за вызов того или иного метода API. Этот метод перегружен и наделен различным набором параметров. В примере видно, что в случае с POST мы передаем аж 5 параметров, а в случае с GET всего 3. Это связано с тем, что метод для POST рассчитан на то, что результатом работы будет обычная строка (вспоминаем реализацию скрипта на бекенде), а вариант с GET — на работу с JSON объектом (результатом будет Newtonsoft.Json).
Если теперь запустить приложение и понажимать кнопку Save, то в Debug-консоли приложения будет видно что-то вроде этого:
Как у них
Я не просто так попросил обратить внимание на возможность выбора типа приложения на страничке Quick Create в панели управления Windows Azure. Дело в том, что нативный SDK для работы с мобильными службами написан не только для Windows устройств. Свои библиотеки выпущены и для iOS, и для Android, поэтому все то же самое можно использовать и на этих платформах. Вот пример кода на ObjectiveC, который будет делать примерно то же, что и в примере:
[self.client invokeAPI:@"CoolAPI" data:nil HTTPMethod:"POST"
parameters:nil headers:nil completion:^(NSData *result,
NSHTTPURLResponse *response, NSError *error) {
NSLog(@"%i", response.statusCode);
NSString *stringData = [[NSSatring alloc] initWithData:result encoding:NSUTF8StringEncoding];
}];Как видите — «чистый» ObjectiveC, без мухляжа. Аналогично для Android, WinRT и даже для веб-версии (на HTML и JavaScript).
Что дальше
Я изначально планировал написать только одну статью сразу про все возможности серверного кода в Windows Azure Mobile Services, но материала получается слишком много. Поэтому сейчас мы закончим, а в следующей части я расскажу о том, как можно работать над облачным бекендом в команде, используя при этом Git. А еще о том, как расширить функциональность общими скриптами и NPM-пакетами.
