В предыдущей заметке я рассказал про то, как сделать видео для iPhone, которое можно передавать на гаджет с использованием принципа Smooth Streaming. И даже дал ссылку на собственный проект, где применил результаты своего знания. К сожалению, как оказалось — весьма поспешно: люди, проверившие ресурс на iPhone 3G, сообщили, что ничего не работает и выдается одна и та же ошибка, схожая с той, которую получал я на своем аппарате — «Формат видео не поддерживается».

То, что я посчитал ограничением первой версии аппарата, оказалось более системным. Сложилось так, что эмуляция iPhone в SDK, распространяемом Apple, строится на немного иных принципах, нежели традиционная эмуляция аппаратуры, как это делали в QEMU в проекте OpenMoko. Если во втором случае действительно эмулировался ARM SoC, то разработчики iPhone пошли по пути меньшего сопротивления — они просто пересобрали среду под традиционную платформу (которая x86), и когда запускался эмулятор — по сути дела работает родной для платформы код, но с ограничениями, налагаемыми эмулятором. А когда программу для гаджета необходимо перенести на устройство — используется кросс-компиляция и уже генерируется код для платформы ARM.

Разумеется, при первых испытаниях трансляции псевдо-потока я использовал iPhone первого поколения и результат был плачевен — устройство от казалось играть данный формат. Но попытка воспроизвести тот же самый фрагмент в эмуляторе оказалась успешной, что и привело к ошибочному выводу, позднее опровергнутому посетителями ресурса. Скорее всего, эмулятор использует мультимедиа-прослойку операционной системы, гораздо менее привередливую, нежели та, которая используется в iPhone OS (у которой ноги растут тоже из Mac OS X). Поэтому он беспроблемно показал то видео, которое мой телефон посчитал сбойным.

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

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

Как я уже ранее писал, вещать видео на iPhone можно было начиная с самых первых версий прошивки в псевдо-потоковом режиме, как, собственно, и делал популярный сервис YouTube. Т.е. через сеть поверх HTTP-протокола отдавался mp4-файл, а сервер умел отрабатывать параметры, передаваемые плеером и формировать заголовки формата в случае, если пользователь желал посмотреть ролик с середины.
Подробнее →

Сейчас, когда идет keynote WWDC 2009 и о новшествах третьей версии прошивки говорят открыто, раскрою и я завесу тайны, надеясь не попасть при этом под NDA. Тем более, что еще во время объявления оных свойств, многие пользователи и разработчики захлебывались слюной на этот счет.
Подробнее →

Мир не идеален, чего уж говорить про программы, которые пишутся одними людьми для других. Редко бывает так, чтобы все работало хорошо и гладко, и виной тому — не злобные программисты, а сочетания множества факторов, начиная от состояния аппаратного обеспечения, заканчивая сложностью программирования как таковой. Увы, наш уважаемый iPhone — не исключение. Доводилось ли вам наблюдать, как программы на нем перестают работать, реагировать на действия пользователя, выдавать несообразные данные или вообще отказываются запускаться? Думаю да, и не раз. Эмоциональный пользователь, скрипя зубами, удалит раздражающее приложение с телефона, поставит ему минимальную оценку, напишет гневный отзыв и с десяток раз пожалеет о потраченном времени и деньгах. Пользователь же дотошный напишет гневное письмо, где во всех подробностях и не стесняясь в выражениях перечислит все найденные ошибки. Чем, конечно, непомерно поможет разработчику и обяжет его устранить неполадки, дабы сохранить свое лицо. Но, увы, часто пользовательское описание внешнего проявления ошибки ничем не поможет разработчику — именно в силу сложности предметной области и множества факторов, влияющих на возникновения сбоя. Поэтому, наилучший способ предоставить разработчику информацию об ошибки и заставить его отработать потраченные на приложение $0.99 — это послать ему отчет о сбое (т.н. крэш-репорт), который волею компании Apple и ее системных программистов сохраняется на телефоне. Этот отчет содержит подробную техническою информацию об инциденте (состояние стека всех выполняющихся потоков и т.п.) и не содержит никаких персональных данных владельца, за исключением, пожалуй, ТТХ устройства. Эта информация гораздо более полезна для программиста и позволит понять суть ошибки и локализовать ее гораздо быстрее, нежели благодаря описанию «не запускается и все тут».

Когда пользователь синхронизирует своё устройство с помощью iTunes, крэш-репорты автоматически копируются в директорию на диске на пользовательском компьютере. Если приложение было скачано из App Store и пользователь включил отправку крэш-репортов в Apple, то крэш-логи будут автоматически отправлены iTunes в Apple и разработчик сможет скачать их через iTunes Connect. В этом случае дотошным пользователям беспокоится не стоит — автор приложения и так все увидит.

В случае же приложений, которые были получены через систему Ad Hoc тестирования, или разрабатываются внутри компаний для своих сотрудников (т.н. Enterprise метод), или пользователь не включил отправку крэш-репортов в Apple, придется совершить ряд дополнительных, но довольно несложных телодвижений. Пользователю нужно будет извлечь крэш-репорты из папки, куда они копируются iTunes. В зависимости от платформы, папки могут быть следующими:

* Mac OS X: ~/Library/Logs/CrashReporter/MobileDevice/
* Windows XP: C:\Documents and Settings\\Application Data\Apple Computer\Logs\CrashReporter\MobileDevice\
* Windows Vista: C:\Users\\AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice\

где — это имя пользователя на компьютере, под которым осуществялась синхронизация c iPhone, а — это имя пользовательского устройства, которое дается при синхронизации в iTunes. Имена крэш-репортов начинаются с имени приложения, содержат информацию о дате и времени, когда произошёл инцидент и — самый главный признак при их поиске — имеют расширение .crash.

Если же ваше устройство было взломано (jailbrake) и синхронизации с настольным компьютером не было и не предвидится, то крэш-репорты можно найти на самом аппарате в папке /private/var/logs mobile/CrashReporter/. В этом случае достаточно просто скопировать эти файлы при помощи scp или любого файлового менеджера, поддерживающего передачу данных поверх защищенного протокола SSH.

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

Специально для ru_iphonedev, совместно с Романом Бусыгиным.

Спустя почти месяц молчания расскажу про покупку права присоединения Apple iPhone Developer Programm, точнее — о моем опыте в этом деле. Ну а прежде, чем приступить к сему благостному занятию, вкратце расскажу о том, что планирую в будущем написать.

Так, в планах:

• описание простейшей CRM, которую мы сейчас разрабатываем в компании;
• интерфейс информационного ресурса для использования в сетях IPTV для получения информации при помощи традиционных STB;
• вкусности iPhone OS 3.

Ну а теперь, когда интерес подогрет, приступлю к основной теме.
Подробнее →