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

DISCLAIMER

Не пытайтесь повторить это со своими телефонами и телефонами коллег! Судя по комментариям, много людей уже заразили свои телефоны, а 100%-тного лекарства еще нет!

DISCLAIMER 2

Даже не пытайтесь назвать так Wi-fi точку!

Около 15 часов назад на Reddit появился забавный пост, который рассказывал о перезагрузке айфона после странного сообщения вида:

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

Так случилось, что я довольно давно занимаюсь разработкой под iOS, но вот незадача — никогда не писал игры. После змейки в 13 лет под IBM 386 наступил перерыв до 2014 года, когда я набрался сил воплотить теплую ламповую мечту в реальность. Что из этого получилось? Графика сводилась так:



А геймплей хотелось сделать похожим на это:


Если интересно, прошу под кат! (много картинок!)

Этот пост — крик гнева в сторону Apple, и все же во мне осталась надежда. Я являюсь iOS-разработчиком уже 4 года, и то, что поначалу казалось сиюминутным несовершенством, несущественными деталями, с годами превращается в китайскую пытку водой, а ведь мы с вами пользуемся IB каждый день, ну или хотя бы раз в неделю.



Возможно, Apple и не заслуживает такой критики — правда, все остальное, ну или почти все остальное, у них на высоте. Исключая iTunes и Apple developer portal (который за последние годы, все же, стал значительно лучше) технологии позволяют сосредоточиться на том, что ты делаешь, а не на том, как это будет смотреться в IE.

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

Уже написав этот текст, автор в поисках другой статьи ввел в хабрапоиск “Google Glass” и поразился количеству результатов за последние месяцы. Совершенно очевидно, что читателю тема приелась и должна вызывать раздражение, а не интерес. Автор осознает что, вероятно, стоило бы писать в хаб “Я негодую”, но, к сожалению, он куда-то безвозвратно подевался.

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

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

Aport.ru отказался от своей поисковой машины ещё 22 августа 2011 года, целиком перейдя на поиск Яндекса.

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

Как и любому front-end разработчику, мне почти в каждом проекте приходится сталкиваться с клиент-серверными протоколами – без них никак. И очень, крайне часто приходится работать с плохо продуманной архитектурой.

Также очень часто разработка протокола и архитектуры ложится на плечи веб-разработчика, что не всегда верно – она в большинстве случаев должна разрабатываться только совместно с теми, кто под эту архитектуру будет подстраиваться. К сожалению, работая за последние три года на нескольких десятках проектов, мне доводилось участвовать в планировании этого участка архитектуры только 3 или 4 раза – во всех остальных случаях она уже была предоставлена в разной степени готовности заказчиком. А ведь насколько мир мог бы быть лучше!

Небольшой дисклеймер

Эта статья не про продуктовые компании – там своя специфика, я пишу только про сервис. Эта статья не про большие проекты – максимум 6-7 человек, на больших всё по-другому.

Обещаете не писать в комментариях, что в вашей компании все эти трудности преодолели, и вообще нет менеджеров? Тогда добро пожаловать под кат!

Статья, скорее всего, не расскажет ничего нового тем, кто давно занимается разработкой приложений с фишкой Augmented Reality, но возможно будет полезна тем, кто интересуется этой темой и близок к написанию AR-приложения.

Good day, хабрасообщество!

Решил разбить эту статью на две части – первая будет про НЭП Новую Файловую Политику и чистку любимой папки Documents, т.е. полезную iOS-девелоперу информацию (вроде на хабре про это ещё не писали). Информация очень полезная, если вы хотите сберечь нервы, время и деньги при залитии обновления / нового приложения на AppStore, так что рекомендую к чтению всем-всем-всем.

Во второй я расскажу про войну с первой линией техподдержки Эппла и синдром вахтёра, но она носит скорее повествовательный характер и её читать не нужно.

“Think of SQLite not as a replacement for Oracle but as a replacement for fopen()”
— About SQLite

А также, скорее всего, под Android, BlackBerry и в сэнд-боксе браузеров для веб-приложений, но я не проверял.

Почему может быть нужно работать с SQLite напрямую?

Любой опытный iOS девелопер тут же упрекнёт меня за использование SQLite напрямую (вернее не напрямую, а через FmDb, но это почти всё равно что напрямую). Он скажет, что нужно использовать CoreData, т.к. оно много всяких ништяков делает автоматически, типа Undo и Redo. И в нём можно рисовать красивые схемки, которые потом приятно показывать заказчику. А в андроиде, например, есть OrmLite.

И я соглашусь – но до той поры, пока у вас база не перевалила, скажем, за 10 таблиц по 500,000 записей в каждой. А если таблиц 52, и есть особо жирные таблицы по миллиону и больше? И базу нужно синхронизировать с сервером через третий формат, к тому же заказчику критично, будет синхронизация длиться час или пять? Если вы встречали задачи такого объёма, добро пожаловать под кат! Если не встречали – то тоже, ведь никто не застрахован от проектов с большими данными, пускай даже таких мобильных и меньше.

Apple никогда официально не заявляла о несовместимостях между разными версиями своих OS. И всё же каждый крупный релиз они что-то меняют в ядре операционки — фиксят баги и привносят новые. И иногда именно фикс багов, с которыми все привыкли жить, добавляет новых трудностей – в iOS 3 ты не задумываясь добавлял 20 пикселей там, где iOS 4 добавляет их сама, и в итоге твоя модальная вьюшка уезжает на 20 лишних пикселей вверх.

Но это не самая страшная разновидность несовместимостей – их можно продебажить, пофиксить и выпустить новый билд. Также легко устраняется, например, ставшее уже традиционным изменение стандартного контрола для проигрывания видео – в каждой новой iOS Apple что-то добавляет, модифицирует, причём полностью забивая на старый интерфейс без всяких там deprecated за пару версий до выпиливания – так, например, в iOS 3 он был обычной вьюшкой от UIView, а в iOS 4 стал резко вью-контроллером, а старая MPMoviePlayerView исчезла.

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

Но относительно новая iOS 5 принесла ещё больше неожиданностей. Об этом свидетельствует хотя бы тот факт, что в последних релизах популярных айфон-приложений обязательно присутствует строчка “Fixed iOS 5 issues” – средний пользователь айпада находит примерно по 10 апдейтов приложений каждый день. Ниже я расскажу о неочевидной проблеме обратной совместимости iOS 4 и iOS 5, с которой мне пришлось столкнуться на своей шкуре и сполна хлебнуть горя.

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

Когда ты устроился в компанию на позицию Junior Developer, ты смотришь вокруг и видишь, с какой лёгкостью старшие товарищи забивают на шаблоны и пишут два одинаковых класса с разными типами переменных. Как они хардодят размеры вьюшек в коде. Как они читают хабр на работе. И ты точно знаешь, что когда вырастешь до Senior Developer-а, ты будешь лучше, надёжнее, ответственнее, любой блок твоего кода можно будет показывать потомкам.

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