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

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

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

Под катом вы найдете дополненную расшифровку выступления Александра Сычева (Brain89) на AppsConf, в котором он поделился вариантами применения конечного автомата при разработке неигровых приложений.


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

В предыдущих статьях цикла (все ссылки в конце статьи) о разработке нового fast paced шутера мы рассмотрели механизмы основной архитектуры игровой логики, базирующейся на ECS, и особенности работы с шутером на клиенте, в частности, реализация системы предсказания локальных действий игрока для повышения отзывчивости игры. В этот раз подробнее остановимся на вопросах клиент-серверного взаимодействия в условиях плохого соединения мобильных сетей и способы повышения качества игры для конечного пользователя. Также вкратце опишу архитектуру игрового сервера.

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

Привет, Хабр! Недавно мы вышли в релиз с нашей игрой, которую долго и упорно готовили и в процессе которой накопилось немалое количество интересных тем, которыми стоит поделиться с сообществом. Тема будет интересна далеко не только iOS и иным мобильным разработчикам, но и всем тем, кому интересно, как всякие графические вещи работают под капотом, а также всем фанатам 2D-стратегий, коим уже третее десятилетие являюсь я сам.

Сразу хочу сказать, данная статья предназначена прежде всего для новичков. Здесь не будет best practice, создание сервисов, репозиториев и прочей оптимизации кода. Расскажу про основы работы с запросами и покажу применение на примерах.

Содержание

• Зачем
• Установка
• Настройка доступа HTTP
• Первый минимальный запрос
• Подробнее о минимуме
• Методы HTTP
• Alamofire.request
  
  • URLConvertible
  • HTTPMethod
  • Parameters
  • ParameterEncoding
  • HTTPHeaders
  • DataRequest
• Обработка ответа
  
  • Ручная обработка ответа
  • Настройка запроса
• Обработка результата ответа
• Разные типы ответов
  
  • responseJSON
  • responseData
  • responseString
  • response
  • responsePropertyList
• Прогресс загрузки
• Примеры
  
  • Создание объекта (POST)
  • Обновление объекта (PUT)
  • Загрузка фотографии на сервер (multipartFormData)
• Итог

В последнее время, часто вижу вопрос:

Можно ли в iOS работать с геолокацией, когда приложение свернули и отправлять данные на сервер?

Это действительно возможно и совсем не сложно.
How to вместится в превью статьи.

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

Чтобы была какая-то конкретика, я предположил, что перед нами стоит задача написать вело-трекер. Со стороны пользователя это выглядит так:

1. Скачиваю приложение
2. Запускаю
3. Регистрируюсь
4. Нажимаю куда просят
5. Закрываю
6. Катаюсь
7. Запускаю
8. Вижу результат

p.s. финальный код здесь.

Думаю, всем разработчикам хочется в той или иной степени украсить свои приложения различными эффектами. Android-отдел компании Live Typing уже выпустил две статьи на эту тему: про тип классов Animator и собственную библиотеку CannyViewAnimation, заменяющую им несовершенный ViewAnimator. Я представляю отдел iOS-разработки нашей компании и тоже хочу высказаться на тему, которая важнее, чем кажется.

Эта статья — введение в мир анимаций для iOS-приложений. Рекомендуется тем, кто никода не работал с анимациями, либо не понимает некоторые моменты в стандартных iOS-анимациях.

​

Думаю, все знают, как бывает непросто поддерживать соблюдение code style и соглашений в iOS-проекте. Сегодня поговорим о том, как автоматизировать этот процесс с помощью утилиты SwiftLint.

Примечания:

• ООС — общероссийский официальный сайт (Государственные закупки).
• Требуемые знания для понимания статьи: VBA (MS Excel).

Привет, Хабр! В данной статье решил написать о том, как работать с галереей с помощью фреймворка Photos. В этой статье рассмотрим базовые возможности фреймворка: создание альбома, сохранение, удаление и загрузку фото. Если будут положительные отзывы, то в следующих частях напишу про работу с live фото, видео, наложение фильтров, кэш и прочие функции.

Гедоммист (в Древнем Риме) — человек, получающий кайф от программирования.

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

Помню об этом, одолевая манящие сложностью алгоритмы.

И хочу рассказать об одной бесполезной задаче, которую я решал неделю в полном экстазе. Задача родилась благодаря 3aicheg, чей комментарий дал мне идею для игры под iOS (вижу Ваши глаза, Шо опять?). Смысл в том, чтобы сделать match game на нерегулярной сетке с гравитацией.

Кстати, если вы думаете, что рассказывая здесь о своем бесплатном приложении, можно получить мировую славу и купить яхту, то вот таблица

Рейтинг статьи	Просмотров статьи	Просмотров видео	Загрузок
+30	20 000	5 000	18
-2	2 500	2 000	14

И потому я восхищаюсь бескорыстными авторами Хабра (особенно теми, кто владеет русским слогом). Теперь к делу! А дело такое…

Привет Хабр! В 2014 году я опубликовал большую статью про наш опыт открытия студии мобильной разработки «с нуля». Хочу к ней вернуться, поделится с сообществом тем, что накипело за 2 года и привести новые цифры по оборотам, рассказать о «набитых шишках», как мы выходим на западные рынки и т.п. В России 2 года работы огромный срок, мы выросли в восемь раз за этот период времени.

Я взял исходную публикацию с 2014 года и дополнил ее (в скобках с пометкой upd.2016) новым взглядом, который поверьте за 2 года очень сильно изменился.

Итак, встречайте — часть 1:

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

Друг наших образовательных программ Михаил Пименов,  CEO компании Wonder Games и Team Lead инди-проекта "Guard of Wonderland" сам не раз задававший себе эти вопросы, создал для себя выборку всевозможных материалов по индустрии геймдева. От полезных ресурсов, до сообществ, подкастов, книг и фильмов, которые призваны помочь понять, с чего начинается и чем заканчивается разработка игрового проекта. Объединив наши силы, мы с Мишей сделали эту статью с подборкой полезных материалов по игровой индустрии. Вы найдете подборку под катом.

С позиции пользователя, iOS — выдающаяся платформа. Возможно, несколько монотонная и жёсткая, но привлекательная и надёжная (в основном).

С позиции разработчика дела обстоят совсем иначе. Работать с iOS (а на самом деле, вообще, с Apple) — всё равно, что пытаться разговаривать с параноидальным роботом, действующим как известный советский пограничник из романа Кафки.

Предлагаю читателям «Хабрахабра» перевод статьи «Using Framer to Prototype iOS Animations» с сайта raywenderlich.com.

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

Размышляя о важности дизайна взаимодействия для приложений, можно сказать, что статичный прототип — это как пазл с недостающими кусочками. Так почему бы всем не создавать интерактивные прототипы вместо всего этого? Что ж, с помощью утилит вроде After Effects прототипирование может занять слишком много времени. А сам прототип может так и не понадобиться.

Попробуйте Framer: утилита для дизайнеров и разработчиков довольно проста в использовании.

Всем привет, меня зовут Артём, я iOS-разработчик. Сегодня хочу рассказать о подходах к использованию UITableViewController и UICollectionViewController.

Едва ли можно найти мобильное приложение, в котором не используется списочное представление данных. Существенную часть времени мы (iOS-разработчики) проводим с TableView или CollectionView. Именно поэтому критически важным является выбор подходов к использованию этих базовых элементов из соображений скорости разработки и стоимости дальнейшей поддержки создаваемых решений. Хочу поделиться выводами, к которым мы пришли с коллегами в Touch Instinct.

Статья рассчитана на разработчиков, которые работают с TableView (CollectionView), но почему-то не работают с TableViewController (CollectionViewController). Далее будет упоминаться только TableView(Controller), но все написанное касается и CollectionView(Controller) тоже.

Сетевое ядро как часть приложения

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

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

Подробности под катом.

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

Давайте поговорим о физике транспортных средств

Физика транспортных средств в видеоиграх не очень сильно обсуждается. Статьи в Интернете о физике транспорта в видеоиграх немногочисленны и поверхностны; обычно они посвящены самым основам. Программист транспорта для видеоигр ощущает себя сегодня в относительном вакууме. Возможно, такая ситуация возникла, потому что эту тему довольно сложно объяснить, а может быть, мы просто стыдимся признаваться в использовании хаков, упрощений и хитростей, которые мы вносим по сравнению с «правильной», реалистичной симуляцией физики. Как бы ни обстояло дело, видеоигры имеют уникальные проблемы в симуляции транспорта, а значит, об этом стоит писать. Это захватывающая тема, относящаяся к физике, работе с камерой, звуку, спецэффектам, а также к восприятию и психологии человека.

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