iOSAPP升级时文件的留存问题及数据库的迁移

升级要考虑到和前一个版本已经存在的文件之间的兼容问题,可以先用旧工程跑一遍,再用新的跑一遍,看有无问题。这是血的教训!!!切记

在应用程序更新过程中被保存的文件:

更新应用程序就是将用户下载的新版应用程序代替之前的版本。在这个过程中,iTunes会将更新过的应用程序安装到新的应用程序目录下,并在删除老版本之前,将用户数据文件转移到新的应用程序目录下。在更新的过程中,iTunes保证如下目录中的文件会得以保留:

/Documents

/Library/Preferences

虽然其它用户目录下的文件也可能被转移,但是您不应该假定更新之后该文件还仍然存在。

常用目录:

/AppName.app      这是程序包目录,包含应用程序的本身。

/Documents/       您应该将所有的应用程序数据文件写入到这个目录下。这个目录用于存储用户数据或其它应该定期备份的信息。iTunes会备份这个目录的内容。

/Library/Preferences这个目录包含应用程序的偏好设置文件。  iTunes会备份这个目录的内容。

/Library/Caches这个目录用于存放应用程序专用的支持文件,保存应用程序再次启动过程中需要的信息。iTunes不对这个目录的内容进行备份。

/tmp/这个目录用于存放临时文件,保存应用程序再次启动过程中不需要的信息。iTunes不对这个目录的内容进行备份。

App升级时数据库的迁移更新

App 升级时,要考虑到3种情况:

1.App可能会多个账户登录,所以存储账户信息不能用NSUserDefaults要使用数据库来存储;

2.App内如果涉及到一些数据没有和后台数据库交互,但属于每个账户特有的数据(如:帐号,背景皮肤,手势密码等等)App退出登录状态时,存储账户信息的数据库不能清空.

但是,一些App运行时的使用的数据库可以清空(如:某一账户登录后,一些界面的网络数据的本地化数据,在退出登录时可以把这些数据库清空,当此账户再次登录时可以通过网络请求再添加,更新等等);

3.当App升级后,本地的数据库是不会被清空的,也不会有变动,但是升级后可能后台数据库添加了一些字段,而且这些字段影响了参数的传递和UI的展示,我们应该怎么做呢?

我们需要考虑做一个数据库转移模块,然后按如下步奏:

具体思路

1、在新版本程序里面放入全新设计的数据库。

2、用户更新程序后打开程序。

3、通过版本判断之类的功能,运行数据转移模块。把老数据库文件里面的数据全部转移到新数据库文件中。

4、转移完毕就可以了。

需要注意的是,设计的时候,这个转移模块只要运行一次就可以了。

总体方案及思路

流程图

在每一次运行程序的时候,判断是否存在数据库,如果不存在则直接创建数据库,若存在取出数据库版本号进行其他的处理.

,当用户第一次下载安装app的时候,第一次建立版本库,将我们的数据信息存入数据库中,同时保存一个当前版本号加一的字段到数据库中.

那么问题来了,为什么我们需要将版本信息加一呢,这是为了以后进行版本判断的时候更加方便.

还有一个问题,为什么我们将版本信息放入数据库而不使用UserDefaults快速存储呢?原因是你需要考虑到

当你的app有不同的用户登录时,UserDefaults是所有数据共享的,你不能根据不同的用户来处理他的信息

判段他的信息是否需要更新

当用户更新app的时候,会直接从数据库中取出上一次保存的版本字段,例如是2.0版本的时候,会直接从case2开始执行,修改完数据结构以后,再一次将版本字段存到数据库中.

所以每更新一次版本,如果数据结构信息有变动的时候,直接在后面加case语句即可.

下面是一些参考代码,使用FMDB库:

-(instancetype)init

{

//设置数据库版本为1

int dbVersion = 1;

if (self = [super init]) {

//判断本地有没有数据库文件

if (![self isExistDB]) {

//不存在 初始化数据库

[self createDB];

}else

{

//如果存在,那么获取版本信息

_dataBase = [[FMDatabase alloc] initWithPath:[self getDBPath]];

NSString * currentVersion = [self getDBInfoValue];

dbVersion = currentVersion.intValue;

}

switch (dbVersion) {//判断版本信息

case 1:

{

//说明用户第一次安装1.0版本

//创建版本表

[self excuteLocalSql:createTB_info];

//创建信息表

[self excuteLocalSql:create_tusersql];

//保存1.0+1.0信息到数据库用于下一次判断版本号

[self setDBInfoValueWithString:@"2.0"];

}

case 2:

{

//更新信息表

[self excuteLocalSql:update_tusersql];

//保存2.0+1.0到数据库

[self setDBInfoValueWithString:@"3.0"];

}

case 3:

[self excuteLocalSql:modify];

[self setDBInfoValueWithString:@"4.0"];

default:

break;

}

}

return self;

}

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,670评论 5 460
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,928评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,926评论 0 320
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,238评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,112评论 4 356
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,138评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,545评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,232评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,496评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,596评论 2 310
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,369评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,226评论 3 313
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,600评论 3 299
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,906评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,185评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,516评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,721评论 2 335

推荐阅读更多精彩内容