Victor Ronin's IT blog

Несколько недель уже вожусь с программирование под iPhone. Почему-то складывается настойчивое желание купить билет на самолет и прийти в офис Appl’а с бейсбольной битой.

Из того, что наболело

— Управление памятью в Objective C какой-то странный изврат. С одной стороны вроде reference counter, а с другой стороны извольте ручками добавлять, убавлять, прописывать правильные атрибуты пропертям.

— XCode 3 расчитан на чертовых ниндзь. Кучу наиболее часто используемой функциональности (а-ля запуск программы или build) висит на комбинации из трех кнопок, вместо одной (или максимум двух). Постоянно приходится мудры какие-то руками выделывать.

— XCode 4 гораздо лучше в использовании клавиш, но он явная beta и крешится на любой чих и при отладке частенько теряет стрелочку, что же мы сейчас отлаживаем.

— Куча системных API возвращает, что операция не удалась, но не возвращает ошибки (и как я понимаю, нету эквивалента GetLastError)

— Куча API крешится при передаче каких-то не совсем подходящих значений. Блин, а слабо входные параметры проверять и не крешиться? Особенно радует, когда это происходит при передаче
параметров только что полученных из другой системной функции.

— API растасовано так, что черт ногу сломит. Естественно чтение из файла и URL нужно запихнуть в NSString. Божественно… может запихнем в NSString вообще все функции, которые возвращают строки?

— Security framework с которым мне надо работать урезан по самое нехочу. При том, что я четко знаю, что API эти в библиотеки есть и пользуются внутренними программами.

Уххх… Поубивал бы.

Люди, а кто-нибудь серьезно занимался разработкой под iPhone на Hackintosh’е (а еще лучше на VM’ке MacOS)?

Поделить впечатлениями о
а) Стабильности
б) Проблемах
в) Насколько оно нормально работает с внешними устройства (а-ля Debug через USB)

Забавная штука строки в программировании. Ну, что может быть проще — есть строка, ее куда-то передать и сохранить. Какие могут быть вообще проблемы с этим?

Как показывает опыт, гигантское количество может быть проблем.

Ну начнет с того, что есть куча кодировок: всякие UTF-8, Windows-1251, ASCII, ANSI? Если вы не совсем понимаете откуда растут ноги, то почитайте тут.

Кстати. еще приятная вещь, которая наложилась поверх всех этих UTF-16 это little-endianess и big endianess (можно почитать тут).

Но это еще все. Еще приятная штука, что куча программ/форматов используют специальные разделители для своих внутренних нужд.Ну например sheel в Unix использует | для pipes, да в Windows/DOS command line она тоже вроде используется. Соответственно, люди придумали escape символы, чтобы показать, что символ пользуется не в переносном (специальном смысла), а
прямом. К этому еще добавилось разделитель слов (пробел) и кавычки (как метод показать, что пробел не специальный знак).

К чему это я? Да прост убил фактически день на отслеживание следующей ситуации.

Installer использует
Command line и вызывает
Ruby script (с параметрами), который использует
Command line и вызывает
Java (c параметрами), которая вызывает какой-то
Java bean (внутри одного большого проекта), который читает и пишет
DB, а также создает
Certificate.

Из этого все Command line не любит определенные символы.
DB не любит определенные символы.
Certificate не любит определенные символы
Большой продукт пытается примерить некоторые входные параметры с тем, что не любит DB и Certificate. Но примеряет не все, не до конца и не совсем по стандарту. Плюс благодаря
этому он еще и херит некоторое количество того, что должно было работать для Certificate.

В общем, выдайте мне машину времени, нужно срочно вернуться на 50 лет назад и выдать им единый метод
а) Хранения integer в памяти
б) Encoding строк
в) Использования разделителей и escape characters
г) Правил по работе с строками вот в таких вот стеках.