I'm a bit confused regarding the document architecture. Lets look at MSN for Mac - what would the document be in that application? The contact list? The text we insert to talk to other people?
When the need comes to save or read data into the application, what type of data should it read? Contact lists or chat logs?
Update:
Pushing this a bit forward, what is a document? A file type that the application is prepared to open?
Maybe MSN for mac isn't a document-architecture application. Not every program needs to use the same system.
In general, a 'document' is just what you say; the data that makes up your application's files. It can refer to documents on disk - which have a particular filetype, or runtime documents, which are a collection of interrelated model objects in your application.
Your application might support saving/loading documents of various different on-disk filetypes, but they could all be represented with the same model objects at runtime.
MSN clients and other chat applications create and view logfiles. They can't edit them, as far as I know, but that's a feature - they're logfiles after all. There are easier ways to create such logfiles, but there is a nice pseudorandom quality to the way these applications do it which some people prefer. Sort of like SO but different.
Related
I realize this question has been asked in different forms but not quite in the same context as this so forgive me please.
I am developing a web based video game. I have a library of over 5000 abilities, spells, skills, character classes, races, etc.
I want the client to receive information from the game library upon request from the server.
My first instinct was to create a library of all of the data in my SQL database, however since the data is static I am not sure if it would be best practice to create objects in my server-side code to store the information.
If anyone can provide some insight I'd appreciate it.
Thanks.
EDIT: I'd like to add to most of the library items have roughly 256 characters of text (descriptions) along with the game related data.
5000 elements is a trivial amount of data for any modern DBMS to manage. If you are considering using a DBMS to manage this data, this would be advantageous over statically defining them in the server side code.
Separation of data from the "business logic" of running the game is very important. This allows you to add new definitions of items in the game, and customize the game without needing to modify any of your executable code to do so. This is also known as the Model/View/Controller design pattern.
I'm an OSX beginner. Where is the best place to store an NSMutableArray of objects. the objects need to be presented to the user for updating, deleting etc. I've already written the code to manage and present the data to the user. i just need to now start saving the data. i don't envisage the array containing more than 50 objects.
i'm not sure where to persist the data. should i use a os file or NSUserDefaults. what does osx etiquette say?
thanks
Since you mention that the user will need to update and delete the data, Core Data is a very good option.
In addition to the benefits of the framework itself, Core Data integrates well with the OS X tool chain. The model design tools allow you to create your schema graphically, quickly and easily. You can use templates in the Instruments application to measure Core Data’s performance, and to debug various problems. On OS X desktop, Core Data also integrates with Interface Builder to allow you to create user interfaces from your model. These aspects help to further shorten your application design, implementation, and debugging cycles.
You can read more about the key features in the documentation to be sure that's what you're looking for.
I am making a web browser made in VB.Net, and I do have people using it from around the world, but I don't think all of them can understand everything it can do. Does anyone know how to create a sort of language pack that users can change the language of every label on the form? The only way I can think of is editing all the labels to another language, then publishing the application again, but that is a lot of work because I do use a lot of labels... any help would be appreciated. Thanks!
What you're looking to do is called "localization." While localization itself is not a difficult topic to understand, depending on the complexity of your application, and the number and diversity of languages you want to support, it can become a rather involved task.
The general concept behind localizing an application is separating translatable elements (like all of the strings in your buttons, labels, and menus, or any images containing words) from the application itself, and storing them as resources which can then be chosen appropriately based on user preference or region, and then loaded into the application dynamically. There are a vast number of ways to accomplish this, and which you choose is entirely up to you, and how much effort you're willing to support. Techniques can range from loading strings from text files, storing and retrieving resources from a database, to using .NET's built-in localization functionality which stores assets in external resource files.
Localization as a topic is incredibly broad, so there is no single method that can be discussed without first knowing your specific goals and constraints. Your best plan of action is to start researching, and find a technique which seems most suitable for your project.
Google: ".net localization"
I'm developing a cocoa application that could be used to manage customer and employee details in a small business.
When I read through the NSDocument architecture, I believe that the document/window management and workflow it gives you is excellent, however I am trying to figure out how that architecture fits into (if at all) an application that reads each record from a database, instead of from individual files.
I think I could "fudge" some of the file-based operations in the workflow to read individual database rows instead of files, but I wonder if that is going to bite me later on.
Am I better off just ditching the NSDocument path and building my own Window- and Document-Controllers? Any thoughts?
Along the same lines, are there any books that describe "application design" in the cocoa world? The Hillegaas book is outstanding for describing the bottom-up approach, but it would be nice to get some guidance about designing/building real-world, complex apps (for those of you with Eclipse RCP experience, there is a great book called "Eclipse Rich Client Platform: Designing, Coding, and Packaging Java Applications" - something like that for Cocoa would be awesome). Anything out there like that?
You could either have your application backed by one sqlite database or store all the records in a file.
NSDocument-based applications are for when your application reads/edits/creates a file. Applications like this include text editors, image editors, pdf viewers, that sort of thing.
If you wanted your users to be able to create/edit/delete the databases you create and perhaps keep several different databases on their computer, NSDocument makes that super convenient.
If your intent is to give your users access to one single database that they an add/remove records to, you don't want to bother with NSDocument.
I don't understand how the term "Document" is used in objective-C and cocoa. When I build an Application, why do I have an "Document"? That makes no sense to me. I could have an Application like an Image Editor, wherein I can open like 100 Images at same time. So every Image is a Document and has its own Nib file? Can someone explain that term in a way that's humanly understandable? Best would be a lot of examples, I think.
From my ancient but still mostly relevant Cocoa NSFAQ (Not-so FAQ):
Q18
Why would I want a Document subclass?
A18
Because you have a central data model which needs an object to manage it.
In more detail, don't always think Document==File. The conceptual Document in most Mac applications may indeed map to a single file on disk but is also often a central object (Model in classic MVC design).
If you're using a database, the Document might manage the database connection and even end up saved as a file persisting that connection.
For your photo library, the Document might be singular, just containing some settings, or you may have multiple Documents corresponding to different layouts and filters as to which photos are visible.
There's no reason why you can't have more than one Document or even hundreds open if you want to go that way - the Document is a way to provide data to views and you can have hundreds of instances if you want.
Document-based, in terms of the Xcode templates, essentially means an NSDocument subclass. NSDocument and NSDocumentController provide an abstraction that makes it simpler to support multiple documents.
You are correct, you can hand-code it without NSDocument just fine. However, NSDocument does make it a bit easier.