Куда поместить общий код для iPhone, CLLocationManager

Question

Если у меня есть приложение панели вкладок, и я планирую использовать Core Location на разных вкладках, есть ли хорошее общее место для размещения кода, используемого для выделения / инициализации CLLocationManager, и получения обновлений после вызова startUpdatingLocation?Или, если он будет использоваться на двух разных вкладках, мне тогда просто поместить его в код для каждой вкладки?Просто интересно, каковы наилучшие практики, поскольку я новичок в программировании.Спасибо.

Answer 1

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

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

вот несколько рекомендаций высокого уровня:

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

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

• используйте утверждения, чтобы убедиться, что они используют интерфейс по назначению, проверьте каждый аргумент, предварительное / постусловие, состояние вашего объекта и т.д..

• делайте ваши объекты / интерфейсы очень маленькими и удобными в обслуживании, с четкой целью их использования по назначению.естественно, это приведет к увеличению количества объектов.

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

• создавайте библиотеки с этими интерфейсами и разделяйте их логически.

теперь, когда с этим покончено…

я бы начал с использования (потенциально нескольких) экземпляров объектов, которые вам понадобятся.в документации нет ничего, что гласило бы "вы не должны создавать несколько экземпляров объекта".

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

обоснование:скорее всего, Apple уже оптимизировала реализацию, так что вам не придется этого делать.

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

Answer 2

Я не согласен с Джоном, AppDelegate - это "простой" способ сделать это, но не всегда лучший.

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

Answer 3

Делегат приложения - хорошее центральное место для хранения таких данных.Вы всегда можете обратиться к делегату приложения с помощью [[UIApplication sharedApplication] delegate]