I have had a request put to me for an app, however it is completely different to the other ones i have done. Basically, without writing a 5,000 word essay, it needs to have "pages" that move in progression of data input, for example - if it were entering details about a car, the first page would ask you the make, then the page would transition, the second page would ask you the model, the page would transition to a new one again, it would then ask you the color - so on and so forth. It needs to have open text fields on some pages and a method for storing the data entered in these text fields locally. I know @GoNorthWest - you made your notepad plugin and enabled it to store data entered into it sorted by date i presume, or something along those lines? i would greatly appreaciate a bit of your input (privately if you prefer) Getting this downpacked myself will constitute 80% of what i need to fulfill in the requirements of this app, the rest im sure i can manafacture around that. Your help is greatly appreciated. Dave

Hi @Dave, I would totally love to help on this, using the Notepad plugin as an basis, but @David helped me quite a bit with it, and I'm still learning what we did! So, unfortunately, I don't quite have the skills to teach yet. However...this sounds like something you could very easily do using HTML and forms, especially if you don't need to save the result to the device forever. If you're essentially just passing variables from one form to another, and using those variables to either populate another field, or generate a form based on a previous response, it's actually pretty easy. Here's an example: http://www.htmlgoodies.com/beyond/javascript/article.php/3471111/A-Quick-Tutorial-on-JavaScript-Variable-Passing.htm Hope this helps a bit. I'll point @David to this post as well for his feedback. Mark

Dont mean to throw a spanner in the works here.. i probably should have explained further. 1. it will need to be an offline app for "in the feild" use where they may not always be internet connection. 2. it will need to be stored there for a reasonable amount of time, im hoping to be able to create it as a "diary" type arrangement where, if you wanted to, you could go back and look at data entered 6 months ago. I realise the data storage will have to be efficent to reduce the size it takes up on the device - however it will primary be simple text and number values. I am also hoping to have some pre-defined fields as drop down boxes (using the car example above - the fields with not alot of variables like "number of doors" would have a drop down box with selections like - 2, 3, 4, 5) I recollect vaguely in previous forum threads the topic of local SQL? or am i completely off tangent there..? I hope this isnt going to be too much of a headache, I dont like Headaches :) Dave

Hi Dave, Well, it's probably going to be more of a headache that you anticipate. Nobody that I'm aware of has cracked the miniSQL database on the device itself. My initial version of the Notepad plugin was based on HTML5 and used localStorage to store the data. That might work for you. Google HTML5 and localStorage to see what you come up with. Mark

Will do, thanks Mark. Dave

My two cents and OF COURSE the final design will depend on lots and lots of factors. What I've found is that in many many cases the complexities related to relational databases are not worth the effort. In cases where you're working with "personal data" and not data that is shared across many users (hundreds or thousands or millions even) you can accomplish this type of thing without as much headache as you may think. Because you're a buzztouch guy, and because you've began to understand the flexibility and simplicity of JSON data structures, why not leverage it here? I would do something like this...(again, assuming you'll have a few dozen, or a few hundred maybe "diary entries" in the app, personal to the app user)... 1) Establish what an "entry" may hold. Figure out a way to represent this in a JSON structure. Because you mentioned "simple text and numbers", lets assume it's a "person" entry but it could be anything. The idea is to establish the structure of "one item" before getting to involved with UI or controls on each screen. Something like this maybe... {"id":"1", "name":"David", "phone":"123-456-7890", "age":"20"} The number of fields (properties) in this list doesn't matter, just establish ALL of them before creating the UI. Each entry in your master list (not mentioned yet) will have ALL the fields but the values may be empty if the user has not entered them yet (except the id). So an empty item would look like... {"id":"1", "name":"", "phone":"", "age":""} 2) Next, create a simple text file (in code) to save all the entries. You could call them "childItems" like we do in buzztouch stuff or whatever you want. It doesn't matter. Your master list may look like.. "childItems":[ {"id":"1", "name":"", "phone":"", "age":""}, {"id":"2", "name":"", "phone":"", "age":""}, {"id":"3", "name":"", "phone":"", "age":""}, {"id":"4", "name":"", "phone":"", "age":""}, {"id":"5", "name":"", "phone":"", "age":""}, {"id":"6", "name":"", "phone":"", "age":""} ] Note the missing comma after the last item, this is intentional. In your app, the default "master file" holding all the items would look like: "childItems":[] (an empty list) 3) Next, think about the UI. The first screen would probably be a list type screen showing all the entries so far. Tapping an entry would load the "details" screen for that entry. Think about how the native contact app works, something like that seems appropriate. The list would have a PLUS button, a details screen would have an EDIT button. When an item was added you would walk them through the screens, step by step like you mentioned and gather the data. The final step would "write" the values (the new entry) to the end of your existing JSON master file. Editing an item would, um, update the existing item. You can use the built in BT_fileManager to do this. It can easily read / write data. You'll need to write your own "edit" routine to update an existing item. There are tons of ways to do this and you'll need do to some Googling to see how JSON is updated. I know you can figure this out. The toughest part, I think, will be getting the UI working the way you want. As you navigate through each screen you'll need a way to "keep track" of what item is being modified (or added). I would create a property in my app's delegate file (a global variable) to hold the value of the currently being edited / added item. When you finished with each screen, and just before you transition to the next screen, you would update this global variable (the JSON for the item) with the values entered. When the next screen loaded, and the user added more data, you would save again. Save, load, save, load...when the "last screen" was finished, and "done" was tapped, you would update or add to the master list. When working with the UI, you could learn a ton by trying to emulate some of the existing native apps, like the contacts app. You'll be surprised at how quickly you'll pick this up. Once you understand how to add controls to the screen, "load them with data" and move to the next screen, details and fancy stuff will become fun to invent. Hope this helps.

Wow, this actually does sound alot easier that what i envisioned it to take... Thankyou for the suggestions, they will be a big help. This is pretty much right on the money what i am after. In a way, talking about native apps, i am looking for a "cross" between the contacts and notes apps - a way to create records (i dont really think they need the ability to be edited once created, although i see this as being one of those "better to have it and not need it, rather than need it and not have it" scenarios.) and have them listed/sorted by date/month/year etc. Thanks again. Dave

Yup...makes perfect sense. As for sorting, the trick is understanding that JSON / plain text data, has no way to understand the difference between text / dates / numbers, etc. This is OK once you understand this. But, it's bogus when you try to "order" a list of simple text. Objective C doesn't understand (no language does) how to simply order a bunch of items by a certain key or whatever. It's just text. The strategy usually goes something like this... a) load ALL the data in an Objective C mutable array (mutable meaning you can add / alter it). c) Manipulate the array. It's in memory and is very powerful. Mutable arrays can be ordered, sorted, added to, removed from, etc. So, all your data manipulation is done with the ARRAY, not the JSON text file you save it to. d) After the Mutable Array is updated, and ordered the way you want, you "Save" it to the text file. e) Then you "read" the text file into an array so you can show a list of items, order it, filter it, whatever. All I'm trying to help you understand is that the JSON text is just a replacement for the otherwise complicated mySQL database. They serve the same purpose, persistant storage. Read the data into an array, manipulate it, then re-write it back to the file system as a text file. Your master list may be called something like "contactData_json.txt" or something. It doesn't matter really. You'll be overwriting that master file with every single edit. It'll be plenty fast. It'll be lightweight, and it'll very very human readable should you need to export, save to iCould, whatever. To get you thinking...consider making each item more and more complicated as time goes on. At first a simple contact. Then, each contact could have it's own sub-list of notes or whatever. Once you get it it'll become easier. Something like this for two contacts each having their own list of notes... "childItems":[ {"id":"1", "name":"", "phone":"", "age":"", "notes":[ {"id":"1", "noteTitle":"note 1", "notes":"blah blah"}, {"id":"2", "noteTitle":"note 2", "notes":"blah blah"}, {"id":"3", "noteTitle":"note 3", "notes":"blah blah"} ] }, {"id":"2", "name":"", "phone":"", "age":"", "notes":[ {"id":"1", "noteTitle":"note 1", "notes":"blah blah"} ] } ] In this kind of setup you have "contacts" and "notes" and each of them are their own JSON structure. A contact looks like (like we already know)... {"id":"4", "name":"", "phone":"", "age":"", "notes":[]} and a "note" looks like... {"id":"1", "noteTitle":"note 1", "notes":"blah blah"} Tinker around, you'll get it. Gonna make you the Mobile Ninja Down Under! LOL

Haha! well thats what im hoping for... This is great! thank you for the info - i will surely have a play and post any questions i run into along the way, no doubt there will be many! Cheers, Dave

excellent - a mini db /json lesson! can't wait to read that closer.... I was playing around with a plist database a while back and it might work for your project. here's where i got the idea/concept http://www.chupamobile.com/products/details/478/GVPlistPersistence+-+Plist+Databases/ never finished it, but one of these days....

Hi ATRAIN53, thanks for the suggestions - i will definately have a read a little later. Thanks! Dave