OneDrive无法添加分类

如果你是从旧版本(V1)直升新版本,请尝试在做好数据备份的情况下卸载并重装应用。

OneDrive添加订阅源出错

  1. 如果是订阅源添加失败,请参照[无法添加指定的订阅源](#无法添加指定的订阅源)
  2. 如果应用左上角提醒数据损坏,请打开设置->RSS服务设置,找到OneDrive的栏位,点击检查数据完整性按钮,检查完毕后重启应用
  3. 如果第二步仍不能解决问题,请打开OneDrive,进入应用文件夹,找到RSS Stalker文件夹,删除其中的内容,并重新安装应用

无法添加指定的订阅源

可能造成该问题的原因不少,归结如下:

  1. 订阅源需翻墙。
    这是最为常见的原因,比如RssHub等订阅源地址,在国内已被屏蔽,需要翻墙才能获取,应用无法提供内置的翻墙工具
  2. 订阅源失效
    时移世易,以前有用的订阅源,后来可能渐渐无人维护导致失效
  3. 订阅源需要验证
    对于一些特殊的订阅源,比如经过服务转化的公众号等,可能会需要进行特殊的验证,这一点应用暂不提供支持
  4. 不是订阅源
    请注意所谓订阅源地址,返回的数据是XML结构,不是HTML网页,不要把随便把网址当订阅源地址,谢谢

总的来说,碰上无法添加的订阅源,请先将订阅源地址复制到浏览器地址栏中进行访问,如果能得到数据,再考虑BUG问题。

在报告问题时,请将无法添加的订阅源地址附上。

能否添加以上/以下设置为已读

能不能添加非我所能决定,要看对应的RSS服务是否支持。

我知道Inoreader、Feedly等服务都提供了相应的功能,但他们并没有公开对应的API,所以应用无法进行相应的操作

支持的RSS服务中,只有NewsBlur提供了对应的API,所以NewsBlur支持设置以上/以下设置为已读

无法打开OneDrive授权/OneDrive授权时应用闪退

该问题基本发生在ARM64的设备(比如Surface Pro X)上,可以推断的是与目前应用所使用的验证框架有关(官方的验证框架不支持那可真是太生草了,不愧是你啊巨硬)。

具体的解决方案,要么是等待我以后有闲钱买台ARM64的设备进行测试,要么等微软注意到这个问题并修复。

如果你不是ARM64平台却出现了类似的问题,请优先检查网络可用性,或者更换手机热点等进行尝试(关闭一些奇怪的加速器)

Feedly授权失败

目前应用采用用户手动生成开发者令牌的方式进行授权,授权过程如下:

打开[授权网页](https://feedly.com/v3/auth/dev)->登录->Feedly发送邮件至邮箱->在邮箱中打开授权邮件->取得Token

请检查你的步骤,不要把第三步中的UserId当成Token填进授权文本框里了。

另外,通过这种方式生成的Token是有时间限制的,为期一月,到期后需要重新生成

能不能使用用户名/密码的方式进行Feedly授权

抱歉,不可以。

Feedly严格限制新应用的接入,新应用需要进行申请。我尝试申请,但被拒绝,理由是尽管看起来UI不错,但并没有特别创新的地方。

因为申请被拒,所以无法拿到通行证,也就不能进行常规的OAuth授权。现在的开发者令牌是不得已的选择。

OneDrive订阅源不显示未读计数了

V1版本中,订阅源显示未读计数的基础是在应用启动时请求了所有订阅源的内容。这个对资源的消耗挺大的,但是V1只接入了OneDrive,所以没得选。

现在新版本接入了更多的RSS服务,这些服务通常都提供显示未读计数的接口,那就不必再让OneDrive承担这种事情了,所以OneDrive模式不会在应用启动时请求全部的订阅源。

如果要让OneDrive显示未读计数需要满足两个条件:

  1. 在设置中打开自动缓存(15分钟缓存一次)
  2. 已经有缓存的情况下会显示未读计数

阅读全文请求失败

应用内置的阅读全文虽然能满足大多数情况下的需求,但是对以下订阅源无能为力:

  1. 需要特殊权限验证的网页(有比较严格的反扒限制,比如微博)
  2. 对内容进行保护的网页(比如infoQ)
  3. 后加载式网页,即在网页渲染完成后,通过js请求数据填充网页内容

对于这些网页,既然人家态度摆在那里,那还是打开浏览器访问吧。

阅读全文按钮能不能放在一级菜单

我再重申一遍,单独的阅读全文不是一个常用功能。

对于全都是摘要的订阅源,请右键订阅源,将其加入全文列表,这样在打开该订阅源的文章时,会自动请求网页原文。

其它的情况都只是特例,完全没必要把阅读全文加进一级菜单

应用的更新频率

经过近两年时间的应用开发,我比较能接受的更新频率如下:

  1. 先进行内测,在内测期间修复bug,提升稳定性,并添加新的功能
  2. 应用正式发布后的一个月视作公测期,以修复问题为主,适当添加新的功能,这段时间的更新会比较频繁
  3. 之后的一个月到三个月时间是一段维护期,如无必要,不再添加新的功能,更新频率大概是一周到两周发布一次稳定性更新
  4. 在应用趋于稳定之后,会降低对该项目的关注度,转而处理我的其它项目
  5. 如果应用面对的使用场景有了较为巨大的变化,或者我的UI能力/编程能力有了较大的提升,会重制软件,然后继续进行这样的循环。