короче проблема такая - отлавливаешь ввод в делегате текстфилда, reload таблицу - соотв. для текстфилда вызывается didEndEditing - а нужно поведение такое, будто бы мы вводим - и ячейка эта не меняется - меняются только результаты ниже

пробовал сразу вызывать becomeFirstReponder для этого тестфилда - некрасиво получается

5 айфон + клавиатура + стандартный автокомплит + ячейка с полем = почти нет места

короче проблема такая - отлавливаешь ввод в делегате текстфилда, reload таблицу - соотв. для текстфилда вызывается didEndEditing - а нужно поведение такое, будто бы мы вводим - и ячейка эта не меняется - меняются только результаты ниже

Не вариант просто над клавиатурой показать поле?

я примерно понимаю в чем дело. Пока идет переход, видимо система все еще смотрит на свойство prefersStatusBarHidden у fromVC, поэтому рисует навбар без учета статусБара. Потом, когда я вызываю у контекста completeTransition, то главным контроллером становится toVC, система понимает, что в нем prefersStatusBarHidden = false и спешно увеличивает размер навбара

prefersStatusBar(Style|Hidden) довольно бесячая вещь, особенно если у твоего дизайнера хорошо с фантазией (и прозрачные, и транслюкент навигейшн бары, и спрятать статусбар, и перекрасить. Так что самое простое, хотя и немного грязное решение, это в плисте VC-depended статусбар = false, и в рутовом контроллере уже баловаться со статусбаром как душа пожелает.

prefersStatusBar(Style|Hidden) довольно бесячая вещь, особенно если у твоего дизайнера хорошо с фантазией (и прозрачные, и транслюкент навигейшн бары, и спрятать статусбар, и перекрасить. Так что самое простое, хотя и немного грязное решение, это в плисте VC-depended статусбар = false, и в рутовом контроллере уже баловаться со статусбаром как душа пожелает.

спасибо, попробовал это решение. А вообще именно в моем случае проблема локализовалась за счет того, что нашел вот этот пост: http://blog.jaredsinclair.com/post/61507315630/wrestling-with-status-bars-and-navigation-bars-on или более конкретно вот этот абзац: UINavigationController will alter the height of its UINavigationBar to either 44 points or 64 points, depending on a rather strange and undocumented set of constraints. If the UINavigationController detects that the top of its view’s frame is visually contiguous with its UIWindow’s top, then it draws its navigation bar with a height of 64 points. If its view’s top is not contiguous with the UIWindow’s top (even if off by only one point), then it draws its navigation bar in the “traditional” way with a height of 44 points. This logic is performed by UINavigationController even if it is several children down inside the view controller hierarchy of your application. There is no way to prevent this behavior. Вобщем чтобы навигейшнБару понять, что он должен быть 64, а не 44 по высоте, ему надо быть прижатым к верху. А в моей анимации перехода в начальном положении между верхом экрана и toVC было расстояние. Решил проблему тем, что сначала поместил toVC вверху, потом тут же переместил куда мне надо, и уже потом запустил анимацию перехода. Но вот как до этого догадаться, не перешерстив пололовину Интернета...

Oh shie~

а вот по поводу >undocumented set of чего--нибудь это эппл умеет. Для меня вот до сих пор загаддка, что это было: NC->LoginVC делаешь popLoginVC, push AnotherVC в котором "H:|[view]-[NC1]-[NC2]|", у NC1 бар transcluent. Получаем забавный эфект - VC1 внутри NC1 содержит скролл, который уезжает не под бар в 64pt, а как будто бар - 44pt, т.е. примерно на середине тайтла

уже у всего что движется выставил automaticallyAdjustsScrollViewInsets в false, у всего что не движется - двигал и выставлял в false, перекопал пол интернета

проблема решила (барабанная дробь) удалением LoginVC из икскода и заливанием его по новой.

а вот по поводу >undocumented set of чего--нибудь это эппл умеет. Для меня вот до сих пор загаддка, что это было: NC->LoginVC делаешь popLoginVC, push AnotherVC в котором "H:|[view]-[NC1]-[NC2]|", у NC1 бар transcluent. Получаем забавный эфект - VC1 внутри NC1 содержит скролл, который уезжает не под бар в 64pt, а как будто бар - 44pt, т.е. примерно на середине тайтла

ну бар вообще и есть 44pt ))

ну бар вообще и есть 44pt ))

А статусбар посчитать?)

ну с ним да

ага

а иос считал, что его по высоте нет

и скролил под translucent бар лишние 20 pt

А у меня вроде всегда так и считается)

я всегда прибаляю высоту статусбара к высоте навигейшн бара

проблема решила (барабанная дробь) удалением LoginVC из икскода и заливанием его по новой.

а дело оказалось в том, что когдато (!) при сохранениии LoginVC (!!) похерились вот эти галочки

¯\_(ツ)_/¯

)))

я всегда прибаляю высоту статусбара к высоте навигейшн бара

А?) что? зачем?)

А?) что? зачем?)

Ну вот у меня всегда 44 пункта высота возвращается)

Ну вот у меня всегда 44 пункта высота возвращается)

нет, я не спрашивал у него высоту

ааа, понял)

видимо, проще скрином показать будет

надо было вот так

а получалось так

шакалы съели скрины, простите

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

У Рамблера для Viper был генератор.

У Рамблера для Viper был генератор.

Generamba вроде назывался

Generamba вроде назывался

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

Core data. Кто-нибудь делал асинхронную запись в базу и одновременное отображение добавляемых данных через fetched results controller? Мой код работает отлично в ios 10, и выдает странные ошибки в ios 8. Мой стек состоит из двух основных контекстов: фоновый backgroundContext, соединенный с persistent store coordinator и основной mainContext в главном потоке, соединенный с предыдыщим через parentContext. . Каждая очередная добавляемая асинхронно порция даных создает третий уровень - еще один фоновый контекст, ссылающийся на родителя- mainContext. В общем, такая схема довольно известная. Вопрос в том, что apple такого запилили с coredata в ios 10, что все работает, чего нет в ios 8?

Я нашел баг! Дело в том, что в коде по инициализации NSFetchedResultsController я производил сохранение UI контекста mainContext, чтобы вставленные на текущий момент записи перенеслись в backgroundContext. Убрал этот код - и вуаля! На ios 8 программа не вылетает... Однако затем я опять переклюсился на ios 10.2. И вспомнил, зачем я это сохранение делал. Без него в консоль шпарят предупреждения "CoreData: error: API Misuse: Attempt to serialize store access on non-owning coordinator". Хотя программа и не вылетает... То ли вставить проверку на версию ios для этого куска кода? Кто-нить сталкивался с такой ошибкой? ( CoreData: error: API Misuse: Attempt to serialize store access on non-owning coordinator )

Возможно. Но тут явная зависимость от версии ios. Без этого кода под ios 8 все работает збс (без всяких предупреждений). На 10 - сыпятся эти ворнинги. Если на 10 этот код вернуть (который я нашел на stackoverflow) - ворнинги пропадают и программа опять возращается в рабочее состояние.

Виню, ибо на стеке про такие вещи писали "..it's a known bug.."

Вот только все это коррелирует с тем, что я наблюдаю на практике.

баг в коде а не в версиях ios

у меня с 8 до 11 работает все нормально

а я с 9 до 6 работаю

и все нормально

сочувствую

6 поддерживать не очень легко

А меня удивляет то, как можно утверждать, что нет разницы между версиями, когда 1) баг проявляется только при смене версии симулятора с чистой программой) 2) Про изменение механизма работы с sql базой в 10 ios apple сама писала с упором на улучшение асинхронной работы. Кроме того, у меня пока не получилось изолировать проблему в чистом проекте с БД из 2 таблиц, т.к в простом примере баг не воспроизводится.

Значит есть еще какие-то существенные нюансы

я про 6часовой рабочий день😉

У всех такое в бете? (эмулятор xcode 9)

неа

Опять странное утверждение, особенно не видя кода) Предположим, я писал код чисто под ios 8. Никаких багов нет. Программа работает стабильно и правильно. Появляется ios 10 - и код внезапно становится кривым, а версия ios оказывается тут не при чем. Вот так логика)

Ты пьян иди домой

эмулятор

Эмуляторов нет, поэтому и троит

да

Запусти на симуляторе, там норм

сложно, однако, бетой пользоваться, но киллерфич сильно много

кто-то уже юзает ARkit?

мне интересно пойдет ли кто-то дальше говнодемок

Вот кстати еще один пример бага кор даты, если ни разу с ними не встречался. https://stackoverflow.com/questions/11990279/core-data-do-child-contexts-ever-get-permanent-objectids-for-newly-inserted-obj

свифтеров

я правильно понимаю, что свифт в том виде каком сейчас находится так и останется до конца времен? И глоабльных изменений каких-то скорее всего не будет? (только не надо налетать на меня с сообщениями типа а что тебе не нравится в нынешнем свифте)

да

особых ломающих изменений синтаксиса уже не будет

они даже новые конструкции очень нехотя добавляют

Мне не нравится в swift отсутствие поддержки siri. Чтобы можно было надиктовывать описание программы, а она за меня код писала

ну с тобой спорить по поводу свифта бесполезно

Делаю редизайн с айфона на ipad версия есть не понятный момент.

cell.myImage.layer.cornerRadius = cell.myImage.frame.height/2

я делаю округление, на айфоне все норм но на айпаде она не округленная в дебаге смотрю height приходит 48

Если изначально она квадратная)

не смотря на то что это айпад

дочитайте пожалуйста товарищи )

почему приходит 48 а не 60 ?

в каком методе?

Эта строка

cellforatindexpath

[:

есть какие предложения ?

эмммм )