Базовый алгоритм при авторизации через OAuth2 у всех один и тот же, разница только в ендпоинтах и форматах запросов/ответов в каждом случае. Если до этого с OAuth2 не сталкивались, рекомендую обязательно прочесть вот эту статью - как для общего понимания, так и в качестве руководства к действию: habrahabr.ru/post/145988 - она хоть и давнишняя, но до сих пор вполне актуальна процентов минимум на 90.
Вообще жесть вопрос, непонятно вообще ничего - ни где база находится, ни где смотреть надо, чья база, есть контроль за софтом, ее обновляющим, какой способ отслеживания был бы приемлемым... Я бы так спросить не смог. :))
Александр Дубина: Вы посмотрели на проблему с точки зрения развития себя как специалиста, но есть и другие взгляды на ту же проблему, с другой точки зрения. Возьму на себя смелость утверждать, что цель любой разработки - это в первую очередь создать продукт (если эта разработка, конечно, не происходит исключительно в целях самообразования). А для создания продукта нужно применять те технологии, которые позволят наилучшим образом решить поставленную задачу, а не те, которые разработчик имеет желание, видите ли, лучше всего изучить. Желания разработчика заказчика не интересуют.
Более того - вы несколько противоречите самому себе. Если вы разрабатываете мобильное приложение, то вы - мобильный разработчик и вам вообще нечего делать на серверной стороне.
Кроме того, язык программирования - это не технология, вообще-то, т.е. вы еще и понятия подменяете. Один и тот же Objective C применяется и для iOS, и для OS X, но технологии, фреймворки, лучшие практики и проч. для обеих платформ довольно сильно различаются. И эта разница еще более заметна, когда мы сравниваем клиентское приложение и серверное, пусть они даже и написаны на одном языке.
> при каждом отдалении или приближении(изменении уровня на единицу) я подгружаю новые и добавляю их на карту,
Из этого я сделал вывод, что вы подгружаете их потому, что возникла необходимость - либо карта отдалилась настолько, что понадобилось показать точки, которые раньше были за пределами экрана, либо приблизилась настолько, что понадобилось показать точки, которых тоже не было видно, например, потому, что вы кластер "разбили" на составляющие его точки.
А если вы не анализируете изменения ситуации, а просто тупо перезагружаете точки по триггеру зума, то возникает вопрос - а зачем гонять туда-сюда то, что уже и так на карте есть?
Можно использовать такой вариант: вы считываете (из локальной базы?) новый массив точек в соответствии с критериями для данной области карты при данном (изменившемся) зуме, сравниваете его с тем, что уже есть на карте, другими словами "вычитаете" из нового массива старый - если после этой операции в новом массиве что-то осталось - то это действительно новые точки, которые надо показать. Добавляете их (именно добавляете к ранее показанным).
Не знаю, какой картографический движок вы используете, я использую обычно Google Maps SDK и локальную базу sqlite. Могу сказать, что операция считывания из базы четырехсот точек проходит за несколько миллисекунд, операция сравнения массивов - еще меньше, а операция нанесения на карту этого количества точек - в районе 5 секунд, т.е. разница по скорости в несколько порядков. Из чего следует вывод, что нужно постараться минимизировать именно операции нанесения/удаления точек с карты, а вот читать из из базы можно, в принципе, сколько угодно - на скорость и отзывчивость интерфейса это не влияет, к тому же это делается в фоновой ветке, тогда как все операции с картой обязаны выполняться в главной ветке.
sl1m_dogg: Можно расчитывать на любой макбук не ранее 2011 г., за исключением 11" Air'ов. Причем я бы смотрел в сторону Pro, а не Air, по причине легкости и относительной дешевизны их апгрэйда.
Он начисляется напрямую на счет в банке, который вы указали (если указали) в соответствующем разделе iTunesConnect. Карта, с которой вы регистрировались, совершенно не при делах.
