• Работа с геолокацией в iOS 24/7
    0

    Симуляция нужна только при дебаге, убедится что все работает как надо.
    Про погрешность я уже писал, зато вспомнил благодаря комментарию о "авиарежиме", отсутствии симкарты и блокировке GPS, что дописал в "интересные моменты".

  • Работа с геолокацией в iOS 24/7
    0

    Да, большое спасибо, недоглядел. Использование в таком виде allowDeferredLocationUpdates в принципе бесполезно было, по статье и коду убрал, текст дополнил.

  • Работа с геолокацией в iOS 24/7
    0

    Код писался с максимально простотой, по этому отсутствует обработка ошибок в принципе didFailWithError / didFinishDeferredUpdatesWithError (CLError.h).



    Про то что allowDeferredLocationUpdates вызывается до didUpdateLocations:
    Start the delivery of location updates before calling this method.

    Соблюдено, CLLocationManager уже запущен. didUpdateLocations это не старт менеджера, первый вызов метода может быть и спустя пару минут, что наблюдал на практике.
    Другое дело, что обычно allowDeferredLocationUpdates вызывается из didUpdateLocations, потому что в документации дальше следует:


    After processing any new locations, call this method if you want to defer future updates until the distance or time criteria are met.

    p.s. большое спасибо за комментарий, попутно вспомнил и поправил в статье, что я забыл о нюансах allowDeferredLocationUpdates и выпилил использование из примера ибо влиять в том использовании не должно было.
    p.p.s. статью писал почти через 9 месяцев "не работы" с геолокацией, немного подзабыть успел, надеюсь никому не навредил "бесполезным" куском кода.
  • Работа с геолокацией в iOS 24/7
    0
    Начнет проигрывать файл только по требованию, просто можно указать сразу запускать или не сразу (все там же в настройках схемы).
    Про скорость вот тут можно глянуть.
    Provide one or more waypoints containing a latitude/longitude pair. If you provide one waypoint, Xcode will simulate that specific location. If you provide multiple waypoints, Xcode will simulate a route visitng each waypoint.

    Optionally provide a time element for each waypoint. Xcode will interpolate movement at a rate of speed based on the time elapsed between each waypoint. If you do not provide a time element, then Xcode will use a fixed rate of speed. Waypoints must be sorted by time in ascending order.


    Про точки и промежутки не понял вопроса, метод вызывается когда новые данные появились (обычно в массиве 1 элемент, но к примеру при использовании `defer` в массиве все точки что накопились)
  • Swift улучшаем performSegueWithIdentifier или удобный роутер со сторибордами
    0
    swift от objc классов остается практически тем же objc только с другим синтаксисом, по этому почему бы и не использовать логику работы objc для улучшения.
    Когда весь проект на swift, много чистых swift элементов, то тут и начинается проявляться проблема «оберток» о которой я упомянул, но похоже забыл написать в статье. Это относится к различию между Any и AnyClass когда надо в prepareForSegue передавать данные.
    К тому же если принять соглашение к именованию контроллеров в сториборде как сам класс, то можно используя небольшую модификацию вместо идентификатора передавать класс и получать в замыкание уже приведенный экземпляр класса (не писать постоянно as! в замыкании)
  • Отзывчивый поиск для UITableView
    0
    Delete
  • Swift и время компиляции
    0
    сегодня оптимизацией кода разбирался тк надоело смотреть на долгую компиляцию
    первым делом написан был скрипт на башике, который делал файл с тем что компилится больше 1мс (потом увеличил до 50) и выводит суммарное время сборки.
    Результат ~ 32'000ms
    Прошерстил 2 функции (flatMap цепочка одна фунция и убрал lazy в другом месте) и уже 20'000ms
    Еще 2 функции перебрал и уже 18сек компиляция

    Собственно всего то разнес во временные переменные результаты
  • Внедрения реактива в архитектуру iOS приложений
    0
    Даже если все сделать на переменных (Variable, PropertyType), то в них всеравно придется биндить сигналы (не скажу в этом случае за rx, но в rac это создаст Disposable и его нужно будет положить в composite (bag)). И всеравно ViewModel будет иметь по этому bag, по этому не вижу ничего плохого если будет подписка на сигналы не только во ViewController.
    Кстати, если все перевести в такие переменные, сложно сопоставлять будет действия когда придет новый человек. А вот если сервисы выдают сигналы и на них подписываются из Presentation (ViewModel к примеру и потом выдает результат по необходимости в Controller на обновления) то сложного ничего нет, потому что разделяются обязанности: сервис сконфигурировал, ViewModel подготовил данные и обновился Controller

    Биндинга между моделью и вьюмоделью не делаем, сервис выдает структуры, по этому сохраняется иммутабельность данных.
    Если есть к примеру необходимость при переходе на экран всегда показывать актуальные данные, значит есть смысл каждый раз при показе экрана эти данные просить у сервиса из «кэшируемых». Это накладывает свои ограничения, но явно показывает принцип работы этого экрана. К тому же пропадает расхождение между хранимыми и показываемыми данными (если разумеется их показывают «как есть»).
    Опять же, если полученные данные из сервиса изменить, это будет только локальным изменением.
  • Внедрения реактива в архитектуру iOS приложений
    0
    огромный комментарий :D

    1) По мне абсолютно нормальная практика когда ViewModel имеет переменные (уже как минимум если используем биндинги), хотя бы на уровне PropertyType. Потому что это ViewModel и это его задача прямая взять на себя работу с данными для экрана. Либо мы говорим о разных понятиях под ViewModel.
    Взаимодействие Controller — ViewModel будет работать как раз на сигналах, ViewModel будет иметь сигналы, в которые будет сообщать о ситуациях нужных для контроллера. Либо создавать и отдавать их обратно контроллеру на действия, в зависимости от ситуации.
    Конечно, можно разнести все такие сигналы в PropertyType, но жизнь от этого проще не станет.

    2) О создании, кто что создает… намного лучше взять DI фреймворк (Swinject к примеру)

    3) В чем проблема от использования структур и кордаты? Это ведь совершенно разные вещи и между ними взаимодействие только на уровне DAO должно осуществляться. Более того, используя структуру мы можем забить на подход с использованием линз тк это копируемый тип и оставить поля в структурах как мутабельные.

    В общем, если нам позволяется совмещать несколько подходов в одном для более быстрого и удобного достижения нужной цели, то это надо использовать. Наш подход состоит в следующем:

    Controller — работа с UI + взаимодействие с ViewModel (подписки на сигналы и получение сигналов для действий)
    —— ниже больше никто не работает с UI компонентами и работают только с данными.
    ViewModel — подготовка данных для Controller + взаимодействие с Service
    Service — инкапсуляция работы, не связанная с экранами на прямую. Прячем сюда всю черную работу попутно убирая возможный повтор действий.
    —— Service взаимодействует с различными компонентами системы, в зависимости от ситуации.

    p.s. реактив должен облегчать работу, а не заставить отказаться от парадигмы вашего языка. К примеру попытка сделать абсолютно все immutable.
    p.p.s. даже в функциональных языках существуют монады.
  • Портфель iOS TEAM разработчика
    0
    Только в один скрипт для сабмита в стор надо дописывать фреймворки.

    Не поделитесь опытом? В проекте ибо в таргет прикладывается скрипт с путями и какие нужны фреймворки. Возможно я что то делаю не так и как вы пишете можно только в одном скрипте указать фреймворки (как в pod'ах можно было указать вот эти вот на все таргеты, вот этот вот «туда», а этот «туда»)

    Также при удалении не нужно ничего пересобирать

    ну да, на удаление не надо пересобирать. Но надо убрать из картежфайла запись, из таргета удалить фреймворк, потом найти его в скрипте и убрать путь до него.
    Конечно ситуация добавления/удаления не такая и частая, но как то смущает. Особенно когда больше 1 таргета на проекте
  • Портфель iOS TEAM разработчика
    0
    минусы рассказать забыли :-)
    1) долгое выкачивание и сборка фреймворков когда нужно добавить/удалить что то
    2) нужно руками прописывать путь к каждому фреймворку и добавлять фреймворк в проект
    2.1) это нужно сделать для каждого таргета
  • Swift улучшаем performSegueWithIdentifier или удобный роутер со сторибордами
    +1
    Отлично, как я и написал «Не претендую на уникальность».
    В конечном итоге люди узнали/узнают что «можно так», а есть «и вот так уже». Я вот не знал когда делал, думаю я не один такой :-)
  • RxSwift: работа с GUI
    0
    1) MVVM не чистый у нас в любом случае (что вызывает зависть у команды winphone :D) = разделение контроллера на presenter + viewmodel
    2) применяем сюда SOA
    3) роутер этот, вот на этот момент я написал мелкую штуку в 50 строк (долго думал нужно ли писать статью, но решился в сб и сейчас текст статьи на проверке/правке перед релизом, увы я не мастер писать связно там крайне мелкая статья в 1.5 экрана), но она позволяет убрать навигацию в отдельный объект полностью. А использование DI повышает переиспользование и тестирование еще выше

    ах да, сториборды, сейчас на моем проекте 6 сторибордов ко всему этому
  • RxSwift: работа с GUI
    +1
    На недели планировал написание о архитектуре с реактивом.
    Используем очень плотно реактив (правда RAC2/RAC4 вместо RxSwift) и уже не один проект успешно живет и развивается. Пропитываем сквозь всю модульную архитектуру и нам это очень хорошо помогает разделять и лучше читать.
    Ну и соотвественно за счет разделения отличная тестируемость достигается
  • Переход на ReactiveCocoa v.4
    0
    при хорошем разделении кода, отладка на RAC не сильно сложнее чем обычный асинхронный код
    наши проекты пропитаны реактивом и включение человека на проект не является неподъемной задачей
  • До чего доводит идея (Objective-C) — target-action на блоках и много рантайма
    0
    Если бы Вы ограничили статью только темой «Разбираемся с NSMethodSignature на примере комбинирования stringWithFormat и NSArray» и убрали привязку к target-action

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

    Да, ломается 2х строчное решение
    Но это все равно меньше пары классов и статьи на пару А4. А по сути всего один метод у UIButton

    Это и есть тот самый обычный подход о котором я писал что в других либах, только там это делается сразу на уровень выше для остальных контролов чтобы было
    И потом такие же для инициализаторов на барбатоны, на таймеры, на жесты и еще на много чего и на самом деле если это собрать, то получится не мало категорий

    Здесь решение максимально общее и по факту совсем не большое если сравнивать от эффекта добавления множества категорий

    1) target-action ни есть задача о performSelector:withObject:

    Вы правы. Но суммарный результат, что решение применимо для любого действия где дергается через селектор вызов, я не смог подобрать лучшее определение
  • До чего доводит идея (Objective-C) — target-action на блоках и много рантайма
    0
    приведите пример использования invoke, когда блок принимает аргументы
    к примеру для вызова через performSelector:withObject:
    ну или когда по нажатию на кнопку надо получить кнопку и евент

    так же интересно, какое неверное представление я дал о блоках?
    p.s. а я и не думал обижаться :-) это про "не злой"
  • До чего доводит идея (Objective-C) — target-action на блоках и много рантайма
    0
    Потому что намного приятнее работать только с тем, что нужно

    А поскольку:
    Это был всего лишь эксперимент, у меня не было желания написать этот код для использования в проектах.

    и это действительно было увлекательное занятие и я думаю все объясняет ;-)
    К тому же адаптация кол-ва аргументов тоже весьма приятно
  • Method Swizzling и Swift: но есть нюанс
    0
    Автор пишет, что можно выбрать другую библиотеку для замены основы под iOS.
    Да и если это работает, пусть и не под iOS, тогда вопрос, может все таки можно без NSObject и dynamic? Почему бы не раскопать эту тему, вместо того чтобы просто написать «вот так можно, это логично и просто и все тут», это будет намного интереснее и полезнее. О этой либе упоминается как раз в приведенном вами источнике
  • Method Swizzling и Swift: но есть нюанс
    0
    Получается в Swift можно использовать swizzling, только если для этого разработчики сами приложат усилия? Практически бесполезно получается ((
    Кстати, а что по поводу SWRoute? Запустить у себя не получилось, видимо не совместимо с последней версией, но люди поставили звезды, возможно у них получилось, не пробовали разобраться с новой версией языка?
  • Method Swizzling и Swift: но есть нюанс
    0
    И внутрь фрэймворка лезть нам тоже очень не хочется, потому что время от времени выходят его обновления и лишаться их — жалко.

    а если класс не наследник NSObject?
    ну или хотя б метод не dynamic?

    тогда только лезть? часто ли пишете такие условия сами?
  • Objective-C вопросы на уровень middle/senior
    0
    речь о «не боевом» именно о этом куске кода
    остальные вопросы не пиши только ответы) а то не удобно будет перед людьми, которые будут такие вопросы задавать
    одно дело когда люди прочитают, загорятся и найдут и еще многое по ходу поиска изучат, а другое дело за пару минут прочитают именно как сам ответ и забьют
  • Objective-C вопросы на уровень middle/senior
    0
    не спорю, код не боевой :D
    но проблема может быть устранена если знать причину и даже с бесконечным циклом
    p.s. если цикл завершиться, то память будет освобождена, но не сразу
  • Objective-C вопросы на уровень middle/senior
    0
    утечка все таки в этом случае не самое подходящее слово, но память будет забиваться (да, здесь используется arc)
    prntscr.com/9l89py
  • Printf Oriented Programming
    +1
    pvs studio часто публикуют в этой теме материалы (возможно, будет интересно почитать или вообще узнать о них) http://habrahabr.ru/company/pvs-studio/
    была хорошая статья на подобную тему, но к сожалению не написали в хабр (а может и была и я не заметил)
  • Objective-C: как работают блоки
    0
    Спасибо большое за замечание и особенно за вопросы (не сарказм)
    Постараюсь написать продолжение (по вопросам) через пол года/год в таком случае и обещаю чаще пользоваться хабропоиском перед публикацией )
  • Objective-C: как работают блоки
    0
    извините, не о том подумал в ответе

    typedef int (^EmptyBlock)();
    void foo(EmptyBlock block) {
        EmptyBlock mallocBlock = block;
        EmptyBlock mallocBlock1 = block;
        
        NSLog(@"my class:%@, ptr block = %p", [mallocBlock class], mallocBlock);
        NSLog(@"my class:%@, ptr block = %p", [mallocBlock1 class], mallocBlock1);
    }
    
    int main(int argc, const char * argv[]) {
        @autoreleasepool {
            int a = 1;
            foo(^int{
                return a+5;
            });
        }
        return 0;
    }
    

    2015-12-01 08:03:08.840 block_testing[683:13269753] my class:__NSMallocBlock__, ptr block = 0x100111d00
    2015-12-01 08:03:08.841 block_testing[683:13269753] my class:__NSMallocBlock__, ptr block = 0x100111d30

    по тексту сейчас поправлю
  • Objective-C: как работают блоки
    0
    typedef void (^EmptyBlock)();
    void foo(EmptyBlock block) {
        NSLog(@"my class:%@, my ptr %p", [block class], &block);
        block = [block copy];
        NSLog(@"my class:%@, my ptr %p", [block class], &block);
    }
    
    int main(int argc, const char * argv[]) {
        @autoreleasepool {
            int a = 1;
            foo(^{
                int b = a;
            });
        }
        return 0;
    }
    

    2015-12-01 07:36:25.293 block_testing[580:13262049] my class:__NSStackBlock__, my ptr 0x7fff5fbff758
    2015-12-01 07:36:25.294 block_testing[580:13262049] my class:__NSMallocBlock__, my ptr 0x7fff5fbff758

    Блок создает внутри себя константные локальные переменные и указатели того, что захватывает. Что при использовании объектов увеличит счетчик ссылок, по обычной для ARC логике (при копировании блока в кучу).

    Тоесть если внутри блока используются объекты, то retain будет отправлен именно при перемещении в кучу
  • Навигация между экранами с использованием xib файлов
    0
    нет, для меня этот кусок кода приемлемый
    1) я использую возможность языка
    2) мне не нужно делать лишние манипуляции с initWithRootViewController
    3) метод createRootViewController использует self только для связи. Можно было сперва просто создать контроллер, потом вызвать initWithRootViewController и только потом связать, но если это делается проще, почему не использовать
    4) если речь про подмену объекта в init, то сам этот момент кейс «пахнет»

    это ведь не конструктор, если в пример хочется привести swift
  • Навигация между экранами с использованием xib файлов
    0
    извиняюсь, кусок скопированного кода (
  • Навигация между экранами с использованием xib файлов
    0
    память под объект уже выделена в момент вызова, без всякой надежды
    как минимум метод initRouter вызван у объекта (который и будет self) — подробнее
    максимум возможного — [super initWithRootViewController:rootViewController] вернет nil и rootViewController будет уничтожен
  • Objective-C что такое на самом деле метод и self? + runtime
    0
    Swift я вписал в теги больше по причине след возможности

    swift
    class FooClass {

    func someMethodWithInt(let value: Int) -> String {
    return String(value * 2)
    }
    }

    let foo = FooClass()

    print(foo.someMethodWithInt(15))

    let f = FooClass.someMethodWithInt(foo)
    print(f(40))

    Вывод:
    30
    80


    так что разработчики Swift могут тоже полезное получить, хотя я и согласен, что статья относится слишком и слишком около Swift
  • Навигация между экранами с использованием xib файлов
    0
    Собрать переходы между экранами, изолировать контроллеры.
    А singleton'ы, к примеру сервисы. Здесь мы можем передать экземпляр.
    Точно так же как мы открываем сторибоард и смотрим навигацию, открываем роутер и смотрим навигацию.
  • Пишем реализацию Observer-а над KVO на objective-c
    +1
    Чем меньше в системе изменяемых моделей, тем спокойнее работать
  • Да начнется unit-тестирование (Objective-C)
    +1
    В прошлом году читал ее, довольно актуальна была. Не дочитал до конца тк рассматривались в основном простые крайне примеры и стандартная библиотека. Может быть после середины книги там и рассматривается мокирование и тп, но даже в таком случае тот же OCMock поменялся с того времени
  • Да начнется unit-тестирование (Objective-C)
    0
    В данный момент график сильно забит (данная статья была написана еще в воскресенье), но чуть позднее (предположительно под конец июня) смогу сесть и написать разбор небольшого приложения под iOS, написанного через тестирование (TDD). Главное нужно будет придумать, что должно быть в этом приложении, чтобы не пришлось объяснять помимо тестирование моменты.

    p.s. А вы скачивали исходники проекта? Кроме описания каждой функции, есть так же небольшой пример использования.