App版本的更新

app 版本更新

当你发布一个App到App Store上去，几天之后，用户发现了BUG，这时候，你需要修改程序重新发布到App Store，然后让用户从当前安装的版本更新到你修改过的最新版本，如果用户采取的是Update方式更新程序，而不是先删除本地再安装，这就存在几个问题。一是：如果你在手机端用到了缓存程序，而恰好你修改的程序和当前缓存文件的格式冲突怎么办？（如：修改后的程序解析当前缓存文件时报错），二是：如果你修改过的程序与当前手机端应用已经建好的Sqlite数据库表冲突怎么办？（如：修改后的程序需要增加字段或者修改字段，或者需要增加表），三是：如果你的云端Servlet方法需要修改或者增加怎么办？（如：云端Servlet需要修改方法，或者当前旧的方法不能满足新的应用了，需要新增）。
      关于第一个问题：缓存。
      由于缓存文件的作用就是提高用户体验，所以说，从某种意义上来说，程序版本升级时，缓存文件可以抛弃的。解决方案是，在缓存目录doc下，按照版本号建立多个文件夹，如：FolderVer1，FolderVer2，FolderVer3。。。1版本程序使用FolderVer1存储缓存文件，2版本程序使用FolderVer2存储缓存文件。当程序从1升级到N的时候，只是新建一个缓存文件夹FolderVerN，旧的FolderVer1文件夹以及其中的数据就不用管它了，让用户想清理缓存的时候自己去手动清理，注意：我们不要试图去用程序清理这个文件夹，因为在清理的时候可能耗时，大大降低了用户体验。

      关于第二个问题：Sqlite数据库需要改变。
      假设你的应用程序在之后会更新5次（5次的可能性比较小，可能是100+次），这样的话，你将面对的现实就是：多种版本的程序共存，你不知道正在从AppStore上更新应用的用户是哪个版本。

解决方案是：使用增量的方式更新，写好 V1-->V2的SQL脚本S12，V2-->V3的SQL脚本S23，V3-->V4的SQL脚本S34，V4-->V5的SQL脚本S45，这样的话，如果用户是从版本2更新到版本5，则需要执行：S23+S34+S45，如果用户是需要从版本4更新到版本5，则只需要执行S45，从版本2更新到版本4，则只需要执行S23+S34。

     关于第三个问题：云端API升级改变。
     这种情况，我们本着一个原则就是，绝对不能去动就的方法，因为总是有用户在使用旧的版本（不要祈求每个用户都更新到最新版本），而是通过增加新方法来为新版本使用。
     这样的话，云端Servlet中可能有 1： getNewList(String param1, String param2)方法，和2： getNewList(String param1, String param2, String param3)方法，可以让2去调用1， 然后再增加一些自己的新增业务逻辑。