Сегодня стартовали официальные продажи Apple Watch. 90% умопомрачительных концептов приложений под них, которые можно найти в Сети, нереализуемы — тем, кто знаком с гайдлайнами Apple, это хорошо известно. О том, что реализовать на часах все же можно и как это лучше сделать с точки зрения разработки и дизайна — под хабракатом.

10 недель назад мы запустили проект для iOS-разработчиков под названием Digest MBLTdev. После первого выпуска количество подписчиков превысило 1 000 человек. Как это работает? Наши топовые разработчики Руслан Гуменный и Саша Черный изучают материалы в сети, тщательно отбирают ссылки, которые не должны остаться без внимания, и формируют из них пятничный выпуск. Далее выпуск отправляется всем подписчикам на указанный имейл или по Safari Push Notifications.

В связи с символическим юбилеем мы решили собрать спец. выпуск для читателей Хабра. Представляем вашему вниманию 10 ссылок и небольшие рассуждения на тему того, как ссылка признается интересной и попадает в выпуск.

Среди задач мобильного разработчика, помимо самой частой (написания, собственно, приложений) периодически появляется и такая, как создание sdk.

Примерами такой задачи может быть создание sdk, использующего REST API какого-либо сервиса (реклама, аналитика, погода), библиотека реализаций алгоритмов, обработка изображений… Список практически неограничен.

Ошибки, допущенные в таком продукте, исправлять гораздо сложнее, чем при разработке приложений. В случае с приложением достаточно обновить его в AppStore, дождаться прохождения модерации и обновления пользователем. В случае же с sdk цепочка прирастает дополнительным шагом — дождаться его обновления разработчиком.

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

Любой подобный sdk обычно состоит из многих компонент: библиотеки, тестового приложения, документации, плагинов к другим инструментам. В этой статье я расскажу о сборке библиотеки в виде фреймворка, некоторых приёмах и особенностях разработки.

Несмотря на то, что в Objective-C 2.0 присутствуют замыкания (известные как блоки), ранее эппловский API использовал их неохотно. Возможно, отчасти поэтому многие программисты под iOS с удовольствием эксплуатировали сторонние библиотеки, вроде AFNetworking, где блоки применяются повсеместно. С выходом Swift, а также добавлением новой функциональности в API, работать с замыканиями стало чрезвычайно удобно. Давайте рассмотрим, какими особенностями обладает их синтаксис в Swift, и какие трюки можно с ними «вытворять».



Продвигаться будем от простого к сложному, от скучного к веселому. Заранее приношу извинения за обильное использование мантр «функция», «параметр» и «Double», но из песни слов не выкинешь.

Анонсированный в июне и только что вышедший Apple Watch SDK вызвал много споров и вопросов. Первая версия имеет ограниченную функциональность, и не за горами выход версии 2.0, нужно подождать ещё несколько месяцев. Впечатления от нового SDK у разработчиков сложились разные. Одни разочарованы большим количеством ограничений, другие, напротив, впечатлены самим фактом выхода. Есть и «прослойка» тех, кто принял новый продукт достаточно сдержанно. Но в любом случае подавляющее большинство разработчиков рады выходу новой интересной забавы.

В процессе разработки любого приложения наступает момент, когда в связи с ростом функциональности трудозатраты на регрессионное тестирование становятся непомерно велики. Другая причина значительной трудоемкости тестирования iOS-приложений (так же как и любых других мобильных приложений) — разнообразие линейки поддерживаемых устройств и версий ОС, необходимость тестирования в альбомном и портретном режимах, а также при различных условиях соединения с интернетом. Стремление оптимизировать процесс тестирования приводит нас к необходимости его полной или частичной автоматизации.

В этой статье я расскажу о том, как мы автоматизируем тестирование наших приложений (ICQ и Агент Mail.Ru), поделюсь нашими наработками в этой области и упомяну о проблемах, с которыми мы сталкиваемся.

Если издали видно общую картину, то вблизи можно понять суть. Концепции, которые казались мне далекими и, прямо скажем, странными во время экспериментов с Haskell и Scala, при программировании на Swift становятся ослепительно очевидными решениями для широкого спектра проблем.

Взять вот обработку ошибок. Конкретный пример – деление двух чисел, которое должно вызвать исключение если делитель равен нулю. В Objective C я бы решил проблему так:

NSError *err = nil;
CGFloat result = [NMArithmetic divide:2.5 by:3.0 error:&err];
if (err) {
    NSLog(@"%@", err)
} else {
    [NMArithmetic doSomethingWithResult:result]
}

Со временем это стало казаться самым привычным способом написания кода. Я не замечаю, какие загогулины приходится писать и как косвенно они связаны с тем, что я на самом деле хочу от программы:

Верни мне значение. Если не получится – то дай знать, чтобы ошибку можно было обработать.

Я передаю параметры, разыменовываю указатели, возвращаю значение в любом случае и в некоторых случаях потом игнорирую. Это неорганизованный код по следующим причинам:

• Я говорю на машинном языке – указатели, разыменование.
• Я должен сам предоставить методу способ, которым он уведомит меня об ошибке.
• Метод возвращает некий результат даже в случае ошибки.

Каждый из этих пунктов – источник возможных багов, и все эти проблемы Swift решает по-своему. Первый пункт, например, в Swift вообще не существует, поскольку он прячет под капотом всю работу с указателями. Остальные два пункта решаются с помощью перечислений.

Мы продолжаем выкладывать видео выступлений с нашей первой конференции мобильных разработчиков #MBLTDev. Следующий доклад — от iOS-разработчика компании «Одноклассники» Юрия Буянова «Опыт использования MVVM в реальных проектах».


Презентация.

Доклад был посвящён практическим аспектам разработки iOS-приложений с использованием архитектуры MVVM. В частности рассматривались способы осуществления навигации и реализации списков в рамках такой архитектуры. Для слушателей, незнакомых c предметом, в начале доклада было сделано небольшое введение в MVVM и ReactiveCocoa. Также были показаны слайды с белочкой, совушкой и единорогом.

Одними из самых востребованных классов в UIKit до выхода iOS версии 8 являлись UIAlertView и UIActionSheet. Наверное, каждый разработчик приложений под мобильную платформу от Apple рано или поздно сталкивался с ними. Показ сообщений или меню выбора действий — это неотъемлемая часть практически любого пользовательского приложения. Для работы с этими классами, а точнее для обработки нажатий кнопок, программисту требовалось реализовывать в своем классе методы соответствующего делегата — UIAlertViewDelegate или UIActionSheetDelegate (если не требовалось чего-то сверх, то достаточно было реализовать метод clickedButtonAtIndex). На мой взгляд это очень неудобно: если внутри объекта создавалось несколько диалоговых окон с разными наборами действий, то их обработка все равно происходила в одном методе с кучей условий внутри. С выходом 8 версии iOS в составе UIKit появился класс UIAlertController, который пришел на смену UIAlertView и UIActionSheet. И одной из его главных отличительных черт является то, что вместо делегатов он использует блочный подход:

    UIAlertController *alertController = [UIAlertController alertControllerWithTitle:@"Hello" message:@"Habr!" preferredStyle:UIAlertControllerStyleAlert];
    
    [alertController addAction:[UIAlertAction actionWithTitle:@"Action" style:UIAlertActionStyleDefault handler:^(UIAlertAction *action) {
        // код обработчика кнопки
    }]];

Такой подход позволяет писать более структурированный и логичный код. Отныне программисту больше не требуется разделять создание диалогового окна и обработку событий — UIAlertController устраняет это недоразумение, но одновременно с этим привносит историческую несправедливость из-за невозможности использования в iOS 7 и более ранних версиях. Решить эту проблему можно несколькими способами:

• Не обращать внимание на UIAlertController и продолжать использовать устаревшие UIAlertView и UIActionSheet.
  
• Использовать нестандартные диалоговые окна. Программист либо пишет собственную реализацию, что приводит к увеличению временных затрат, либо подключает сторонние компоненты (например, SIAlertView), использование которых имеет ряд недостатков:
  
  1. программные модули с хорошей поддержкой можно пересчитать по пальцам (зачастую их создатели быстро забрасывают это неблагодарное дело);
  2. если в проекте используются несколько компонентов от разных разработчиков, то при их взаимодействии могут возникать проблемы (редко, но это возможно).
  
  
• Проверять версию iOS и создавать либо UIAlertController, либо UIAlertView или UIActionSheet.
  

Последний вариант наиболее логичен, и большинство разработчиков, я уверен, выбрали бы именно его, но данный метод имеет существенный недостаток — условие проверки версии операционной системы придется писать каждый раз, когда потребуется отобразить диалоговое окно. Столкнувшись с этим на практике, я создал специальный класс-обертку UIAlertDialog, который позволяет забыть об этой проблеме.

Эта статья рассказывает о проблемах, которые поджидают программиста, работающего с часовыми поясами. В теории, вроде, всё хорошо, просто и понятно, но жизнь — штука сложная, и на практике, порой, возникают совершенно неожиданные ситуации.

TL;DR: Работа с таймзонами — это боль и унижение. Никогда не работайте с таймзонами!

Итак, все кругом твердят вам, что при получении времени от пользователя нужно сразу же переводить его в UTC, работать со временем нужно только в UTC и хранить время тоже нужно строго в UTC. Совет, на первый взгляд, выглядит разумным, и следование ему делает вашу жизнь проще… Если только ваша программа не предполагает сложной работы с датами. Записать в базу данных дату и время регистрации пользователя на сайте? Сохранить время отправки сообщения или дату создания заказа в интернет-магазине? Вывести сообщение в лог с указанием даты-времени? Используйте UTC и всё будет в порядке, можете даже не читать эту статью дальше. Любое текущее время можно совершенно спокойно конвертировать в UTC и забыть о проблемах. Но что, если мы хотим работать с временем в будущем? Или в прошлом? Например, если мы пишем сервис календаря, или сервис для отложенной отправки сообщений?

Сделать веб-сайт доходным можно двумя способами. Первый – привлекать больше трафика, второй – повышать конверсию, т.е. побуждать большее количество посетителей становиться покупателями. Скорее всего, вы уже слышали о том, что трафик можно просто купить – сотни интернет-ресурсов предлагают эту услугу. А не лучше ли оптимизировать конверсию? Как узнать, что именно нужно проверить, и как провести A/B тестирование?

А/В тестированию и оптимизации уровня конверсии посвящено бесчисленное количество ресурсов. Однако, очень редко на сайтах подробно разбирается весь этот процесс целиком от самого начала («Что и как тестировать?») и до конца («Как улучшить конверсию?»).

Как многие читали в книгах, в языке Objective-C изначально есть два корневых класса — NSObject и NSProxy. И если на первом основано практически все и с ним невозможно не столкнуться, то вторым пользуются значительно реже. В этой небольшой статье я опишу те применения этого класса, которые приходилось использовать мне.

Swift это новый язык программирования от компаний Apple, который она презентовала в этом году на WWDC. Вместе с языком программирования, Apple выпустила отличный справочник по языку Swift, который я рекомендую прочитать или ознакомиться с ним. Тем не менее, читать книгу это очень долго! Так что если у Вас нет много времени и Вы просто хотите узнать о новом языке Swift, то эта статья для Вас.

В данной статье я бы хотел поделиться некоторыми размышлениями по поводу перехода от Objective-C к Swift. Я постараюсь дать Вам несколько советов и указать на недостатки при разном подходе к обеим языкам. Поэтому без лишних отступлений, перейдем к самой статье.

С момента анонса языка Swift скорость была ключевым элементом маркетинга. Еще бы – она упоминается в самом названии языка (swift, англ. — «быстрый»). Было заявлено, что он быстрее динамических языков наподобие Python и Javascript, потенциально быстрее Objective C, а в некоторых случаях даже быстрее, чем C! Но как именно они это сделали?

Спекуляции

Несмотря на то, что сам язык предоставляет огромные возможности для оптимизации, у нынешней версии компилятора с этим не все в порядке, и получить хоть какие-то успехи в тестах производительности стоило мне немало сил. В основном это происходит из-за того, что компилятор генерирует массу излишних действий retain-release. Думаю, что это быстро поправят в следующих версиях, но пока мне придется говорить о том, благодаря чему Swift может быть потенциально быстрее Objective C в будущем.

Более быстрая диспетчеризация методов

Как известно, каждый раз, когда мы вызываем метод в Objective C, компилятор транслирует его в вызов функции objc_msgSend, которая занимается поиском и вызовом нужного метода в рантайме. Она получает селектор метода и объект, в таблицах методов которого производится поиск непосредственного куска кода, который будет обрабатывать этот вызов. Функция работает очень быстро, но зачастую делает куда больше работы, чем действительно нужно.

Передача сообщений удобна тем, что компилятор не делает никаких предположений относительно того, какой объект попадется ему в рантайме. Это может быть экземпляр типа выражения, дочерний класс, или вообще абсолютно другой класс. Компилятор можно обмануть, и все будет работать как положено.

С другой стороны, в 99.999% случаев вы не будете врать компилятору. Когда объект объявлен как NSView *, это либо непосредственно NSView, либо дочерний класс. Динамическая диспетчеризация необходима, а вот настоящая пересылка сообщений практически не нужна, но природа Objective C заставляет всегда использовать самый «дорогой» вид вызовов.

Почти каждый микроконтроллерщик сталкивался с громадными switch-case и мучительно их отлаживал.
И много кто, начиная писать реализацию какого-либо протокола, задумывался как написать её красиво, изящно, так чтобы через месяц было понятно что ты имел в виду, чтобы она не отжирала всю память и вообще какала бабочками.
И вот тут на помощь приходят машины состояний, они же конечные автоматы (те самые которые используются в регулярных выражениях).

Собственно через регулярные выражения я к ним и пришёл.

По решению Московского городского суда доступ к «пиратским» копиям некоторых сериалов от «А сериал» (дочерняя компания «Амедиа») должен быть закрыт. Похоже на то, что антипиратский закон начинает работать в полную силу. С самим постановлением можно ознакомиться вот здесь. Стоит отметить, что режиссер «Престолов» и канал НВО ранее не раз уже говорили о том, что нелегально распространяемые копии фильмов/сериалов только повышают продажи лицензионной продукции.

Если вдруг однажды вы заметите, что с вашего счета начнут утекать деньги в непонятном направлении, эта статья поможет вам разобраться в причинах и, самое главное, вернуть эти деньги.

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

Как вообще можно подписать на услугу без моего ведома?

У сотовых операторов есть «партнеры», оказывающие разного рода услуги (например, купить картинку-подарок в «Контакте»). Смысл подобных услуг заключается в следующем:

1. Вы вводите номер телефона.
2. Вам присылают код подтверждения.
3. Вы вводите этот код.
4. С этого моменты вы считаетесь официально подписанным на какую-то услугу (будь то одноразовую или нет).

Подвох заключается в том, что легитимность подключения какой-либо услуги операторы запрашивают у самих компаний, которые эту услугу подключают (эти компании именуются партнерами сотовых операторов). Более того, отправление уведомления и подтверждения подключения какой-либо услуги лежит полностью на совести партнеров операторов (контент-провайдеров). Интересным также является тот момент, что в биллинге у некоторых сотовых операторов (например, у «Билайна») нет информации по поводу входящих смс, т. е. если вам будут говорить, что вам пришла смс с подверждением, вам не смогут это доказать.

Всё это делает возможным, например, следующую схему:

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

   Я считаю, что одним из главных устройств, которое должно быть в любом автомобиле, является видеорегистратор. Что это такое и для чего он нужен? По большому счету, это небольшая штука, основная задача которой – записывать всё то, что видит водитель в лобовое стекло своего автомобиля. За этот «бесполезный» кусок китайской пластмассы иной раз хотят очень много денег, поэтому многие считают его покупку нецелесообразной, предпочитая купить какой-нибудь сабвуфер. Однако в жизни любого водителя может случиться (тьфу-тьфу-тьфу) такой момент, когда подобное устройство может оказаться единственным спасением – пройдет всего какой-то миг, а видеорегистратор, в отличие от того же сабвуфера, успеет многократно окупиться. От приключений на дороге никто не застрахован, просто одни вздохнут с облегчением, а к другим моментально придет понимание, что регистратор все-таки нужен. Был.



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

Хочу поделиться с Хабра-сообществом моим хобби, которое, если честно, даже некоторую прибыль мне приносит.

Начну сначала. Лет так 6-7 назад мне очень стала интересна такая штука как фото-мозаика. В самом начале я пробовал делать её вручную. Немеряное количество слоев в фотошопе и куча потраченного времени меня остановила года так на три. Но со временем только появлялся азарт.
И вот я начал свое исследование программного обеспечения для создания фото-мозаик, которого было перепробовано огромное количество. И в конечном итоге выбрано лучшее.

О лучшем как раз и пойдет речь.