2016-09-01 2 views
0

Я использую Singleton довольно широко, чтобы взаимодействовать с firebase, подобным следующему классу. Я считаю, что синглтон очень удобен, поэтому я хотел получить более глубокое представление об этом, прежде чем начинать использовать его. Один из инструкторов из онлайн-курса отметил, что я должен быть очень осторожным в использовании синглтона, но он действительно не объяснил, почему. Я хотел бы знать, как я могу правильно его использовать и почему мне нужно быть очень осторожным в их использовании?Использование синглтона в IOS и вещей, которые необходимо соблюдать для

class DataService { 
static let dataService = DataService() 

private var _BASE_REF = Firebase(url: "\(BASE_URL)") 
private var _USER_REF = Firebase(url: "\(BASE_URL)/users") 
private var _JOKE_REF = Firebase(url: "\(BASE_URL)/jokes") 

var BASE_REF: Firebase { 
    return _BASE_REF 
} 

var USER_REF: Firebase { 
    return _USER_REF 
} 

var CURRENT_USER_REF: Firebase { 
    let userID = NSUserDefaults.standardUserDefaults().valueForKey("uid") as! String 

    let currentUser = Firebase(url: "\(BASE_REF)").childByAppendingPath("users").childByAppendingPath(userID) 

    return currentUser! 
} 

var JOKE_REF: Firebase { 
    return _JOKE_REF 
} 

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

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

class PostService { 

static let ps = PostService() 

private var _myPosts = [Post]() 
private var _otherPeoplesPosts = [Post]() 
private var _followingPosts = [Post]() 

var myPosts: [Post] { 
    return _myPosts 

} 

var otherPeoplesPosts: [Post] { 
    return _otherPeoplesPosts 
} 

var followingPosts: [Post] { 
    return _followingPosts 
} 
+0

Если точка синглтона - это просто сохранить данные, есть лучшая альтернатива, например, данные ядра, если вы можете их использовать. Если вы можете передать данные в контроллер просмотра вместо того, чтобы использовать синглтон, который также лучше. Что касается управления памятью, это безопасно. Утечки памяти не произойдет, если вы сбросите свойства, и ваши объекты не содержат ссылки на синглтон. Из моего опыта я использовал только синглтоны, когда у меня была какая-то непрерывная работа или такая служба, как кэширование изображений, где каждый класс может ее использовать и использовать (UIView, UIViewController, любой класс модели/структура и т. Д.) –

+0

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

+0

«Синглтон переносит состояние на всю жизнь приложения». Означает ли это время жизни приложения на телефоне или время жизни приложения до его закрытия (переднего плана и фона). – user172902

ответ

0

Насколько я знаю, единственный главный вопрос, касающийся одиночек является факт, что они остаются в памяти, используете ли вы их или нет.

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

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

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

Итог, это зависит от использования и размера ваших данных.

Надеюсь, это поможет в некотором роде.

Смежные вопросы