This is a design questions, so multiple ideas will be fine.
In my iPhone app, I keep track of Multiple players' life, which can increase and decrease over time. After the game is done, I want to be able to show them their life throughout the game, so they can see how they did. Now, this will also be stored in Core Data, so they can look over their past games and see how they did.
So, the question is this: What is the best way to do it? I would like this information present in the life log:
time: Player Name - Current Life (Change in Life)
Where those variables would be stored and would be pulled out to display the list. So what's the best way to do this? Should I make a "Life Change" entity in Core Data and have many many of these lines in it? Or is there a better way?
Thanks for your advice!
Have a life entity that is hanging off of a one to many relationship that stores the data that is needed. Then when you display the data, turn those objects into text to display to the user, there is no reason to store thar kind of information as raw text in core data when you just need to store the variables.
Related
I'm still in college and I'm trying my hand at designing my own applications, for practice and also for funsies, but I'm having some big questions.
Currently, I'm attempting to design an application that uses a relational database backend to store records related to a pen-and-paper RPG that a friend and I have been designing. It will need to store characters, weapons, items, etc. Since it's based off of a sci-fi universe, there are guns, etc.
Now, I'm stuck in the conceptual stages here because I'm not sure how I would store some of the weirder to grasp types of information here. Since it's a tabletop RPG, there are dice involved, typically referred to as D4, D6, D10, D20, etc. and a lot of these weapons, for example, have several kinds of attacks each (they're guns, so it's like firing modes, etc.) and a typical attack would be something like "D20 + 20."
Now, I know that I could just store it as a string variable, but I was hoping to design this in such a way that I could actually add some dice-rolling/etc. functionality to it. Is there a simple or effective way of storing a Math.random variable (not the result, mind you, but the actual range number) in a SQL record so that I could just grab it and use it real quick?
For extra context, I was hoping to have one table of the actual weapon templates & stats and another table of just actual instances of those weapons, so I could keep track of ammo in each gun, who owns it, etc.
I'm using Netbeans and a Derby database. Thanks for any help you guys.
As stated above, I don't know why you just wouldn't create a java/C#/any programming language application that can simulate the dice rolls for you. I mean, you could integrate the database into the application to retrieve information. Otherwise just simply make the ability to input information on weapons/Armour into the application in the form of popup dialog boxes (Or something along those lines).
A database is primarily used to store information in a structured way and automatically updates this information as needed. What you are suggesting to do is more dynamic and has nothing to do with storing information and more so with actually playing the game. Not wanting to change your idea about creating it. Just creating an actual application that utilizes a database can be written in a language other than SQL. (And much easier to do it this way as well.)
Your question is very broad, but I would not store a descriptive characteristic like "D20 + 20" in your database only yo parse it out in the app. Instead store that as two or three (depending on what it represents) attributes (columns) in your database, and let the app display it appropriately.
I don't know exactly what you mean by storing "equations" and "RNGs" in your database, but those belong in the application, not the database. You can store inputs or parameters that guide those equations, but not the equations themselves.
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.
I think this is a pretty basic question, but I'm finding it hard to search for information because of the wording.
Basically, I'm working on an app that keeps track of my students. I want to assign each student a unique ID number. How can I create this variable so that I can reference and increment it when I want to add a new student? Obviously, I'll need to close and restart the app, and still keep track of the last ID number given.
Thanks.
Sorry for silly question. ]
store it the same place you store your student data. A database is the usual place these days.
You should also look into CoreData, this is a good abstraction of a persistent store, for Objective-C object, it can be backed by a Database, XML, Binary data, iCloud.
If your ID high value is all you want to store, Core Data would be overkill, and you might want to consider using NSUserDefaults. Not knowing more of your use case makes it difficult to know how appropriate this would be, but I mention it just in case you have a very lightweight need.
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.
I am trying to write an app that searches a website, and takes all of the results and puts them into a customized table. I am an Objective-C and iPhone SDK noob, and am hoping that this logic is what I am trying to accomplish:
1) Searching multiple search engines and pulling all of the data off of each website, storing each into a different array (for example: Searching Google, Yahoo, and Bing for "Shoes", and taking all of the different search results, hyperlinks and all, and storing them into three different arrays)
2) Pulling the data out of each array, and putting into a table (Table view in Interface Builder)
I am assuming that I need to declare global variables, so that they can be called from different classes......right?
What's the syntax for doing this?
How do I set this up in IB?
Did I bite off more than I can chew for this first app?
Thanks for your help!
Aaron, I also think you're biting off more than you can chew WRT a single question on SO, but let me point you to a resource I wrote on a similar topic about how to structure your program.
As an Obj-C noob, you're going to need to take extra care to remember the Model-View-Controller pattern. Extracting data from a web site is a bit of work - and you want to keep that very separate from your display and control code.
Have a clean API model that extracts and sorts data, and have a clear view controller class that reads data from the API.
My advice is to write the whole app in psuedo-code first and try out your thinking on us.