OpenMoko Ideas
From Snowulf
A list of programs/concepts we are tossing around doing for the openmoko w/ some comments.
Concepts
Offline BART schedule viewer
- Could do this via a website that pushes a file (or text message) to the Moko after the user selects which "lines" they are interested in.
- BART Schedules don't change much, and when I'm in a hurry I want to get em fast. So some how just scrape all the current schedules and save them to a CSV or similar that would be kept on the user device. Possibility of accessing a website (We maintain) to check for updated files
Gas mileage calc/log book
- Tiny app: Date/Time (default to Now), Location (Use GPS?), Miles since last fillup, Total Gas Added Read-Only field: MPG
- Possibly add a total of 3 modes. Add Gas, Add Maint, View Logs. Also for gas, might want total vehicular odo - and the ability to setup more than one vehicle.
Super simple voice memos
- Save wave files with filename: DATE_TIME
- possibly with the option to email them automagically after record - or save to device.
Tip calculator
- Tiny app: Check total Outputs: Tip at 10,15,20,25% and the total (so they don't have to do math on the Credit Card receipt)
Offline Currency Converter
- if you are traveling internationally you might not want to use the data service much. Save to local device, with a note of how old the data is on every start. Default screen should have 5-10 most popular currencies in the drop down / recently used, with the ability to expand to all listed quickly.
Flashlight/Mirror
- Flashlight means all pixels go white, mirror is black. 100% back light brightness.
Halo 3 Stats
- Have the ability for users to punch in the name of the player they want to look up, it goes, fetches, and comes back. Might have to go through an interpreter on a web server (we maintain) that can scrape down the data to something useful. CPU power and network speed would be an issue.
Time Zone/Time Converter
- Simple enough, can store limited City info if desired
- multiple methods of selecting time zones, converting, etc. Like lookup by City, timezone itself, possibly GPS?
Unit Converter
- simple enough, add interface similar to google
- I was thinking something like http://www.onlineconversion.com/ except w/o the "auto" function. Select a type, two units, and a value.
Weather/Forecast
- Current could require data transfer, OR setup a subscription service where they text the info to us and we (via an engine) text right back with the current weather
- I'm thinking quick databurst. I'm sure a few of the sites have ultra simple RSS/etc feeds that we could scrape and convert.
GPS to Area/Zip Code
- App would have a button to TXT current GPS to us and an engine would query a database and return Zip(s) and Area Code(s) depending on how specific we wish to get
- US only. Also more leaning towards standard databurst.
- Definitely not going to be Offline only. Several compressed DB's rank in at 700 MB.
- Initially start with GPS->Zip, seems the most likely to be possible.
- Possibly useful info: http://www.chilidog.com/zip/zipnotes.html
- Possibly useful info: http://geocoder.us/
- From Schuyler @ geocoder.us:
"Yeah, find yourself an ESRI Shapefile of the 5-digit ZCTAs, load it into PostGIS or MySQL Spatial and do contains() queries or similar. Be sure the operators in your SQL actually use the spatial index. SDE"
- US Census Cartographic Boundary Files
- Census 2000 5-Digit ZCTAs in Shapefile format
- MySQL Spatial Extensions
- OGR - Many people seem to mention this - might be useful
- shp2mysql - "Main Site"
- MapServerWiki w/ MySQL - Includes shp2mysql info.
- shp2myql-php
- LibMyGis and Documentation - Custom Lib - might be of use for conversation from shp to mysql load.
Japanese Hiragana/Katakana/Kanji Flashcards
- Offline download, would just require flashing an image on the screen and then at a button press "flip" the card with the description/explanation on the back
Sniping Calculator
- Lots of trig
- Need to borrow Paul's Barrett M95 - when he gets it. To "test the software" of course
SMS Games
Thinking of simple 2 player, turn based games. In order to "play" against someone else, there needs to be a method to communicate. Most younger gen don't have dataplans, but do have unlimited SMS plans. Why not build a method to send carefully crafted SMS messages between phones to "play" the game. On the reciver end, the game catches the sms message and updates the game client. This will allow you to play "casually" with up to several friends at once. Of course the trick is crafting a text message that contains the move, board status (to keep sync), etc... All while staying under the size limit. I think it would be an interesting challenge.
- Security Concern: We will have to rely upon both clients playing by the same rules. But as this is open source software, someone will be able to download the source code, make changes and "cheat". There is absolutely NOTHING we can do to stop this. Any security we put in place, can be faked, hacked, or worked around.
Battleship
- Wikipedia:Battleship (game)
- Grid typically 10x10 with 17 squares of ships.
- Very tricky security wise. To prevent players from "changing" their grid, we send both players grids so both clients are in sync, but this allows for spying. Might be best just to ignore the security concerns.
Checkers
- Wikipedia:Checkers
- American Checkers is an 8x8 board, with 12 pieces per side. That means 24 pieces to track and 32 possible locations. Also Kings
- Simple Rule Set
Chess
- Wikipedia:Chess
- 16 Pieces a side, 32 total. 64 locations.
- More complex per piece ruleset
Card games
- There are a large number of card games. Due to their simplicity would be very easy to communicate
- How to track the deck?
Other Considerations
- Text Messages sent/received between users are great. As noted, most people do have unlimited plans these days, or some really high number. The problem is as a "service provider" it costs us money. Now this is an option worth considering. We charge them $3 a month, and allow them to request weather updates up to 30 times a month (10 cents a text message is about standard). This might be something to consider for later though. I don't know how we'd receive their messages. Going from us, outbound is easy - but getting the requests from them is a bit more tricky.
- A text message has to traverse the operator networks, and interchange between operator networks (depending). Its not actually an email, but most operators have email to text message gateways. The problem is that there isn't necessarily a method for sms to email. It will require more research. If we can fashion sms's as email from the device to us, and then "reply" with another email back to the device - then great. But that might not work in all cases.
