I resort to your expertly advice because I am sort of "new" to Objective-C, I have read a couple of books and docs (namely Aaron Hillegass & Stephen G. Kochan's books), but some things are still unclear to me, for lack of practise.
To put you in context, I have a NSDocument project that uses Core Data for storage.
I struggle with 2 things right now: reading/writing to files, and table views ^^
So my first question is about Core Data : is it only able to save in SQL, XML or Binary format ?
Or can I use core data to read/write in any format, according to what I declared in the plist file ?
I am trying to work with .po files, and I want to display the translations in a table view containing 2 columns (1 for the msgid and the other for the msgstr).
To read and write files in the po format and display lines in my table view, I most likely need to parse the files using line endings and characters such as "#"as delimiters.
I haven't gotten around to doing that yet (I have no idea how to do that yet!), but I would like to know if it is possible or if I need to restart my project that doesn't use Core Data...
Please DO NOT just throw links to the apple documentation at me, it's the most confusing thing ever, and feels like it's made for experts only! I need me some human-readable explanations :)
Thanks a bunch for any help and advice you can give me!
It is possible to write a different storage format for Core Data, but it is not easy and it sounds like you are not at a level where that is a possibility (no shame there, I'm not either).
If you are only displaying data from the .po files then there is no need to use CoreData. CoreData is meant to provide a file storage solution. You create/edit data and save it using coredata. If you have no intention to create and edit data then get rid of coredata, it will only get in the way.
Related
I am an absolute beginner, so I am sorry if this question has been asked before and I simply couldnt find it because I was lacking the right search terms. Feel free to point me to the right posts and delete this one her. So apologies in advance.
I am looking to program a software that imports a list and links every word or sentence on that list to an audio file. I then want to export the whole thing: the list, the audio files AND how the relations between the words in order to use everything with a different app, programmed in a different programming (that is all yet to come. it will probably be in ruby)
Since I will probably not be able to open coredata files with ruby, which file format will be the best for me, so that I can use it in ruby etc.? or will I have to save all audio files individually, as audio files and have a separate txt file that links the words to the files? This sounds... wrong? :(
Sorry I am so lost right now!
You can use json file to hold all your data. It is widely accepted as a data interchange format. But better not to embed audio files in another file. Instead you can save path to you audio file.
I have several pieces of data that need to be merged into one file (ATContentTypes blob file, Plone 4.1). The total amount of data is likely to be quite large so I really don't want to have to load it all into memory, concatenate it, and do something like o.setFile(data). If I were writing directly to the file system I could just do open(myfile, 'a') and write to it, but I'm not clear how I could do that with a blob supported content type. All of the docs and tests I've been able to look at just have it being set with a str or in-memory StringIO. Is there a way to append to this field without loading the whole thing into memory?
Similarly, I've also looked at using Dexterity with a plone.namedfile NamedBlobFile. It looks like that field just has a 'data' attribute that is basically a string. How could I append to that without loading the whole thing into memory?
It's quite old and the product has never been officially released, but it can help you: ore.bigfile.
It's well explained in this blog article: http://blog.jazkarta.com/2010/09/21/handling-large-files-in-plone-with-ore-bigfile/
I'm writing a quick front end to display guitar tablature. The front end is in Flash but I want to store the tab in some human-readable format. Anyone know of something that already exists? Any suggestions on how to go about it? One idea I got from reading some stackoverflow posts was to use a strict ASCII tab format like so:
e||-1------3--------------0--|----2-------0---
B||--1-----3------------1----|----3-------0---
G||---2----0----------0------|----2-------1---
D||----3---0--------2--------|----0-------2---
A||----3---2------3----------|------------2---
E||----1---3----3------------|------------0---
It has advantages. I can gain a lot of info from the structure (how many strings, their tunings, the relative placement of notes) but it is a bit verbose. I'm guessing the '-'s will compress away pretty well when sent over the wire.
If anyone knows of an existing data-format for describing guitar tab I'll take a look as well.
edit:
I should note that this format is 90% for me and may not ever been seen by anyone other than myself. I want an easy way to write tab files that will be displayed eventually as graphics in a Flash front-end and I don't want to have to write an editor front end.
Check out the ASCII tab format. Also great description of the format is here:
http://www.howtoreadguitartabs.net/
ASCII export would be a great feature, but using ASCII as internal data format is not a good idea. For example, note durations would be extremely hard to express (hou would you store 32nds or even 16ths?, not to mention triplets...), so parsing those files would be extremely difficult. Moreover, users would be tempted to load ASCII files created outside your app, which will be likely to fail.
To sum up, i'd recommend to either try to reuse existing format or invent your own if that's not feasible. You may try to use XML for that.
EDIT: Beside DGuitar, i know of TuxGuitar and KGuitar, which support Guitar Pro files. You can look into their sources or ask their authors about file formats. I think there is also open source PowerTab-to-ASCII converter.
See Supported file formats in TuxGuitar.
TuxGuitar is open-source multiplatform software for reading, writing and playing the guitar tabs.
It supports the mentioned Guitar Pro and PowerTab format, and it also has its own TuxGuitar (.tg) format.
If you need the backend data structure to remain in human readable form I would probably stick it in a CDATA inside of XML. That could be inserted into a relational database with song/artist/title information and become searchable. Another option is to save it as zipped text files and insert links to those files in a database with the main artist info still searchable by sql.
These are not human readable:
Most common formats are Guitar Pro (proprietary) and PowerTab (freeware). DGuitar and TuxGuitar are open source viewers for Guitar Pro format. I'm sure that they have documentation for the format somewhere (at least in the code).
Advantage for using a common format would be the easiness of making tabs with those programs.
The Guitar Pro 4 format is described here http://dguitar.sourceforge.net/GP4format.html
I wrote a quick utility for displaying tab. For personal use. You can happily take the internal format I used.
I use a very simple string based format. There are three important structures.
Column, a vertical column in the output tab - all notes played simultaneously.
Bar, a collection of Columns
Motif, a collection of Bars
A Column looks like ':#|:#|*:#' where each * is a string number and each # is a fret number. If you are playing a chord you separate each string:fret with a '|'
A Bar looks like '[,,-,*]' where each * is a Column. A - indicates an empty column where no notes are played.
A Motif looks is just many Bars running back to back. For instance
"[1:5,-,3:7,-,3:5,-,3:7,-,-,3:5,3:7,-,1:8,-,1:5]"
e||---------------|---------------||
B||---------------|---------------||
G||---------------|---------------||
D||--7-5-7--57----|--7-5-7--57----||
A||---------------|---------------||
E||5-----------8-5|5-----------8-5||
"[-,-,1:3|2:2|3:0|4:0|5:3|6:3,-,-][-,-,3:0|4:2|5:3|6:2,-,-]"
e||--3--|--2--||
B||--3--|--3--||
G||--0--|--2--||
D||--0--|--0--||
A||--2--|-----||
E||--3--|-----||
I am looking at some files generated in the early 90s. One of them seems to hold references to data packed in some binary format in a number of large files.
The first six bytes of the file are 0x42 0x4f 0x53 0x53 0x20 0x37 which spells BOSS 7.
My searches of various sources of file type information, including /usr/share/file/magic have not turned up anything. Does anyone know what software might have been used to generate files that start with these bytes? Any information on file layout would be great.
It looks like the file might have been generated by VisualWorks Smalltalk:
[BOSS 7.5]
Contains the Binary Object Streaming Service, which supports efficient storage and
retrieval of objects, including code, to and from files.
Note that for code storage, the parcel system now supercedes BOSS.
I tried to load the file using the IDE provided at http://www.cincomsmalltalk.com/ and it generated a meaningful exception:
The identifier MediaCollectionDictionary has no binding
The file does contain:
MediaCollectionDictionary
MediaCollection*
CallMediaVehDict2
etc which means, if I could now figure out what the rest of the files do and learn enough SmallTalk, I could disentangle this mess.
Of course, I am not sure if this analysis is correct. So, please if you have any other ideas, let me know. Thank you.
Much later: So, my initial assessment seems to be correct. I got some useful tips on comp.lang.smalltalk: http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/5d55d857e2f80158#
Ask on comp.lang.smalltalk
Ask on the vwnc mailing list
I'm trying to figure out how to do this as I'm not sure what's the proper way of doing this.
I've got several strings that I want to store/save permanently, even after the application is closed. How should I proceed? Do I read or write from a textfile?
I believe you're looking for a feature known as Application Settings. This feature will take care of storing settings between instances of the application. The manner in which it stores settings is ClickOnce and User aware so it takes much of the problems out of the picture.
Here's a link to an overview on the topic
http://msdn.microsoft.com/en-us/library/c9db58th(VS.80).aspx
Use My.Settings
Yes, you might store it in a simple text file or use a settings file.
Take a look at Application Settings:
http://msdn.microsoft.com/en-us/library/0zszyc6e.aspx
I store what I need in a plain text file. I use my own format: First line: lenght of the array or the number of bytes/lines the data needs to be stored. Second line: data types. third line: directories or path info. At the end I store the data.
That's because programming languages can read by characters or by lines. C++ considers either whitespaces and lines.
SQL or Access is when you need to store more complex data than just strings or arrays.
Yes, I'd store it in some form of text file, then you can read it on load. It's very easy to implement in Visual Basic and you might even find some samples in Codemonkeys or similar. I'd avoid using the registry. Of course if you want, you could also use some sort of database (Access, SQLITE, etc.) to store the values. But that depends upon the type of data and how much do you need to read/write from it.
yes you can write to a text file, or try SQLite, which can let your VB program have database capabilities.
http://www.google.com/search?hl=en&q=visual+basic+sqlite&btnG=Search