02-15-2011 11:18 PM
Thanks JRab. Imported it into burrito and it worked.
After going through everything, I realized its just not coming to me now. I don't really know where to start. I'm going to New York on Thursday for a photography project, and I haven't spent much time planning and getting everything ready, so I think I'm going to put this on hold until I get back on Monday. Maybe after taking a bit of a break things will start coming to me more easily.
Thanks for all the help everyone.
02-15-2011 11:28 PM
The file that should help you out a little is called SQLiteModel.as under the src/model package. it can be overwhelming at first. i know you are a little out of it but are you familiar with SQL? if not you should probably start out with the basics and ease into it. just look up stuff like select statements and how to "pseudo" connect to databases and what it entails. that way when you have a foundation of how its done theoretically, the code will make much more sense to when you look at it. defintiely take your time and pace yourself. and like you said with a fresh pair of eyes it'll do wonders for you. good luck with your photography project and this one!
02-15-2011 11:36 PM
I'm not familiar with SQL at all. This kind of application is very new to me. I will definitely start with the basics like you suggested, and work my way into implementing it into my app. Thanks for all the help JRab, I cant tell you enough how much I appreciate it. You are definitely keeping me motivated. I'm looking forward to the little break I'll be having in a couple of days. I know its still kind of work, but sometimes I don't even consider it work anymore since I enjoy it so much. That's why I got into photography.
Thanks again JRab, and I hope everything is going well for you. Thanks everyone!
02-16-2011 06:23 AM
Is this information stored for a single user or for multiple users? If you aren't comfortable with SQL, the Shared Object could be a good choice. In the Adobe link I posted earlier they use multiple Shared Objects. For your example, you could have contactInfo as an object with four name-value pairs of strings, and then three Shared Objects for Skills, Education, and Experience. Those three could all be arrays of strings.
I don't want to discourage you from following JRab with the SQLite model, only provide another option.
02-16-2011 08:54 AM
02-16-2011 08:57 AM
Eventhough it makes sense to save as SQL, if you have no prior experience with it, it will probably frustrate you. So unless you can get someone to provide all the code needed to make SQLlite work specifically for your app (especially when the schema changes from one version to the next), I would stick with either SharedObjects or XML file(s).
02-16-2011 12:24 PM
Yes the informaton is for a single user. What you are describing sounds like a good idea as well.
Saving to XML also sounds like a good idea. If you could provide sample code that would be graetly appreciated. What I'd like to do is explore all the options and see which one works best, so that if I need to use it in the future I will at least know which method works best for me.
02-16-2011 12:30 PM
02-16-2011 12:49 PM
There is a lot of information on the web about XML. Here is just one of many tutorials that might get you started:
XML is basically self describing, hierarchial data storage that is maintained in a single file. No services or applications are need to manage these files, the application can read and write these files by themselves. XML structure is common, but the contents and layout (schema) can be pretty much what ever you want. If your application is the one managing the file, then there is no need to validate the structure. If more than one application is accessing the files than some type of schema needs to validate the layout or have some kind of API or server manage that for each client.
HTML is one of the best well known XML schema file.
Here is a very simple example:
<person> <firstname>Bob</firstname> <lasname>Smith</lastname> </person>
Names inside the less than and greater than brackets are known as "tags". It represents a name of the value that is contained inside the bounding tags. All tags have to be "bounded". A start tag (in the above example) is "<firstname>". The end tag is "</firstname>" (note the forward slash). If tags are not properly bounded, the XML parser/reader will not be able to read the data properly.
Tags can be "nested" which allows for a hierchial collection of information. In the above example, firstname and lastname are "inside" "person". There is no limit to the amount of nesting that can occur. So you could have:
<people> <person> <firstname>Bob</firstname> <lasname>Smith</lastname> </person> <person> <firstname>Mary</firstname> <lasname>Fernwood</lastname> </person> </people>
Here we have 2 "persons" inside a nest of "people".
To differentiate between the 2 "people" we can either add another tag (uid) to each person like:
<people> <person> <uid>12345</uid> <firstname>Bob</firstname> <lasname>Smith</lastname> </person> <person> <uid>67896</uid> <firstname>Mary</firstname> <lasname>Fernwood</lastname> </person> </people>
Or we can add what is called "tag attributes" that provide "inline" name/value information:
<people> <person uid="12345"> <firstname>Bob</firstname> <lasname>Smith</lastname> </person> <person uid="67896"> <firstname>Mary</firstname> <lasname>Fernwood</lastname> </person> </people>
Note that attriburetes have an equal sign to them and are bounded by quotes.
More to come...