Обновление UIImageView после applicationWillEnterForeground

uiimageview
swift3

#21

Тогда задаю вам тот же вопрос. В примере, который я привел выше, вы гарантируете, что после изменений в коде поставите [unowned self]? Если отвечаете да, то программирование это не ваше.

А что бы вы сказали про код-ревью в Яндексе, когда бы прочитали эту статью?

Человек не смог пройти код-ревью, потому что не поставил пробел после function. Так что в больших компаниях сидят еще те параноики. И наверное, они знают, что делают.


#22

Не важно, что я отвечу. Мое, не мое, не вам решать. Вас ткнули носом в то, что не стоит везде лепить [unowned self]. Вы какой то пример “родили”, по Вашим словам. Но если Вы его рожали, то следовало аборт сделать и не мучаться.

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

Для вас ориентир большие команды? Тогда именно я Вам сочувствую. В Яндекс нет единого стиля, каждая команда работает как ей нравится. В том же Рамблер есть определенный стиль и требования. Кто прав? Да фиг знает, но в Рамблер легче заменить разработчика на проекте или добавить еще кого в проект.


#23

Никто меня ни во что не тыкал. Не надо мне говорить, что в большинстве случаев [unowned self] излишен, не мните о себе слишком много, что вы один понимаете, когда его нужно ставить, а когда нет. Я говорю лишь о том, что код постоянно меняется в процессе. И лучше заранее поставить [unowned self], даже если это претит вашим эстетическим чувствам. Потому отслеживать потом это будет очень тяжело, когда сроки горят, а мерджи идут за мерджами.

Замыкание - это одно из немногих тонких мест свифта, поэтому когда работаете с ними, надо повышать бдительность. Написать два “лишних” слова нетрудно. Зато трудно потом найти утечку. Видимо, вы никогда не искали (особенно такие, которые возникают периодически по неизвестной причине), поэтому относитесь к этому так халатно. Что говорит об отсутствии у вас опыта. Свифт это ваш первый язык программирования? Если да, тогда все понятно.


#24

Хорошо, видно просто так это не закончится. Любите примеры? До этого была задана дефолтная конфигурация Реалм для работы с сервером:

func setup() {
    SyncUser.logIn(with: credencial, server: authServerURL) { user, error in
      if let user = user {
        Realm.Configuration.defaultConfiguration = Realm.Configuration( syncConfiguration: SyncConfiguration(user: user, realmURL: realmURL) )
      }
    }
  }

Как известно, реалм имеет свою ивент-систему, умеющую динамично менять способ работы в данными, обновляемыми в реальном времени. Сервер/локальное хранилище.

func connect(block: @escaping (_ realm: Realm)->()) {
    let realm = try! Realm()
    block(realm)
  }

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

static func objects<T: Object>(type: T.Type) -> Results<T>? {
    let realm = try? Realm()
    return realm?.objects(type)
  }

Исходя из перечисленного, стало возможно помимо выборки данных, работать с Реалм таким способом и не париться как Реалм синхронизирует данные:

@objc func update(updateBlock: @escaping () -> ()) {
    RealmManager.manager.connect { realm in
      try! realm.write(updateBlock)
    }
  }

То есть, в данном контексте обновление объекта происходит так:

let realmEntity = ......
realmEntity.update {
  realmEntity.propertyName = ....
}

Если на ревью я увижу здесь Ваш [unowned self], то вы язык учить все же пойдете! И не важно какой у меня по счету язык. Еще раз блеснете пафосом вроде:

Или:

Я лично спущу Вас с небес на землю. А то вы под ногами уже и земли не чувствуете!


#25

В Свифте ARC и утечки бывают только в результате цикла сильных ссылок (unsafe не берём в расчёт), если в результате захвата замыканием не возникает цикла сильных ссылок, то пусть оно хоть обзахватываеться ARC уничтожен все объекты.

Так никто не пишет, lazy здесь не нужен:

lazy var getProp: () -> String = {
}

Это тоже самое что это:

var getProp: () -> String = {
}

А тут всё просто, getProp сильная ссылка и self в замыкании будет сильной ссылкой.

Lazy var кстати пишется так:

lazy var getProp: String = {
}()

Очевидно что свифт вы знаете плохо, судя по тому что вы писали здесь iOS SDK тоже посредственно, если взглянуть на ваш код здесь думаю что про кодстайл вы и не слышали.

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


#26

Можно также Ваш совет, по проблеме в коде? Если есть мысли. Спс


#27

При чем тут разбор моего кода? Представьте, что он вам достался от товарища, который его написал два года назад и полгода как уволился. Вы что скажете тимлиду код плохой, дайте другой?

Я задал простой вопрос: вы гарантируете, что после внесения изменений в код не забудете поставить unowned self?


#28

Я предложу его рефакторить, именно так поступают с быдлокодом.

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


#29

Мда. Рефакторить? А кто за это будет платить?))) Заказчик? Он подумает, что вы прикалываетесь. Работодатель? А если это не один класс, а целая гроздь классов в десятки тысяч строк кода? Тоже предложите отрефакторить? За свой счет, дома, когда напишете заявление об увольнении.

Насчет гарантий - вот этого и следовало ожидать)))


#30

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


#31

Юноша, вы с фриланса? В компаниях как раз и рефакторят, так как часто это приложение остается компании на поддержку и развитие. Я скажу еще одно ужасное слово… Они еще и тестами код покрывают, чтобы не возникало таких глупых ситуаций. Тесты отлично документируют код для будущих разработчиков. Если тесты писать как TDD, то можно вообще не париться, что приложение развалится из-за случайного быдлокодера


#32

Из javascript он и видимо не подозревает что ARC появился ещё в Objc и люди уже собаку съели на утечках и цикла сильных ссылок.


#33

Тогда понятно. Там вроде еще и с наследованием пляска. Вроде как наследник при изменении своих свойств, меняет свойства родителя и это может затронуть всех других наследников родительского класса