Android Developer Challenge Critique

[whitemice]

My Android Developer Challenge Critique can be found here:
http://blog.zedray.com/2008/05/16/android-developer-challenge-critique/

Regards
Mark

[ConAim]

Very well written articles. That pretty much summary of what our
developers have in common about this challenge...

[Hong]

Right on the money, mark!  Very very well written!

[Alex Pisarev]

Mark,

Thanks for an article, just wanted to address the LBS "missing signal"
and "weak batteries" issue.

1) Basically, you're right, those problems exist and, for example,
Commandro has some tricks inside it in order to correctly respond to
missing signals, as well as it can be run as a background service
(without UI at all) with minimal and rare GPS interaction in order to
keep saving battery.

2) There are also some solutions on the hardware side which we hope
will be used in new Android phones, such as u-blog highly sensitive
low-power chips as well as increasing the number of signal processing
correlators (http://lbs.gpsworld.com/gpslbs/Indoor+Positioning/Indoor-
GPS-The-No-Chip-Challenge/ArticleLong/Article/detail/501030?
contextCategoryId=33822).

3) A sophisticated Location Provider created by Google which will be
able to integrate the last known GPS position data with Cell ID
approximations (when the phone is out of GPS range) can also become
really helpful, do you read me Google?

Just my 2 cents.

Regards,
Alex

[Steven A.]

Very good writeup - agree with it.

[whitemice]

Excellent points Alex, and congratulations on winning the challenge…

>>1) Basically, you're right, those problems exist and, for example, Commandro has some tricks inside it in order to correctly respond to missing signals, as well as it can be run as a background service (without UI at all) with minimal and rare GPS interaction in order to keep saving battery.<<

That’s my approach too.

There are a lot of tricks and shortcuts which need to be implemented
to make consumer LBS a realistic proposition. My plan was to build
all of this into an intelligent platform (see Snowball), rather than
having each developer try and work it out on their own.


>>2) There are also some solutions on the hardware side which we hope will be used in new Android phones, such as u-blog highly sensitive low-power chips as well as increasing the number of signal processing correlators.<<

This hardware is in the pipeline, but don’t expect the fundamental
limitations of GPS to be solved any time soon. Rule of thumb says -
technology in experimental chips now can be in phones in something
like a 3-5 year timescale.

Currently we have a big drop off in performance when comparing the
best dedicated GPS devices (say a TomTom) to a GPS enabled phone (say
an N95). I expect this to be a problem for some time.

>>3) A sophisticated Location Provider created by Google which will be able to integrate the last known GPS position data with Cell ID approximations (when the phone is out of GPS range) can also become really helpful, do you read me Google? <<

Agreed, if Google want some expert consultancy on this issue then I’m
your man. ;-)

[Alex Pisarev]

>
> Agreed, if Google want some expert consultancy on this issue then I’m
> your man. ;-)

Hi Mark,

Just had a quick look into SnowBall. Your idea to use wi-fi hotspots
as well as bluetooth for more accurate location data delivery is
probably the best dream the LBS might offer. I mean if you have
something like LocationProvider which can return reliably the best
approximated/calculated coordinates (which are calculated on the basis
of last known GPS position/Cell ID/Wi-Fi Hot Spot location and
Bluetooth reading from nearby phones), I would definetely start using
it in my app and would definetely pay for it (as soon my app gets to
real phones).

It looks like you're currently building apps on top of the service,
however, having something simple like "pls give me the best known
locational data at the moment with the provided accuracy" as well as
allowing user to configure between "less accuracy-more battery" and
"more accuracy-less battery" modes is definetly kind of service that
most of the LBS application developers' and end users would be
interested to use, and we're not an exception here.

[Muthu Ramadoss]

I agree, this would be a really useful service that a lot of teams are looking for and would also pay for. We did have some discussion on this forum about snowball and how to keep the devices networked using a mix of bluetooth, wifi, cell towers etc., but guess the discussion dropped after a few excited conversations.

The market is out there for anyone providing reliable GPS information, or for a new kind of network which would keep the devices connected no matter what.

--
take care,
Muthu Ramadoss.

http://cookingcapsules.com - nourish your droid.
http://mobeegal.in - find stuff closer.

[whitemice]

Hi Alex
I’m glad you like it.

However Snowball is designed to do two very different but highly
complementary things:

(1) Provide you with the best available position information (better
than Cell ID but without using GPS).

(2) Allow you to post and search location *sensitive* content in your
area, while bypassing the positional requirement altogether (i.e. LBS
without knowing your location).

It turns out that (2) is a much faster and more reliable solution for
applications that don’t really need to know position but instead need
to know relative proximity (e.g. which Pizzeria is closest, or where
can I find a date).

I implemented (2) and some of the battery vs. accuracy vs. cost UI for
the challenge, along with 2 proof-of-concept applications to show what
it could do. Unfortunately doing LBS with opportunistic peer-to-peer
networks is a bit of a mental jump for most people, so I am currently
sharpening my presentation skills in order to get my message across
better.

Regards
Mark