Hey people, I think the place to discuss mobile ideas is in the forum, as there's lots of overlap. Here's all the mobile ideas...

cD0CAh5 Cellphone Gas Calculator
kTA3iBW Wireless Handshake
6lUc7QP Mobile pet
TxLVFia Mobile Podcaster
O89LCEd Feelrz
JkxhCyk Poison pill for mobile devices
hG9mjzd Mobile Profile Timer
dg9L2kM Mobile Presence Helper
HoZfzfF Car Tag
GQLSvHL Automated Forwarding to Mobile Device
7UYaxu9 GPS-driven cell-phone compass
6RXyLm7 Virtual Pro
gBBftmO wireless, phones and people
NwXE1eF Scheduled SMS messaging
ECG8ZQ8 Portable Wireless Fax Machine
YSMkQoj Language Translator for Cell Phones

(I'm not distinguishing between old and new ideas. I also don't mean to steal any focus from ideas (such as Sneaky's Language Translator for Cell Phones). I want to try think about these in terms of overlapping features and technologies.

Gonna post again in a sec... Thinking as I post.

Posted: December 6, 2007, 11:38 am

A lot of these ideas work around location data. It would probably be helpful to create an application that uses location based data and make the source available to the community.

This application would serve as an example and allow the subsequent ideas to be implemented faster.

I am volunteering to help code it, anyone else want to join?

Posted: December 6, 2007, 11:44 am

I think I have all ready seen a tutorial on the Google android site.

Posted: December 6, 2007, 12:46 pm

Oh ok. I have only seen "hand wavy" presentations that don't give solid code examples. If you have a link that would be most helpful.

Posted: December 6, 2007, 12:51 pm

Applications which care where you are and alert user due to proximity (app is continually requesting location data):

cD0CAh5 Cellphone Gas Calculator - Lets assume this is only compelling if it alerts you to nearby deals. Potential for gas prices to be scraped from other. Micco points out booze is also fungible. My experience in Canada is that prices for booze don't vary much (heavy taxation overshadows any discount), but maybe in the states booze alerts are attractive.

kTA3iBW Wireless Handshake
Proximity to other people.

6lUc7QP Mobile pet
Proximity to other pets.

O89LCEd Feelrz
Proximity to other people.

gBBftmO wireless, phones and people
Proximity to other people.

dg9L2kM Mobile Presence Helper
Proximity to familiar locations.

7UYaxu9 GPS-driven cell-phone compass
Keep recording location so you can retrace your steps to find your car.


Applications which depend on ability to gather photo or video data, and share it quickly:

HoZfzfF Car Tag
Need to take photos and/or video to share with citizens or police.

6RXyLm7 Virtual Pro
Need to capture video, send to an expert for analysis.

JkxhCyk Poison pill for mobile devices
Want to record stream of photos, video, audio to help document the theft. Location is also sought, but because only used when device is stolen, higher priced A-GPS not so big a concern.

ECG8ZQ8 Portable Wireless Fax Machine
Need to be able to take photos of documents, relay them to a server (where conversion to fax will occur).

TxLVFia Mobile Podcaster
Most useful if we can stream video as we record it. But either way, we'll at least need to record and send complete audio or video clips to a server.


Applications which need to interact with phone settings or carrier settings:

GQLSvHL Automated Forwarding to Mobile Device
Need to instruct carrier automatically with new forwarding rules.

hG9mjzd Mobile Profile Timer
Need to alter phone's profile setting.

YSMkQoj Language Translator for Cell Phones
Need to intercept SMS messages and translate them. Outgoing SMS not as hard as we could be creating those in the app. If possible, initiating conference calls with a human translator would be handy.


Ideas I'm ignoring:

NwXE1eF Scheduled SMS messaging
Google Calendar already sends SMS alerts.


---

9-1-1 CONCERNS

This would apply to any tool created to document public nuances by recording photos, audio and/or video. Such a tool would be useful during any 9-1-1 call, or phone conversations with sketchy characters. It needs to be determined if an application can be launched automatically when the user dials pre-determined phone numbers. Or will a user have to choose between a phone call, or running an app?

If the user needs to choose between them, then it makes apps like "Car Tag" (or apps to monitor stolen mobiles) much less appealing.

---

LOCATION TRACKING

Availability of A-GPS data, and how much control ANDROID can exert over the mobile phone will determine which of these 3 categories of ideas can be implemented.

It may be an implementation of tools for one idea will in turn help similar ideas. For example...

"Feelrz" and "Virtual Pets" would both benefit from proximity alerts to other people running the same application. And if you're running "Feelrz" and "Virtual Pets" at the same time, we don't want to double the number of A-GPS calls. In fact, since presence and proximity are going to be so fundamental to so many different apps, we should think about how this data can be moved onto a central server and shared with all demanding applications.

Gee. Maybe there will be a privacy concern there? I kid.

Somehow this data would need to be available to any application caring about proximity. For some reason I'm having a bit of trouble getting my head around this... I don't know if I'm stating the obvious here (and its a service Google will be providing... API call to find everyone who's close by).

I don't see Google offering that... They'll fire events on your phone when you are close to a lat/long. But not when a friend gets in range.

http://code.google.c...oolbox/apis/lbs.html

How could privacy be handled? Well we could avoid the challenge entirely by offering zero privacy. At least until a compelling application is created. And collecting and sharing the location data will enable plenty of other apps... monitoring general traffic flow for example. It could be that one cost for users of this software is that they need to share their location data.


---

PHOTO AND VIDEO CAPTURE

Most phones can take photos and videos, and send them as attachments. It appears that ANDROID will grant full control over the phone's multimedia capabilities. We need to determine if a video capture needs to be completed before the data can be shared. Or can a video be captured in a series of short clips, with the last clip being uploaded while then current clip is still being recorded?

Can photos be taken without the entire mobile phone switching to "I'm taking a photo now" mode? Can it be done in the background?


---

If any of this is known by community members, please share. I hope if multiple ANDROID projects take off that codebases (and location tracking servers) can be shared, as it'll be a heck of a lot easier to roll out ANDROID app #2 and #3 than it will be to roll out app #1.

Posted: December 6, 2007, 2:18 pm

In fact, since presence and proximity are going to be so fundamental to so many different apps, we should think about how this data can be moved onto a central server and shared with all demanding applications.

This already built into the Android API.

The Location Manager class provides a method called addProximityAlert() which register an alert to be fired given a longitude, latitude pair and a radius around that point.

Further more the same class provides a function to register for periodic update on the current location. (Function is called registerUpdates() ) In one variant you can even specify the criteria for the provider so you can have setting for "low power" or type of provider.

http://code.google.com/android/reference/android/location/LocationManager.html

Posted: December 6, 2007, 2:35 pm

I don't see Google offering that... They'll fire events on your phone when you are close to a lat/long. But not when a friend gets in range.

Yes, you have identified the crux of the matter. One way around this would be to change the problem. Don't locate between two people. (moving objects)

Instead locate person 1 in proximity of a stationary location (say a coffee shop) and the locate person 2 in proximity of a stationary location. If person 1 is near the location, and person 2 is near the location you can conclude person 1 is near person 2.

So in a sense you can only meet people in "meeting places' that are in the system.

Not sure if this is making any sense... I can elaborate if needed.

Posted: December 6, 2007, 2:44 pm

On December 6, 2007, 3:35 pm ccozad said:
This already built into the Android API. The Location Manager class provides a method called addProximityAlert() which register an alert to be fired given a longitude, latitude pair and a radius around that point.

Ccozad, but its not firing proximity alerts when two people approach each other, right?

That's going to be they key to most of these people-meeting-people apps. Am I missing a way to achieve that via their current API? I don't believe its possible.

(I don't mean it can't be done, just what we need to track participants with our own server. Google isn't offering up that info.)

Posted: December 6, 2007, 2:47 pm

Read above, beat you to it

Posted: December 6, 2007, 2:52 pm

So to elaborate some more...

We are essentially locating based on fixed points in a grid.

Here is how I envision it working...

1. The app sends my current location to the server
2. The server returns a list of grid points near by
3. Those grid points get loaded into the proximity manager
4. If I enter the proximity of a grid point,
4a. The old grid points are removed from the proximity manager
4b. The app gets a new list of grid points near by
4c. The new grid points are loaded into the proximity manager.

The process continues, swapping in and out grid points as I move about

Now for say the mobile pets app, the server could not only return the near by grid points, but it could also return a list of other pets at the SAME grid point.

Posted: December 6, 2007, 3:01 pm

1. The app sends my current location to the server
2. The server returns a list of grid points near by

We'll need our own server to track people, pets... anything moving. Proximity manager can be used if we want it to fire events as we approach things... but one way or another we have to track the location of people ourselves, because Google doesn't let you ask...
- Who (among my friends) is nearby?
- Where are my friends?
---
Ccozad and me just chatted about this, and we both tentatively agree that Google doesn't tell you this info and need to track it ourselves. Anyone else want to weigh in on this? See absolutely no need for a server to track people's location data? To facilitate location based hookups?

Posted: December 6, 2007, 4:12 pm

In my previous post I ranted about technical challenges. For sure, any info on what is/not possible with ANDROID, share away.

But now I'm going to do a brain dump about compelling aspects of the above ideas... what is good is currently spread across too many idea entries. I'd like to consolidate what is interesting and maybe someone will declare they want to be a champion for a given application type.

How to brainstorm? Goosie suggested a mind map tool like...
http://www.bubbl.us
http://cmap.ihmc.us
...but I'm going to shy away from that just because I don't want to raise the barrier to entry for this discussion. (Let me know if you think I'm wrong about that.)

---

There will probably be friend-finder like apps appearing quickly in the ANDROID space. Small companies will jump in, bigger ones will shy away (for fear of a privacy incident). But until Google steps in (by releasing some APIs which tell you where your friends are, or if they're close), we should lean towards transparency rather than privacy. If you run a friend-finder app, you are saying to the world "here is my location". Maybe your real name is masked behind a GUID or alias... but anyone can hit our API and ask where you are.

That doesn't mean just anyone can contact you via the apps. But it does mean people can start building their own applications which mine the public data.

For example, say you write a simple game where a player needs to run around other people by a 50 meter radius. (We can quibble about GPS accuracy, but this is just a thought experiment.) The people you run around might not be playing the same game. They're running other applications which use our public APIs. But they're human, they're probably moving, and that makes the challenge of running around them much more difficult and interesting.

It helps with the problem of content creation. You don't always need to write an AI bot to battle with.

I believe we'll see increasing returns (Law of Plentitude) which includes people calling the API but running other apps.

So what might friend-finder features include? Well a minimum set of features is meeting new people and locating your friends. That's core. Even if we're writing a location based game, those features are still core, because you'll be looking for new opponents.

How much of the communication would have to take place inside the app is the big question. Is there any reason to write an IM style client when the phone itself will be capable of SMS? Do android phones already have IM clients, and we can just launch it or tap into it?

Posted: December 6, 2007, 5:21 pm

Does anyone think creating a public server for sharing location data is a smart move? I see a it as a pre-requisite for the people-meeting-people apps.

I think our community might find building ANDROID prototypes which call this public API fun... perhaps the API itself boring? Does anyone want to take it on?

IF we agree its a bottleneck, but that no one wants to take on the creation of it, I can go outside the community to try get it done. Does a community member want to offer to do it for a certain amount of Cambros?

What's the smart move here? Is the location tracking really not a big thing, and I'm over-focusing on it?

---

The API would be called when ever you want to know who's around you. When you call the API, you also submit your latest location data. That's the trade.

Posted: December 7, 2007, 8:57 am

Wow! bravo!

I would be willing to work on the project. I would need to map out the architecture before jumping into it.... time is at a premium lately, so it would be very helpful to collaborate with some other members in the community.

Posted: December 7, 2007, 9:25 am

On December 7, 2007, 10:25 am ccozad said:
I would be willing to work on the project. I would need to map out the architecture before jumping into it.... time is at a premium lately, so it would be very helpful to collaborate with some other members in the community.

So what's the smartest thing for us to do? I'm only suggesting a different approach with the API because there are so many things to tackle here before a useful ANDROID application can appear... it seems like the API could be developed in parallel with the client-side apps.

Certainly I need help defining this API... everyone interested in ANDROID apps should ponder this and see if it helps them realize their vision. (Even if it doesn't immediately appear ANDROID tracking data helps your particular app.)

So we define/debate the API. Then put it up for say... a reverse auction? Price keeps going up in Cambros. I could run an eLance campaign simultaneously (maybe offer lower funds there to give CH community an advantage)... then once we know API is being built to spec anyone else keen on ANDROID can focus on other issues.

(I'd like to point out PetersonLimitedCo is running a ChessSphere competition too. I don't want to compete with him for coders, but maybe we can find a model here which drives more coding.)

Posted: December 7, 2007, 10:00 am

Should we do the API planning on this thread or a new thread?

Posted: December 7, 2007, 10:03 am

Well, I'll make a decision then

As mentioned above,

- Who (among my friends) is nearby?
- Where are my friends?

Brainstorm
First thing to do is discuss the concept of friends. A person can have 0 or more friends. Another point is that if person A is a friend of person B, person B is also a friend of person A.

The second statement, "where are my friends" is probably the more straight forward of the two to answer. Every person who is registered (is "known" has a location (it's a location based system1 ).

Now that location may or may not be correct. One key indicator on a person's location is the time they were at that location.

So from this stream of consciousness, we can pull out:

API calls
- addUser(user_ID)

The system needs to know about a person.

- addUser(user_ID, location)

If we know the location when we first add the user, great.

- updateLocation(user_ID)

Update the location of the given user.

-getLocation(user_ID)

Retrieve the location of a given user

-addFriend(user_ID, friend_ID)

Establish a relationship

-getFriends(user_ID)

Get a list of friends for a given user

----------------
TO DO
- Think about security policies
- Think about distance and proximity

Posted: December 7, 2007, 10:28 am

There will probably be friend-finder like apps appearing quickly in the ANDROID space.

They were out before you post.

Here is the links I was talking about with the source and tutorial:
http://www.anddev.or...part_i_-_ii-t93.html
http://www.anddev.or.../viewtopic.php?p=434

Posted: December 7, 2007, 12:17 pm

ccozad and Kevin_Cox, thanks for your feedback on this.

Kevin_Cox, this is certainly a great way to track friends, and integrate it within ANDROID's existing contact list. Guess I won't be calling the CH genera "Friend Finder".

Can you double check that I'm understanding the communication correctly? Every participant is updating their own profile Notes field, to contain Geo data? And this data propagates naturally the same way an MSN alias change propagates?

So they bypass any need for a central server, but also the app is only useful for tracking people you have already listed as contacts. (Which is still a pretty darn good thing.)

If that is correct, then their geo propagation mechanism is certainly one that hadn't occurred to me, but it also doesn't offer up possibilities of how valuable the data could be if tracked on a server.

(This also calls into question if this is still a worthy endeavor, I believe it is but less so.)

Instead of an API call to inform a server of new geo data, can a person's own profile "notes" be updated, and monitored via a server? Then its up to the server to have a list of "contacts", and record the historical geo data and the "notes" fields are all updated. I assume the server would somehow have to access this info as if it was another contact, a contact which is given permission by other ANDROID users to see their Notes field data.

CCOZAD,

addUser(user_ID)
...I wonder if each handset has a GUID and we can use that. Or the "contact" name of each handset as shown on Kevin_Cox's example. I'm mostly worried about someone pretending to be someone else, but it may be an integrated security system takes care of that if we switch to receiving messages from Contacts rather than a REST API.
...so that didn't take long for me to worry about re-thinking! Anyway its something to check out before we pursue an API in too much detail.

updateLocation(user_ID)
...we'd need to pass in their ID, plus geo data so >1 parameter.

getLocation(user_ID)
...for sure need that

Retrieve the location of a given user
-addFriend(user_ID, friend_ID)

...dunno. Again, the existing example depends on your handset to already track "contacts". So we'll not worry about "friends" yet. I like your friends-of-friends thinking, but its a whole can of worms we don't have to deal with yet.

---

At CH we're going to discuss whether we can factor some sort of ANDROID tracking into CH3. It might be appropriate, or not. But if so, we'll try set it up on a dev box, and we can hit that for testing purposes.

Certainly what Kevin_Cox has posted shows there's more than one way to skin this cat, and my proposed way might not be the best. I know there's value in a central server tracking this data, but people are less likely to opt-in when there's less big-brotherly options available.

Posted: December 10, 2007, 11:18 am

So they bypass any need for a central server, but also the app is only useful for tracking people you have already listed as contacts. (Which is still a pretty darn good thing.)

Well, if you read the article closely, they are faking the geo data of the friends. The geo data resides in a file... however how does that file get there?

So I don't think the necessity of a "friend finder" server has been removed. It may be that the front end is now a lot easier with this working example, but that file of friend locations still needs to be populated.

Posted: December 10, 2007, 11:56 am

addUser(user_ID)
...I wonder if each handset has a GUID and we can use that. Or the "contact" name of each handset as shown on Kevin_Cox's example. I'm mostly worried about someone pretending to be someone else, but it may be an integrated security system takes care of that if we switch to receiving messages from Contacts rather than a REST API.
...so that didn't take long for me to worry about re-thinking! Anyway its something to check out before we pursue an API in too much detail.

Yes, user ID should be the phone number (the SIM card) or something unique. This would offer an increased level of security. However, if your stalker significant other happens to work at your cell provider... they might just some how impersonate the SIM card of one of your friends to track you. Not to mention good old theft...

Which BTW, might make a good horror movie... Sandra Someone is a "normal" girl who spends lots of time dressing by open windows... and suddenly her world shatters as each of her friends is being hunted by a psycho. And then she realizes the killers secret. He has hacked into her android phone and is using the "CH Friend Finder" service to find each friend's exact location.

She has to team up with Norm "No Technology" McPherson to take down the killer. (She has to team up with Norm because he was the only person "dumb' enough to buy an android phone with out a data plan) Turns out Norm isn't so bright in other areas... so Sandra is left to deal with the psycho while being hobbled by Norm's stupidity and pathetic pick up lines.

...

Posted: December 10, 2007, 12:28 pm

I think that Location Based Scheduled Event Reminder could be included in this also
http://www.cambrianh...er/ideas-id/L5YVHdE/

I fully support "bundling" many of these ideas from a common server.

Posted: December 10, 2007, 1:57 pm

Lets just make spy tools for the gov. So secret MIB with an ear bud. Can act like a friend but hide his presence. This would be good because the phone company's are all ready making money by the ping to track people.

Why not turn it one them. He he he...

Posted: December 10, 2007, 11:46 pm

On December 10, 2007, 12:56 pm ccozad said:
Well, if you read the article closely, they are faking the geo data of the friends. The geo data resides in a file... however how does that file get there?

They're calling the phone's GPS API, and each phone appears to update its own contact profile. And these contact profiles are shared as a more background ANDROID service. Can anyone back me up on this? I'm not 100% certain that this is the process... I don't see code for it in the demo, so I assume that is now users actually share their geo data (and how privacy concerns are allayed).

Posted: December 11, 2007, 9:49 am

On December 11, 2007, 10:49 am GordonMcDowell said:

On December 10, 2007, 12:56 pm ccozad said:
Well, if you read the article closely, they are faking the geo data of the friends. The geo data resides in a file... however how does that file get there?

They're calling the phone's GPS API, and each phone appears to update its own contact profile. And these contact profiles are shared as a more background ANDROID service. Can anyone back me up on this? I'm not 100% certain that this is the process... I don't see code for it in the demo, so I assume that is now users actually share their geo data (and how privacy concerns are allayed).

Each of the contacts have static positions. I am basing this on

As we need to store the GPS-Location of our contacts somewhere, I chose the Notes-Section in each Contacts-Profile. Saving a GPS-location is pretty simple, as we choose a well-structured style of data: a URI-String, which can easily found and extracted from the Notes-String using Regular Expressions. (all that is explained in details below)

So all of the friend locations are hard coded.

Posted: December 11, 2007, 10:24 am

As a human you can see the format of the URI: "geo:[-]XXX.XXXXX,[-]XXX.XXXXXX#".
Simply setup two or three sample-contacts (with different GPS-Locations) just like in the image below.
Or take these:
geo:37.402346,-122.075014# (Google-Headquarters, SF, California)
geo:37.444608,-122.216034# (McDonalds, Rolling Eyes near MountainView, SF, California)
geo:37.41622,-122.089919# (Starbucks, somewhere in SF, California)

Hard coded... so this is a good example for the front end, but the back end (that provides the friend locations) is not included.

Posted: December 11, 2007, 10:26 am

Ok CCOZAD, I'm being a crappy driver of this 'cause I don't have the emulator installed yet. Honestly any programing time I've found I've been working on a CH2 mod. Gulp. I need to get the CH2 mod done so I can at least put it in the testing pipeline before a ADHD myself further with investigating an ANDROID app.

Sorry people, I guess I need to put the sharing-of-location-data concept on hold, at least for the moment.

Should I try consolidate the ideas further in terms of what makes a good social app? I do find the virutal-pet space worth debating, as well as the my-android-is-stolen space interesting.

Any brainstorms anyone wants to offer on those?

Posted: December 12, 2007, 11:43 am

I have a head full of ideas for the virtual pet one, including how to create artificial demand for them.... but alas, that must be on the back burner for a while ad I don't see myself getting to it before feb of next year.

Posted: December 12, 2007, 1:24 pm

I'd still like to hear about ideas and tangents for the virtual pets...

Posted: December 12, 2007, 3:59 pm

Yes, and someone else besides you and I talking

Posted: December 12, 2007, 4:08 pm