2011-01-25 26 views
0

简短背景:我目前正在为Mac编写Xcode程序,我计划将它的一部分(概念上,如果不是全部代码)写入到苹果手机。它涉及通过蓝牙从外部传感器不断接收数据(无论用户需要交互数据都必须接收)。我已经在Mac上使用IOBluetooth构建了一个简单的程序,它可以配对并开始接收数据,我打算使用BTstack和越狱iPhone来访问iPhone上的蓝牙芯片。关于可可程序的程序布局和存储的建议分析

在我变得太远之前,我想从概念上正确地设置这个程序,因为我习惯了程序编程,而Obj-C对我来说是一个新的野兽。正如我所说的,我希望在移动到iPhone时能尽可能多地保存这些代码(我知道有不同的视图类,但我看到很多相似之处)。

1)随着我的程序,我会不断地在后台接收数据(不管用户的行为 - 即一旦用户启动程序并选择BT设备,数据将流动),我需要存储和分析该数据可以呈现给用户。所以(这个问题),如何解决这个问题?我正在考虑将所有BT代码放在appdelegate中,然后有一个视图控制器(在Mac上只是一个处理窗口,但在iPhone上将是一个带有多个子视图控制器的选项卡控制器),以及一个模型,用于分析和存储由“控制器”访问的数据(也作为日志文件,供将来参考),在这种情况下是appdelegate。这种布局是否有意义?是否可以将所有BT代码和分析放在appdelegate中,或者是否应该放在自己的类中(知道在Mac和iPhone上的BT代码必须不断接收突发数据) ?如何改进?

2)分析方面的一个相关问题。我没有在网上找到一个可分析的例子(我找到了程序,但没有解释他们使用的模型)。保存的基本数据非常小〜每小时50kB。但是,结果(包括频谱和瀑布图)每小时可能大于2MB(这是一个可能每天运行数小时的程序)。要分析“在旅途中”,只是将结果放入滚动缓冲区中,我知道速度会非常快,但我希望我的程序允许用户回顾过去的特定时间段。我的问题是模型对象应该分析数据并将结果存储在基本数据旁边,或者模型只存储基本数据,然后将该数据返回给控制器,然后控制器将其分析并将其呈现给视图(如果重新划分数据甚至是几分钟,这将会非常繁重,更不用说小时了)?

任何想法或建议将不胜感激,因为我觉得铺设适当的基础可以为我节省数日的编码(和固定/调试)数小时。

回答

1

至于你的问题1:

我建议你写一个类/对象从应用程序的委托管理蓝牙数据,分别。应用程序委托是视图对象与控制器相遇的地方,因此会有很多对AppKit(在OS X上)和UIKit(在iOS上)的调用。这个改变将如此之大,以至于在同一个文件中的操作系统之间的#ifdef对于应用程序委托没有多大意义。

相反,在应用程序委托内部制作一个持有蓝牙控制器的伊娃。这样你的代码将会更好地构造,并且更容易被重用。

至于你的问题2:

在OS X光机,它通常有足够的内存,这些天,召开和缓存的RAM的所有结果数据会就好了,如果是每小时2MB 。

在iOS机器上,RAM是一种严重濒危的资源。例如,如果您的程序将计算的数据缓存到内存中并消耗大量内存,并且用户将其发送到后台,则操作系统可能会彻底杀死您的程序而不是挂起它。然后,无论如何,您都需要重新计算数据,因为您的应用已重新启动。

即使在iOS机器上,文件系统容量也相当大。因此,一种方法是将计算出的数据写出到磁盘上,并让视图控制器从那里重新载入先前计算的数据。这样,您的程序即使在重新启动后也可以访问预先计算的数据。

这cacheing代码OS X和iOS之间甚至共享,如果你不硬编码的缓存目录到程序中。

+0

谢谢。让我确定我明白你写的是什么:离开AppDelegate(仅仅是在应用程序启动后做些事情),有一个用于蓝牙数据接收和解析的控制器,以及一个视图控制器(在iPhone上用于标签视图的嵌套视图控制器) ,最后是存储的模型。两个后续问题:模型应该对数据进行分析,还是只保存收到的数据?而且,我的想法是正确的,BT控制器应该是单身人士(永远不应该只有一个实例,并且它需要始终运行 - 捕获进来的数据)? – 2011-01-26 20:32:47

+0

我同意BT控制器是单身人士;但是在应用程序委托中单独创建一个实例(而不是强制它实际上是单例)可能就足够了。我不确定将分析代码放在哪里。我至少会让它独立于BT控制器;您可能想稍后重新分析原始数据以生成图。然后将分析代码分开将派上用场。 – Yuji 2011-01-27 13:58:00

0

如果你的iPhone上的软件应该从BTstack后台处理数据的连续运行,我建议建立一个LaunchDaemon的数据处理和提供配置的常规应用。 (虽然BTstack鼠标/键盘/ GPS不遵循这个建议,他们会在我避开对其进行更新 - 蔚为使用的实际文件传输例如守护进程)

相关问题