I want to organize my game files in the best way possible. Right now i'm organizing my data in three folders: /Document/Save/Stages , /Document/Save/Entites , /Document/Save/GameData. I'm using NSCoding and FileManager to store all data in these folders.
For performance, what's the best way to organize the saved files: Multiple folders, witch one with they own data or one single folder with all data?
Thx.
OBS: My english is't very good. Sorry for any mistakes
Not really a question with a set answer.
My preferred way is to have 1 singleton game data class with NSCoding to handle all the saving. Depends how much data you have and what needs to be saved. I dont think performance should be that different, its properly more of a choice of how you like to organise it.
If you like multiple folders than go for it.
Related
My app is a document-based and uses NSPersistentDocument to manage its Core Data stack.
It works great when each document has its own data, but now I want documents to share parts of their model.
In my case, the users import large files and I don't want to copy them for each document.
I want to have a model that is tight to the app itself and not to the particular document.
I'm not really sure how to go about it. NSPersistentDocument provides some methods to override for configuring Core Data stack but I don't know how to set it up.
Can anyone give me some tips how to achieve that?
very interesting case ,
NSPersistentDocument : A document object that can integrate with Core Data
https://developer.apple.com/documentation/appkit/nspersistentdocument#relationships
I would add my 2 pennies for MVC ideology:
The Model-View-Controller (MVC) is an architectural pattern that separates an application into three main logical components: the model, the view, and the controller. Each of these components are built to handle specific development aspects of an application.
while its great for relational databases like SQL where cascade delete is possible, and other query based operations.
but the moment you want to couple data between 2 objects you will run into few issues.
if any of the document/record depends on other siblings, you need to sync them, which is usually a pain in a**.
if any document is very big, your DB will start sweating already, if it has cascade dependencies to other members of db.
Possible solutions
since the persistent document can integrate with the core data, try putting any new data to core data and calculate difference from there.
ideology behind design principles
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
here is the full pdf
I'm very new in iOS programming and i can't find the best approach for my problem. I'm currently programming a multi-language word game and i have several dictionaries. I just need to use the words. I mean i don't need any description, synonym etc.
Is plist good enough for this? Or should i use sqlite or core data?
I've read lots of information about core data and sqlite in SO. But i can't decide which one is better way for me.
Any advice is appreciated.
Best Regards,
Taha
It depends on number of words and your app's logic of retrieving data. If the number of words is not that large, you could use plist file. As for sqlite, while building your logic, you have take into account that you can not retrieve data from the database concurrently, e.g can't request data at the same time from different threads.
I have a general design question for dealing with data. I currently am working on an app that stores about 100+ different unique properties (mostly integers, some strings) and am currently using a single object of a custom class to manage all of them.
I need the data to be "persistent" throughout the app so I currently pass the object via segues. I have managed to build 20+ views, most with their own view controller. I am very new to Objective-C and iOS development and have a feeling this is a bad practice.
I do not understand that much about core data and am not sure if it would be a better solution for me. I have also read about singletons and have heard mixed things about using them for this sort of solution.
In the future, I will need to permanently store the data that is held temporarily in the custom class I have written.
What is the best way to deal with this situation? Is it standard practice to pass the object around over many different views?
If the data needs to permeate through the entire app then a singleton might be a good way to go.
In game dev there is a pattern called the chalkboard pattern that allows any part of the game to read and write to the chalkboard. This can be used for health points, scores, etc...
This would suit you well too. Rather than pushing your data model around all the time just use the singleton to access each bit/ If the data needs to be updated then store the updates to the singleton.
The thing to avoid is using the singleton just because its there. If a bit of data needs to get from one place to another then don't just use the singleton if it isn't necessary.
I've developed quite a few local apps, however this is the first time I'm introducing networking (more specifically posting to, and reading from a database). I am receiving back a JSON object from the database but I am currently using arrays and dictionaries. The objects do have relationships to each other, and I was wondering whether CoreData is the way to go. If so, do I just replicate part of the database I wish to be made viewable in the app and store it in my CoreData model? Are there any tutorials out there for this?
Also, just as a side note, I've also included Facebook integration with which I download the users list of friends. Would CoreData be good for storing this kind of information too? Or would I be better sticking with dictionaries?
Thanks in advance.
Based on my experience (other could say different things) Core Data is the right choice but its adoption could depend on the time you could dedicate to it. At first could be very complicated but I think you could take advantage applying the knowledge in some other projects.
Out of there there are some tutorials or books on Core Data.
First I suggest to read about core-data-on-ios-5-tutorial-getting-started. In the site there are, I think, other tutorials. Then, you could try to read a post on core data I've written some time ago: Mapping Business Objects with Core Data in iOS. Also Apple doc is your friend. So read the Introduction to Core Data Programming Guide to have the details that are going on.
If so, do I just replicate part of the database I wish to be made
viewable in the app and store it in my CoreData model?
Yes, just a part. You can create a minimal model that includes the key parts you need to have in your device. What I want to highlight is that you don't need to take care of normalization concepts when you deal with Core Data. Yes you could, but in CD you deal with objects and it's important to make attention to memory consumption (the framework helps you) and performances.
Would CoreData be good for storing this kind of information too? Or
would I be better sticking with dictionaries?
With CD you could take advantage of NSFetchedResultsController. A NSFetchedResultsController objects is optimized to work with tables and it used to display data also in batches. Through this component you can deal with a lot of elements (say friends in Facebook) without overload the memory. See core-data-tutorial-how-to-use-nsfetchedresultscontroller.
If you want to know something else, let me know.
Hope that helps.
This question is somewhat related to this.
I want to have document storage along with some complex metadata. I am not using sharepoint. I have a very simple directory structure that goes 2 levels deep. (One folder and documents underneath). I want to store metadata associated with each file....tags, popularity (# of times accessed), creator name, etc...
What is the best way to achieve this? I am leaning towards the relational database with the link to the file but I have to think this problem has been solved before.
Your approach sounds just fine to me. Just store the folder and filename as one of the columns values and all the other metadata in other columns.
Do you have any concerns about this approach? Or perhaps a specific part of this approach that you're not sure of how to implement?