Добрый вечер всем!

Не так давно (в феврале этого года), я решил заняться программированием. В качестве языка был выбран Java. И с того момента я упорно изучаю все возможности данного языка. Недавно наткнулся на статью про RESTful на хабре. Прочитал и понял, что надо осветить альтернативный способ создания данных сервисов. Ещё меня поразило, насколько некоторые статьи пишутся непонятно для новичков. Я решил написать статью в которой расскажу и о прикладной части создания веб сервиса.

Я не претендую на истину. Я просто хочу показать простой и быстрый способ создать веб сервис.

Начало

Необходимое ПО

Самое главное это IDE. Я предпочитаю Eclipse. Данный проект я написал в Eclipse for Java EE Developers Juno. Четно говоря, предыдущий релиз был стабильнее, но этот внешне приятнее. В качестве фреймворка для REST я выбрал Jersey. Его легко найти и скачать. Точно так же как и саму IDE. В качестве сервера я установил GlassFish плагин для эклипса. Инструкцию по его установке точно так же легко найти. Ну на этом и всё.

Создание проекта

Итак. У нас есть Eclipse, папка с JAR-файлами Jersey и установленный GlassFish плагин. Теперь запускаем Eclipse и создаем пустой Dynamic Web Project, на последней вкладке не забываем отметить чек-бокс, который отвечает за генерацию web.xml файла.

The dream

UICollectionView — класс UIKit, появившийся в iOS 6. Строго говоря, это класс, позволяющий показывать на экране коллекцию айтемов. Структура коллекции — абсолютно произвольная, но обычно UICollectionView используется для всяких сетко-подобных контролов с ячейками, хедерами и футерами. Понимая, насколько абстрактен данный класс, разработчики Apple создали мощный механизм для создания любых лейаутов. По большому счету, даже UITableView это конкретная реализация UICollectionView. Возможности данного класса, в каком-то смысле, фантастические. Но в данной статье речь пойдет не об этом.

Ахиллесова пята разработчиков Apple — постоянное стремление делать СДК, которое будет работать «автомагически». Просто сделайте то-то и то-то, и класс «will do the right thing». К сожалению это работает далеко не всегда. И UICollectionView — яркий пример. Начиная с релиза в iOS 6 и по сегодняшний день (iOS 7.0.4) класс содержит довольно большое количество багов, с которыми очень трудно и неприятно иметь дело. Приходится угадывать, что же происходит «под капотом», и методом тыка заставлять UICollectionView работать как надо. Количество приобретенных костылей уже достигло таких размеров, что я решил поделиться известными багами и найденными решениями.

Кому интересно — милости просим под кат.

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

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

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

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

Некоторое время назад я написал этот код:

NSMutableArray *environments = [NSMutableArray new];
for (NSString *key in [dictionary allKeys]) {
    XCCEnvironment *environment = [[XCCEnvironment alloc] initWithName:key
                                                            parameters:dictionary[key]];
    [environments addObject:environments];
}
return environments;

Заметили проблему? Я — нет.

В данном посте я хочу обратиться к теме, о которой многие начинающие iPhone-разработчики часто имеют смутное представление: Objective-C Runtime. Многие знают, что он существует, но каковы его возможности и как его использовать на практике?
Попробуем разобраться в базовых функциях этой библиотеки. Материал основан на лекциях, которые мы в Coalla используем для обучения сотрудников.

(оригинал — Mike Ash, взято отсюда)

Многие Cocoa разработчики имеют довольно смутное представление об Objective-C Runtime API. Они знают, что он существует где-то там (некоторые не знают даже этого!), что он важен, и Objective-C без него неработоспособен, но обычно этим все знания и ограничиваются.

Сегодня я расскажу о том, как устроен Objective-C на уровне Runtime и о том, как конекретно вы можете это использовать.

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

Так как Sketch был создан специально для работы над мобильными и веб-интерфейсами, неудивительно что он стал одним из самых быстрых и гибких инструментов для прототипирования. Эти 10 советов сделают его еще более мощным средством.

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

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

Одной из типовых задач при разработке приложений под iOS является создание кастомных элементов UI, в том числе иногда может потребоваться анимировать изменения значения какого-либо из свойств. В статье рассматривается процесс создания подкласса UIView, имеющего свойства, значения которых можно изменять с анимацией. Простой пример: необходимо отрисовывать круговой прогресс с возможностью анимировать изменение цвета и значения в пределах от 0 до 1.

В iOS 6 Apple представили замечательную возможность для вёрстки UI для iOS-приложений — Auto Layout. Но вот что удивительно, до сих пор очень немногие проекты используют эту возможность. А ведь это очень сильный инструмент, если с умом подойти к вёрстке UI, можно сэкономить очень много времени на подстраивании элементов для 3,5” и 4” экранов, портретно-ландшафтном расположении экрана и даже на универсальной вёрстке для iPhone и iPad.

И это всё не считая того, что скоро представят iPhone 6 и никто до сих пор точно не знает, какое там будет разрешение и какой экран. Лучше бы заранее подстраховаться.

В основном, тема Auto Layout довольно простая, и изучить её несложно. Но лично я столкнулся с большой проблемой при расположении элементов в UIScrollView. Я потратил немало времени и нервов на изучение того, как же правильно расположить элементы и указать размер контента для того чтобы ScrollView начал пролистываться.

Хоть и решение довольно простое, но на него не так просто выйти. В данной статье я бы хотел рассказать, как же всё-таки правильно готовить UIScrollView в Auto Layout.

Уже довольно давно в Xсode есть возможность проверить свой код на соответствие современным особенностям Objective-C (Edit > Refactor > Convert to Modern Objective-C Syntax…). Мне всегда было интересно наблюдать за тем, что Apple продвигает в качестве хорошей практики; и даже если вы не доверяете Xcode автоматически изменять код, это простой способ проверить его на возможность внесения потенциальных улучшений.

Xcode 6 представляет несколько нововведений, а кроме того, гораздо большую гибкость, позволяя самостоятельно контролировать, какие преобразования запускать:



К сожалению, из описания преобразования не всегда очевидно, что оно делает. Некоторые полезные подробности можно прочитать в руководстве Adopting Modern Objective-C, а также посмотреть на WWDC 2014 Session 417 What’s New in LLVM. Эта статья содержит мои заметки по каждому из преобразований.

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

Подходит к концу 2014 год, и сейчас самое время подвести итоги и выделить ключевые тренды в iOS разработке.

Functional Reactive Programming

Благодаря фреймворку ReactiveCocoa, новая парадигма программирования все чаще используется среди iOS разработчиков.

Отказоустойчивость, отзывчивость, ориентированность на события и масштабируемость — вот четыре принципа реактивного программирования. Подробности можете узнать в реактивном манифесте (перевод на Хабре).

Для себя я выделил следующие преимущества реактивного подхода:

• loose coupling — потоки события позволяют уменьшить связанность между различными частями кода;
• explicit state — состояние программы определяется набором событий, и поэтому им становится легко управлять.

В качестве альтернативы реактивному подходу рекомендую посмотреть на Futures. Есть как минимум два интересных фреймворка: PromiseKit и CollapsingFutures

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

Первоначально эту нишу занимали крупные инновационные интернет-компании типа Google или Twitter, однако такие требования к приложениям начали всплывать во многих областях индустрии. Финансовые и телекоммуникационные компании первыми начали внедрять новые практики, чтобы удовлетворить новым требованиям, а теперь подтягиваются и остальные.

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

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

В Xcode 5 компания Apple представила новую систему построения интерфейсов приложений для iOS (6+) и MAC OS X (v10.7 +) “Auto Layout” (AL) призванную заменить устаревшую “Springs & Struts” (S&S). Основываясь на задании правил (Constraints) определяющих размер и положение интерфейсных элементов, AL предоставляет значительно более широкие возможности чем S&S. Тем не менее, слабой стороной AL (помимо большей сложности) является работа с переменными наборами элементов. Сама по себе система AL вообще не поддерживает опциональные элементы, но есть способы обойти это ограничение.

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

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

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

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

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

Здравствуйте, дорогие читатели Хабрахабра!

В этой серии статей я расскажу, как быстро и почти безболезненно поднять свой собственный WhatsApp под iOS. Статью делю на две части для вашего удобства:

1. Создание проекта, простой UI, привязка к сервису мгновенных сообщений
2. Делаем красивый UI, добавляем видео и аудио звонки, передачу фото и документов

К сожалению, пособие о том, как набрать 400 000 000 пользователей и продать сервис за 19 Инстаграмов, затерялось где-то на книжной полке. Постараюсь его найти, если кому интересно.

Заинтересовавшихся прошу под кат.

Добрый день, уважаемые читатели Хабрахабра!

Сегодня я хочу рассказать вам о том, как просто и быстро подключить вебсокеты в свое iOS приложение на примере чата известной биржи криптовалют. Реализуем мы это при помощи удобного открытого решения SocketRocket.

Этот подход может пригодиться для:

• Реализации чата в мобильном клиенте под iOS
• Использовании информации чата для обучения нейронных сетей

Заинтересовавшихся прошу под кат!