Weighted companion cube surely?
106 posts • joined 29 May 2007
Re: Too late
Yup. Also moved to Feedly (having found the interface to be better than I remember on first investigation) and upgraded to Feedly Pro. Tiny Tiny RSS got a look in but API issues have prevented support in apps like gReader so it got ditched rather quickly.
I'd probably still be on The Old Reader if they hadn't made such an absolute statement of cutoff with a short deadline. The latter likely caused a lot more people to jump that might otherwise have hung on in case of just this situation.
Re: Looking forward to that
Thumbs up on the keyboard layout bit. Got quite peeved when I discovered that. If you're rooted and happy to have a bit of a fiddle then there are ways around it (not that you should need to). Posted up the way I did it here: http://floor4.co.uk/2012/08/07/nexus-7-bluetooth-keyboard-and-uk-layout/
Re: Mine is ok
@Gizzit101 To be fair, there were a lot of cock ups with the addresses ("Gordon House" wasn't the only issue - mine had a scrambled postcode - and as every person I spoke to at TNT was aware of the issue I don't think it was a tiny number, but certainly not "every delivery") and the service to resolve it was bloody awful. The screen hasn't been a problem for me though.
Have you got a breakdown anywhere of how iSuppli calculated the additional costs over manufacture per unit? Would be interesting to see how they worked it out from general product line costs (marketing, software, support, bulk shipping) and individual item costs (packaging, Play store credit [not real money of course but there must be a cost]).
Re: 85 percent?
Well, it'll be about a month by the time the Nexus 7 hits, and I don't think that's a massive ask from a dev perspective (given this is an incremental upgrade). Can't remember which talk it was in but there was something about getting the JB source out early to device manufacturers so maybe there's something similar with top devs? Doubt it, but it's possible.
Anyhoo, not convinced there are many "big" apps not working.
I'm torn on this issue. I do want all of my devices to be connected all of the time, but I'm not sure I *need* all my devices connected all of the time. One of the reasons I'm happy I've ordered a Nexus 7 is that I'm moving from a PlayBook. With the PlayBook I really hated the lack of a connection, and that's because the tablet seemed to constantly remind you of that fact. The system really didn't seem to cope with being disconnected elegantly, whereas with Android I'm normally happy losing my connection while down in the tube. My gMail and offline cache on gReader (third party - well worth a look though) are there for me to go through and deal with without ever once complaining that they can't sync right at that minute.
p.s. "Faffing setting up tethering"? Come on! For me that's one press on a widget :) Having said that, I haven't used an iPhone to tether and if it's anything like the number of presses required just to turn bluetooth on on my iPod I understand your pain.
Re: Phonegap and Appcelerator
You forgot the real benefit of using PhoneGap. Straight from the Getting Started guide for Android it'll teach you the excellent practice of requesting as many permissions as possible. This will in turn endear you to your users and to every other person who wants to see users paying attention to what permissions they accept.
No, wait, I have something backwards there ...
"It could be fixed in a manner such as I suggested. Cyanogenmod already features functionality to override services on a per app basis. It just needs to be implemented in the standard Android build so it can percolate out into all devices and become the default behaviour."
I totally agree that this *could* be done, but it would then potentially require a change to all apps to react to this, as you design with the assumption that you get what you have asked for as otherwise there's no install. As I said, it's a matter of opinion as to which way you want to go, but it's not an explicitly broken model. It offers controls, and some people don't pay them enough attention. A second layer of confirmation would then introduce annoyances for some while protecting others - it's going to be a matter of personal choice as to which you think is best and in this case they haven't gone with that.
A better solution would be to encourage people to care about the permissions more and, as someone said above, a big problem is permission bloat from lazy developers. I avoid apps with too many permissions, but I can understand that some users start to, as a result, treat permissions in the same way I treat most EULAs. Scrolly scrolly, accepty accepty. Read? Nah. Already have too many of those long things to read.
Unfortunately this is where Google fail massively IMHO. The dev documentation really doesn't stress the benefits of aiming for mimimum possible permissions, big publishers are pretty lax about their own requests so set a bad example, and the market (sorry, Play) doesn't enforce detailed per-description permissions to make devs think about what they're putting in. Google could influence all of these factors. I had a look at PhoneGap the other week and was appalled to see in their getting started guide they just suggest pasting in a massive list of permission requests to the Android manifest! That sort of rubbish really doesn't help keep the permission bloat low.
Re: One more time -
"Android's model is broken because once you install you have no second chance to modify the permissions. It's obvious some people do not read the permissions or do not understand the dangers of leaving them open."
That doesn't mean that the model is broken ... it means that it doesn't operate the way you think it should and that people are ignoring the safeguards put in place. Nothing broken about it.
Agree with almost all you say, except one thing (and don't wholly disagree):
"Most of the remotely "legitimate" reasons for priacy have long since been stripped away (I want it in an MP3 format, it's over-priced) or are rapidly being stripped away."
The only caveat I'd put here, where it relates to the argument of "I pirate so I don't get a product neutered by DRM", is that these reasons are still alive and kicking and, in some cases, getting worse in the game industry. Always having to be online to play, etc. etc. Certainly it tends to be limited to certain studios (Ubi ...) and many are providing much better solutions (gotta love Steam tbh - reasonably unobtrusive and the trade-off of control is that they backup all your games for you*), but I wouldn't say in that case that it's "rapidly being stripped away".
* or, more cynically, they're holding onto all the games they sucker me into buying in their quite daftly awesome sales until I can spare the install space
Rant comment accidentally posted as news?
But, for this Mac user, there is no download link and a piece of text on the top right of the screen says: "Your Google Drive is not ready yet."
Well Google, which is it? Is the damn drive ready or not?
Erm. Well it exists as a product that they're rolling out but it does quite plainly state that your drive is not yet ready. I think that answers your question ....
I think you should also watch those blinkers when you're reading that article. A more correct statement would be "use Google's services when distributing through other Google services". Until (and I will be surprised if it is) it's announced that this tablet only allows apps through the Android Market (nope, not calling it Play yet) then I don't see the problem.
Re: Permission blocking
"We need the ability to block individual permissions on an item by item basis - not just "if you install this we'll do all these things"."
Still needs to be a mandatory vs optional thing (and so can be done in app with the current system if the developer could be bothered - and obviously if you trust them). If I'm making an app whose functionality depends on a particular permission (camera access say), there's no point making it available if you're going to block said permission (and likely then complain in the reviews when the feature doesn't work).
Sounds great but ...
Until they sort out their signup processes to have secret questions that can be used by everyone then I'm not registering. Tried pointing out to them that favourite song / favourite colour / street you grew up on questions don't apply universally but haven't seen any change.
Glad to see a good'un
After the abysmal reviews I've been reading of some of the other non-air ultrabooks, it's nice to see a positive one. If they had gotten this to market a few months ago I'd probably have ended up with one of these rather than an air as the early photos looked great. Unfortunately I have no willpower and wanted my tech then. Still, whenever my current machine becomes obsolete it's nice to know the non-Apple crowd aren't completely useless.
Just to add a quick example to illustrate the point - do you really expect an app whose entire functionality is based around taking pictures with the camera, which has:
a) explicitly requested the camera permissions
b) excluded itself from devices without cameras
to be checking for permission exceptions when using the camera? That's not good practice, that's redundant code.
RE: rubbish engineers
You're missing the point. This isn't about basic exception handling. This would mean you'd have to consider the functionality you've built your app around to be optional somehow. It's a change to design. The whole point of having a standard platform and then a permission set requested at runtime is to guarantee that functionality is available to you. Besides, there should not be a security exception as you have actively asked for that access using the mechanism provided to do so.
Also, I'd like to direct you to the below excerpt from the android documentation on the subject. What is it with people commenting on android development without actually reading the documentation?
Often times a permission failure will result in a SecurityException being thrown back to the application. However, this is not guaranteed to occur everywhere. For example, the sendBroadcast(Intent) method checks permissions as data is being delivered to each receiver, after the method call has returned, so you will not receive an exception if there are permission failures. In almost all cases, however, a permission failure will be printed to the system log.
RE: Permissions - Could be better
I half agree. Justification of permissions is a must. There's no reason that any developer should be asking for a permission without being able to explain it (whether that explanation is a lie is another matter altogether ...).
The denial's a tougher one. Two aspects of this would punish developers:
- A lot more work needs to go into managing each feature of your app as you don't know up front that you have permission to do something that you explicitly request in the manifest.
- This could potentially kill all free ad-supported apps if everyone blocked network access.
A compromise would be to allow developers to have two levels of permission request - mandatory and optional. Where something can be safely disabled, allow it to be done by the user. Where it's an integral part of the app, make it mandatory. If you don't want to grant the permission, don't install the app. Simples. Having the optional permissions then controlled at the OS level gives you the additional peace of mind if you don't trust an in-app "don't send this data" option.
Google needs to educate, but not just users
While I think the tone in some parts of this article is a bit off ("allowed" them to be downloaded - makes Google sound malicious), this paragraph here covers exactly where the problem lies:
"With so many Android apps requiring access to geographic-location data, messaging functions, and other sensitive resources, Google has yet to educate users how to tell legitimate requests from illegitimate requests."
I would extend this a bit though as it also needs to educate developers. It's hard to educate users when permissions become as much of a pain to check as a EULA. The problem isn't that the permission system is wrong, it's that developers ask for too many / the wrong permissions. As some chap mentioned earlier, when TETRIS FREE was first released it asked for all sorts of permissions (SMS included) that it DID NOT NEED (I'm basing that assertion on the fact they eventually removed said permissions - never did answer my question why they had them in the frist place). Google needs to put a few more warning signs in place between development and the market to stop developers and say "look, are you really sure you need these. really? really???? 'cos it's only going to piss off your users if you're wrong". Anyway, a bit more waffle along these lines at the link I posted under the TETRIS FREE comment.
p.s. That Sophos blogger can f*ck right off with his exclusion approach. Blanket restriction is the lazy way out - how many times do devs suffer this sort of crap in corporate systems, preventing them doing their jobs.
No android icon so this'll have to do ...
Strangely I've heard some people tell that it's offered them surprising performance on low specs. Wonder if there's some specific hardware combos that have a bit of extra oomph in the code.
Agree on the regular save though. I keep getting CTDs, although generally after quite a bit of play (and more recently, just after slaying a dragon *sob*). Other than that, I've not witnessed any major bugs - after New Vegas this has pleased me!