Почитав интервью создателей знаменитого бестселлера “Cut the Rope”, в котором утверждается, что на создание веревки ими было потрачено больше всего времени, я не поверил, что написать «алгоритм движения тяжелой нити» действительно так сложно, и для этого надо чуть ли не самим писать физический движок. Погуглив, готового ответа я не нашел, и решил попробовать сделать самостоятельно нечто подобное на cocos2D + Box2D.
За основу были взяты правила:

1. Цепь делать лучше с помощью прямоугольных тел, соединенных Revolute Joint’ами;
2. Чем тяжелее объекты составляющие цепь – тем она стабильнее;
3. Количество итераций при шаге – чем больше, тем лучше (мне хватило 3-х);
4. Очень помогает, если каждый кусочек цепи, помимо Revolute Joint’а соединить Distance Joint’ом.

“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, и есть особо жирные таблицы по миллиону и больше? И базу нужно синхронизировать с сервером через третий формат, к тому же заказчику критично, будет синхронизация длиться час или пять? Если вы встречали задачи такого объёма, добро пожаловать под кат! Если не встречали – то тоже, ведь никто не застрахован от проектов с большими данными, пускай даже таких мобильных и меньше.

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

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

Это не единственный минус библиотеки, и в интернете можно найти много обсуждений относительно за и против Three20.

Необходимо сказать, что главный разработчик остановил разработку над Three20, и решил создать новую библиотеку Nimbus, основной идеей которой будет простота и высокая документированность:
«Nimbus is an iOS framework whose feature set grows only as fast as its documentation.»

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

В данном посте будут подробно рассмотрены вопросы, связанные с работой TTModel.

Для тех, кто не собирается использовать Three20 у себя в проектах, будет полезно подсмотреть на одну из возможных, заслуживающий внимания, реализаций модели в шаблоне MVC.

Всех, кому еще интересно, прошу

Вводная часть:

Сам инструментарий называется NDEV. Чтоб получить необходимый код (его мало) и документацию (её много), надо зарегиться на сайте в «программе сотрудничества». Сайт:

dragonmobile.nuancemobiledeveloper.com/public/index.php

Это весь «геморрой», если клиентов вашего приложения менее полумиллиона и они пользуются сервисами менее 20 раз в день. Сразу после регистрации вы получите членство «Silver», которое позволит вам бесплатно пользоваться данными сервисами.
Разработчикам предлагается пошаговая инструкция по внедрению в свое приложение на iOS сервисов распознавания и синтеза речи:

Возможно, кому-то я не открою Америки этим постом, но мне информация показалась интересной, а в Сети она не была широко освещена.

В России будет создана Ассоциация разработчиков мобильных приложений. Ого!

В преддверии осени я завершил разработку iPhone-приложения для хостинга ServerClub.com. Теперь выдалась свободная минутка, и мне хотелось бы воспользоваться ею, чтобы поделиться с Хабрасообществом некоторыми усвоенными в ходе проекта уроками, а также поведать о «граблях», которые встретились на пути.

Итак, началось все с того, что в HQ компании ServerClub.com, предоставляющей в аренду серверы и сопутствующий сервис, родилась идея дополнить веб-сайт мультиплатформенным мобильным клиентом, который предоставлял бы пользователям доступ к их серверам, данным по трафику, датчикам, тикетам, финансам, счетам на оплату, а также позволял бы заказывать серверы прямо из приложения. Вообщем, задумали они повторить весь функционал веб-клиента, переосмыслив и упаковав его в мобильное приложение. Сразу было понятно, что работы предстоит немало, но все же, как это часто бывает, оптимизм переборол разум, и я оценил работу в 1 календарный месяц, по прошествии которого я рассчитывал опубликовать приложение в App Store. Вот только в ходе разработки, согласования и уточнений каждая крупная фича «обросла» еще и мелкими нюансами, на реализацию и полировку которых ушло дополнительное время. Кроме того, неожиданные сюрпризы преподнесли ревьюверы, но обо всем по порядку.

Вместо предисловия

Гуляем в субботу с друзьями на одной московской площади. Вокруг празднично, много народу. Хороший приятель с исключительно гуманитарным образованием, работающий в продажах, неожиданно поворачивается и говорит: «Слушай, забыл сказать: вы своим приложением спасли меня от скуки. Мозг кипит, очень здорово! Особенно неметрическая система радует».

Воскресенье, вечер. Раздается звонок на мобильный: «Алло, Антон? Слушай, тут в задаче 925 нет подсказки с переводом вершков в аршины. Не забудь поправить в обновлении!» И это человек, который в пятницу жаловался, что считать в уме тяжело, выдержки не хватает.

Понедельник. Сижу рядом с домом в кофейне, дописываю код версии 1.1. Заходит мужчина лет тридцати. Хорошее пальто, костюм. Берет кофе, достает iPad и открывает новости. Через 15 минут вижу знакомый экран. Говорю: «Я — разработчик!» Он: «Врешь?» Показал паспорт, пообщались.

Недавно установил приложение google+ на iPad, и встретил что-то свеженькое из навигационного меню. В принципе обновление ленты через paging на ScrollView не представляет сильно новых технологий, но в сочетании с верхним текстовым баром (на котором, между прочем, интересно меняется шрифт) и цикличным поведением выглядит вполне очень даже удобно и интересно. Для людей, кто совсем не представляет, как выглядит это в google+ iphone-клиенте можно попробовать представить это по рисунку ниже:



Поэтому решил потратить несколько часов, чтобы сделать такой же удобный контрол, в дальнейшем думаю много раз еще пригодится. Реализация оказалось не такой простой лично как я рассчитывал, поэтому решил поделиться методом создания такого контрола, думаю он может понадобится многим разработчикам, да или хотя бы нормально работающий цикличный scrollView тоже предоставит интерес. К слову говоря, первым делом естественно занялся поиском подобных движков на stackoverflow и прочих кодовых ресурсов, но найти не удалось. На дизайнерскую часть особого упора не делал, все будет примитивно, но в тоже время и универсально.

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, с которой мне пришлось столкнуться на своей шкуре и сполна хлебнуть горя.

Именно такая идея пришла мне в голову, гуляя с детьми в парке. Наверняка каждый видел в парке детскую игру, в которой тебе дается молоточек и надо бить по головам зайчиков или кротов, которые выходят из 6-7 дырок. Я бы, честно говоря, ее даже не заметил, что тот звук, который издает данный аппарат, заставляет невольно повернуть в его сторону. Какие-то непонятные китайские фразы и к тому же очень громкие. Как раз в этот период времени требовалась свежая идея для мобильной игры. Задача состояла в том, чтобы придумать идею игры для iPhone с минимальными трудозатратами, т.к. по плану очередная игра должна была быть опубликована в Apple AppStore в этом году.

Марко Армент (Marco Arment) — известный веб и iOS разработчик, блогер. В 2008 году он запустил Instapaper и до сих пор разрабатывает и поддерживает его сам, что само по себе заслуживает уважения. До этого он работал в Tumblr. Еще он вместе с 5BY5 ведет отличный подкаст о технологиях — Build & Analyze. (примечание переводчика)

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

Вот наиболее свежие данные о людях использующих приложение Instapaper:

Давайте рассмотрим с вами очень простую задачу – вычисление хеш-суммы некоторой строки. Задача встречается повсеместно, стоит вспомнить хотя бы аутентификацию пользователя посредством OAuth. Решение задачи будем рассматривать в рамках разработки приложений под iOS. Ниже, я постараюсь показать наиболее красивое (на мой взгляд) решение задачи с точки зрения архитектуры программного кода.

Спасибо Shmatlay за сегодняшний обзор сервиса Test Flight.
Поскольку в нашей компании мы им тоже пользуемся и достаточно активно, не могу не вставить свои пять копеек по поводу указанного сервиса, основываясь на опыте его эксплуатации.
Если кто-то пропустил указанный пост, кратко поясню, что Test Flight — это сервис, упрощающий тестирование приложений для iOS-устройств путем облегчения процесса сбора кодов тестовых устройств (UDID-ов), а также путем более легкого распространения подписанных для тестеров билдов Вашего приложения. Ну и плюс, можно видеть, сколько раз приложение запускали, сколько раз оно падало, а также получать некоторую отладочную информацию.

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

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

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

Хочу поделиться своим опытом разработки приложения для iOS (IP-калькулятор). Опыт нельзя назвать успешным, тем интереснее, и, надеюсь, полезнее будет мой пост для начинающих разработчиков.

Предыстория

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

Первое на что упал мой взгляд- это виртуальная школа iTunesU. Здесь я нашел лекции курса CS 193P которые ведут разработчики эпл для студентов Стэнфордского университета. Лекции достаточно хорошо охватывают базовые особенности языка и нативных фрэймворков, однако есть одно НО– лекции на английском и никакого перевода к ним нету. Для меня лично проблем это не вызвало, потому что Aple по всей видимости выбирает на эти лекции только кандидатов с хорошо поставленной речью, и прожитые в США 8 месяцев дали мне возможность смотреть лекции в оригинале и учится у «носителей языка» (шучу-шуткую).

Так как каждый год выходит новая версия Xcode, а лекции стэнфорда в которых рассматривается именно текущая версия становятся доступны с опозданием в семестр, я решил написать серию статей, которые будут идти по практической части (!) данного курса. Так как я слушал лекции осени 2010 для меня будет практическт полезным написать программу в xcode 4.2 который был изначально разработан под 3ю версию. Здесь я не буду углублятся в особенности ObjC а буду давать голую практику.

Вчера разработанное нами приложение Coin Keeper заняло третье место в топе платных приложений русского AppStore.

Интересно то, что мы разрабатывали его не на привычном Objective C, а на C#, используя фреймворки Monotouch и Monodroid.

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

Если вы работаете над проектом с большой посещаемостью и контентом, отчасти (или полностью) формируемым пользователями — то, скорее всего, у вас уже были мысли, что неплохо бы сделать мобильный клиент. Так и мы, работая над нашим проектом, решили, что пользователи будут охотнее пользоваться нашим проектом и активнее создавать новый контент. К тому же — мы ведь можем облегчить жизнь пользователя, так почему бы и нет.
И мы сделали. Осторожно, много картинок и текста.

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

Это можно сделать