Apple Event: May 7th at 7 am PT

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Level 1

94 points

Database

I'm thinking of using a plain text format for a data file format for my app/platform. It seems to me that I can use string programming to read and write data from a plain text file, and since almost all of the data needs to be read and written in series rather than searched through like a dictionary-type database, a plain text file seems like a good solution.

The problem is converting the numeric values to objects, performing a calculation, and placing them into an array.

So my questions include 1) Am I missing something before I go ahead and make plain text files my format for application data?

2) What are some of the efficient ways to take comma separated float values in a string from a location or file (after locating the symbol used by the reader to identify the beginning and end of the data string), convert each into an object, perform a calculation, and add that value to an array? I need several such sub-arrays, which then have to be re-calculated together. Will a new stack be opened for a new array, or should I direct the computer to open a new stack for each new array that is needed simultaneously?

Let's say I have these values in a string read from a text file: "12.3,12.5,12.6,13.2,13.4,13.8"

So let's say I take the string, read to a comma, convert it into an NSNumber object, all assigned to an instance variable. Then I do the same for the second value, etc. Is it better to take a couple of values and perform the calculation, move the result to another array, and then re-use the instance variables, or is it better to store an array of the NSNumber objects before doing any calculations? Should I read each value, assign a variable, and then put all the variables and calculation directives onto a queue?

iMac

Posted on Oct 20, 2012 5:41 AM

Best reply

etresoft

Level 8

46,530 points

Posted on Oct 20, 2012 8:01 AM

mark133 wrote:

I'm thinking of using a plain text format for a data file format for my app/platform. It seems to me that I can use string programming to read and write data from a plain text file, and since almost all of the data needs to be read and written in series rather than searched through like a dictionary-type database, a plain text file seems like a good solution.

Don't do that.

The problem is converting the numeric values to objects, performing a calculation, and placing them into an array.

Among other problems.

1) Am I missing something before I go ahead and make plain text files my format for application data?

Yes. That is a royal nightmare.

2) What are some of the efficient ways to take comma separated float values in a string from a location or file (after locating the symbol used by the reader to identify the beginning and end of the data string), convert each into an object, perform a calculation, and add that value to an array? I need several such sub-arrays, which then have to be re-calculated together. Will a new stack be opened for a new array, or should I direct the computer to open a new stack for each new array that is needed simultaneously?

Hmmmm... Perhaps the only thing worse than plain text is comma delimited text. Really, you don't want to go there.

Why not use Core data? I know it can be difficult to get your head around, but it will be worth it in the end. Start slow. Do some practice apps. Just never roll your own data format.

View in context

43 replies

mark133 Author

Level 1

94 points

Oct 21, 2012 3:29 PM in response to etresoft

Thank you again for the information, views and encouragement.

I won't need to serve the data, but users will need to be able to share data in document style quickly and easily with other users.

If iOS doesn't read or generate XML easily (I guess it could, really, I mean isn't XML just a form of text document?), then that presents a difficulty in that another important part of the functionality of the platform is in entering data through iOS.

This is why I've been asking for a number of years for a file format standard that contains label information for the file, data points consisting of a time-stamp, latitude, longitude, and a single variable (non-ratio) measure, with an optional field for altitude (or negative altitude).

mark133 Author

Level 1

94 points

Oct 21, 2012 3:30 PM in response to mark133

I was also asking for a time standard, but it looks like that is here now with the number of seconds from 1970 time formatter, which needs to be in a float format for split-second measurements.

etresoft

Level 8

46,530 points

Oct 21, 2012 4:22 PM in response to mark133

mark133 wrote:

I won't need to serve the data, but users will need to be able to share data in document style quickly and easily with other users.

The only reasonable way to make that happen is by storing the data on some web site and providing an interface where users can download it and upload changes.

If iOS doesn't read or generate XML easily (I guess it could, really, I mean isn't XML just a form of text document?), then that presents a difficulty in that another important part of the functionality of the platform is in entering data through iOS.

I was just talking about the internals of Core Data. iOS can do XML, but I would recommend JSON.

This is why I've been asking for a number of years for a file format standard that contains label information for the file, data points consisting of a time-stamp, latitude, longitude, and a single variable (non-ratio) measure, with an optional field for altitude (or negative altitude).

I was also asking for a time standard, but it looks like that is here now with the number of seconds from 1970 time formatter, which needs to be in a float format for split-second measurements.

There are many time standards to choose from. I suggest just using GMT time with decimal precision - something like: 2012-09-11 20:20:13.839950. I doubt you would need anything more than that. It is easy to store and read.

mark133 Author

Level 1

94 points

Oct 21, 2012 6:53 PM in response to etresoft

I guess that makes sense on the data, a kind of FaceBook for numbers, because the users should be able to both generate and use each other's data. But there really wouldn't have to be any central location if the data file itself was in a universal format, even if the reader was part of the platform?

It sounds like I need to do more learning about JSON and remember the GMT time format that's available. I'll be back when I get there. Thanks again for the help, pointers and guidance. Please let me know if anything else comes to mind.

mark133 Author

Level 1

94 points

Oct 22, 2012 7:35 AM in response to etresoft

Thanks etresoft. It looks like JSON is the standard I was expecting to find and the standard I have been seeking.

mark133 Author

Level 1

94 points

Oct 22, 2012 3:44 PM in response to etresoft

So let me see if I have this right...

If I want the application user to enter data into a file, provide that file to other users, and select files from other users to use in the application, then this could go something like:

The user-entered data is placed into strings that look like JSON elements. The elements are combined into a text that looks like a .js file. Should I then save those files with a different extension, to indicate their association with the application?

From there, the .js files can be combined with other text to generate a .html file if I want to have a browser become a viewer for the data, or else the file can be loaded into CoreData for use in the application and/or viewing.

mark133 Author

Level 1

94 points

Oct 22, 2012 3:48 PM in response to mark133

Or alternatively, the user enters data that goes into CoreData, and CoreData generates the .js file, or an .html file with the JSON objects? (But that seems to be a convenience that is not available on my xCode version, or else I don't know where to look yet).

xnav

Level 5

7,089 points

Oct 22, 2012 4:37 PM in response to mark133

http://developer.apple.com/library/mac/#documentation/Foundation/Reference/NSJSO NSerialization_Class/Reference/Reference.html

etresoft

Level 8

46,530 points

Oct 22, 2012 4:48 PM in response to mark133

I'm not sure I follow you. HTML and Javascript files need to be static. You would want to keep your data in some kind of database on a server and serve it via HTTP as JSON or XML. Then, your client software would parse that data into its own data store however you want to do that. To upload data back to the server you would use key-value coding to post changes one by one. That is a major undertaking. You might want to consider starting with something smaller.

mark133 Author

Level 1

94 points

Oct 22, 2012 4:56 PM in response to etresoft

I guess what I see is that having the data both written by the application as a JSON file of some kind and read by the application as a JSON file (of the same kind), means that the same file has a form that is more universal than any text file, and while it can be included in an .html file for use in conjunction with a browser, it can also be a file that can be transferred via any form of hard memory, e-mail, etc and subsequently viewed or used off-line. Changing the data once it's entered into the JSON file is not part of the need for the platform I'm designing.

mark133 Author

Level 1

94 points

Oct 22, 2012 4:58 PM in response to mark133

mark133 Author

Level 1

94 points

Oct 22, 2012 5:37 PM in response to xnav

I'm still running OSX 10.6.7 because I think I understood at some point that if I upgrade to the latest version I have to replace my FinalCutStudio with the latest FCPX and also sign up for the paid subscription xCode service instead of the current XCode that is installed now (4.0.2).

So even though I'm behind the times, I have had all the tools I need to do what I want to do, apart from here and now, where the convenience of adding a JSON class to the available Cocoa classes looks like a benefit worth considering.

The advantage is one-sided, and not a double sided disadvantage when upgrading, is that correct? I mean, with respect to an added class in Cocoa, the class uses what is available for various versions and platforms on a fundamental level and so the upgrade to the newer OSX simply makes the development easier for the developer, while the potential market is at least the same, or wider.

But do I have to make the jump to a subscription XCode service to get the latest advances? Until now, I have had time to consider the course of development, but with a subscription service fee I will have to move into a more productive mode on a project that could easily consume too much of my time. As far as the need to upgrade to the newer FCPX, I'm not as concerned about that.

xnav

Level 5

7,089 points

Oct 22, 2012 5:44 PM in response to mark133

Xcode 4.5.1 is free on the Mac AppStore. Also see https://developer.apple.com/xcode/index.php

You only need to pay if you want to run an iOS app on a real device, or submit an app to the Mac AppStore.

Message was edited by: xnav

etresoft

Level 8

46,530 points

Oct 22, 2012 7:15 PM in response to mark133

There is no such thing as a "JSON file". Stop thinking about files.

mark133 Author

Level 1

94 points

Oct 22, 2012 7:29 PM in response to etresoft

I'm all for losing bad paradigms, but what am I supposed to think of in place of files for data that is valuable, sharable, owned, unchanging, and useful?

Database