I have used UIDocument, but I don't understand the advantage over using Archiving? Assuming you don't want to use iCloud.
From Apple's docs: http://developer.apple.com/library/ios/#documentation/uikit/reference/UIDocument_Class/UIDocument/UIDocument.html
Applications that make use of UIDocument and its underlying
architecture get many benefits for their documents:
Asynchronous reading and writing of data on a background queue. Your
application's responsiveness to users is thus unaffected while reading
and writing operations are taking place.
Coordinated reading and
writing of document files that is automatically integrated with cloud
services. Support for discovering conflicts between different versions
of a document (if that occurs).
Safe-saving of document data by
writing data first to a temporary file and then replacing the current
document file with it.
Automatic saving of document data at opportune
moments; this mechanism includes support for dealing with suspend
behaviors.
You get nice integration with NSUndoManager, too
Related
The AWS documentation is seemingly endless, and different pages tell me different things. For example, one page tells me that AWSDynamoDBObjectMapper is the entry point to working with DynamoDB, while another tells me that AWSDynamoDB is the entry point to working with DynamoDB. Which class should I be using? Why?
EDIT: One user mentioned he didn't understand the question. To be more clear, I want to know, in general, what the difference is between using AWSDynamoDB and AWSDynamoDBObjectMapper as entry points to interfacing a DynamoDB.
Doc links for both:
AWSDynamoDB
AWSDynamoDBObjectMapper
Since both can clearly read, write, query, and scan, you need to pick out the differences. It appears to me that the ObjectMapper class supports the concept of mapping an AWSDynamoDBModel to a DB vs. directly manipulating specific objects (as AWSDynamoDB does). Moreover, it appears that AWSDynamoDB also supports methods for managing tables directly.
I would speculate that AWSDynamoDB is designed for managing data where the schema is pre-defined on the DB, and AWSDynamoDBObjectMapper is designed for managing data where the schema is defined by the client.
All of this speculation aside though, the most important bit you can glean from the documentation is:
Instead of making the requests to the low-level DynamoDB API directly from your application, we recommend that you use the AWS Software Development Kits (SDKs). The easy-to-use libraries in the AWS SDKs make it unnecessary to call the low-level DynamoDB API directly from your application. The libraries take care of request authentication, serialization, and connection management. For more information, go to Using the AWS SDKs with DynamoDB in the Amazon DynamoDB Developer Guide.
I would recommend this approach rather than worrying about the ambiguity of class documentation.
I am unsure about the structure of coreData and how the objects are saved in a directory. So what I know is that you create an instance of UIManagedDocument and make a URL for it and where it will save files. Then you call "SaveToURL", what exactly is created when you call this? is it the core data stack? Then when you save information into the entities you declared is a separate file created within the stack for each set of information in an entity? Finally, what exactly is a context of a UIManagedDocument.
These are the three main questions
What is created when you call "SaveToURL", is it a document or a
file or a stack?
When you save information in entities, are separate files created
within this file/stack?
what is a UIManagedDocument context?
I strongly suggest you read Core Data Programming Guide and start with Core Data Basics Chapter.
UIManagedDocument is a special kind of document, an UIDocument subclass, that stores its data using Core Data Framework. So it combines the power of document architecture and core data capabilities.
You can read more about document based architecture from Document Based App Programming Guide for iOS and I recommend WWDC2011 Storing Documents in iCloud using iOS5 session video. I also recommend Stanford CS193P: iPad and iPhone App Development (Fall 2011) Lecture 13.
What is created when you call saveToURL:forSaveOperation:completionHandler: is an implementation detail of UIManagedDocument and UIDocument and you should not really worry or depend on it. However in current implementation a folder containing an sqlite database file is being created.
No. All entities will be contained in a single database file also
more generally called: a persistent store. It is possible to use
more than one persistent store, but those are more advanced use
cases and UIManagedDocument currently uses one.
UIManagedDocument's context refers to a NSManagedObjectContext from underlying Core Data Framework. UIManagedDocument actually operates two of those in parallel to spin off IO operations to a background thread. When it comes to the nature of a context itself here's a quote from Core Data Programming Guide:
You can think of a managed object context as an intelligent scratch
pad. When you fetch objects from a persistent store, you bring
temporary copies onto the scratch pad where they form an object graph
(or a collection of object graphs). You can then modify those objects
however you like. Unless you actually save those changes, however, the
persistent store remains unaltered.
But it really is a good idea to take a look at the lectures and other material I posted above to get a general picture of the technologies used and their potential value to you as a developer in different situations.
I come from a web development background and haven't done anything significant in Java in quite some time.
I'm doing a small project, most of which involves some models with relationships and straightforward CRUD operations with those objects.
JPA/EclipseLink seems to suit the problem, but this is the kind of app that has File->Open and File->Save features, i.e. the data will be stored in files by the user, rather than persisting in the database between sessions.
The last time I worked on a project like this, I stored the objects in ArrayList objects, but having worked with MVC frameworks since, that seems a bit primitive. On the other hand, using JPA, opening a file would require loading a whole bunch of objects in the database, just for the convenience of not having to write code to manage the objects.
What's the typical approach for managing model data with Java SE desktop applications?
JPA was specifically build with databases in mind. This means that typically it operates on a big datastore with objects belonging to many different users.
In a file based scenario, quite often files are not that big and all objects in the file belong to the same user and same document. In that case I'd say for a binary format the old Java serialization still works for temporary files.
For longer term or interchangeable formats XML is better suited. Using JAXB (included in the standard Java library) you can marshal and demarshal Java objects to XML using an annotation based approach that on the surface resembles JPA. In fact, I've worked with model objects that have both JPA and JAXB annotations so they can be stored in a Database as well as in an XML file.
If your desktop app however uses files that represents potentially huge datasets for which you need paging and querying, then using JPA might still be the better option. There are various small embedded DBs available for Java, although I don't know how simple it is to let a data source point to a user selected file. Normally a persistence unit in Java is mapped to a fixed data source and you can't yet create persistence units on the fly.
Yet another option would be to use JDO, which is a mapping technology like JPA, but not an ORM. It's much more independent of the backend persistence technology that's being used and indeed maps to files as well.
Sorry that this is not a real answer, but more like some things to take into account, but hope it's helpful in some way.
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.
I am writing my first objective-c daemon type process that works in the background. Everything it does needs to be logged properly.
I am fairly new to Apple stuff so I am not sure, what is the most common and/or best way to log activity? Does everyone simply log to a text file in their own special format, or use some sort of system call?
You should look at the Apple System Logger. ASL writes to the system log database (making it easy to query the log from Console.app or from within your own app) and additionally to one or more flat files (if you choose). Peter Hosey's introduction to the ASL is the best I'm aware of. ASL is a C-level API, but it's relatively easy to wrap in Objective-C if you'd like. I would recommend also taking a look at Google's Toolbox for Mac. Among many other goodies, it contains a GTMLogger facility that includes ASL support. I've ditched my home-grown ASL wrapper in favor of the GTMLogger.
Another alternative you might want to try is https://github.com/CocoaLumberjack. Lumberjack is quite flexible and will allow you to log to various destinations, configure log levels, etc. It's very log4j / log4net like, if you are familiar with those.
It's also reports that it is faster than ASL... I don't know how it compares to GTMLogger with respect to functionality or speed, but the documentation seems to be a bit more approachable.