модель процессора обнаружения iPhone / НЕОНОВАЯ поддержка
Первый ответ имел правильный JavaScript, но ASP.NET не обязательно представляет элемент управления вводом непосредственно, таким образом, лучше поместить onchange событие на управление FileUpload.
Другой маршрут для движения должен обеспечить богатую загрузку через flash/silverlight/ajax. Большой компонент для этого может быть найден в Загрузчик Ajax приблизительно за 100$
4 ответа
Одно временное решение, которое я могу придумать, - это определить, доступен ли OpenGL ES 2.0, поскольку новые процессоры позволяют это.
На сайте mobileorchard есть статья о том, как это сделать. сделай это.
Не совсем то, о чем вы спрашиваете, но одно простое решение - сделать ваше приложение жирным, чтобы оно содержало исполняемый код как для ARMv6, так и для ARMv7. Если вы сделаете это, соответствующий код будет запускаться на процессоре автоматически, и вам не нужно будет выполнять какие-либо проверки во время выполнения. Фактически, вы позволяете загрузчику выполнять обнаружение времени выполнения за вас.
Для этого измените параметр «Архитектура» в вашем проекте XCode с «Стандартный (armv6)» на «Оптимизированный (armv6 armv7)»
Затем, в своей реализации вы делаете следующее:
#if defined __ARM_NEON__
// Code that uses NEON goes here
#else // defined __ARM_NEON__
// Fallback code without NEON goes here
#endif // defined __ARM_NEON__
Есть похожий макрос, который вы можете использовать для проверки (не NEON) возможностей ARMv7, которые я не могу припомнить.
Если вы действительно хотите чтобы выполнить диспетчеризацию во время выполнения, взгляните на функцию sysctlbyname в libc. В частности,
Я знаю, что это хреново, но лучшее, что приходит мне в голову, - это определить, поддерживает ли устройство запись видео. В настоящее время его поддерживают только устройства iPhone и iPod на базе ARM7, поэтому я думаю, это законный способ.
Для этого используйте availableMediaTypesForSourceType UIImagePickerController в сочетании с isSourceTypeAvailable в kUTTypeMovie.
EDIT: Я отозвал этот ответ, так как он оставил без внимания очевидную дыру, которую я понял позже: что делать, когда мы получим неизвестный подтип на каком-то будущем оборудовании? ЭТО НЕ БЫЛО ЗАЩИТОЙ ОТ БУДУЩЕГО. Кроме того, неопределенность документированного статуса этого API не помогает, учитывая нулевую терпимость Apple к использованию недокументированных API.
Вам следует воспользоваться ответом Стивена Кэнона и построить свое приложение на жире. Надежное, защищенное от будущего обнаружение во время выполнения в настоящее время не представляется возможным (к моему огорчению, уверяю вас).