What I have so far is a JSON file that I read inside the singleton. I use the singleton to be able to share data between different controllers.
Now I have to implement Core Data; I was wondering if I'm supposed to delete the singleton and just use the core data, or if I can implement it within the singleton?
Singleton works very well for Core Data.
Simply move all the methods from App Delegate to your singleton class and call them from there.
Related
I am going to use my first app classes in my second app through wcf.
Now I want to know it is possible to call my classes from first app with all properties and methods related it?
just started iOS 7 development. I'm building an app which stores a user profile. Certain data, like photos and reviews, need is related to multiple users.
From researching, I found that Core Data essentially provides this type of relational DB. But super n00bie question - is a Core Data the same as a Singleton? Which should I use for accessing user data across multiple viewControllers?
If I go the Core Data route, it seems that I'll have instantiate a Core Data object in every ViewController. Doesn't that seem excessive??
With Singletons, I won't have to do that, but I'll need to have proper thread management.
Sound right?
CoreData is an object model framework, and a singleton is a design pattern. This isn't even comparing apples to oranges, because apples and oranges are both fruits.
But your question makes it seem like you want to know how to access your data throughout your app. There are a few common patterns for this.
You typically use one or more instances of NSManagedObjectContext. You can pass this instance along to each view controller. Or you can have some singleton object which has a reference to the NSManagedObjectContext. This singleton is often the App Delegate, especially since the built in Xcode templates already come with a reference to your NSManagedObjectContext in the App Delegate.
it's not the same thing at all.
Core Data allows you to create subclass of NSMamagedObject which are object representing table in a sql data base stored on disk.
singleton are unique instance of any class (usually if not never an NSManagedObject).
read on wikipedia about singleton it's a good article.
both have nothing to do with iOS7
When I have worked with Java applications involving a database and ORM (object relationship manager) the architecture was usually separated so when working with database entities in the database layer you worked directly with the entities. But if you needed to access the entities in the GUI you would create a data transfer object (DTO) of the entity and then use it in the GUI layer.
What is the preferred approach in iOS applications?
One example would be that I do a fetch from Core Data to retrieve some objects in a ViewController and then display the results in a TableView in the ViewController. Is it necessary to convert the NSManagedObjects to DTOs before showing the results?
What is the preferred approach in iOS applications?
Is it necessary to convert the NSManagedObjects to DTOs before showing the results?
No, it is not neccessary. The managed object is already a (generic) object wrapping the database entity. You can access the managed object's properties (ie the entitys attributes) using -valueForKey: calls.
But the preferred approach is to subclass NSManagedObject to fit your entities. In Xcode there is an option to generate subclasses automatically (editor-> generate NSManagedObject subclass). That way you get your own subclass object for your entities and can access their properties using dot notation.
On fetching objects, just let the result be of type of that subclass.
If you want to add custom methods to your entity objects, you should create a category on your managed object subclass. This is because if you change your db scheme and have to let xcode recreate your subclasses, it completely overwrites the and your custom methods would be lost.
I want to use SQLite database to store the scores of the games created with cocos2D framework. I use a singleton class controller called GameManager to control my application. To load the Scores I have a ScoreScene class which inherits CCScene and that class is called from GameManager, then when ScoreScene loads and from ScoreScene ScoreLayer class is called which inherits CCLayer class. I temporarily stored the score variable in GameManager and it is accessed from everywhere.
Now please help me and point out any weaknesses in my design and also help me in how I can implement SQLite database and store the score from GameManager class to the database.
The GameManager singleton seems to take the responsibility of managing common data and actions globally, right? Just be careful if there are multi-threading cases. I think your design is OK to use.
For SQLite part, you can refer to Apple official documentations if you want to use it via Core Data:
Core Data Programming Guide: Persistent Store Features
Core Data Programming Guide: Using Persistent Stores
Or you can use it via C interface directly. Some references:
http://klanguedoc.hubpages.com/hub/Tutorial-on-Creating-an-IOS-5-SQLite-Database-Application-IOS-5-SQLite
Use CoreData or SQLite on iPhone?
What is the preferred method of accessing ivars from different classes?
Application Delegate Class
Say I want to access the root controller (#synthesized as rootController) from the Application Delegate class in another UIViewController class. I've read somewhere that you access ivars from the Application Delegate class differently than you access other ivars.
Regular Class
If I want to access some ivars from lets say another UIViewController class. I would like to access the ivar which contains a list (NSArray) of names (#synthesized as names) in class A and get access to them from class B.
The ivars have default access (protected).
Perhaps you can point me to a good tutorial explaining how to access ivars.
The application delegate is a singleton so you can access those properties from anywhere.
In the case of a 'normal' class, and assuming you don't want to make it a singleton, you would normally use the delegate pattern. This means that class A becomes the delegate for class B and class B can call methods that class A will implement, this is how UITableViews work with the DataSource delegate.
This only works if you only need to access these properties from one other class (delegates don't support multi-delegates without a bit of hackery), otherwise I would encapsulate your data in a model which any class can access.
If I understand correctly your question, you will want to get a solid grasp at the Model-View-Controller pattern (which, by the way, is ubiquitous in iOS).
Basically, you should distinguish between your Views and your Controllers -- this is very "natural" in iOS because it is enforced by the framework -- but also between controllers/views and your Model, which is where you have your data, in your case the list of names. Controllers access the model and modify it and also mediate access to it from the Views.
The Model should be factored out someway -- say, in a class of its own -- in order to allow for modularity and low dependencies. In one particular desing (not meaning it is the best or more appropriate for you) the Model could be a Singleton, so that you can easily access it from other objects.
You will understand that a Model to be effective must be properly designed, but this is the way to go.
Check this tutorial and also this S.O. topic.
I think the concept you need here is declared properties: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17
You seems to already using it (with #synthesize).
ivars needs getters and setters to be accessed from the exterior of the class. By using properties, these getters/setters can be automatically implemented with #synthesized.
For the application delegate, i do not understand: do you want to access another controller from the UIViewController via application delegate ?