I want to create one that will help me and others on the field, but currently I have too many ideas that might make the app too messy. Gonna be developing this on the Android platform as it's a little cheaper for newbies like to put up free apps.

So anyone wants to start the ball rolling with ideas? I want to keep it clean and simple, enough for anyone to download it and start using it to keep track of stuff. I would prefer that a standalone app for now before thinking of any complicated integration as I'm still a very new Android programmer.

Look up the old thread(s) about the "Mariner Project"!

Like you, I have too many ideas, but not a great deal of time. Sometimes find it hard to remain focused, too (the curse of the creative mind).

Meanwhile, I agree that Android may well be the answer. But (again) there's only so much time!

I know myself how tempting it is just to get stuck into the coding, getting engrossed in the intricacies involved (lost amongst the thickets), only to emerge, bleary-eyed and torn some days later realising that an hour spent with pencil and paper right at the onset would have been (literally) time well spent!

Are you talking about an equipment (repair) database, note-taker, or some such thing? So have you got the basic database set up?

Anyway, here's an idea ... why don't you start the ball rolling, and let us pick it about? It's far easier (for us) that way!

And one last tip:- do as much as you can in pseudocode. That way, not only is it more likely to be easier to re-work into other languages (and platforms) later on, if need be ... but it also retains the clarity you will undoubtedly be glad of when you come to look at it all again in two or three years from now!

Hmmm, I was thinking of just having 4 fields in my app:

[ID]<--Self generated
Serial Number
Fault
Next Action
Date/Time

And allow me to sync to a simple CSV file in Dropbox (using the api). I can look at it when I'm back at my desk. That's all I can come up with at this time.

Fair enough. Minimal is good.

You could do that in any language or platform.

Even the Psion Organiser!

In my experience it's often the navigation (key-presses etc.) that cause the problems, and take the time (to code).

But my comment here would be that you need to be careful about identifying a piece of equipment solely by Serial Number:-

1) There can be more than one occurrence
2) They can also be tapped in wrongly (especially if long)
3) They can sometimes be hard to find (especially on fixed equipment)
4) They can sometimes be hard to read, defaced or even missing

If you're keen to use just the one field to pin-point an equipment item, think about using an equipment Control Number (Tag Number, Asset Number, Property Code) instead.

I have always preferred equipment Control Numbers myself. They can (should) be short (and all the same length - which helps in databases and spreadsheets), neat, and semi-meaningful. And (of course) unique!

Let us know how you get on.

But meanwhile (and so we can keep up with you), what are the details for those fields you are proposing? I am assuming they are all characters (for CSV). But how about lengths?

For instance, the "Fault" and "Next Action" fields could end up being long (wide) unless you're thinking of using some sort of codes in those.

I'm not very sure what you mean by the navigation portion.

Well, the serial number field will be up to the user. I just listed it as serial number as this is how it's done over at my side. Anyone else using the app can treat it as a tag number, asset, etc.

Hrmmm, I was thinking of just leaving the Next Action and Fault fields as a normal text field as I do not have any idea what kind of codes to put in, so the length is just going to be 255 characters. Since it's going to be like a quick summary, I am guessing it's not going to be detailed.

Navigation? Searching the database, scrolling through records, etc.

255 characters? Twitter makes do with 140!

Before you embark on programming, I would highly suggest that you create the design and workflow of the app.
By doing so you will get a clear picture as how the whole system will work and what workflow will be included. Also what type of Graphical Layout you would like to have. Make sure it is a modular based system, that way in future you can modify and add more features to it.

So create a VISIO workflow diagram.

Also look at OPEN SOURCE programmes that may reduce the time consumed to write Andriod code.

http://code.google.com/hosting/search?q=label%3aAndroid

http://sourceforge.net/

Hope this helps.


Tim

Can I assume that your are responding to Vulpix there, Tim?

There is always an inclination to jump straight in and "begin coding". But as reported so many times on here in the past ... I advocate sitting down with pencil and paper myself. That's what I like to do, anyway.

Meanwhile, I notice that we haven't heard back from Vulpix in almost a year. Hopefully by this time he has produced something of value. Either that or been side-tracked by something else (as so often happens), or just given up ... whatever.

How about an app that mutes people who speak loudly on their phone?
Or a time limit on those who chatter about rubbish for the whole of the train journey to work?
Robert

That gets my vote, Robert.

What shall we call it ... the Glock?

"Chatter about rubbish"? Chatter about their "private" (NOT) life, you mean!