Содержание:

Часть 0. Синглтон-Одиночка
Часть 1. Стратегия
Часть 2. Наблюдатель

Сегодня мы разберемся с "начинкой" паттерна "Наблюдатель". Сразу оговорюсь, что в мире iOS у вас не будет острой необходимости реализовывать этот паттерн, поскольку в SDK уже есть NotificationCenter. Но в образовательных целях мы полностью разберем анатомию и применение этого паттерна. К тому же, самостоятельная реализация может обладать большей гибкостью и, в некоторых случаях, быть более полезной.

Вот список 25 Android-библиотек, релиз которых состоялся в январе-феврале 2017 года. Все они достойны внимания, место в списке не определяется значимостью. Приступим!

Любому дизайнеру, над чем бы он ни работал — сайтами, журналами или мобильными приложениями, — наверняка приходилось слышать термин «сетка». Существуют сетки для всевозможных вариантов расположения контента. Мы применяем колоночные сетки, чтобы выстраивать контент по горизонтали, сетки базовых линий, чтобы выравнивать блоки текста по вертикали, гибкие (soft) и жесткие (hard) сетки — в зависимости от того, насколько строго собираемся их придерживаться. Я заинтересовался системой 8pt сеток, когда услышал, с каким увлечением говорит о ней Брин Джексон, и решил посмотреть, какие преимущества она может дать моим дизайнам (и может ли вообще).

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

Недавно, читая пост про SwiftyVK, нашел там ссылку на статью про OptJSON, позволяющую сильно упростить работу с JSON в Swift. И хотя подход, описанный в статье, действительно интересен, меня не покидало ощущение, что это все-равно слишком сложно.

Я попробовал еще немного упростить библиотеку OptJSON, и вот что получилось:

let obj = json?["workplan"]?["presets"]?[1]?["id"] as? Int

Содержание:

• Разработка через тестирование – что это?
• Три закона TDD
• Примеры применения
• Преимущества и недостатки
• Литература и ссылки

Разработка через тестирование – что это?

Разработка через тестирование (Test-driven development) — техника разработки программного обеспечения, которая определяет разработку через написание тестов. В сущности вам нужно выполнять три простых повторяющихся шага:
— Написать тест для новой функциональности, которую необходимо добавить;
— Написать код, который пройдет тест;
— Провести рефакторинг нового и старого кода.

Мартин Фаулер

Данная статья посвящена вопросу тестирования в рамках Objective-C используя Xcode 6. Рассматриваются стандартная библиотека для тестирования и сторонняя библиотека OCMock. Опытные разработчики, возможно, не найдут здесь слишком полезной информации, тем же, кто недавно встал на этот путь — статья откроет необходимые базовые знания по написанию unit-тестов на языке Objective-C.

Для основы тестирования просьба обратиться сюда.
Для основы unit-тестирования сюда.

А теперь мы начнем изучение unit-тестирования в рамках Objective-C.

Swift 2 сфокусировался на улучшении самого языка, взаимодействия с Objective-C и повышении производительности компилируемых приложений. Новые возможности Swift 2 представлены в 6 различных областях:

• фундаментальные конструкции языка, такие, как enum , scoping (область действия), синтаксис аргументов и т.д.
• сопоставление с образцом (pattern matching)
• проверка доступности (availability checking)
• расширения (extensions) протокола
• управление ошибками (error handling)
• взаимодействие с Objective-C

Я буду рассматривать новые возможности Swift 2, сопровождая их примерами, код которых находится на Github.

Кому нужны модульные тесты? Не Вам — Ваш код идеален. Но все же, Вам просто нужно прочитать эту статью, которая должна больше рассказать о написании модульных тестов на Swift’е. Вдруг это Вам в дальнейшем пригодиться.

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

Модульное тестирование работает с изолированными “микрокомпонентами”. Зачастую Вам нужно «мокировать» классы – то есть обеспечить фейк функциональной реализацией, чтобы изолировать специфический микрокомпонент, таким образом, он сможет быть протестирован. В Objective-C существует несколько сторонних фреймворков, которые помогают это реализовать. Но они еще не доступны в Swift’е.

В этом руководстве Вы научитесь, писать свои собственные mock-обьекты, fakes и stub'ы, чтобы покрыть тестами давольно простое приложение, которое поможет вам запомнить дни рождения ваших друзей.

При проектировании iOS приложений со многими MVC приходится решать вопросы передачи информации от одного MVC к другому как в прямом, так и в обратном направлении. Передача информации в прямом направлении при переходе от одного MVC к последующему осуществляется обычно установкой Mодели того MVC, куда мы переходим, а вот передача информации «назад» из текущего MVC в предшествующий осуществляется с помощью делегирования как в Objective-C, так и в Swift.

Кроме того, делегирование используется внутри одного MVC между View и Controller для их «слепого взаимодействия».

Дело в том, что Views — слишком обощенные (generic) стандартизованные строительные блоки, они не могут что-то знать ни о классе, ни о Controller, который их использует. Views не могут владеть своими собственными данными, данные принадлежат Controller. В действительности, данные могут находиться в Mодели, но Controller является ответственным за их предоставление. Тогда как же  View может общаться с Controller? С помощью делегирования.

Нужно выполнить 6 шагов, чтобы внедрить делегирование во взаимодействие View и Controller:

1. Создаем протокол делегирования (определяем то, о чем View хочет, чтобы Controller позаботился)
2. Создаем в View weak свойство delegate, типом которого будет протокол делегирования
3. Используем в View свойство delegate, чтобы получать данные/ делать вещи, которыми View  не может владеть или управлять
4. Controller объявляет, что он реализует протокол
5. Controller устанавливает self (самого себя) как делегата View путем установки свойства в пункте #2, приведенном выше
6. Реализуем протокол в Controller

Мы видим, что делегирование — не простой процесс.
Как в Swift, так и в Objective-C, процесс делегирования можно заменить использованием замыканий (блоков), принимая во внимание их способность захватывать любые переменные из окружающего контекста для внутреннего использования. Однако в Swift реализация этой идеи существенно упрощается и выглядит более лаконичной, так как  функции (замыкания) в Swift являются «гражданами первого сорта», то есть могут объявляться переменными и передаваться как параметры функций. Простота и абсолютная ясность кода в Swift позволят более широко использовать замыкания (closures), захватывающие контекст, для взаимодействия двух MVC или взаимодействия Controller и View без применения делегирования.

Я хочу показать использование захвата контекста замыканиями на двух примерах, взятых из стэнфордского курса 2015 «Developing iOS 8 Apps with Swift» (русский эквивалент находится на сайте «Разработка iOS+Swift+Objective-C приложений»).

Один пример будет касаться взаимодействия View  и Controller в пределах одного MVC, а другой — двух различных MVC. В обоих случаях  захват контекста замыканиями позволит нам заменить делегирование более простым и элегантным кодом, не требующим вспомогательных протоколов и делегатов.

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

Добрый день.

Я занимаюсь IT-преподаванием. Читал Java Core (материалы тут).
Сейчас написал и продаю курс «Scala for Java Developers»

В этом посте решил открыть видео двух курсов (проходивших в режиме вебинаров) по многопоточности под JVM (это 16 + 16 двухчасовых лекций).

Больше о материалах (программа, полезные ссылки) можно прочитать в постах-объявлениях о вебинарах (Программа курса «Multicore programming in Java» (25 марта 2014), Программа и материалы курса «Multicore programming in Java» (31 июля)).

Курс рассчитан на слушателей, которые начинают изучать многопоточность с нуля (после крепкого курса Java Core, Middle Developer из чистого web-а или перешедшим из скриптовых/интерпретируемых языков программирования). Он не будет подходить тем, кто перешел из «суровых» С/С++ или ищет «академической высоты».

Детально рассматриваются темы Hardware, New Java memory Model, java.util.concurrent (atomics, blocking queues, thread pool, locks, synchronizers), message passing alternative, software transactional memory alternative, Java 7 Fork/Join, Java 8 Parallel Streams (+Lambdas, +Stream API), CSP/JCSP alternative

В один прекрасный момент, когда на собеседованиях меня уже убеждали, что я senior iOS developer — у меня возникло ощущение, что я уперся. Пишу похожий код, решаю задачи похожими способами и ощущение, что непонятно, куда развиваться дальше. Я думаю, с этой проблемой сталкивался не один я — нехваткой новых идей, концепций, направлений. Я бы хотел рассказать вам о тех инструментах и фреймворках, которые помогли преодолеть мне это ощущение.

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

Чтобы направить всю энергию системы в необходимом направлении, нужно эту систему ограничить правилами.

Привет, Хабр! Продолжаем серию статей об архитектурном дизайне мобильных приложений. Под катом поговорим о проектировании слоёв UI. Добро пожаловать!

Признак плохого дизайна №1:
Наличие объекта-«бога» с именем, содержащим «Manager», «Processor» или «API»

Ведущий iOS-разработчик Redmadrobot Егор BepTep Тафланиди — о том, как добиться стройного архитектурного дизайна мобильного приложения, используя классические шаблоны проектирования и логическое разделение исходного кода на модули.

К добавлению внешнего сервера рано или поздно приходит любой сложный проект. Причины, при этом, бывают совершенно различные. Одни, загружают дополнительные сведения из сети, другие, синхронизируют данные между клиентскими устройствами, третьи- переносят логику выполнения приложения на сторону сервера. Как правило, к последним относятся большинство «деловых» приложений. По мере отхода от парадигмы «песочницы», в которой все действия выполняются только в рамках исходной системы, логика выполнения процессов переплетается, сплетается, завязывается узлами настолько, что становится трудно понять, что является исходной точкой входа в процесс приложения. В этом момент, на первое место выходит уже не функциональные свойства самого приложения, а его архитектура, и, как следствие, возможности к масштабированию.
Заложенный фундамент позволяет либо создать величественный архитектурный ансамбль, либо «накурнож» — избушку на куриных ножках, которая рассыпается от одного толчка «доброго молодца» коих, за время своего существования повидала видимо — невидимо, потому что, глядя на множественные строительные дефекты заказчик склонен менять не исходный проект, а команду строителей.
Планирование — ключ к успеху проекта, но, именно на него выделяется заказчиком минимальный объем времени. Строительные паттерны — туз в рукаве разработчика, который покрывает неблагоприятные комбинации где время — оказывается решающим фактором. Взятые за основу работающие решения позволяют сделать быстрый старт, чтоб перейти к задачам, кажущиеся заказчику наиболее актуальными (как-то покраска дымоходной трубы, на еще не возведенной крыше).
В этой статье я постараюсь изложить принцип построение масштабируемой системы для мобильных устройств, покрывающей 90-95% клиент-серверных приложений, и обеспечивающей максимальное отдаление от сакраментального «накурножа».

Хочу поделиться своим мнением и опытом относительно работы Mac OS X на обычном PC компьютере. Может кому-то этот топик будет интересен или полезен.

Я разработчик ПО для Mac OS X и iOS. И я обожаю технику и ПО от Apple (но я не являюсь ярым фанатом). За свою жизнь у меня побывало много гаджетов от Apple: PowerBook G4, MacBook, iMac, MacBook Pro, iPhone, iPad и пр.

Техника для меня лишь инструмент достижения целей. В данный момент времени на работе я использую iMac (Core i5), в личных целях: обычный стационарный PC, ноутбук Lenovo, телефон на Android и iPad.

Недавно мне для работы дома понадобился очень мощный компьютер с Mac OS X. По характеристикам из техники Apple подходили лишь топовый iMac (с Core i7-2600 3,4 ГГц) и Mac Pro. Оба стоят просто запредельные деньги — более 100 тыс. рублей. Я психологически не был готов потратить такие деньги на компьютер. Ограничил бюджет суммой 55 тыс. рублей и решил собрать «Хакинтош». Я немного слежу за тематикой «Хакинтош» и имею четкое представление, что «там и как».

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

Я достаточно часто сталкивался с подобным мнением и не придавал ему особого значения, но когда женский коллектив нашей организации поздравил программистов с 23-м февраля по доброму назвав их «космическими войсками», решил всё же расставить определенные акценты в данном вопросе, т.к. одна из моих профессий связана напрямую с психоанализом. Да и баш уже не молчит.

Одно из моих любимых удовольствий – productivity porn, порнография эффективности. Или, для тех, кто в теме – pr0n. Это набор техник, тактик и трюков по максимизации личной эффективности. Что называется, «getting things done».

Следующие техники я использую в комплексе, но возможно не все они пригодятся конкретно вам. Даже если вы почерпнёте одну-две идеи – значит, моя цель будет достигнута. Итак, начнём внезапно.

Не составляйте себе расписание

Эта статья для тех, кто получает от разработки приложений больше удовольствия, чем денег.
Тем не менее, здесь пойдет речь об увеличении дохода с Ваших приложений.
В 2013 году я совершенно случайно столкнулся с тремя способами увеличить денежный поток раза в два, то есть вместо 25 долларов в день мне стало капать 50. А иногда 100.
Кому эти суммы кажутся смешными, проходите мимо.
А кто знает цену каждому заработанному доллару — прошу под продолжение.

Ситуация в appStore для casual разработчиков быстро меняется.
2 года назад можно было заработать, выпуская платное приложение одновременно с бесплатным аналогом.
После появления в магазине более 100 000 программ этот трюк стал неэффективен.
Год назад шустрые парни стали выкладывать только бесплатные приложения, но с покупками внутри.
Одновременно число программ в appStore перевалило за 500 000.
В ближайшее время ( судя по финансовым отчетам 2012 года) только реклама внутри приложения принесет быстрые деньги.



До прошлого года я использовал фирменную рекламу от Apple.
Однако родная iAd реклама работает исключительно на территории врага.
Чтобы добрать деньги с игроков, живущих не в США (а это минимум 25%), следует прикрутить рекламу от, скажем, Google, которая будет мелькать там, где не работает iAd.

Под habracut я опишу механизм AdWhirl, реализующий показ баннеров от разных производителей.
Пример кода взят из бессмертной игры нашего прекрасного детства.