Предложения по компоновке и хранению программы Какао, которая анализирует - PullRequest
0 голосов
/ 25 января 2011

Краткая справка: в настоящее время я пишу программу на Xcode для Mac, которую я планирую передать (концептуально, если не целые куски кода) на iPhone.Это предполагает постоянный прием данных через Bluetooth от внешнего датчика (независимо от взаимодействия с пользователем данные должны быть получены).Я построил на Mac простую программу, использующую IOBluetooth, которая отлично работает в паре и начинает получать данные, и я планирую использовать BTstack и взломанный iPhone для доступа к чипу Bluetooth на iPhone.

ПередЯ зашел слишком далеко, я хочу концептуально выложить эту программу правильно, потому что я привык к процедурному программированию, и Obj-C - новый зверь для меня.Как я уже говорил, я бы хотел сохранить как можно больше этого кода при переходе на iPhone (я понимаю, что существуют разные классы для представлений и т. Д., Но я вижу -lots- сходств).

1) С моей программой я буду постоянно получать данные в фоновом режиме (независимо от действий пользователя - то есть, когда пользователь запускает программу и выбирает устройство BT, данные будут передаваться), и мне нужно хранить и анализировать эти данныепрежде чем он может быть представлен пользователю.Итак (вопрос), как можно это изложить?Я думал о том, чтобы поместить весь свой код BT в приложение applegate, а затем иметь контроллер представления (на Mac был бы только тот, который обрабатывает окно, а на iPhone был бы контроллер вкладок с несколькими контроллерами подчиненного представления), имодель, которая анализирует и хранит данные (также в виде файлов журнала, для дальнейшего использования), к которым обращается «контроллер», в данном случае приложение applegate.Имеет ли этот макет смысл?Является ли кошерным MVC / Cocoa помещать весь код BT и анализ в appdelegate, или он (они) должен быть в своем собственном классе (ах) (зная, что код BT на Mac и iPhone должен постоянно получать пакеты данных)?Как это можно улучшить?

2) Смежный вопрос на стороне анализа.Я не нашел ни одного примера Какао в сети, который бы анализировал (я нашел программы, но не объяснил модель, которую они используют).Базовые данные, которые сохраняются, очень малы - около 50 КБ в час.Однако результаты (включая графики спектра и водопада) могут составлять> 2 МБ в час (это программа, которую можно запускать много часов в день).Анализировать «на ходу» и просто бросать результаты в буфер прокрутки, который я знаю, было бы очень быстро, но я хочу, чтобы моя программа позволяла пользователю оглядываться на определенные временные сегменты в прошлом.У меня есть вопрос, должен ли объект модели анализировать данные и сохранять результаты вместе с базовыми данными, или модель должна хранить только базовые данные и возвращать эти данные контроллеру, который затем анализирует их, чтобы представить их представлению (это будет очень сильно загружать процессор, если будет перезаписывать даже минуты данных, не говоря уже о часах)?

Буду очень признателен за любые мысли или предложения, так как я считаю, что правильная заработка может сэкономить мне неисчислимые часы кодирования (и исправленияотладка) позже.

Ответы [ 2 ]

1 голос
/ 26 января 2011

Что касается вашего вопроса 1:

Я предлагаю вам написать класс / объект, который управляет данными Bluetooth, отдельно от делегата приложения. Делегат приложения находится там, где объекты представления встречаются с контроллером, и поэтому будет много вызовов AppKit (в OS X) и UIKit (в iOS). Изменение будет настолько велико, что #ifdef между ОС внутри одного и того же файла не будет иметь особого смысла для делегата приложения.

Скорее, сделайте ивар, удерживающий контроллер Bluetooth внутри делегата приложения. Таким образом, ваш код будет лучше структурирован, и его будет легче использовать повторно.

Что касается вашего вопроса 2:

На машине с OS X, которая обычно поставляется с большим количеством оперативной памяти, хранение и кэширование всех полученных данных в оперативной памяти было бы просто замечательно, если бы это было 2 МБ в час.

На iOS-устройстве ОЗУ является ресурсом, подвергающимся серьезной опасности. Если ваша программа кэширует вычисленные данные в памяти и использует много оперативной памяти, а пользователь отправляет их в фоновый режим, ОС, например, может сразу же убить вашу программу вместо ее приостановки. Тогда вам все равно придется пересчитать данные, потому что ваше приложение перезапускается.

Емкость файловой системы достаточно велика даже на машине с iOS. Таким образом, один выход - записать ваши расчетные данные на диск и позволить контроллеру представления перезагрузить оттуда предыдущие вычисленные данные. Таким образом, ваша программа может получить доступ к предварительно рассчитанным данным даже после их перезапуска.

Этот код кэширования может даже использоваться совместно OS X и iOS, если вы не жестко закодируете каталог кэша в программе.

0 голосов
/ 12 сентября 2011

Если ваше программное обеспечение на iPhone должно работать непрерывно в фоновой обработке данных из BTstack, я рекомендую создать LaunchDaemon для обработки данных и предоставить обычное приложение для конфигурации.(Хотя BTstack Mouse / Keyboard / GPS не следуют этому совету, они будут обновлять их, когда я найду время - Celeste использует демон для фактической передачи файлов, например) *

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...