小编Sta*_*ich的帖子

策略模式和委托模式(不是委托)之间有什么区别？

我一直在努力隐藏footerview.我的问题是,当我单击按钮时,我在页脚中有一个按钮,下面将添加一个部分作为最后一部分,按钮也将转移到新创建的部分,现在我想隐藏表格上一部分中的页脚更新部分后.

footerView.hidden = YES

我在按钮动作中使用了它,但它不起作用.

我有一个适用于iPad的现成企业(非AppStore)遗留iOS应用程序,我需要重构(它是由另一个开发人员,我的前任在我目前的工作中编写的).

此应用程序通过JSON从具有MSSQL数据库的服务器获取其数据.数据库模式有大约30个表,最广泛的是:客户端,城市,代理每个都有大约10,000个记录,并且预计将来会进一步增长.收到JSON后(每个表的一个JSON请求和响应对) - 它被映射到CoreData - 该过程还包括将相应的CoreData实体(客户端,城市,代理和其他)相互粘合在一起,即在CoreData层上设置这些实体之间的关系.

本项目的CoreData fetch-part(或读取部分)本身已经过大量优化 - 我猜,它使用了几乎所有可能的性能和内存调整CoreData,这就是为什么UI层的应用程序非常快速和响应,所以我认为其工作完全令人满意和充分.

问题是准备CoreData层的过程,即服务器到客户端的同步过程:它需要花费太多时间.考虑30个网络请求,产生30个JSON包("pack"我的意思是"一个表 - 一个JSON"),然后映射到30个CoreData实体,然后将它们粘合在一起(在它们之间设置适当的CoreData关系).当我第一次看到在这个项目中完成所有这些工作(太慢)时,我想到的第一个想法是:

"第一次执行完全同步(应用程序的第一次启动时间) - 在一个存档文件(例如数据库转储)中执行整个数据库数据的获取,然后以某种方式将其作为整体导入到核心数据土地".

但后来我意识到,即使这样的单文件转储的传输是可能的,CoreData仍然需要我执行相应的CoreData实体的粘合来设置它们之间的适当关系,以便很难想象我能够如果我依赖这个计划,我会在表现上受益.

另外,我的同事建议我将SQLite视为核心数据的完全替代品,但遗憾的是我没有使用它的经验,这就是为什么我完全无法预见这种严肃的设计决策的所有后果(即使是同步过程非常慢,我的应用程序确实有效,特别是它的UI性能现在非常好).关于SQLite,我唯一可以想象的是,与Core Data相比,它不会促使我在客户端粘合一些额外的关系,因为SQLite有其良好的旧外键系统,不是吗？

所以这里有一些问题(受访者,请不要在回答时混淆这些要点 - 我对所有问题都有太多困惑):

1. 是否有人以上述方式对"首次大量导入整个数据库"方法有这样的经验？如果他们利用JSON < - > CoreData对,我会非常感谢知道任何解决方案.

2. Core Data是否具有一些全局导入机制,可以允许大量创建相应的30-table-schema(可能使用上述"30包JSON"之外的某些特定源),而无需为30个实体设置相应的关系？

3. 如果2)不可能,是否有可能加快同步过程？这里我指的是我的应用程序使用的当前JSON < - > CoreData方案的改进.

4. 迁移到SQLite:我应该考虑这样的迁移吗？我会从中受益吗？整个复制过程 - >传输 - >客户端准备工作如何？

5. CoreData和SQLite的其他替代品 - 它们可能是什么样子？

6. 您对我所描述的情况有任何其他想法或想法吗？

更新1

虽然Mundi写的答案很好(一个大的JSON,使用SQLite的"No"),但我仍然对如何对我所描述的问题有任何其他见解感兴趣.

更新2

我确实尝试用我的俄语英语以最好的方式描述我的情况,希望我的问题可以变得非常清楚,每个人都会阅读它.通过第二次更新,我将尝试为其提供更多指南,以使我的问题更加清晰.

请考虑两个二分法:

1. 我可以/应该在iOS客户端上使用什么作为数据层 - CoreData vs SQLite？
2. 我可以/应该使用什么作为传输层 - JSON(答案中建议单一JSON一次,甚至可以压缩)或者一些DB-dump-dumps(如果有可能的话,当然 - 请注意我是在我的问题中也问这个问题).

我认为通过这两个二分法的交集形成的"扇区"非常明显,从第一个选择CoreData而第二个选择JSON是iOS开发世界中最广泛的默认值,并且我的应用程序使用它从这个问题.

话虽如此,我声称我会感谢看到有关CoreData-JSON对的任何答案以及考虑使用任何其他"扇区"的答案(如何选择SQLite和某种转储方法,为什么不呢？)

另外,需要注意的是,我不想只删除其他选项的当前选项,我只想让解决方案在其使用的同步和UI阶段快速运行.所以欢迎关于改进现有方案的答案以及建议其他方案的答案!

现在,请参阅以下更新#3,其中提供了有关当前CoreData-JSON情况的更多详细信息:

更新3

正如我所说,目前我的应用程序收到30包JSON - 整个表的一个包.让我们以宽大的表格为例:客户,代理商,城市.

它是Core Data,所以如果一个client记录有非空 …

您好我设置firstWeekDay有问题,这是我做的:

NSCalendar *gregorian = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar]; 
comp = [gregorian components:(NSYearCalendarUnit | NSMonthCalendarUnit | NSWeekCalendarUnit | NSWeekdayCalendarUnit) fromDate:targetDate];
[comp setWeekday:2];

NSDate *firstWeekDay = [gregorian dateFromComponents:comp];

如果2011-01-01周六是targetDate,我日历中的第一周周日似乎是2011-12-26周一,但实际上应该是2010-12-26周一.我怎么能做对的？

我还是xcode/iOS的新手,有以下问题:

为了显示一些移动调试信息,我将一个UIview作为outlet-property添加/连接到我的一个Viewcontroller.此视图是UIview的自定义子类.现在我添加了一些UIlabel作为此视图的子视图,并希望将这些标签的插座连接拖到我的customUIview.h文件中,以便可以将这些标签作为我的自定义UIview类的属性进行访问(无需直接从查看控制器).

问题是界面构建器(我使用的是Storyboards/xcode4.3)没有成功.我可以将插座连接到ViewControllerClass.h,但不能连接到我的子视图的.h文件.任何人都可以指出问题出在哪里？

我一直对如何编写以下代码以将其用于单元测试感兴趣:

是否可以使用检查特定线程是否被阻止的方法来扩展NSThread？

现在我正在使用NSCondition:Xcode向我展示了由-wait调用以阻塞线程的链:

[NSCondition wait] 
pthread_cond_wait$UNIX2003
_pthread_cond_wait
__psynch_cvwait

除了检查由NSCondition完成的锁定,如果它甚至可能,我也非常感谢方法也适用于任何其他阻塞功能(调度信号量,条件锁,睡眠线程等) - 我不知道Objective-C内部如果它们可能被一种方法捕获或者每种方法都需要它们.

这是我想要实现的一个简单示例.神秘的方法叫做isBlocked.

// Some test case
// ...

__block NSThread *thread;
NSCondition *condition = [NSCondition alloc] init];

dispatch_async(someQueue(), ^{
    thread = NSThread.currentThread; 

    [condition lock];
    [condition wait];
    [condition unlock];
});

while(1) {
    NSLog(@"Thread is blocked: %d", thread.isBlocked);
}

注意:我不擅长C和所有这些低级POSIX的东西,所以,请详细说明.

注2:我对调度队列的解决方案感兴趣:如果有人可以告诉我如何测试someQueue()被 - [NSCondition等待]阻止的事实(不是它将被阻止的事实(fx)在运行[条件等待]并且设置了块之前修改了一些代码,但是线程/队列被阻塞的事实),我会接受这个作为答案,就像我在工作时那样 - [NSThread isBlocked]方法.

注3:怀疑"这是不可能的"这样的坏消息,我声称任何有关捕捉 - [条件等待]被运行且线程被设置被阻止(见注2)这一事实的想法都值得赞赏,也可以接受为一个答案!

更新1,以解决理查德J.罗斯三世的好答案.不幸的是,他的答案在我原来的例子中不起作用,这个版本更接近我的实际工作(虽然它与我最初提供的例子没有太大差别 - 抱歉我没有把它包含在第一版的问题):

// Example

// Here I've bootstrapped Richard's isLocking categories for …

我在我的应用程序中使用Auto-Renewable Subscription.当我测试它时,我想在Sandbox环境中取消自动可再生订阅,但我发现它无法通过使用测试用户取消自动可再生.如何在沙箱环境中取消自动续订？如何在Sandbox环境中获取取消日期？谢谢!

我正在使用NSTask和NSTextView编写一个简单的终端.如何和应该实施？openptyCtrlCCtrlD

我开始像这样的shell:

int amaster = 0, aslave = 0;
if (openpty(&amaster, &aslave, NULL, NULL, NULL) == -1) {
    NSLog(@"openpty failed");
    return;
}

masterHandle = [[NSFileHandle alloc] initWithFileDescriptor:amaster closeOnDealloc:YES];
NSFileHandle *slaveHandle = [[NSFileHandle alloc] initWithFileDescriptor:aslave closeOnDealloc:YES];

NSTask *task = [NSTask new];
task.launchPath = @"/bin/bash";
task.arguments = @[@"-i", @"-l"];
task.standardInput = slaveHandle;
task.standardOutput = slaveHandle;
task.standardError = errorOutputPipe = [NSPipe pipe];
[task launch];

然后我拦截CtrlC并发-[interrupt]送到NSTask这样的:

- (void)keyDown:(NSEvent …

在键入时,clang --version我们获得了有关它所构建的LLVM版本的信息:

Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)

但是现在使用Xcode 7我们只得到以下内容:

Apple LLVM version 7.0.0 (clang-700.0.72)

我从https://copr-be.cloud.fedoraproject.org/results/alonid/llvm-3.9.0/epel-7-x86_64/00505197-clang-3.9.0/获取了rpm包, 用于Clang 3.9.

我正在通过命令安装rpm包

rpm -ivh clang-3.9.0-3.9.0-3.1.el7.centos.alonid.src.rpm

但是,当我这样做

rpm -ivh clang-3.9.0-3.9.0-3.1.el7.centos.alonid.x86_64.rpm

我收到以下错误:

error: Failed dependencies:
    clang-3.9.0-libs(x86-64) = 3.9.0-3.1.el7.centos.alonid is needed by clang-3.9.0-3.9.0-3.1.el7.centos.alonid.x86_64
    libLLVM-3.9.so()(64bit) is needed by clang-3.9.0-3.9.0-3.1.el7.centos.alonid.x86_64
    libclang.so.3.9()(64bit) is needed by clang-3.9.0-3.9.0-3.1.el7.centos.alonid.x86_64
    libclangAST.so()(64bit) is needed by clang-3.9.0-3.9.0-3.1.el7.centos.alonid.x86_64
    libclangBasic.so()(64bit) is needed by clang-3.9.0-3.9.0-3.1.el7.centos.alonid.x86_64
    libclangCodeGen.so()(64bit) is needed by clang-3.9.0-3.9.0-3.1.el7.centos.alonid.x86_64
    libclangDriver.so()(64bit) is needed by clang-3.9.0-3.9.0-3.1.el7.centos.alonid.x86_64
    libclangFormat.so()(64bit) is needed by clang-3.9.0-3.9.0-3.1.el7.centos.alonid.x86_64
    libclangFrontend.so()(64bit) is needed by clang-3.9.0-3.9.0-3.1.el7.centos.alonid.x86_64
    libclangFrontendTool.so()(64bit) is needed by clang-3.9.0-3.9.0-3.1.el7.centos.alonid.x86_64
    libclangIndex.so()(64bit) is needed by clang-3.9.0-3.9.0-3.1.el7.centos.alonid.x86_64
    libclangRewrite.so()(64bit) is needed by clang-3.9.0-3.9.0-3.1.el7.centos.alonid.x86_64
    libclangRewriteFrontend.so()(64bit) …