Live data from Hacker News

My iOS 7 Wishlist

tomdale.net

151–160 of 160 posts

Re: My iOS 7 Wishlist

#151
post #26

Earlier quoted context omitted.

This is what happens when you market a phone as something that "just works". It's great that iOS is able to be used by kindergarten-level children, but at the same time, it's not. My next phone is going to be Android-based, because I believe that I can handle using mobile devices expecting users to be able to think critically.

>.. because I believe that I can handle using mobile devices expecting users to be able to think critically. And this type of attitude is why the general public think developers are assholes.

I'm not talking to the general public. I'm talking to people who want more than something that "just works" at the cost of user control.

Re: My iOS 7 Wishlist

#152
post #61

Earlier quoted context omitted.

Apple makes it very easy to create location aware reminders. So I don't think this is the problem you think it is.

I'd argue that Apple makes it possible to create location-aware reminders, but not necessarily "very easy." Say I want to set up a reminder to pick up some dish soap next time I'm near my neighborhood grocery store. I could open the "Reminders" app and try to do it, but that only works if the store is in my address book for some reason or I know the address. Otherwise I have to search for the grocery store in Safari…

It's very easy in Siri: "Remind me to take out the trash when I get home."

Arbitrary locations aren't easy, but the fixed "work" and "home" ones are... and for the purposes of this discussion, they all use the same battery life.

Re: My iOS 7 Wishlist

#153
post #20
post #16

Earlier quoted context omitted.

They aren't push notifications, but client-side notifications that respond to the user's learned habits and situation. I guess some of Google Now's functionality could be offloaded to push, but lots of it is based on the user's location, which isn't available on iOS to an app that isn't open.

User location is available to background iOS applications; Apple includes two APIs specifically for that purpose: fine and course background location updates. The app will be notified whenever the user's location changes, if it's activated or not.

I thought that only worked for apps that were once opened (since the phone last closed) and hadn't yet been killed by iOS's background task management thing?

Re: My iOS 7 Wishlist

#154

Earlier quoted context omitted.

Isn't that what he said?

He's saying he doesn't think Google Now uses much power because it doesn't shown up in the battery statistics, but he also says that GPS shows high usage. I was saying that Android doesn't report an app's usage of GPS etc. as battery usage of that app.

Does Google Now even use GPS? Passive wifi/cell tower location will probably work for almost every feature I can recall.

Re: My iOS 7 Wishlist

#155
post #116

Earlier quoted context omitted.

No, it always has a WiFi or HSPA data connection, and I haven't disabled any of the usual suspects (e.g. syncing or location services). Of course the display is off most of the time, and that's the big battery hog. The screen is on maybe an average of half an hour a day.

That’s a nice trick, making the battery last longer by not using the phone. I’ll try it myself.

shrug. That's my usage pattern. I find it hard to imagine having the screen on for more than that on an average day, even if the phone is in active use more than that (e.g. when listening to podcasts, or taking a GPS trace during a workout). And of course there's the passive use of just having it constantly syncing. With previous Nexus devices just the passive background noise of Android was often enough to use up the battery in a day.

Re: My iOS 7 Wishlist

#156
post #51

I have one wish: that the iOS programmers at Apple learn how to write efficient concurrent code and that they stop leaning on the next, faster, generation processor so hard that any phone that is just one generation older than the leatest and greatest becomes slow as shit. My iPhone used to be fast. Most things used to be snappy. Now it is slow as shit. From the address book lookups (which I have timed to usually clo…

> Apple learn how to write efficient concurrent code Sorry but what ? Apple has one of the best concurrency implementations on ANY platform. GCD is superbly designed and combined with blocks makes concurrency trivial. The biggest problem is that developers often try and over optimise. > which I have timed to usually clock in at 8-9 seconds, but which can take as long as 20 seconds This is definitely not normal. > iOS…

> No. It really isn't.

Then we are observing very different realities. Beginner's mistakes have been evident for years and years in the iTunes (desktop) application where the GUI thread is routinely blocked by anything from network activity to slow disk IO.

With the latest generation of iOS, these problems have started cropping up elsewhere in iOS apps. For instance if you use the podcast app as intended, and download content directly on your iPhone, the UI has a tendency to block on IO operations that should have taken place in the background. The UI will hang and refuse to scroll. Also, the player has become really temperamental -- often refusing to accept volume control inputs via the screen for many seconds after laboriously starting to play a stream.

(And why the hell did Apple have to split up the iPod application in the first place. Now you have iTunes U, which is sluggish and buggy, you have Podcasts, which is sluggish and buggy etc. WHY!?)

Re: My iOS 7 Wishlist

#157
post #84

Earlier quoted context omitted.

No, concurrency is not a silver bullet, but when your programmers consistently make beginner's mistakes the software really sucks. You do NOT allow the UI thread to hang on blocking calls. That's UI programming 101. And Apple engineers are unique in how consistently they fail to follow even this most rudimentary of rules.

Sorry. Have you see the source code of any part of the iOS system? No I don't think you have. Give me some reference to somewhere that the UI thread hangs. Not blocking the UI is taught to everyone who writes apps for the app store, so my assumption is that the guys who wrote the app store code know a little better than we do.

Take a step back, observe what the app does. Whether it blocks on slow system calls or coarse grained locks is irrelevant. The point is, the GUI thread hangs. That isn't supposed to happen. Quite a bit of Apple software does this. This suggests that this is somewhat systemic.

Re: My iOS 7 Wishlist

#158
post #108

Earlier quoted context omitted.

[deleted]

You do understand that this is an app right and not part of iOS. Here's a thought for you. How about using another podcast app ?

I think we can do without the condescending tone. I think most people here are fully capable of distinguishing applications from OS. However, when Apple provide a suite of apps that are shipped with the OS it is reasonable to expect that those apps work.

Re: My iOS 7 Wishlist

#160

Earlier quoted context omitted.

It's getting worse. My Nexus 7 doesn't allow it either, although you can work around it and (use it as a flashdrive at least) by pretending it's a camera. I understand the problem is having a disk mounted by two OSs similtaneously. There is newer protocol called mtp ( http://en.wikipedia.org/wiki/Media_Transfer_Protocol ) that is supposed to be the answer, but it isn't supported by older OSs. Feels like they reinvent…

MTP is a complete trainwreck. The main problem is that the support in Windows is absolutely useless. Copying a big file and want to continue exploring the contents? Nope. Any kind of simultaneous operation will just plain not work. There is a very odd warning if you copy over plain old data like zip files - it tells you that the device might not be able to play the content. You can still copy them over, at crappy spe…

I believe it. Not sure what was wrong with ftp, sshfs, or even a smb lite?
Post reply on HN