Знакомства или дейтинг – вечны, они будут существовать всегда в различных формах: на улице, в интернете, на сайтах или внутри мобильных приложений. Люди всегда будут иметь желание познакомиться с кем-то и каждый будет выбирать себе наиболее удобный способ. Некоторые продолжают знакомиться в барах, кафе, на улице, другие – используют современные технологии и знакомятся в онлайне. У каждого свой выбор и не будем судить ни одну из сторон, но дальнейшее обсуждение пойдет именно о знакомствах в онлайне.


Примеры приложений дейтинга

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

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

Да, лайки помогли, и использование взаимных симпатий тоже, но всё-таки в рынке дейтинга мало что поменялось за последние 15 лет, а это странно для индустрии ИТ, в рамках которой происходит развитие в том числе онлайн знакомств.

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

Широкий выбор мобильной рекламы: от мешающей до ужасающей. Во всяком случае до 2016 года.

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

В далеком 2013 году я узнал о проекте PaintCode и был весьма впечатлен увиденным. Еще бы, каким-то чудом векторные картинки превращаются в строки кода, который в свою очередь вдруг начинает работать в вашем приложении и вся эта магия всего за 99.99$.

Я долго смотрел на экран монитора и какой-то страх неизведанного отталкивал меня. Еще бы, я человек далекий от дизайна и рисования и не смог с первого взгляда оценить всего могущества этого проекта. Отправил ссылки на видео и на сайт проекта нашим дизайнерам и подумал: «ну, вот сейчас они начнут заниматься настоящими делами!». Но их выражение лица было похоже на мое. Еще бы, они не могли понять всех этих замысловатых формул и переменных…

Чтобы оставаться профессионалом в разработке iOS приложений, нужно постоянно учиться у других и узнавать о новейших инструментах и приемах. Кроме сайта Apple с документацией, существуют несколько ресурсов с ценными статьями и уроками, которые помогут нам стабильно развиваться. О них и пойдет речь в этой статье.

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

Я уже делился советами по разработке кастомной клавиатуры, а также опытом продвижения приложения до и сразу после релиза — статья. На этот раз хочу рассказать о процессе разработки и дать пару подсказок о том, что делать после загрузки приложения в App Store.

Доброго времени суток!

Сегодня я хотел бы вновь затронуть тему разработки jailbreak-программ под iOS. В русскоязычном интернете довольно проблематично найти что-то понятное новичкам, поэтому я попытаюсь исправить это недоразумение и объяснить как решаются некоторые моменты.

Установка ПО, настройка среды и устройства, написание твика с нуля — именно это ждёт вас под катом. Если вам интересно, как поменять часть iOS под себя — добро пожаловать.

Уже довольно давно в 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. Эта статья содержит мои заметки по каждому из преобразований.

Привет, Хабр! Мой сегодняшний пост — это руководство для начинающих программировать графику на Apple Metal API. Когда я начал разбираться с этой темой, то обнаружилось, что помимо документации от Apple и примеров от них же и смотреть особо нечего. Сегодня я расскажу о том, как создать простое приложение на Metal, которое отображает трехмерный куб с освещением. Затем мы нарисуем несколько кубов с использованием одной из главных фишек Metal — рендеринга в нескольких потоках. Заинтересовавшихся прошу под кат.

А помните, как вы просили меня про шейдеры написать? Помните? Нет? А вот я помню и даже написал. Милости просим, поговорим о прекрасном.

Сегодня я поведу речь о том, как я делал объемные вращающиеся планеты для нашей игры blast-off. Тоесть они, конечно, совершенно плоские, всего пара треугольников, но выглядят как объемные.



Заинтересовало? Прошу под кат. Картинок прилично.

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

Functional Reactive Programming

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

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

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

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

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

Перевод поста Piotr Wendykier "Extending Van Gogh's Starry Night with Inpainting"
Скачать перевод в виде документа Mathematica, который содержит весь код использованный в статье, можно здесь (архив, ~8 МБ).

Могут ли компьютеры научиться рисовать, как Ван Гог? Определенно да, до некоторой степени! Для этого, подобно художникам-копиистам, алгоритму сначало потребуется взять некоторое оригинальное произведение, а затем он сможет на их основе создать что-то сам. Насколько хорошо он сможет с этим справиться? Пожалуйста, судите сами.


Вторая премия на фотоконкурсе ZEISS

Одними из самых востребованных классов в 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, который позволяет забыть об этой проблеме.

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

Привет, Хабрахабр!

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

Трудно отыскать iOS-разработчика, никогда не пользовавшегося для тестирования своих приложений сервисом TestFlight, или хотя бы не слышавшего о нем. Его популярность в феврале этого года подтвердила сама Apple, купив компанию Burstly, благодаря которой в свое время появился TestFlight.



Как известно, Apple не из тех, кто бросает деньги на ветер — 9 сентября Apple представила TestFlight в App Store уже под своим брендом.

Игрок больше любит получать, чем терять.

При GameDev надо учитывать эту прекрасную особенность психики. Проиллюстрирую тремя играми: замечательным Faster than Light (родившемся ещё на ПК), популярном изначально планшетном Out There и пришедшем из настольного мира Galaxy Trucker.

Ни в одной из этих игр нет возможности сохраниться.

Являясь счастливым обладателем MacBook Pro с SSD на 256Gb, стал замечать, что система непонятным образом «разрастается».

Вроде бы фильмы качаются на внешний жесткий диск, на SSD находятся только рабочие файлы, а место куда-то исчезает.
Из 256Gb со временем осталось лишь 107Gb.

Утилита OmniDiskSweeper показывала, что должно быть занято около 70 Gb пользовательскими данными. Вопрос — куда делись еще примерно 80Gb?

Набрав в терминале
# du -h -d 1 /
увидел в корне странную папку с названием /.MobileBackups, как раз и занимающую 80Gb.

Дальнейший поиск выяснил — что это локальный бекап, который создает TimeMachine на случай, если у вас не окажется под рукой диска с резервными копиями. Т.е. по сути, когда вы удаляете файлы из корзины, они не удаляются физически, а переносятся в эту папку.

Отключается все это через консоль:
# sudo tmutil disablelocal

Дополнительно можно почитать здесь.