Pull to refresh
62
0
Павел Тайкало @Kilew

Пользователь

Send message
Относительно использования ViewModelей в табличке, вместо тоо, чтобы писать так:
RAC(self.titleLabel, text) = RACObserve(self.viewModel, someValue)

и отписываться каждый раз при prepareForReuse,

Можно использовать следующую запись (обращаем внимание на запятые ;)
RAC(self.titleLabel, text) = RACObserve(self, viewModel.someValue)
Можно подумать, что я собирался спорить, что на Obj-C писать меньше надо. Чаще всего больше. Может, быть даже всегда.

Я говорю о том, что создается ощущение, что примеры на Objective-C на Xamarin'е писали люди, ОЧЕНЬ давно писавшие на Objective-C, и не самым лучшим образом )

Xamarin сам по себе очень хорош. Но рекламировать его на таких примерах — это как по мне, немного грязный ход.
сравнение кода на Objective-C с C# — ересь полная. Маркетологи вступают в дело.
В Objective-C, конечно, побольше текста по сравнению с C#, но этот конкретный пример отстал от реальности эм… года на полтора

Objective-C вариант, наши дни:

  NSDictionary *  attrs = @{
     NSFontAttributeName : [UIFont systemFontOfSize:12],
     NSForegroundColorAttributeName : [UIColor blackColor],
  };
    
  NSAttributedString * string = [[NSAttributedString alloc] initWithString:@"Hello, world" attributes:attrs];
Режим зануды: ON
Осталось вспомнить, что каждый символ в строке находится в UTF -16 кодировке значит, занимает так же 2 байта, следовательно

UTF-16 — кодировка с переменным количеством байт на символ. Либо 2, либо 4 байта.
Режим зануды: OFF
Конкретно в этом случае — не надо.
Надо в случае такого кода:
if ([label respondsToSelector:@selector(resizeToContents)]) {
   [label performSelector:@selector(resizeToContents)];
}


А в общем случае, нужно просто смотреть, что возвращает метод
if ([label respondsToSelector:@selector(resizeToContents)]) {
   [label performSelector:@selector(resizeToContents)];
}
Вызывал кто-то глубоко в коде, не используя результат вызова (прямо как в примере). А причина, почему вызывалось через performSelector — скорее всего из-за использования приватного метода. Проще, наверное было сделать так, чем поправить библиотеку, вынести метод в заголовок, сапдейтиться и использовать правильный метод. Кто знает ;)
Я еще поищу, но там было что-то вроде
if ([label respondsToSelector:@selector(resizeToContents)]) {
   [label resizeToContents];
}
Есть, все же предположение, что им абсолютно все равно правильный ответ или нет.
Важно понимать, как человек решает задачи, в которых много неизвестных
Важен сам процесс принятия решения, оценки сложности задачи, нежели конкретный ответ

Я использую AppCode как основную среду для разработки.
Xcode (до AppCode 1.6) приходилось открывать
а) для конфигурации настроек проекта (создание таргетов, настройка сборки)
б) для запуска Instruments на девайсе
в) сборки/заливки в AppStore

Xibs/StoryBoard не использую, поэтому вроде ОК.
Соотношение по проведенному времени AppCode/Xcode где-то 95%/5%
Но все равно от Xcode, думаю, полностью не избавишься

Поработаем с 1.6, увидим, как оно дальше будет
а) Что это делает на Хабре?
б) Синхронный вызов NSURLConnection будет блокировать весь UI до окончания запроса, который на девайсе при низком инете может длиться относительно долго
в) строки вида
realName = [userData objectAtIndex:14]; realName = [realName stringByAppendingString:[userData objectAtIndex:20]]; [user setObject:[data objectAtIndex:1] forKey:@"access_token"]; [user setObject:[data objectAtIndex:3] forKey:@"expires_in"]; [user setObject:[data objectAtIndex:5] forKey:@"user_id"];
Будут валиться при любом мало-мальском изменении API вконтакте
г) При изменении порядка параметров, либо добавлении новых, этот код тоже не будет работать
д)"(вместо пробелов ставим "+")" А что ставим вместо ?,/,:,+? Для таких вещей есть (stringByAddingPercentEscapesUsingEncoding, который, правда, он пробел плюсом не закодирует, но если сильно надо, то на просторах интернета можно найти решение согласно RFC3986)
е) Лучше было бы найти готовое решение в данном случае. А то кто-то найдет это.

Если бы не камни можно было бы и его использовать — а так ;) То попадаешь в состояние «слишком много вершин» в следующей волне, то в состояние «почему там мало вершин» в следующей волне ;)
В 2007 году на ICFP Contest'e, когда спасали Endo
save-endo.cs.uu.nl/
Похожую структуру и применяли.

В практических задачах — вряд ли встретится, но структура хороша, если стоит задача в быстрой генерации больших текстовых данных.
Где же Вы были раньше?
Очень бы помогло в ICFP Contest'e 2011 года
http://www.icfpcontest.org/
То, что я видел — это библиотеки для работы с их сервисами (Gmail, Google Docs, etc)
Вот, например
У нас ситуация абсолютно противоположная. Читать код проекта, который писали 5 разных людей без CodeStyle намного сложнее, чем читать код проекта, который писали 5 тех же людей с использованием Code-Style, пусть даже и не полностью.
Конкретные правила расстановки пробелов, отступов знаков препинания, и именования переменных, которые были выработаны путем долгих и мучительных дискуссий ;)
Основаны на Cocoa Coding Guidelines и Google Objective-C Guidelines.

Просто куча правок и изменений, добавлены новые «правила и замечания», и в результате — наш Code Style лежит на Wiki, и все пишут в одном стиле (±), во всяком случае пытаются. Для «продвижения и осознания» Code Style использовались примеры старых проектов, которые писали разные люди.

Wiki внутренняя, если нужны конкретные правила текущей редакции — то пишите в личку — поделюсь.

Лично для себя настроил AppCode и подогнал его под корпоративный CodeStyle. Uncrustify нормально настроить не получилось. Все еще подумываю про собственный форматтер с блэкджеком ;)
Не все хотят применять технологии везде и всюду, особенно в видах спорта
Вот, например что по этому поводу говорит Гугл
1) Видать какие-то конструкции заумные, не вписывающиеся в грамматику
2) Давайте не превращать Хабр в Bug Tracker :) Пишите в личку — разберемся, поправим, перевыложим.

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity