Pull to refresh
23
0
Татьяна @IrixV

IOS developer

Send message

Да, есть такое. Руководство и HR пытается нас развлечь, но часто это похоже на спектакль для людей, у которых горит дом)).

Вполне годная статья для первоначального знакомства с корутинами. Спасибо.

Спасибо за статью
Можно объяснять с точки зрения принципов, а можно — с точки зрения целей, это не совсем одно и тоже. Объяснять с точки зрения соблюдения принципов неплохо, потому что все принципы произошли из неких производственных необходимостей, и созданы для того, чтобы решать проблемы. Если человек это понимает — этого достаточно, если нет — начинаются споры о исполнение принципов ради самих принципов и т.п.

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

Случайно наткнулась на статью, от души посмеялась . Люблю людей, которые не боятся обидеть чувства верующих, ну и в целом, обладают здравомыслием.

В CoreData создание связи между объектами всегда сопровождается созданием инверсии. Поэтому фраза «если вы используете инверсию» аналогична фразе «если вы используете CoreData». Если у вас есть какой-то интересный опыт с CoreData memory management, и вы знаете в каких ситуациях возникают утечки и как этого избежать — напишите отдельную статью или подробный комментарий, будет интересно.
У меня не было намерений описывать все детали CoreData. Это невозможно в одной статье. Здесь набор пунктов, «которые я считаю важными или недостаточно освещенными в туториалах».
Про циклические связи я не писала. Инверсия — это не циклическая связь, она обеспечивает внутренний механизм кеширования и докачки данных в CoreData, и никак не меняет связанность таблиц. Если же вы реально используете циклические связи в базе — то это ваше право и ваши проблемы.
Про Parent Entity я не писала, и не рекомендовала их использовать. Это полезная вещь, которая может уменьшить количество кода. Но основная проблема — это усложнение понимания структуры данных. Так что здесь нужно тщательно взвешивать свое решение. Использовать Parent Entity имеет смысл только, если у вас действительно большое количество кода в классе, и, главным образом, много совпадающих полей. Есть также несколько статей, о проблемах с performance при использовании Parent Entity. Я этот момент не проверяла лично, допускаю, что такое возможно. Но в целом, при правильном проектировании базы, выборки из одной или из двух таблиц, или фильтры не должны серьезно влиять на производительность. Даже если у вас миллионы записей в локальной базе (что очень маловероятно), вы вряд ли сможете почувствовать разницу, разбив одну таблицу на две или наоборот.
Спасибо, это очень важное замечание, использовать «конструктор» удобнее и безопаснее, так как не требуется выполнять приведение типов. Уж не знаю, как и почему я упустила эту важную деталь, внесу исправления в статью по вашему комментарию.
Добрый день. Можете пояснить ситуацию, почему:
class RestRequest: NSMutableURLRequest {
}

let request = RestRequest() // падает
let request = NSMutableURLRequest() // работает

На ObjectiveC как-то без сюрпризов с конструктором
Спасибо, пригодилось!
А LinkedIn jobs ваше приложение? Оно очень странно притормаживает при прокрутке таблицы с вакансиями, такое ощущение, что оно не нативно написано? Автолайот точно таких тормозов не даст на простейшей таблице.
Согласна, чем больше можно убрать из контроллера, тем лучше. Даже применяя чистое MVC, можно добиться неплохой читабельности кодов. А если еще и VIPER добавить, то можно убрать дублирующие коды. Конечно, хорошо планировать архитектуру заранее, чтобы потом не возится с переделками. Но когда нет постановки задачи и нет трудовых ресурсов — без переделок никак не получается.
Спасибо за статью,
Интереует ваше мнение по ахитектуре MVC:
Как разделить контроллер и модель данных, кто из них должен посылать запрос серверу:
1) Можно повесить это на модель, но при этом нужно показывать индикатор активности(крутилку) пользователю и блокировать какие-то кнопки — а это делает контроллер.
2) Другой вариант – это послать запрос на контроллере, и полученные данные передать модели в блоке завершения.
Сочту за комплимент). На самом деле, у них есть чему поучиться, и иногда хочется понять как все это выглядит изнутри, и особенно пристально поразглядывать архитектурные паттерны больших проектов, потому что такой опыт трудно получить «по учебникам». Ну а в целом, мне очень нравится делать свои проекты самостоятельно или в маленькой команде, проектов уже немало.)
Посмотрела тест по IOS. Вполне объективный. Нашла 2 ошибки, куда прислать скриншоты?
К сожалению, ни UICollectionView, ни тем более UITableView в базовом исполнении не дают необходимой производительности, даже если не использовать AutoLayout. Столкнулась с этим, когда делала приложение для автомобильного форума. Что делает UITableView если в несколько ячеек подряд затолкать по 50 фотографий в перемешку с разноформатным текстом — очень сильно дергает экран, а в худшем случае приложение падает. Но, спасибо FB за его бесценные библиотеки.
Два дня разбираюсь с работой геолокации в фоновом режиме.
На IOS7 геолокация работает все время пока программа загружена, даже если она свернута.

На IOS8 и IOS9 геолокация работает около 18 минут после сворачивания, потом режим background переходит в режим suspend и все глохнет.
Я что-то делаю неправильно, или получить данные от свернутой программы невозможно через XX минут?

Также вызывают вопросы некоторые другие особенности работы геолокации. Без установки фильтра на расстояние, запросы идут каждую секунду. После установки фильтра 2 запроса и далее молчание ( если я не двигаюсь). Как-то оба варианта не очень.

Пробовала allowDeferredLocationUpdatesUntilTraveled, выдает ошибку с кодом 12.

Буду очень благодарна, если кто-то поделится опытом по этому поводу.
Спасибо за статью. А можно ли ссылку на игру? Расскажите, пользуетесь ли еще какими-либо инструментами, кроме unity? Blender'ом например или чем-то еще? Как создаете воду/огонь и т.п., как редактируете и оптимизируете шейдеры. Вопросов очень много, так что буду с нетерпением ждать следующую статью.
Также очень интересует информация по срокам, сколько времени заняло у вас создание игры (или оценочно займет), и сколько людей участвует в создании.
Ну и, конечно, хочется пожелать вам огромной удачи в этом нелегком и рискованном деле!

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity