This isn't just "the people that work next to me".
I'm not about to tell all the third party APIs I use daily that their REST api's aren't REST. It's too much work.
Here is what you originally said:
When I hear a colleague say REST it usually means what you have in your example. So much so, that it would take to much time and effort to correct everyone.
We weren't talking about the whole world fucking up, we were talking about your colleagues not knowing what they were talking about. To which my response is: tell them they are fucking up so they can stop fucking up. "I can't change the world" isn't a response to that.
I didn't read his thesis at the time.
Again, this is what you originally said:
I remember reading Fielding's blogs and work when REST was becoming a popular term. The idea of hypertext links was not as prevelent. It was there with some mention to atom rss and the likes
If it mentioned Atom, then you're talking about years after he published his thesis. You say you remember reading his work, but you clearly didn't read it despite it being available at the time. Just some nebulous "blogs" (that couldn't have existed because he didn't start blogging until years afterwards).
I remember reading Fielding's blogs and work when REST was becoming a popular term. The idea of hypertext links was not as prevelent. It was there with some mention to atom rss and the likes, but it wasn't the main point of REST.
Hypermedia as the engine of application state is listed as one of the four fundamental constraints of REST in his thesis. It's a central part of REST. It wasn't retrofitted later. If you missed it, you weren't paying attention. REST is essentially a description of the architectural style of the WWW. And you're saying that the idea of hypertext links wasn't prevalent from the start? What WWW have you been using?
When I hear a colleague say REST it usually means what you have in your example.
Then you work with people who don't know what they are talking about. You can either point that out to them so that they can fix their ignorance, or you can let them labour under the misapprehension that they know what they are doing. Do them a favour and point it out to them. Or at the very least, ask whomever is in charge of documentation not to refer to it as REST.
REST is not some nebulous term where you can argue your case. It's got a specific meaning. Mislabelling any old HTTP web service as REST is like confusing Java with JavaScript - something nobody who claims to know what they are talking about should be mixing up.
If you look at that API and you think it's REST, then you don't know what REST is. Here's Roy Fielding's blog post where he points out that these types of APIs aren't REST. Roy Fielding is the guy that described this architectural style and coined the term "REST" in the first place.
Here's one example: You perform a GET request at/vehicles to obtain a list of vehicles. These vehicles take the form of JSON data, including an id attribute. If you want to perform operations on a vehicle, you need to construct URLs of the form/vehicles/{id}/.... That is not REST.
REST is hypertext driven. It revolves around content types, not manual URI construction. If that were a RESTful API, it would describe a vehicle list media type, and that media type would contain URIs, not IDs that you have to construct new URIs from using out of band knowledge. Their approach is like if every web browser was hard-coded to find articles at/articles instead of using links. It's dumb.
This misunderstanding is far too common. Don't guess at what REST is when you construct an API like these guys did, look it up for yourself.
This just reinforces what I said the other day about Apple's App Store approval process really making a difference to the quality of the applications available for iOS.
Apple have a rule in their guidelines:
2.20 Developers "spamming" the App Store with many versions of similar Apps will be removed from the iOS Developer Program
I remember getting same-day delivery on books from Amazon UK in 2008. At the time it was only Birmingham and London areas that they did it in, but now it looks like they service more areas.
Granted, perhaps some of the things it does it shouldn't have access to (e.g., contacts and such), but that's something that's changing in iOS7 anyways.
Apple already prompts the user for address book access in iOS 6. iOS 7 adds camera and microphone I think.
Then why not allow outside markets and advertise theirs as the premium one?
I'm responding to what you said here:
Either way security problems will exist and pretending that their app auditing is anything more than a justification for a walled garden is simply burying your head in the sand.
You were arguing that the promotion of a walled garden was the sole purpose for the approval process for the App Store. That's a silly thing to say, and I explained why. You've now changed your argument to something else - that Apple are enforcing the App Store as the sole source of applications to build a walled garden. That's a different argument entirely, and doesn't make what you said earlier any less silly.
Either way security problems will exist and pretending that their app auditing is anything more than a justification for a walled garden is simply burying your head in the sand.
The walled garden is probably one reason for the approval process, but it's certainly not the only one. Apple seem genuinely motivated to use it to raise the quality of the end-user experience.
Here's one example: a few years ago, developers were complaining that Apple was rejecting their apps for having an icon of a phone in their app. It didn't make sense - why would Apple object to that? It wasn't an icon depicting a competing phone. It wasn't infringing on their trademarks or copyrights. People couldn't figure it out.
Then, a short while after, the iPad was released, which could run iPhone apps too. Suddenly, that restriction made sense. Apple wanted the designs to make sense for people using iPads as well. Is it a bit of a control-freak thing to do? Sure. But there's no reason to do stuff like that unless it's to improve the end-user experience.
Here's another example: Using undocumented APIs. A lot of people point to this as evidence that Apple are hobbling apps, artificially limiting their functionality. But any developer will tell you that people using non-public APIs is a nightmare for forwards compatibility. As soon as there's applications in the wild using an API, you'll have to make the choice between supporting it, unchanged, for eternity, or breaking things for users. Ask Microsoft- they've still got a tonne of backwards compatibility code in Windows because sometime in the early 90s, applications rooted out private APIs and depended on them to function.
How about another example: I've had an application rejected for giving a misleading error message. If somebody was trying to log in and their Internet connection wasn't up, it told them their username and password was wrong instead of telling them to check their connection. A dumb bug, but one that could confuse end users.
It doesn't really make sense for Apple to invest in this approval process, and piss off developers, and slow the whole thing down to a crawl if this is just a pretext for having a walled garden. Apple aren't shy about being control freaks. If it was just about being a walled garden, they'd say so, they are shameless about it.
Sometimes the simplest explanation is the right one - Apple have an approval process that rejects applications on quality and UX grounds because they want to ensure the quality of applications on the App Store. They might also have other motivations as well, but there's no reason to believe that that one is anything other than genuine.
Every single one of those, requires permission from the user to do - posting tweets an app cannot do directly, it brings up a sheet.
Read the paper - they watched the interaction in a debugger to find the right messages to send to the right private classes in order to bypass this.
This only worked with iOS 5 - last year Apple moved sheets like these into external processes and used a proxy view controller to show them in applications instead of embedding the functionality directly, so attacks like this aren't possible any more where this technique has been used.
I agree that this is somewhat sensationalised, but they were able to do this without the normal user approval in the 4% or so of people still running a two year old version of iOS.
I'm an iOS developer, and the approval process can be a real problem for me sometimes, but I still think the App Store is far better with it than without it.
I've seen a lot of clients ask for dumb stuff. Using UI elements in confusing ways. Doing user-abusive stuff. Being generally annoying and self-serving rather than being designed with the user's best interests as a goal.
The great thing about the approval process is that I can tell those clients "Apple won't allow it" and it instantly shuts them up. The alternative would be hours of trying to convince them not to do something horrible, which leaves everybody unhappy no matter what decision is made. And this is the best case scenario, when you've got a developer willing to go to bat for the users. There's plenty of developers out there who will blindly do whatever the client asks, no matter how shitty it makes the UX.
It's not just bad decisions. It's QA as well. Do you have any idea how keen people are to just push stuff live and then fix it after? I don't know about you, but I don't want a dozen updates every morning as developers meddle with their apps trying to get things right. The approval process gives developers the stick necessary to perform proper QA. We don't dare push anything live if there's the possibility of a crasher, because Apple will reject it and we have to wait another week to get reviewed again.
If the approval process wasn't there, then the quality of the apps on the App Store would plummet. You think it's bad with Android, but Android doesn't attract the worst kinds of ambulance chasers. The App Store would be 75% Geocities level quality in no time at all.
What I do disagree with is making the App Store the only way to get applications onto the device. There's really no legitimate reason for not allowing side-loading for people willing to go into settings and agree to a disclaimer.
For the most part, yes, but not in the way you think. Objective-C is a very dynamic language. It's not really about sandboxing - apps can't modify their own code. What they can do is include components that do fairly generic, innocuous things, then take external input and construct messages to those existing components on the fly based on that input.
If your battery was great until a software update, then the problem probably isn't the battery but the software, and replacing the battery won't solve your problem.
Developers are, for the first time in the history of free software, helping inform each other about licensing and aiding in the selection process
Huh? In the 17-odd years I've been using Free Software, I've never known there not to be an ongoing public discussion amongst developers about licensing.
the brief window when I could have got a beta dev version
I'm a developer who signed up in that window to get a beta dev version, and they've failed to do that even. They've sent me some generic marketing emails, but nothing that would help me actually get my hands on a device. Totally lost interest now. If they can't even figure out how to deliver the goods, chances are it's not going to be a great product.
Stores already have barcode scanners at every POS, and with a little software they can easily interact with non-NFC smartphones that display loyalty info on the screen.
Depends on the type of scanner. Laser scanners are widespread and don't work well with phone screens.
Actually, when Jobs announced the iPhone for the first time, in the keynote he made a point of telling everybody that it ran OS X and had desktop-class applications.
In context of the mobile operating systems and mobile apps that came before the iPhone, it's easy to see why he'd say that, but it wasn't quite true. The difference between what they did and what Microsoft did is that they recognised iPhoneOS and OS X had different, mutually exclusive design goals, and acted on that understanding, whereas Ballmer demanded "no compromises" for the mobile version of Windows.
If the vendor picked the option of giving you the source code along with the binaries they can be argued to both be part of one piece of software.
No, that's not the case, and the GPL isn't written that way. The source and binary forms are treated individually and where distribution together is mentioned, the GPL describes the source form as accompanying the binary form, not being a part of it. If one thing accompanies another, they are by definition distinct from one another.
They can't. The organisation I bought the machine from is only compelled by the GPL to provide source code to the person they distributed the binaries to, i.e. me.
This is not true. The GPL requires that the offer is made to "any third party".
Not really. You are quoting "any third party", so I assume you are talking about GPLv2. Here's the relevant section from that license:
You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
[...]
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
When the vendor distributes the machine to me, they are compelled to provide the written offer to me. I am not compelled to give this written offer to anybody I might sell the machine to.
I think you might have misread my comment. Why are you talking about redownloading the software to put it on a new machine? I am buying the machine with the software preinstalled. I'm not downloading or installing anything.
Because you can get around the GPL once that way. It is not really a hole worth being concerned about.
Once? People can buy machines in bulk. Are you missing the relevance to the story here? Consider what happens if a company like Fantec contract an external organisation to install GPLed software on their components before reselling them.
Generally you are only allowed to pass on the entire software or none at all, not to modify it by only providing parts.
In the scenario I described, I'm not modifying anything.
Either the source code came with the software, in which case it could be argued that you have to transfer both binaries and source code in order to comply with copyright
Why would I be compelled to transfer source code to anybody? The only thing that would require me to do so is the GPL. I don't have to agree to the terms of the GPL because I'm not making any copies of the software.
The GPL is a license that allows you to do things that would otherwise be covered by copyright in exchange for you agreeing to do certain other things. In this scenario, I'm not doing anything that is covered by copyright. There's no reason for me to agree to the GPL.
In the latter case the person you sold it to can just go directly to whoever made the written offer.
They can't. The organisation I bought the machine from is only compelled by the GPL to provide source code to the person they distributed the binaries to, i.e. me.
All they can do is alert the copyright holder(s) of the license violation and hope that the copyright holder(s) care.
What license violation? The vendor is complying with the terms of the license by providing source to me if I ask for it, and I don't have to agree to the license, so I'm not violating it.
Even if you manage to circumvent the GPL this way, it is rather inefficient. You have to redownload the software every time you put it on a new machine, otherwise you're copying it. If you make scripts to do it for you, you are likely to end up modifying the software, which triggers copyright.
I think you might have misread my comment. Why are you talking about redownloading the software to put it on a new machine? I am buying the machine with the software preinstalled. I'm not downloading or installing anything.
If modification takes place, it will be the vendor I am buying from that does the modification, and that vendor is only compelled to provide source code to me.
Under very few legal codes is it OK to distribute something that you do not have the appropriate copyright/licence.
Distribution is fine. It's copying that is restricted by copyright.
For example, I can go and buy a game in a box from a shop. I then give you that game. I'm distributing the game, but I am not copying it. Copyright doesn't stop me because copyright is for copying, not distribution.
Why does that matter? Well consider this: what happens when I buy a machine with GPL software preinstalled on it by the vendor? I have the right to ask for the source code, right? Well what happens when I sell that machine to somebody else? I never had to agree to the GPL because I never made any copies of the software. I'm not obligated to follow the terms of the GPL. Does the person I sold the machine to have any right to ask me for source code? Why?
Huh? This is a phone we are talking about, not a tablet. It's got a perfectly reasonable screen size. Any larger, and I'd have a problem fitting it in my pocket. Screen size is not a good way of judging a mobile phone, especially if you think bigger is better.
When I buy an eBook, I do not own the book. In order to read the book, I have to hope that some DRM server somewhere will authorize the eBook reader to show me the book I want to read.
That's only true of some ebook publishers. For instance, I've bought a lot of ebooks from O'Reilly. You get DRM-free files in multiple formats that you can do what you like with.
If you've bought an ebook that has to ask for permission before letting you read it, you bought from a bad publisher. It's not a problem inherent to e-books.
I have books on my book shelves that are over 50 years old, and I can still read them fine
I've got decades-old physical books that I can't read. Why? Well I had to get rid of a load of them because they were simply taking up too much space. And the ones I've kept, I can't read them when I'm abroad, when I'm commuting, or pretty much anywhere except my house, because it's not feasible to bring all my books with me every time I leave the house.
What those APIs return is directly related to the users choice- for example, if the user says "no" when the application attempts to determine your location via Core Location, then the CL APIs will still work- they'll just return useless information (basically hardcoded to nothing). The other APIs work in the same way.
No, that's not true. iOS tells the application when something is unauthorised. For example, you can call [CLLocationManager authorizationStatus] at any point, and if you ask for the user's location and get denied, it sends your delegate a locationManager:didFailWithError: message saying that the user denied the request. The same is true for other APIs. You don't get fed bad data.
Slashdot Mirror
Here is what you originally said:
We weren't talking about the whole world fucking up, we were talking about your colleagues not knowing what they were talking about. To which my response is: tell them they are fucking up so they can stop fucking up. "I can't change the world" isn't a response to that.
Again, this is what you originally said:
If it mentioned Atom, then you're talking about years after he published his thesis. You say you remember reading his work, but you clearly didn't read it despite it being available at the time. Just some nebulous "blogs" (that couldn't have existed because he didn't start blogging until years afterwards).
Hypermedia as the engine of application state is listed as one of the four fundamental constraints of REST in his thesis. It's a central part of REST. It wasn't retrofitted later. If you missed it, you weren't paying attention. REST is essentially a description of the architectural style of the WWW. And you're saying that the idea of hypertext links wasn't prevalent from the start? What WWW have you been using?
Then you work with people who don't know what they are talking about. You can either point that out to them so that they can fix their ignorance, or you can let them labour under the misapprehension that they know what they are doing. Do them a favour and point it out to them. Or at the very least, ask whomever is in charge of documentation not to refer to it as REST.
REST is not some nebulous term where you can argue your case. It's got a specific meaning. Mislabelling any old HTTP web service as REST is like confusing Java with JavaScript - something nobody who claims to know what they are talking about should be mixing up.
If you look at that API and you think it's REST, then you don't know what REST is. Here's Roy Fielding's blog post where he points out that these types of APIs aren't REST. Roy Fielding is the guy that described this architectural style and coined the term "REST" in the first place.
Here's one example: You perform a GET request at /vehicles to obtain a list of vehicles. These vehicles take the form of JSON data, including an id attribute. If you want to perform operations on a vehicle, you need to construct URLs of the form /vehicles/{id}/.... That is not REST.
REST is hypertext driven. It revolves around content types, not manual URI construction. If that were a RESTful API, it would describe a vehicle list media type, and that media type would contain URIs, not IDs that you have to construct new URIs from using out of band knowledge. Their approach is like if every web browser was hard-coded to find articles at /articles instead of using links. It's dumb.
This misunderstanding is far too common. Don't guess at what REST is when you construct an API like these guys did, look it up for yourself.
This just reinforces what I said the other day about Apple's App Store approval process really making a difference to the quality of the applications available for iOS.
Apple have a rule in their guidelines:
I remember getting same-day delivery on books from Amazon UK in 2008. At the time it was only Birmingham and London areas that they did it in, but now it looks like they service more areas.
Apple already prompts the user for address book access in iOS 6. iOS 7 adds camera and microphone I think.
I'm responding to what you said here:
You were arguing that the promotion of a walled garden was the sole purpose for the approval process for the App Store. That's a silly thing to say, and I explained why. You've now changed your argument to something else - that Apple are enforcing the App Store as the sole source of applications to build a walled garden. That's a different argument entirely, and doesn't make what you said earlier any less silly.
The walled garden is probably one reason for the approval process, but it's certainly not the only one. Apple seem genuinely motivated to use it to raise the quality of the end-user experience.
Here's one example: a few years ago, developers were complaining that Apple was rejecting their apps for having an icon of a phone in their app. It didn't make sense - why would Apple object to that? It wasn't an icon depicting a competing phone. It wasn't infringing on their trademarks or copyrights. People couldn't figure it out.
Then, a short while after, the iPad was released, which could run iPhone apps too. Suddenly, that restriction made sense. Apple wanted the designs to make sense for people using iPads as well. Is it a bit of a control-freak thing to do? Sure. But there's no reason to do stuff like that unless it's to improve the end-user experience.
Here's another example: Using undocumented APIs. A lot of people point to this as evidence that Apple are hobbling apps, artificially limiting their functionality. But any developer will tell you that people using non-public APIs is a nightmare for forwards compatibility. As soon as there's applications in the wild using an API, you'll have to make the choice between supporting it, unchanged, for eternity, or breaking things for users. Ask Microsoft- they've still got a tonne of backwards compatibility code in Windows because sometime in the early 90s, applications rooted out private APIs and depended on them to function.
How about another example: I've had an application rejected for giving a misleading error message. If somebody was trying to log in and their Internet connection wasn't up, it told them their username and password was wrong instead of telling them to check their connection. A dumb bug, but one that could confuse end users.
It doesn't really make sense for Apple to invest in this approval process, and piss off developers, and slow the whole thing down to a crawl if this is just a pretext for having a walled garden. Apple aren't shy about being control freaks. If it was just about being a walled garden, they'd say so, they are shameless about it.
Sometimes the simplest explanation is the right one - Apple have an approval process that rejects applications on quality and UX grounds because they want to ensure the quality of applications on the App Store. They might also have other motivations as well, but there's no reason to believe that that one is anything other than genuine.
Read the paper - they watched the interaction in a debugger to find the right messages to send to the right private classes in order to bypass this.
This only worked with iOS 5 - last year Apple moved sheets like these into external processes and used a proxy view controller to show them in applications instead of embedding the functionality directly, so attacks like this aren't possible any more where this technique has been used.
I agree that this is somewhat sensationalised, but they were able to do this without the normal user approval in the 4% or so of people still running a two year old version of iOS.
I'm an iOS developer, and the approval process can be a real problem for me sometimes, but I still think the App Store is far better with it than without it.
I've seen a lot of clients ask for dumb stuff. Using UI elements in confusing ways. Doing user-abusive stuff. Being generally annoying and self-serving rather than being designed with the user's best interests as a goal.
The great thing about the approval process is that I can tell those clients "Apple won't allow it" and it instantly shuts them up. The alternative would be hours of trying to convince them not to do something horrible, which leaves everybody unhappy no matter what decision is made. And this is the best case scenario, when you've got a developer willing to go to bat for the users. There's plenty of developers out there who will blindly do whatever the client asks, no matter how shitty it makes the UX.
It's not just bad decisions. It's QA as well. Do you have any idea how keen people are to just push stuff live and then fix it after? I don't know about you, but I don't want a dozen updates every morning as developers meddle with their apps trying to get things right. The approval process gives developers the stick necessary to perform proper QA. We don't dare push anything live if there's the possibility of a crasher, because Apple will reject it and we have to wait another week to get reviewed again.
If the approval process wasn't there, then the quality of the apps on the App Store would plummet. You think it's bad with Android, but Android doesn't attract the worst kinds of ambulance chasers. The App Store would be 75% Geocities level quality in no time at all.
What I do disagree with is making the App Store the only way to get applications onto the device. There's really no legitimate reason for not allowing side-loading for people willing to go into settings and agree to a disclaimer.
For the most part, yes, but not in the way you think. Objective-C is a very dynamic language. It's not really about sandboxing - apps can't modify their own code. What they can do is include components that do fairly generic, innocuous things, then take external input and construct messages to those existing components on the fly based on that input.
I would expect from the context of the rest of the sentence, that it's 15m devices on the Internet with UPnP.
If your battery was great until a software update, then the problem probably isn't the battery but the software, and replacing the battery won't solve your problem.
Huh? In the 17-odd years I've been using Free Software, I've never known there not to be an ongoing public discussion amongst developers about licensing.
I'm a developer who signed up in that window to get a beta dev version, and they've failed to do that even. They've sent me some generic marketing emails, but nothing that would help me actually get my hands on a device. Totally lost interest now. If they can't even figure out how to deliver the goods, chances are it's not going to be a great product.
Depends on the type of scanner. Laser scanners are widespread and don't work well with phone screens.
Actually, when Jobs announced the iPhone for the first time, in the keynote he made a point of telling everybody that it ran OS X and had desktop-class applications.
In context of the mobile operating systems and mobile apps that came before the iPhone, it's easy to see why he'd say that, but it wasn't quite true. The difference between what they did and what Microsoft did is that they recognised iPhoneOS and OS X had different, mutually exclusive design goals, and acted on that understanding, whereas Ballmer demanded "no compromises" for the mobile version of Windows.
No, that's not the case, and the GPL isn't written that way. The source and binary forms are treated individually and where distribution together is mentioned, the GPL describes the source form as accompanying the binary form, not being a part of it. If one thing accompanies another, they are by definition distinct from one another.
Not really. You are quoting "any third party", so I assume you are talking about GPLv2. Here's the relevant section from that license:
When the vendor distributes the machine to me, they are compelled to provide the written offer to me. I am not compelled to give this written offer to anybody I might sell the machine to.
Once? People can buy machines in bulk. Are you missing the relevance to the story here? Consider what happens if a company like Fantec contract an external organisation to install GPLed software on their components before reselling them.
In the scenario I described, I'm not modifying anything.
Why would I be compelled to transfer source code to anybody? The only thing that would require me to do so is the GPL. I don't have to agree to the terms of the GPL because I'm not making any copies of the software.
The GPL is a license that allows you to do things that would otherwise be covered by copyright in exchange for you agreeing to do certain other things. In this scenario, I'm not doing anything that is covered by copyright. There's no reason for me to agree to the GPL.
They can't. The organisation I bought the machine from is only compelled by the GPL to provide source code to the person they distributed the binaries to, i.e. me.
What license violation? The vendor is complying with the terms of the license by providing source to me if I ask for it, and I don't have to agree to the license, so I'm not violating it.
I think you might have misread my comment. Why are you talking about redownloading the software to put it on a new machine? I am buying the machine with the software preinstalled. I'm not downloading or installing anything.
If modification takes place, it will be the vendor I am buying from that does the modification, and that vendor is only compelled to provide source code to me.
Distribution is fine. It's copying that is restricted by copyright.
For example, I can go and buy a game in a box from a shop. I then give you that game. I'm distributing the game, but I am not copying it. Copyright doesn't stop me because copyright is for copying, not distribution.
Why does that matter? Well consider this: what happens when I buy a machine with GPL software preinstalled on it by the vendor? I have the right to ask for the source code, right? Well what happens when I sell that machine to somebody else? I never had to agree to the GPL because I never made any copies of the software. I'm not obligated to follow the terms of the GPL. Does the person I sold the machine to have any right to ask me for source code? Why?
Huh? This is a phone we are talking about, not a tablet. It's got a perfectly reasonable screen size. Any larger, and I'd have a problem fitting it in my pocket. Screen size is not a good way of judging a mobile phone, especially if you think bigger is better.
That's only true of some ebook publishers. For instance, I've bought a lot of ebooks from O'Reilly. You get DRM-free files in multiple formats that you can do what you like with.
If you've bought an ebook that has to ask for permission before letting you read it, you bought from a bad publisher. It's not a problem inherent to e-books.
I've got decades-old physical books that I can't read. Why? Well I had to get rid of a load of them because they were simply taking up too much space. And the ones I've kept, I can't read them when I'm abroad, when I'm commuting, or pretty much anywhere except my house, because it's not feasible to bring all my books with me every time I leave the house.
Also, applications cannot pester the user in this way. After two rejections, the requests for user location data is automatically denied.
Apple reject applications that do things like that.
No, that's not true. iOS tells the application when something is unauthorised. For example, you can call [CLLocationManager authorizationStatus] at any point, and if you ask for the user's location and get denied, it sends your delegate a locationManager:didFailWithError: message saying that the user denied the request. The same is true for other APIs. You don't get fed bad data.