Monday, 24 August 2009

Look Ma, I'm on the internets!

I've dabbled with blogs in the past (eg Xanga) but now actually writing this thing matters. My computer science dossier has to be documented constantly from the birth of the idea to its eventual conception. Currently, I'm planning a database with a twist - it pulls data from Amazon and autocompletes fields for you. It'll be used for albums and books with the possibility of expansion.

As per usual, I've jumped the gun and thought of a neat program that I could write which includes some of what I've learnt in the past. I have some old code that basically follows this structure so the main work is adapting/updating it.
The problem is that my dad has too many CD's and books to sort through and wants a unified way of working out the size of his collection (Eg Database).

I have some idea of how it should work as I typed out some notes beforehand:

Storing Data
Using a text file with strings appended with a unicode character because of string length flexibility. The disadvantages of doing this is that it will be slow for read and write (because it needs to process the lines and then the strings) but the string length justifies this. This is because I don't acutally know how long the titles or other information can get, so its best to future proof the database. Two text files will be used, one for books and the other for music - speeds up the data processing + reduces excess fields. This works out because if it was in one, there would need to be a TYPE field, to differentiate between books and CD's. Data will be written, not appended to make it easier to remove data when requested. This is because there are two main ways to write data, the entire file or at the end. Writing the entire file avoids lots of problems so it is the better solution. No images will be used, the reason for this is because of base64 encoding. Base 64 is when you convert a file to text but it may include the end character that splits the data apart. This will cause errors so its easier to nip it in the bud by not having it at all.

Data Input
This will be handeled by simply entering the data in the database. A possible feature that will hopefully be implemented is pulling data from amazon .com for the author, date, genre and other data. For multiple results - if less than ten results and show the data returned and let the user pick the correct one. If one result returned only, use that data. If more than ten, ask the user to specify their request. When the data is read from the text file it is placed into an arraylist. Doing this means that removing entries will remove the current selection from the arraylist. These modifications will be saved when the entire list is written to disk. Adding new entries will follow a similar process in which the arraylist expands to fit the new data.

User Interface
I will use AWT for the user interface, with text boxes for the input (everything can be modified) with buttons to accept confirmation. A feature that needs to be implemented is searching/filtering and thus will require a textbox to do so.

Thats basically what I've decided for this project in a big nutshell.

1 comment:

  1. OK Nathan this sounds like a project that is a) do-able and b) has the complexity to achieve the mastery factors.

    NOW go back to the beginning and talk about the problem. What is the problem? - 1 sentence isn't long enough. What ways could this be solved? What would your objectives be with the solution? How will you know that these have been achieved?

    Check out the documentation for Stage A. Check out the example files. Then get cracking

    ReplyDelete