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'm interested in how to properly abstract Firebase in order to decouple it with my app in case I want to switch back ends in the future.
Right now I have a single class with static methods that access the Realtime Database and Storage. I call these static methods throughout the app.
Is this the best way to use Firebase in a production environment? My app is written in Swift.
You can create a Wrapper class
class YourWrapperClass: NSObject {
}
Import the frameworks like Firebase that you want to use with this wrapper.
import Firebase
Create the methods with the use of Completion Handler/Closures/Blocks
That’s It. By this way you can use the code reusability.
Whenever you want to stop using Firebase, you will have to just stop calling methods from this wrapper class & implement alternative methods you want to call/use instead. Hope this will help.
I think the best way here is to have struct with static members for each main node in your Firebase database and also separate models for each main folder of Firebase storage. It should look like API's. You can change it in the future without any problems.
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 7 years ago.
Improve this question
For a new app I am designing I want to implement a Request Manager Class (swift) that will handle all the calls to the backend.
Which is the right way to do it? Class Methods or a Singleton and can you please provide me with a pattern or some sample code for me to get started?
Thank you in advance
First of all use Alamofire instead of AFNetworking. Alamofire was made by the same team as AFNetworking, but it's written in pure Swift.
Singleton pattern is a good choice for APIClient. My approach is to make generic wrapper on Alamofire which handles requests with unified error handling and completions, takes care of authentication headers and stuff.
Next step is to extend generic wrapper (i.e by subclassing) to handle application's domain-specific behavior -> all calls that connects to API goes here.
Big plus of this approach is fact that you can reuse this generic wrapper in another app.
Try Alamofire (AFNetworking for swift)
Alamofire.request(.POST, "http:/www.abc.com" , parameters: ["consumer_key": "Og5pRGI2V"]).responseJSON { response in
print(response)
}
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 7 years ago.
Improve this question
Is it better to declare an ivar in a class extension?
Or is it only a developer preference?
As the name suggest it is an extension to the functionality of class. You may add extra behavior to the class using extension. Adding member variables or stored properties have quite a bit problems viz:
When it is possible to add data member in extension the original class is not aware of the added data member. This leads to problem of allocation for such members while creating object for such classes.
It could also create problem with initialization and de-initialization of data members as these are not known to original init() or deinit() methods.
Adding data member may alter the very nature of class in terms of its behavior.
Currently you are unable to add instance variables to class extensions. This is true for both swift and Obj-C. See this question: Defining a property in iOS class extension.
If you mean, by adding a iVar to the interface extension:
#interface MyClass(){
MyIvar *ivar
}
well, thats a bit of a matter of choice and convenience. In general you should limit your public interface to a minimal set of properties/methods that allow the user to interact with the class in the way you design/expect. While your code will work fine using either method, exposing more properties/functions can result in more problems as consuming classes may uses properties/functions in ways unplanned for or unexpected.
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).
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 9 years ago.
Improve this question
I'm starting an app in iOS which will use a SQLite database.
I would like to reuse the code of this app for others in future.
I would like to make first a view associate to a ViewModel.
I will use a repository for my data. First, it will be generate, and after, data from SQLite database.
Then, when I'll use the database, just change some stuff in my ViewModel and all will work good...
I don't know if you see what I mean...
Do you know some good practices to do this? Tutorials, explanation, or anything else interesting?
EDIT:
I would like to follow this way:
Repository can be database data or random generated data for testing before I have the database...
ViewModel is the "model of myt view" which set all objects of my view with the data fetched in my Repository...
I understand the idea, but I don't know how to proceed to do this and I found nothing about the method... Maybe it's not a good way ?
If you have any suggestion, please let me know ;) Thank you!
Make an object class for the interaction with the sqlite, Preferred will be a singleton class which could also be used as intermediary storing class.
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.