This is a case of what should be done (or not), in my opinion.
There is some inherent difference between how a browser acts and how
the phone behaves.
For example, navigation on the browser is not stack-based (in the
sense of how stacks are),
it is a list that keeps track of pages visited. Clicking back and
forward takes you back one page,
forward one page respectively.
Clicking home from the browser to take you to your home page adds one more
link at the top of this list ,and doesn't clear the whole list.

The Android phone app, however is implemeted as a stack, singly-linked list.
Clicking back will take you one level back (there is no forward, so
not really a direct comparison to the browser).
Clicking back continuously will keep taking you back till you get to
the home screen
which in this case is the head of the list (or bottom of the stack,
however you look at it).
No matter what is done again, you should not be able to go back one
level from the head of this list,
else you get a null pointer as there is nothing to go back to.
It is all just a matter of how it is implemented. The "Home" button
does the exact work of the
back button ALL AT ONCE, while the back button does it one at a time.

If a circular list is used to implement this, then you get the
functionality of going back from home
if something else is linked to it. I wouldn't want this myself, but it
could be another way for implementation.


On Fri, Jan 29, 2010 at 11:50 AM, Peter Eastman <[email protected]> wrote:
> On Jan 29, 1:14 am, Sean Hodges <[email protected]> wrote:
>
>> On my Nexus One phone: When I click the back button, it navigates back one
>> screen, when I press the home button, it takes me back to the home screen.
>> ALWAYS.
>
> And if you then hit Back after hitting Home, it doesn't take you
> back.  ALWAYS.
>
> I've said this at least three times already, so I'm not sure why
> people still keep not understanding what I'm saying, and insisting
> that Android behaves exactly like a web browser.  It doesn't.  If you
> don't believe me, please click the Home button in your web browser
> right now, then click Back.  Good, you should now be looking at this
> message again.  Right?  Now pick up your Nexus One, click Home, then
> click Back.  See?  It *didn't* take you back to where you were
> before.  There really is nothing complicated about this.  It's a very
> basic inconsistency in the UI, and it really should be fixed.
>
>> and what you are suggesting should be done realistically (dictate to vendors 
>> how they should
>> all be making their phones? recall all the existing phones, or leave 
>> existing users with broken devices?)
>
> Please look at the concrete suggestions I made in my original post.
> Making the behavior of the Back button more consistent doesn't involve
> any hardware changes.  It's purely a software change.  Establishing a
> standard way of telling users when a menu is available doesn't require
> any hardware changes.  It's purely a software change.  Eliminating the
> Search button is a hardware change, but it's not dictating anything to
> phone vendors, but rather the exact opposite: it's *removing* a
> requirement.  Currently all Android devices are required to provide a
> Search button, and they shouldn't be.  If they'd rather get rid of
> that button to save space, or use the space for something more useful
> like a "pick up phone" button, they should be free to do so.
>
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Android Discuss" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/android-discuss?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/android-discuss?hl=en.

Reply via email to