I am extreamly new to programming. I am writing a simple game which gives you a score everytime you run the game. I am trying to figure out how to save the scores and recall them to a high score page. I am trying to figure out if saving to a dictionary is the best way, or using an array, or what. Plus, how does the dictionary handle an object that needs to be updated and changed, everytime the high score is beat?
well, the simplest way is just to store them in a text file. How this works is relatively simple in any programming language and most languages will have some documentation online that explains the functions for reading and writing from files. How to actually handle the values in memory (array, list, etc) will depend on the language you are using.
I'm new to Obj-C too, but from a pure programming point of view I'd agree with maqleod. You're problem is twofold: you need a data structure to hold the highscores in memory whilst your game is running. I think an NsMutableArray would serve you best, because it can sort itself for you (an NsDictionary is better when you want to lookup discrete values). On a higher level however, you need to save this data between sessions - data persistency. Thats where saving to a text file comes into play. If you look up / google "archiving objects" you'll find that it' really quite a trivial task in obj-c to save the contents of an object (eg. An array containing highscores) to a file - and of course initialize it again from file next time the game starts up.
Related
So i have developed an application in vb.net but recently i came across the requisite of allowing multiple languages for it. I dont know if there is any 'common' way of doing this kind of things, but my approach to accomplish that is the following:
I'll need to search in the code for components, error messages and everything that is displayed in the GUI of the application to be translated.
Secondly i will create a class in which i'll store in memory a dictionary of everything that will be translated
after, i'll replace the stuff to be translated withing an entry of the dictionary
then when the application start i'll load the dictionary
later on, i'll replace the static dictionary and will load it in memory from the database
So for example, my dictionary class:
Dim dictionary As New Dictionary(Of String, String)
dictionary.Add("00011", "hello there!")
Somewhere in my code i'll replace:
mylabel.text = "hello there!"
With:
mylabel.text = dictionary.item("00011")
Later on i will, instead of having a static dictionary, create that dictionary getting the information from a database like this (and load it at the start of the application:
_______________________________________
word_code ### word_EN ### word_FR
_______________________________________
00011 ### hello there ### bonjour il
I will load the dictionary considering which language is selected.
I'm not very confortable with this approach and i have no idea if this is the right thing to do, but if so i have a couple of questions:
is a dictionary the best data-structure to do so?
will this be memory-heavy considering i'll have 1000 entries, 1m entries or 10m entries?
is there any logic and faster way of accomplish the same?
Thank you so much in advanced,
J
It's a common way of doing it - having a system name along side a language code being used to look up a translated value. However, generally speaking I'd only advice you to do this for something like system texts and smaller text segments.
The reason is that in for example CMS/ecommerce systems, pages with lots of text likely will need to be translated in a data model to support it to begin with; and then you already have the language division.
So in that situation, you're better off making a page structure with a translated data model where the detail will be language specific per language for your current website.
For example, you'll have a product -> product_detail where detail keeps the translated values for said product. Similar for article -> article_detail and so on.
But for general translations and system texts which needs to be displayed, it's a common way to do it.
And as you suggest yourself, structures like like dictionary would be a good structures to to make fast look ups and can be cached in the system so you do not need to retrieve them all the time.
Some ways you can expand on it, is by sub dividing your translations into sub groups; say you have an order page and a product page. Then you can have translations assigned to "product" and to "order" with a "common" group as well.
It will also make it easier to build smaller cache objects, extract less data from your data storage etc, so a page which only revolves around orders don't need to worry about product translations.
It will require memory, but unless you put entire CMS systems into the translations, it should be "minor".
I would however question a need of 10 million entities of translations and wonder whether or not your system actually requires that many and if it does, then maybe consider an alternate approach and whether it might be better to make multiple versions of the "page" to eliminate the need for translations.
I would also advice you to not use "00011" as a system code to begin, and go for a more "readable" version (like "hello") to ease the readability and maintainability of your code. Then if you want a 'system value' which is like "00011", it's easy to do a search/replace.
I'm writing an iOS applications that saves Music albums(just an exercise I'm doing for the fun of it) .
For every Album there's a singer, song names, time, and a picture
The final result will be a lot of objects with a lot of details including a picture attached to every object. Should I even consider doing something like that with plist? (can pictures be stored in a plist?)
What's the best way to save and access that data?
I'm new to iOS and from the training videos I've seen Core Data is not recommend for the beginner user. Is that really the case?
If I'm going with plist, should I create one plist for every genre for example rap.plist , rock.plist etc' or just a big data.plist?
Thanks
I would go for core data. If you choose the right template when you create your new project in xcode then reduce the once-off overhead work significantly.
With that simple structure I would say that the templates provides nearly everything you need. Just define your model and layout and off you go.
There is just the images where I would spend a bit more time in thinking it over. I personally never put the image data into core data itself. I rather stored them as file and within my core data model I just stored the path and filename to access it. As file name I simply used a timestamp. You could use some auto-increment or other unique id technique but a time stamp would do as well. It will not be visible to the user anyway.
I think the best way you can do this, since you are new to IOS is by using sqlite. Save all the information you want in your local database and display it on the screen.
You can use plist if you have data structure that is small.
Note that property lists should be used for data that consists primarily
of strings and numbers. They are very inefficient when used with large blocks
of binary data. A property list is probably the easiest to maintain, but it will be loaded into memory all at once. This could eat up a lot of the device's memory.
With Sqlite you will easily be able delete , edit, insert your data into the database.
Core data also uses sqlite for data storage only it helps you to manage your data objects, their relationships and dependencies with minimal code.
And since your are new getting started with core data would not be such a good idea i think.. so i would suggest start off with normal sqlite. Save the data in one of your folders of your app and store their path in the database.
You dont have to write different plists.. You can use the same one if you are using.
EDIT : here is a link that will help you with learning sqlite
http://www.iosdevelopment.be/sqlite-tutorial/
you need some more code to set up the core data stack (the store coordinator, the store, the object model, and a context)
it is a tad more complicated but that shouldnt scare you off.
Reading a plist is indeed dead easy but while good for smaller data (like the info.plist) it doesnt scale and soon you need a fullblown DB
As you edited your original question an decided to go with plist now.
In that case I would go for one plist per ablum and one overall plist for the list of albums.
You could, of course, use more plists for categories etc.
However, if you are thinking of data structures like categories you are far better off with core data. Especially when it comes to searching.
No one seems to be mentioning SQLLite, I would go that way and for reasons that I explain here ( https://stackoverflow.com/a/12619813/1104563 ). Hope this helps!
coredata is a apple provided persistant tool, while plist is XML file. The reason why core data is not recommended for beginner, I think, is core data is more difficult than plist from programming perspective. For your application, obviously core data is more suitable. But alternatively, you may also use archive file, that's between core data and plist.
Why use plists and xml files? If I only want to store a few values, is it okay to use plain text files or does this go against Objective-C best practices?
-------EDIT-------
I'm not sure if this should go in a separate post or not, so I'll just put it here...
If I'm making an app where a user can design a cupcake and save it with their preferences (color, flavor, size), which method should I use. I imagine my users aren't going to make hundreds of designs, but some will inevitably make a large number.
I'd say it's fine, but considering how easy they make it to read plist files, my question would be why bother?
The main reason that plists are commonly used is because the native APIs can handle these easily. You can load a NSArray/NSDictionary directly from a plist with one command.
SQL databases are used when you are going to have many occurrences of similar data. For example, if you need to record contacts for a social app, you would use a database that could contain the id, name, age, gender, phone number, email, etc.
Other than these, there are custom binary formats, but these are specialized for whatever project is being worked on. Depending on what you need to accomplish, a text file could work for you, but there may be better answers. There is nothing wrong with using text files, but these are not commonly used as you would have to write your own methods to parse them. Really, I would need to know more about what type of data you will be storing before I could tell you which option would be best.
An edit to answer your edit:
For this, the best thing to do would be to use a SQL database, as every cupcake is going to have various properties, such as name, type of cake mix used, type of frosting, color of frosting, sprinkles yes/no, etc. This is perfect for a SQL database, because dbs have named colums (ie "name", "mixType", etc), and each row in the table will have different values for each of these columns.
This could also be implemented with a plist, but it wouldn't be as efficient, and it would use more disk space (although not much if youre just using it for cupcakes). I assume that you have a Cupcake class, so you could just implement a load function like this:
+(id)cupcakeWithContentsOfFile:(NSString*)file {
if((self = [super init])) {
NSDictionary* plist = [NSDictionary dictionaryWithContentsOfFile:file];
self.flavor = [plist objectForKey:#"flavor"];
// Etc.
}
return self;
}
This is an interesting question. I actually have an app out there that DOES indeed use simple text files for data that the app uses. Because the original code came from a windows / mac program, and I wanted to keep the data files consistent, Windows doesnt provide pfile type operation. I wrote all of the code on windows to read in the files, and since it was all ANSI-C it transported to MacOS X quite nicely.
When it came to porting it over to the iPhone and iPad, it still was just as easy to port the code then to re-write not only the data files into PList format, but also the PList reading code.
For All apps that I have begun from scratch that arent windows bound also, I have used PLists though.
This is actually an issue that I go back and forth on. PList and / or XML reading and processing is certainly NOT going to be as high of performance as a well designed text file format as both are bloated due to all of the excess tags that may or may not be necessary. If you are trying to develope a single data file that has many types of data, than this could be the simpler approach, but if you are looking for less datasize, and maybe faster execution, then formatting your own file may be much better. I know this isnt a definitive answer.
So in the end, it isnt a "best practices" sort of thing, but really a preference type of thing.
What is the best way to save the state of a program. Maybe that is not the right way to describe it but, what I mean is almost any application you can input a whole bunch of data make selections and choices and then save these in files unique to the application your working with.
For the time being I will ask my question in term of VB.NET since it is what I am currently working with. I understand the use of the stream writer to write data to a file (any file extension can be used even your own made up one) and then you can later open the file with the stream reader and load the saved application state. At least that is what I know how to do.
Are there other ways to approach saving the state? In my case I have a dictionary that is defined through user input to store a lot of data and I am trying to find the best way to save the dictionary so I can load it again.
I would suggest the best way to save state is the way that makes sense to you (and presumably fits in with your architectural style).
There are various locations and methods of encoding state into a file but, with the exception of a few extreme cases, there's unlikely to be any (user) perceivable performance differences between the techniques.
If one was feeling especially concerned about such things, it might be worth hiving off the reading or writing of state onto a background worker thread but I'd probably hold off on that if / until you actually start running into any disk bound perf issues.
You can actually do this using vs.net IDE and click your way to happiness. Click a control where you want to save the state, then expand the ApplicationSettings in properties. Then click the ... (box) by PropertyBinding. Now choose the property you want to store the setting for and click New. Now name your setting and select whether it is a per user setting or a application setting in the scope.
OMG, THAT IS IT, AMAZING!
Now, when you want to save the state of a windows form, just put in your code:
My.Settings.Save()
I'm currently looking for the best way to save data in my iPhone application; data that will persist between opening and closing of the application. I've looked into archiving using a NSKeyedArchiver and I have been successful in making it work. However, I've noticed that if I try to save multiple objects, they keep getting overwritten every time I save. (Essentially, the user will be able to create a list of things he/she wants, save the list, create a few more lists, save them all, then be able to go back and select any of those lists to load at a future date.)
I've heard about SQLite, Core Data, or using .plists to store multiple arrays of data that will persist over time. Could someone point me in the best direction to save my data? Thanks!
Core Data is very powerful and easy to use once you get over the initial learning curve. here's a good tutorial to get you started - clicky
As an easy and powerful alternative to CoreData, look into ActiveRecord for Objective-C. https://github.com/aptiva/activerecord
I'd go with NSKeyedArchiver. Sounds like the problem is you're not organizing your graph properly.
You technically have a list of lists, but you're only saving the inner-nested list.
You should be added the list to a "super" list, and then archiving the super-list.
CoreData / SQL seems a bit much from what you described.
Also you can try this framework. It's very simple and easy to use.
It's based on ActiveRecord pattern and allow to use migrations, relationships, validations, and more.
It use sqlite3 only, without CoreData, but you don't need to use raw sql or create tables manually.
Just describe your iActiveRecord and enjoy.
You want to check out this tutorial by Ray Wenderlich on Getting started with CoreData. Its short and goes over the basics of CoreData.
Essentially you only want to look at plists if you have a small amount of data to store. A simple list of settings or preferences. Anything larger than that and it breaks down specifically around performance. There is a great video on iTunesU where the developers at LinkedIn describe their performance metrics between plists and CoreData.
Archiving works, but is going to be a lot of work to store and retrieve your data, as well as put the performance challenge on your back. So I wouldn't go there. I would use CoreData. Its extremely simple to get started with and if you understand the objects in this stack overflow question then you know everything you need to get going.