Hacker Newsnew | past | comments | ask | show | jobs | submit | kaolbrec's commentslogin

I.. agree. Them having those policies is what makes this presumably a business and not a standard. Maybe something like this is better implemented closer to how BrowserID is (or am I talking out of my rear?).

Other than that, I'm intrigued.


In theory, this kind of problems was what OAuth was designed to solve - access to protect (private) resources by requesting the user's permission. In practice, I'm not sure if it's trusted enough in terms of security to be used for this. Giving access to CC or SS numbers is 'somewhat' more sensitive than letting someone post on your Twitter account.


This gets to be particularly annoying if you, for instance, check multiple folders. Of course you can just hold back to quit the app, but that would be an obvious solution, and put designers like this guy out of a job.

As for "no satisfactory solution".. the first thing that comes to mind is having the notification take you to the inbox, but then open the message itself, thereby building the "stack" properly.


But no one wants that flow. If I wanted that flow, I'd buy an iPhone so that I have to completely stop what I'm doing and switch tasks (not that I dare say anything bad about iOS multitasking).

I don't want to get a text, reply to it and then have to relaunch my previous app. A tap of the back button and I'm back to doing whatever I was before I sent the text.


I wasn't aware that going from say,

browser -> message

to

browser -> inbox -> message

Would suddenly mean that the browser gets killed. Is this really the case?


No, but I see no reason that that makes any more sense, the user experience is that they navigate to their browser, surf, drop directly into a message and then go back. Especially since I think you're still thinking about things from an old mindset where users use the homescreen to switch apps. That's fine, but for those of us that want to leverage Android multitasking (and presumably iOS multitasking allows you to jump back into an application via the multitasking pane), it's nice that we have a "history" so to say of our "session".

Not to mention that this simply wouldn't work in Android. If another application is launched via an Intent... and I press the back button and just return to a new level inside the launched application... I'm going to be peeved. Like, I'm removing the app irritated. I'm actually not sure a developer can even do that, thank god.

Why would you want to insert a new activity in the "back button history" that the user never visited? I was be distraught and am when applications screw with the Activity flow is messed with. The Google Voice app is notorious for stacking activities incorrectly to where it makes the back button useless.

That's why I prefer devs let Android handle it. The default behavior allows users to use their phones like iPhones (in terms of just going home -> app all the time) but also allows us to quickly switch into and back out of quick things like checking an email or replying to a text.


I can assure you I am not thinking of using the homescreen in that way, since I never experienced android when it worked that way.

In the context of checking inboxes, adding an "inbox" activity does make sense, especially if you receive multiple notifications. Although I don't see why there couldn't be a way for the inbox activity to only be added when necessary.


If you receive multiple email notifications it does take you to the inbox. If you only have 1 you go directly to that message.

* note: this is the Gmail app, I'm unfamiliar with the generic email app.


It was probably webdoc.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: