Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have read several articles discussing pros an cons about singleton patterns. But I would like to know:
Is it advisable to have multiple singletons in an iOS App?
what are the pros and cons...?
Currently I am having only one singleton globally and holding strong references of other necessary properties including custom composite classes. But the idea sounds something strange for me for an example, accidentally I can create several instance of a custom composite class which I don't want.
You should have as many singletons as you need. Take a look at Cocos2d - it contains a fair amount of them: CCDirector, CCTextureCache, CCSpriteFrameCache and so on. There's no limit on singletons, say 5. If it's convenient for you to have one single center class for a certain kind of operations (like accessing network or a database or whatever) and you never need a second instance of this class then feel free to make it a singleton.
It depends on your requirement.
You can have multiple singleton classes or objects.
The singleton object will be alive till your application quits.
For memory managing concern, it'll be very difficult if you have multiple singleton objects(You can't release these singleton objects, when a memory warning raises).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm already using Dagger2 and everything is working but I have a doubt about the proper way to integrate it into the business logic.
What Robert Martin says in "Clean Architecture" is that the DI frameworks, since they are frameworks, are details that should be kept away from the Entity and Use cases and more in general from all the classes that are at a higher level than the frameworks.
What R.M. suggests is to allow only the Main-module to know the DI framework used and to inject the other classes by yourself in such a way that you can replace one DI framework with another one without having to change the BL.
Is there a way to isolate Dagger in such a way that the business logic does not see it?
Strictly speaking, yes: DI frameworks should also not be used in use case or entities circle. (That includes attributes and annotations)
The question would be how strict u want to handle this rule in ur project. Every rule and decision has pros and cons. As u said the pro of keeping DI out of the inner circles would be that u could easily replace it later. U would have to decide how big the benefit is compared to the cons, e.g.: having to pass dependencies to use cases manually.
Personally I currently try to handle it very strict in my projects. But my usecases tend to have only few dependencies ...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am new to IOC, I am building an Application where we are using IOC containers while discussing we decided an architecture that each module will have two Assemblies one for all module level work which is not exposed outside of that module and one with public access for the functions we want to expose outside.
My problem is I needs to create two IOC containers one at APP level and one at module level and there is a singleton instance which I want to register to both but the moment I resolve them two instances of the class got created on both levels is there a way to just get one instance.
One way is to create a Singleton class and inhibits to generate another instance but that I think will removed the concept of IOC is there any other way to just resolve singleton instance between two IOC containers.
Thanks
I am new to IoC, even I just understand the need of this concept few days ago. But, from your situation, why don't just rely registering the Singleton in one container while the other resolve from the one you registered.
Do this solution break concept of IoC too? I am sorry if this is not answer you search for. I am learning.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
What is exactly inheritance, polymorphism and encapsulation in iOS with example? Do iOS uses all this features? And how?
The concept of inheritance brings something of a real-world view to programming. It allows a class to be defined that has a certain set of characteristics (such as methods and instance variables) and then other classes to be created which are derived from that class. The derived class inherits all of the features of the parent class and typically then adds some features of its own.
Please check This link: An Objective-C Inheritance Example
The word polymorphism means having many forms. Typically, polymorphism occurs when there is a hierarchy of classes and they are related by inheritance.
Objective-C polymorphism means that a call to a member function will cause a different function to be executed depending on the type of object that invokes the function.
Consider the example, we have a class Shape that provides the basic interface for all the shapes. Square and Rectangle are derived from the base class Shape.
Please check This link: An Objective-C Polymorphism Example
Encapsulation is an Object-Oriented Programming concept that binds together the data and functions that manipulate the data and that keeps both safe from outside interference and misuse. Data encapsulation led to the important OOP concept of data hiding.
Data encapsulation is a mechanism of bundling the data and the functions that use them, and data abstraction is a mechanism of exposing only the interfaces and hiding the implementation details from the user.
Please check This link: An Objective-C Data Encapsulation
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
What is the best practice for having globally (e.g. from all view controllers) accessible current User object?
I am using core Data.
EDIT:
I just realized I should elaborate a bit (and immediately received a comment regarding that)..
current User means the user who is the owner of the phone and is associated with an entry in the remote database. User enters login/password (or registers) and then can access the remote server, get data etc..
Object visibility is a major part of app architecture. It is up to you to make your objects visible to the other objects that may need a reference to it. No simple rule can be given. I have tips in my book on how to make objects visible in an absolutely global way:
http://www.apeth.com/iOSBook/ch13.html#_global_visibility
For example, store a reference in the app delegate, which every other object can easily get a reference to. But there are lots of other solutions and approaches (which that chapter also talks about). It's a matter of planning ahead.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
In my application, I want to have a "brain" that keeps track of what's going on. That is - multiple view controllers need to be able to set values in this brain and get at its data too.
How would I go about implementing this? From what I can tell, making my brain a singleton class is an option, otherwise I'd have to declare the brain as a delegate in every view controller and assign the brain to it every time it's created, which seems quite messy.
Your answer is in your question as you said. Use Singleton pattern if you want to access an object from multiple objects and there is no need for more than one copy.
Bear in mind that you must keep your data thread-safe if you will have two or more objects in your code that will try to manipulate the "brain" at the same time.
As for the Singleton pattern, you might like to read this What is so bad about singletons?
Make sure you design your app using the MVC pattern and you should be good. The "brain" is the model.
How your "model" behaves depends on your application.
Singleton pattern is an option. Another option is NSUserDefault.
Yes you are right Singleton is a good option.
As i think you are dealing with low amount of data so singleton will be good and easy otherwise go for saving data in a database or NSuserDefaults.