4 ms·
I'm sympathetic to Marco's blog post here, but I wonder if he's failing to interpret the two paragraphs from the documentation within the context of Instapaper'
by pohl 15y ago
I'm sympathetic to Marco's blog post here, but I wonder if he's failing to interpret the two paragraphs from the documentation within the context of Instapaper's purpose.
With respect to point #1, and in the context of what Instapaper is for, the user is intending to read an article offline, and the local copy of the article was generated by the user's intent (and can, therefore, be considered user-generated even though the user is not the author of the article.)
With respect to point #2, the articles fail the "can be downloaded again" test in light of the app's purpose of making the articles available to the user when the network is not available. When the network is unavailable, the articles cannot be downloaded again. Edit: JeffDClark makes another excellent point here that the article may have originally been behind a paywall and therefore cannot be guaranteed to be re-downloadable. The same is true if the author removed the original article from their webserver.
Ergo, put them in the Documents folder. Whether this would satisfy the app reviewer is another question, but it's worth a shot to carefully explain to them how your app is not violating the letter of the law.
- rcthompson 15y agoBut it doesn't make sense to back this data up to iCloud, which is what happens to the Documents folder.
- pohl 15y agoReally? If I generate an offline copy of an article on my phone, wouldn't I want to have access to it on my iPad? Why wouldn't I want the truth to be in the cloud?
- Mavrik 15y agoBecause there's no point in burning your cloud storage, Apple bandwidth and prolong backup times when those articles can be easly re-downloaded from Instapapers servers on iPad. Same result, without long backup times, Apple server bandwidth usage and your iCloud storage usage.
- pohl 15y ago...when those articles can be easly re-downloaded from Instapapers servers... My premise, in point #2, is that this actually isn't the case with respect to Instapaper's raison d'être. In fact, that's sort of the premise behind much of Marco's post too.
- masklinn 15y ago> when those articles can be easly re-downloaded from Instapapers servers on iPad. That's kind-of the issue though, is it not? One of Instapaper's strength is that it provides for reading in a nicely formatted and offline way. You don't need a connection to go through your IP stack, unless iOS has decided to clean out everything.
- sbov 15y agoYou're quoting that out of context. His point is, if you back it up to iCloud, to get any use out of the backup, you need to be online. Therefore it's a waste, because in that scenario, you can just download it from Instapaper anyways.
- mynegation 15y agoWhy there is no point in burning Apple's bandwidth, but there is a point in burning Instapaper servers' bandwidth? I don't care how Apple (or Marco) solves the problem, but I sure do not want to lose Instapaper articles at random.
- modeless 15y agoIt's not just Apple's bandwidth; it's users' iCloud storage, which costs users money.
- statictype 15y agoThe user can always choose not to sync Instapaper if he feels its costing him storage (though in reality, I have to wonder how much storage simple articles with occasional images could really take). I think that has to be the best solution. It's far better to just have everything sync to iCloud and let the user choose to disable it rather than having Instapaper's primary core functionality - being able to read articles offline - not work properly.
- roc 15y agoI took the original suggestion as a practical solution to make the best of the current situation. It doesn't make sense to potentially have a redundant backup, but it makes for a better user experience than disappearing articles.
- coob 15y agoSay I have a multimedia app that downloads assets. I don't want to see them randomly disappear or have them backup to iCloud. Where should they go?