Android App ideas

Yeah, there are plenty of barcode scanners. E.g. Google Goggles. I like to use the Amazon barcode app when I'm in shops to see if I'm getting ripped off too badly for e.g. computer bits, TVs, etc.
 
Yeah, there are plenty of barcode scanners. E.g. Google Goggles. I like to use the Amazon barcode app when I'm in shops to see if I'm getting ripped off too badly for e.g. computer bits, TVs, etc.

Also seems like a great tool for haggling and price matching purposes.
 
No no no. What I described is far more targeted than a barcode scanning app. I am not talking about price matching or google searching.

Yeah I can scan a bag of chips and get a google search on it. Big deal. I am talking about scanning it and getting a standardized report on the ingredients, the manufacturer, where the ingredients came from, etc. The same form with the same standardized presentation of information for every food item in the store it can find. The database could cull from official USDA public records, for example, and tell me what Texas farm had the cow, what slaughterhouse the cow was shipped to, etc. etc. Instantly, with one swipe. That's not possible right now.

This would be for the niche market of high end food buyer people, the rich crunchy organic food types who want to know whats in their food and where it came from and who all have iphones or smartphones.
 
Barcodes don't store that much information though. The code just identifies the trade item uniquely, e.g. "Tesco Value Chicken Breast 500g". It's no good trying to find exactly which farm this particular chicken came from, because all "Tesco Value Chicken Breast 500g" will have the same barcode, whether the farm is in Worcestershire or Istanbul. It's not just a matter of looking the barcode up in a giant government database; the barcode itself needs to store that information, in order to uniquely identify a "Worcesterhorsehockye Tesco Value Chicken Breast 500g" from an "Istanbul Tesco Value Chicken Breast 500g". And if it did that, you wouldn't need a government database at all - a regular barcode scanner will tell you all the unique information that's encoded on it. In fact, a regular barcode scanner does tell you all that information uniquely on it. It's just that "farm of origin" isn't stored on it.
 
Yeah I can scan a bag of chips and get a google search on it. Big deal. I am talking about scanning it and getting a standardized report on the ingredients, the manufacturer, where the ingredients came from, etc. The same form with the same standardized presentation of information for every food item in the store it can find. The database could cull from official USDA public records, for example, and tell me what Texas farm had the cow, what slaughterhouse the cow was shipped to, etc. etc. Instantly, with one swipe. That's not possible right now.
I think creating the database for all that in the first place would be the hard project; creating a client application to access it would be relatively trivial.
 
@Mise: I was more thinking of being able to take a picture of the entire package and search from that alone, like you can do with some apps now for plain google search or price matching. I mentioned that and the barcode, but forget the barcode for now! Sheesh! :)

@mdwh: I agree the database would be the hard part. I don't know enough about where this information comes from but it is out there, it's basically what the author of "Omnivore's Dilemma" did. But I think there is a market for this, like I said in the sort of yuppie, urban organic food type folks. People that watched "Food Inc." and swore to never buy non-grass fed beef ever again, etc.
 
Well, there are two problems then. First is to identify the product, and second to build a database with all the information you want in it. Google Goggles is one attempt at identifying "things" based on their appearance (or rather, the picture's similarity to other images in its vast image-search database); we'll need to wait for that sort of image recognition software to mature before being able to use it effectively.

The second, as mdwh says, is a massive project. You'd either need the government to do it, or to crowd-source the solution. For example, many people use websites that give you nutritional information on products. I've used Fat Secret in the past: http://fatsecret.com/ . Users can scan the barcode or search the database manually to find the product they're eating. If the product isn't there, they can tap the numbers in themselves, based on the legally required nutritional information thing on the packet (or based on whatever information they have). That way, the users build up the database themselves, which is a lot cheaper and quicker than having one company go out and find all the nutritional information for all the products themselves. It's kind of like wikipedia, only for nutritional information. Of course, it requires a critical mass of users to work, but that's a matter of marketing, not programming. There's no reason why you couldn't make a website that did the same thing that Fat Secret does, except for the kind of yuppie information you're after.

But anyway, neither of those things are "apps", they're just giant databases. As mdwh said, the app part is trivial once you have the database - it's the database that's the hard part. But I mean, there's no reason why you couldn't hire a web developer to make the website for you, and then sell ads on the site to turn a profit. In otherwords, you're not describing an app, you're describing a web start-up.
 
The moneymaker would not be selling ads, or at least that would not be the primary revenue. If the app could develop a user database of information and preferred foods/shopping habits it could be another datamine to sell user info to food manufacturers. If there was a critical mass that showed customers preferred foods with available info in the database, then companies would want to jump on the bandwagon and make their product info available to it, so you could turn it into a third party licensing scheme and also make money that way. Yes... money....mmmm delicious, sweet money....

While the backend work is far more than the app, the app itself is critical since that would be how everyone gets the info.

But, back to regularly scheduled programming I guess, I am jacking your thread sort of.
 
Ahh yeah, that's a much better revenue source! Mmmmm corporate backing... *salivates*
 
So I made another app. It's called "Economister". It allows you to browse The Economist's website in a mobile optimised mini-browser. It strips out all the adverts, "Tweet/Like This" crap, all the side bars, all the top menus, all of that crap, and just leaves you with the plain article and basic HTML formatting. It even removes the pictures and replaces them with a link, so you don't have to waste precious Kilobytes on your data-plan. It also means that it's much faster than viewing it in a browser, first because it doesn't download as much stuff, and second because it's just showing you a basic text box, and none of the other fancy stuff that the browser shows you.

It's arranged by section, as per the RSS feeds, and it also allows you to Download the articles for offline reading. It's not particularly sophisticated, and I'm sure you guys will find some bugs in it. But please tell me, so that I can make a better, marketable version for monies. I figure I can make a few quid off this, because The Economist just released an official offline reader, but you need to be a subscriber to download the articles. My one

Unlike the other app I made for the FT, this one is actually legal, because The Economist has no paywall and gives all their articles online for free. And unlike my app that adds swear-words, this one won't trigger the autocensor and annoy mods. So here it is! http://dl.dropbox.com/u/2142379/Economister_v1.5.apk

Screenshots:
Spoiler :

 
Top Bottom