"That’s four different ways to talk to Google on this phone, not counting apps like Maps and Gmail. And each one has a slightly different interface and provides slightly different results"
[..]
I quoted the above passage, though, because it suggests some rough edges regarding what is supposed to be the Pixel’s standout feature
I don't disagree . But consistency isn't everything. To free-associate for 5 minutes on the subject of Force Touch (surely a stand-out feature, and moreover one that's had 12 months to shake out the edge cases):
The weather app springboard icon force touch action has both a widget and the actions are nouns - quick links to recent cities. The clock app force touch action has no widget, and the actions are verbs (create new alarm, for instance).
The core "telephone" apps have different combinations of actions and widgets - Messages (no widget, "new message" and a list of recent contacts as actions), FaceTime (no Force Touch actions at all, but a widget listing recent contacts), Phone (a widget listing recent contacts and actions, including contact search), and Contacts (a widget with recent contacts, and a create contact action, but no search this time).
Some built-in Apple apps have no force-touch menu at all (eg Videos, Find iPhone,
The "leaves" in the iPhone safari tab switcher have fake parallax as you tilt the phone, and respond to force-touch by flexing apart. You can long-press to drag them around. The "leaves" in the system task switcher do neither of these things.
Springboard icon force-touch menus grew a "share app" action in iOS 10. Unless you get at that menu from a spotlight search, in which case they don't have it any more.
While I was looking at the weather and clock apps anyway,
The cities in the iOS weather app sync with their Mac equivalent (but the Celsius / Fahrenheit setting doesn't). The cities in the world clock app do not.
To rearrange world clock rows you tap "Edit" and use the drag handles that appear. To rearrange weather rows you long press (not force touch, that does something different) and drag up and down. But both apps have swipe to delete.
Having said all that, Force Touch is amazing and you will have to pry it from my cold dead fingers. I just don't think universal consistency on a platform is achievable in a world where you sill also have to actually ship things.
So while it's nice that I'm able to host my own email, that's also the reason why my email isn't end to end encrypted, and probably never will be. By contrast, WhatsApp was able to introduce end to end encryption to over a billion users with a single software update.
In Intent Resolving in Android M, Said Tahsin Dane points out a change in Android Marshmallow to the intent querying mechanism. Specifically, when using queryIntentActivities,
If there is a domain verified application, [queryIntentActivities] does not return anything else. MATCH_ALL flag removes some system filters but only if there is no verified application.
This makes a lot of sense if I’m an application wanting to open a link to some other app and I want the system to just Do The Right Thing. But it led to problems with one aspect of the Eventbrite app.
Sometimes I want to be able to open the event the user is currently looking at in a web browser. I was doing this by constructing the URL to the web version, asking the system for everything that could handle it, then removing the Eventbrite app from the list and presenting the remaining intents (presumably the user’s web browser(s)) in a chooser. But when I added validated App Links, the list of “remaining intents” was empty - I had only been offered myself in list of possible handlers for the URL.
I’m working around this by building the intents list in 2 stages. First, I ask for a list of apps that can handle a “normal” URL. Then when I build the Intent list I’ll substitute the “real” URL:
// This URI is handled by the Android M "App Links" system, and if I// try to open it the only intent the system will offer me is the// Eventbrite app.UrirealUri=Uri.parse("https://www.eventbrite.com/e/17811426456");// We'll ask the system to open a generic URL, rather than the deep-link// capable one we actually want.UrifakeUri=Uri.parse("http://www.eventbrite.com");IntentbrowserIntent=newIntent(Intent.ACTION_VIEW,fakeUri);PackageManagerpm=getActivity().getPackageManager();List<ResolveInfo>activities=pm.queryIntentActivities(browserIntent,0);// Loop through everything the system gives us, and remove the current// app (the whole point here is to open the link in something else).finalList<Intent>targetIntents=newArrayList<>(activities.size());for(ResolveInfocurrentInfo:activities){StringpackageName=currentInfo.activityInfo.packageName;if(!packageName.contains("com.eventbrite")){// Build an intent pointing to the found package, but// this intent will contain the _real_ url.Intentintent=newIntent(Intent.ACTION_VIEW,realUri);intent.setPackage(packageName);intent.setData(realUri);targetIntents.add(intent);}}// Now present the user with the list of apps we have found (this chooser// is smart enough to just open a single option directly, so we don't need// to handle that case).IntentchooserIntent=Intent.createChooser(targetIntents.remove(0),"");chooserIntent.putExtra(Intent.EXTRA_INITIAL_INTENTS,targetIntents.toArray(newParcelable[targetIntents.size()]));startActivity(chooserIntent);
Now I can offer to open the current view in the user’s web browser, but still retain the Eventbrite app as the default handler for Eventbrite events when followed from elsewhere.
I read some reviews of the watch. I haven't used one, but I can tell you most of the same things the reviews do:
For the first week or so you'll be playing with it constantly and there will be lots of people saying "the battery life isn't good enough", because it's not designed to be used constantly.
You'll get lots of notifications and you'll realize that they're really annoying and intrusive. Then you'll put the effort in to manage those notifications and the problem will go away, you'll only be told about important things.
Then the novelty will wear off and it'll just be a thing you glance at but you'll forget about it a lot but it's useful and you'll be happy you have it.
Then you'll get to the actual useful phase where it really does fulfill that "I don't look at my phone" thing and you'll find that not only does the battery last long enough* but your phone battery lasts a lot longer now as well, because you're not looking at it as much - calendar notifications no longer mean that you're holding an inherently distracting device that you're inclined to keep fiddling with.
Then you'll stop using it, and think "this is actually annoying to wear", and take it off.
Then you'll realize that actually you use it all the time and had stopped noticing and now it's incredibly irritating to have to pick the phone up all the time, and you'll miss messages because your phone is face-down on the desk or something, so you put it back on.
...
Forgive me while I'm That Android Guy for a moment here. But I know all this because we did this last year. I'm genuinely interested to see if the extra capabilities of []WATCH are really meaningful, but it'll be hard - ecosystem lock-in means that almost no-one will be able to have worn both. Maybe the touch-drawing or the Haptic Wossname or whatever will be a meaningful improvement over Android Wear. Maybe not. I don't know anyone who'll be able to tell me, and I'm bored of reading reviews that tell me all the same things I learned last year about smart watches.
Oh. And it's really annoying in restaurants and cinemas because YOU HAVE A LIGHTBULB STRAPPED TO YOUR WRIST. Google solved that one pretty fast - there's a 'theatre mode' now that locks the backlight off unless you explicitly tap to wake, but wow that was annoying while it lasted.
* battery life of >20 hours and <1 week is not interesting because everything in that range means "charge nightly". I have a Pebble Time coming. I'm wondering if the slightly >1 week battery it promises will make a meaningful difference.
It is as if you are trying to build a cargo aircraft, and you insist that it should also lay eggs because it can fly. It is a flying machine, and it has wings and it flies, and you can even call it a “bird”. But aircraft are not actually birds, and the more bird-like you try to make them, the more you get in the way of the potential of the technology.
There are a couple reasons why we open activities launched from Chrome with NEW_TASK flag. The biggest reason is that it provides a much clearer user experience: the user sees the new app as a separate entry in recents -- also, if we were to place a different application on top of Chrome activity, the Chrome icon may end up opening that application sitting on top of Chrome, which is fairly confusing for the user.
-- Bug 445956, wherein the Chromium developers consider the Android task metaphor too confusing for users and work around it.
Ratchet and Clank: Up Your Arsenal was an online title that shipped without the ability to patch either code or data. Which was unfortunate.
The game downloads and displays an End User License Agreement each time it's launched. This is an ascii string stored in a static buffer. This buffer is filled from the server without checking that the size is within the buffer's capacity.
We exploited this fact to cause the EULA download to overflow the static buffer far enough to also overwrite a known global variable. This variable happened to be the function callback handler for a specific network packet. Once this handler was installed, we could send the network packet to cause a jump to the address in the overwritten global. The address was a pointer to some payload code that was stored earlier in the EULA data.
Valuable data existed between the real end of the EULA buffer and the overwritten global, so the first job of the payload code was to restore this trashed data. Once that was done things were back to normal and the actual patching work could be done.