Creating a user heavy application and am a bit lost on what to do as far as the editing and saving data to a user goes. Can anyone push me in the right direction? Thanks.
One of the beautiful things about CoreData is that, once you create your data model, you are largely relieved from the details of how to write, edit and save the data itself. Of course, if you want to you can take control of those details.
I'd suggest you look at the tutorials here: http://www.techotopia.com/index.php/An_iOS_6_iPhone_Core_Data_Tutorial
That will definitely set you on the right course. I think you'll find it's actually very easy!
Related
I'm making my project for a-level computing and I reached a problem that im not sure how to solve. Im making something similar to a student information management system and I want a way to store a small list of students maybe 5 to 10 preferably in my program and make reference to them from all forms and so that if something is changed on one of the students maybe a piece of information, that these information is carried to the next form. My teacher has very little knowledge on programming and so im kind of stuck, i have no previous experience with databases or sql however if someone is willing to break it down ill be very grateful and ive got a good understanding of arrays. My deadline is the 10th of may so asap please, thanks
- kyle
If you prefer simplicity I would stick to a CSV file or XML. I found a website which an end-to-end tutorial on how to create the XML and add items (students) to it using VB.net as according to your tag. You need only after to read them from the file, but might just as well add new:
http://vb.net-informations.com/xml/how-to-xml-in-vb.net.htm
I would stick with XML (or CSV as preffered) as it is a text file basically so you can see and make changes directly if needed.
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 having some trouble trying to figure out how to implement a Rails 3 multi-page form with file uploads, where each step is handled by the update/edit actions in the controller.
Ryan Bates provided his wonderful screencast for how to to do multi-step forms using sessions, as well as a brief description on how to accomplish something similar by saving to the database on the initial step and then perform updates on each successive step. I have also read his gist giving a more detailed explanation of some different options on how to create a multi-step form (I am leaning toward option 1).
But I am still quite a bit lost when it comes to the actual implementation of a multi-step form. My goal is to use carrierwave for the file uploads (images), and perhaps workflow by geekq for the state machine to help with with validations at each step.
Just to be clear, I am currently trying to create an entry in the database on the initial step of the wizard, and have each successive page update the model.
Any ideas?
An example or a point in the right direction would be greatly appreciated.
Thanks!
Note: I have read another post where they mention something about a key/value data-store, but that unfortunately is a bit over my head...
Key-Value store or SQL for that matter are very loosely tied to your actual problem. Those are just a different approaches on how your data are actually stored in the backend. Using one way or another doesn't really make a difference in your case.
As for the actual question I think its too general for SO. Multistep forms tend to be very different one from another. There is no "one good way" of doing those.
The reason you are not getting any answers on this is probably because there is no real question asked. What you should do is to try to do actual implementation and post more specific questions when hitting the wall somewhere.
In the end - I believe the multistep forms are not really the best idea when it comes to usability. Of course there are valid reasons to use them in some cases, but you should really think twice if there is a way to avoid those in your case.
One of the problems I had while ago with forms and uploads was the validation (It isn't related to Multi/Single step specifically). Normally when validation fails user would have to re-upload the file. Fortunately in your case this not much of an issue, since Carrierwave handles that automatically.
This may sound like a noobish question (in fact, it is), but I can't figure out what I should use to save between sessions:
NSStrings
NStextStorages
I've found some alternatives, but I don't know which is best for the case and why:
Core Data (or has it nothing to do?)
SQL
Edit: I have a simple interface that adds "posts" to a database (that doesn't exist yet, hence my question). Each "post" has a "title" one or two "authors" and a "body". While the "title" and the "authors" are plain strings (NSStrings), the "body" is rich text (NSTextStorage). But I don't want to save files, I want to generate a database that I could then use to format automatically and generate a PDF file (for me to print). I've been reading Core Data and it looks like the way to go, I'm just not sure how I could then convert my data and format it into a PDF.
Core Data would probably be great for what you're doing, although anything you do with Core Data you can probably do with SQL if you already know it.
Read the Core Data guides. Basically you lay out your schema and then can add or remove managed objects from the managed object context. Core Data is nice because it can do a lot of validation for free, and is good performance.
I was in a similar situation not too long ago.. and although im developing for iPhone, i belive the principle would be the same.. i found core data to be very useful, once i got to grips with it it proved to be quite useful..
if your saving a lot of information/data, than core data may be the way to go..
hope this helps :)
I've been using the Game State Management sample which has worked so far. I've hit a snag though: when Tombstoning, the screens are serialised; the only trouble is, the MessageBoxScreen has event handlers for Accepted and Cancelled.
What's the best way to serialise these? I did a bit of research on using Expression Trees but this seemed overly complex for what I wanted to do.
How do you serialise these? Or... What alternative approach do you use to save the state of a screen that contains delegates?
I'd definitely steer clear of attempting to serialize anything remotely resembling a lambda, or for that matter, named methods. Remember: you're storing state, and nothing else.
Depending on how far and wide your various assignments to these delegates are, you might be able to get away with maintaining a Dictionary<String, WhateverDelagateType>, serializing the keys and looking up the callbacks after deserialization.
Another thing to consider--I'm no expert, but reading between the lines it sounds as if you're working towards tombstoning a very temporary modal dialog. Do you really want that? You might be better off bringing your user right to the high scores table, or whatever follows your dialog, on his/her return.
I decided against this. I instead persists game flow as a kind of 'flow chart'.
The flow chart is declared in code and has properties 'LastShape' and 'LastResultFromShape'.
In my code, I rebuild the flow chart definitions each time, something like this:
flowChart.AddShape( "ShowSplash" );
flowChart.AddLine( "MainMenu", ()=>lastResult=="Clicked" || lastResult=="TimedOut");
flowChart.AddShape( "MainMenu");
flowChart.AddLine( #"ShowOptions", ()=>lastResult=="OptionsClicked");
flowChar.AddLine( #"ShowSplash", ()=>lastResult==#"TimedOut");
etc.etc.
The flow goes from the top down, so 'AddLine' relates to the last shape added.
After tombstoning, I just read the last shape and the last result and decide where to go in the flowchart based on that.