Альтернатива устройству UDID - подготовка себя

Возможный дубликат:
UIDevice uniqueIdentifier устарел - Что делать теперь?

Я знаю, что об этом было много вопросов, но я думаю, что, поскольку Apple продвигается досрочно и активно отрицает приложения, использующие UDID (http://pulse.me/s/7mzKE), разработчикам необходимо принять активный подход и обсудить этот вопрос навалом.

Итак, вопрос в том, что такое хорошая, стабильная и правильная альтернатива уникальной идентификации устройства, кроме доступа к свойству UDID?

Ответы

Ответ 1

Это зависит от ваших потребностей... если вы ищете простой идентификатор устройства для своего приложения, то документация по устаревшему методу uniqueIdentifier в значительной степени обеспечивает ваш ответ:

Не используйте свойство uniqueIdentifier. Чтобы создать уникальный идентификатор, характерный для вашего приложения, вы можете вызвать функцию CFUUIDCreate для создания UUID и записать его в базу данных по умолчанию с помощью класса NSUserDefaults.

CFUUIDCreate вернет уникальный идентификатор трубки, уникальный для вашего приложения. Вам нужно сохранить его в NSUserDefaults, потому что он изменится, если вы выполните последующие вызовы. Для большинства применений этого будет достаточно, и это не так, как если бы Apple не обеспечила достаточного предупреждения об этом изменении (iOS 5 вышел уже более шести месяцев, а разработчик docs дольше).

Другой сценарий - это то, где вам нужно разделить свой идентификатор устройства между приложениями (т.е. сетями мобильной рекламы). Это более сложная проблема с рядом альтернативных вариантов (также нет гарантии, что они останутся в будущем: основная причина Apple для отказа от API UDID - это, по-видимому, остановить отслеживание пользовательского интерфейса).

Ответ 2

Мой личный фаворит - OpenUDID.

Вы можете захватить GitHub здесь.

Я обобщил свои мысли и кратко изложил его здесь.

Ответ 4

Один из MAC-адресов устройств 2 или 3 уже обнаруживается спецификацией протокола во время любой беспроводной связи.

Ответ 5

Хотя я думаю, что это не типичный "способ преодоления этой конкретной технической проблемы", я согласен, что это очень важно и может быть хорошо обсуждено в SO каким-то образом (не уверен - wiki? Forum?). Мне было бы интересно узнать, есть ли дискуссии о том, как Flurry beat this.