关于可可程序的程序布局和存储的建议，以进行分析

Question

Short background: I am currently writing a program in Xcode for the Mac, which I plan to take parts of (conceptually, if not whole chunks of the code) over to the iPhone. It involves constantly receiving data through bluetooth from a external sensor (regardless of user interaction the data must be received). I've built a simple program on the Mac using IOBluetooth that pairs and starts receiving the data just fine, and I plan on using BTstack and a jailbroken iPhone in order to access the bluetooth chip on the iPhone.

Before I get too far I want to conceptually lay this program out correctly, because I am used to procedural programming and Obj-C is a new beast for me. As I stated, I would like to be able to save as much of this code as possible when I move to the iPhone (I understand there are different classes for views etc, but I see -lots- of similarities).

1) With my program I will be constantly receiving data in the background (regardless of user actions - ie, once the user starts the program and picks the BT device, the data will flow) and I need to store and analyze that data before it can be presented to the user. So (the question), how would one lay this out? I was thinking of putting all of my BT code in the appdelegate, and then having a view controller (on the mac would just be one which handles the window, but on the iPhone would be a tab controller with multiple sub view controllers), and a model that analyzes and stores the data (also as log files, for future reference) that is accessed by the "controller", in this case the appdelegate. Does this layout make sense? Is it kosher MVC/Cocoa to put all of the BT code and analysis in appdelegate, or should it(they) be in its own class(es) (knowing the BT code on both the mac and iPhone must constantly receive bursts of data)? How could it be improved?

2) A related question on the analysis side. I haven't found a single Cocoa example on the net that has analysis (I've found programs, but no explanation of the model they use). The basic data that is saved is very small ~50kB per hour. However, the results (including spectrum and waterfall plots) could be >2MB per hour (this is a program that one might run for many hours a day). To analyze "on the go" and just throw the results in a scrolling buffer I know would be very fast, but I want my program to allow the user to look back at specific time segments in the past. The question I have is should the model object analyze the data and store the results alongside the basic data, or should the model only store the basic data, and return that data to the controller which would then analyze it to present it to the view (this would be very CPU heavy if regraphing even minutes of data, let alone hours)?

Any thoughts or suggestions would be greatly appreciated, as I feel laying proper groundwork could save me untold hours of coding (and fixed/debugging) later.

Answer 1

As for your question 1:

I suggest you to write a class/object which manages the bluetooth data, separately from the app delegate. The app delegate is where the view objects meet the controller, and as such there will be lots of calls to AppKit (on OS X) and to UIKit (on iOS). The change will be so great that #ifdef between the OSes inside the same file won't make much sense for the app delegate.

Rather, make an ivar holding the Bluetooth controller inside the app delegate. That way your code will be better structured, and will be easier to be reused.

As for your question 2:

On an OS X machine, which usually comes with plenty of RAM these days, holding and caching all the resulting data on the RAM would be just fine, if it's 2MB per hour.

On an iOS machine, RAM is a seriously endangered resource. If your program caches the calculated data in the memory and consumes a lot of RAM and the user send it to the background, the OS might outright kill your program instead of suspending it, for example. Then you'll need to recalculate data anyway, because your app is re-launched.

The filesystem capacity is quite big even on an iOS machine. So one way out is to write out your calculated data onto the disk, and let the view controller reload the previous calculated data from there. That way, your program can access pre-calculated data even after it's relaunched.

That cacheing code can be even shared between OS X and iOS, if you don't hard-code the cache directory into the program.

Answer 2

If your software on the iPhone is supposed to run continuously in the background processing data from BTstack, I recommend to create a LaunchDaemon for the data processing and provide a regular app for the configuration. (Although BTstack Mouse / Keyboard / GPS don't follow this advice, they will when I get around to update them - Celeste uses a daemon for the actual file transfers eg)