фейсайди, пушнотификации, фоновые вычисления, кеширование состояния приложения это неполный список фич нашего ПВЗ и даже свистелка есть, в общем не так легко затащить через Web. А так согласен, для приложения аля стартап бери и пиши на чем хочешь
Проблема xib и storyboard еще в том что 1. системе их надо парсить, держать в памяти - время и ресурсы 2. связь с кодом (вызов событий или переходов на экраны) не гарантирует отсутствия эксепшенов и ошибок, чето переименовали - перестало просто работать, отсутствуют проверки на этапе компиляции короче
Теорию могут заучить почти все. Применять эту теорию на практике могут немногие.
а как вы это делаете? Я не совсем понял. Вот есть вроде намек на "дополнительные вопросы", но вы сказали что они задаются "если ответ не нравится", значит у вас какие то ожидания от кандидата есть, технические, что если например вы ждете от кандидата, что он вам расскажет про барьеры в очередях, а он знает лучшее решение в организации цепочек запросов в сеть с помощью Promise? Вроде дичь, вот уже Combine есть, но в конкретной задаче Combine хуже справится, и как оценить тогда такой ответ?
Еще есть кейс, что после одного из ваши собесов сольют в сеть "правильные ответы" и будут появляться кандидаты, которым не нужно вообще задавать вопросов, потому что они чешут от зубка, как опытные синьеры. Как с этим боритесь?
Вы очень крутую вещь подсказали в статье: "иногда я меняю условия" вот это реально помогает определить софты, а вот про отсев нежелательных личностей, можете пояснить? Как он происходит? Как вы определяете не подходящего для вашей команды человека?
Спасибо большое за дополнение. Но получается, что #Preview теперь уже точно не компилируется? Потому что до SDK iOS 17 все попадало в билд и уже вычищалось во время архивации, соответственно нам пришлось обрамлять своими макросами такие превью, так как их компиляция могла задействовать моки, которые складываются в некомпилируемые пакеты и соответственно на CI возникала ошибка компиляции, теперь этого можно избежать с помощью такого макроса?
Мне статья помогла понять, как кастомизировать данные для переходов на экраны. Спасибо. Так же я сделал форк, чтобы продемонстрировать передачу параметров на экраны (это важный момент) и кроме того добавил диплинки, потому как использовать координатор имеет смысл именно совместно с диплинками, ссылка ниже на форк https://github.com/sofbix/NaviTest
Вы правы, так спасти жизни можно, фича действительно моргинальная, не сколь своим явлением, сколь реализацией. Если залезть под капот SDK Localise, то там обнаруживается Swizzling, работа с Notification Center, обязывание разработчиков обновлять текстовые сообщения в специальном методе. Хочется такой SDK не использовать.
Руковожу в общей сложности с 2013, когда твой отдел достигает 25 людей, то ваще не до признания, и честно говоря, не помню чтобы возникало желание засветиться еще до внедрения, после внедрения и получения профита было дело, хочется делиться своими наработками, скоро про это напишу, кстати. Если бы следующее предложение прочитали после первого, то получили внятный ответ о моем участии в выборе стеков, так то надо мной руководитель тоже есть.
Все впорядке, дружище. Мы выпустили нативку в сентябре, рейтинг приложения с тех пор вырос, пользователи стали более довольны, акции растут. Правильный выбор сделали, главное что результат есть
Вы видимо не часто пишите движки рендеринга на эпловские продукты, раз не видите проблем в рендеринге для такой компании как Google. Может тогда Google в легкую напишет альтернативу iOS? И Apple с этим ничего не будет делать?
Зачем увеличивать штат еще больше у нас полно нативщиков так то, зачем вкладывать в технологии, которые не привели команду к успеху?, чтобы что? Я просто не понимаю, вам нравится Дарт и вы хотите чтоб Озон тоже на Дарте писал? Ну да, у нас зрелая компания которая мониторит рынок, смотрит скорость разработки продукта и знает во что вкладывать, а во что нет. Наш выбор вам кажется необоснованным, наверное у вас другая компания аля стартапа (я писал об этом), полно разработчиков Flutter, которые лезут в форточку готовы получать меньше нативщиков и задачи не требуют написания кучи плагинов и потом их еще поддерживать, нативный мир то тоже не стоит на месте
В SwiftUI встречается множество косяков, но в целом он намного приятнее для разработки и ревью кода, есть даже подозрение что верстка начиная на нем с iOS 14 меньше ресурсов тратит, чем AutoLayout и соответственно меньше тормозов. Когда вы выбираете что то отличное от MVC то на UIKit это выглядит костыльно, а здесь полная свобода и Combine помогает вам с реактивщиной даже. Если вам хочется крутых кастомизаций, то помогают backports, но чем дальше вы от iOS 13, тем их меньше будет.
Спасибо за ссылка, интересно всегда мнение со стороны узнать.
Распространение языков очень интересное, если смотреть ту же статистику сравнения Dart и Kotlin по странам, то создается впечатление что у KMM и Flutter не только разные цели но и разный контингент.
Way not? на Qt тоже круто попробывать, был недавний опыт. А ведь все эти V/H/Z-Stack в верстке пошли именно благодаря их наработкам. Только с каждой итерацией переработок подобных технологий происходит закрытие недостатков и новые фишки появляются.
Вопрос индивидуален, чем то лучше и Flutter в зависимости от проекта, я поэтому и привел сравнительную табличку с нативом, и привел область применения Flutter, где он сможет быть 100% полезyнее. Однако из реакции на статью я заключил, что к примеру банки пытаясь сэкономить и стараясь выглядить уникальными зачастую делают свои приложения на Flutter, которые тоже неплохо вписываются в общую тусовку.
Я согласен про инфраструктуру полностью, она немного утяжеляет нововведения. Когда в компании были борцы за Flutter, естественно они и инфраструктуру пытались модернизировать и успешно частично. И Веб затащить пытались, но я не знаю по какой причине не вышло у них изначально, не могу прокомментировать. Так что от части это наш случай - не стало борцов с целой системой, не стало и Flutter - но только от части, это один из 5-и пунктов, и он так же есть в статье.
>>Правильно, предложить вернуться к проверенной и надежной схеме. Не вернуться, приложение изначально было на Flutter, это дало старт и быстрое развитие со своими нюансами. Вы правы, про "наш опыт" до конца не донесено видимо, это видно и по другим коментам, другие тоже думают что мы туда сюда переписываем, пожалуй стоит немного подправить статью.
>>Были проблемы со "сканером штрихкодов", "анимацией на iOS" и системой хранения на hive. Что-то ещё можете добавить? Это все что я по опросам смог выудить по проекту ПВЗ, по опыту других товарищей (из стартапов) могу еще добавить "Странный рендеринг на iOS", когда пиксели вдруг лезут, ну то есть картинка становилась мутненькой, может сами разработчики накосячили где, я не стал это приводить в статье, но подозреваю, что "свой рендеринг" это тоже не гуд вообще, это как я писал - надо постоянно оптимизировать движек и поспевать еще и за Apple кроме своих проблем с Android.
Странно, при попытки диалога и попытке обьяснить другими словами вас минусуют, это шутка? может вы хотябы прокоментируете свою реакцию? смайликом или еще как
Тоже об этом думал. Смотря какой прототип, иначе говоря, если прототип будет состоять из различных применения всевозможных аппаратных датчиков, камер, акселерометров и прочее, +это должно работать лучше чем у всех, то тут без нетива никак, ну а если документооборот то годно. Лично свои прототипы я тоже пишу на одной из платформ, для опробации достаточно будет, позже можно масштабировать на другие.
Менеджмент из бизнеса не интерисуются такими ньюансами, которые изложены в статье, эти ньюансы скорее интересны вам как разработчику и прожект менеджеру максимум, чтобы не допустить элементарную ошибку в расчетах, которую вы допустили: "3 - 4 разработчика на платформу (итого 6 - 8, а на Flutter обычно в два раза меньше)", почитайте комментарии, даже те кто зачем-то рьяно защищают Flutter (будто я на него напал) не считают что 2 нативных разработчика = 1 Flutter разработчику. Это все рано, что полагать, что 9 женщин родят ребенка за месяц.
На данном этапе развития KMM естественно не могильщик, я предположил что его развитие в перспективе может просто потеснить сильно Flutter, как это было с другими эффектными мультиплатформами в прошлом. Compose сделают и будет вам UI на KMM, сделали же для Андройда, у нас зашло, рекомендую кстати вам как человеку, который и в нативной разработке могет.
Вернусь к бизнесу, так вот бизнес смотрит на фундаментальные показатели: сроки (ага нтивка тянет быстрее, значит пока флатеристы баги правит в чужих компонентах эти преуспеют, надо скорее пересаживаться на рельсы), качество (не надо думать что свои сотрудники стерпят любое качество приложения, мы вообще то следим за отзывами и ходим в ПВЗ сами, интересуемся что сотрудников не устраивает). И еще есть фундаментальные показатели глобальные, а они говорят за тренд сменяемости, потому что любой мультеплатформе надо поспевать и обогнать конкурентов и поспевать за изменениями в нескольких платформах - такая нагрузка рано или поздно станент отказонеустойчивой. Вы серьезно думаете что один Dart c Flutter хотябы нагонит всех-всех?
фейсайди, пушнотификации, фоновые вычисления, кеширование состояния приложения это неполный список фич нашего ПВЗ и даже свистелка есть, в общем не так легко затащить через Web. А так согласен, для приложения аля стартап бери и пиши на чем хочешь
Проблема xib и storyboard еще в том что
1. системе их надо парсить, держать в памяти - время и ресурсы
2. связь с кодом (вызов событий или переходов на экраны) не гарантирует отсутствия эксепшенов и ошибок, чето переименовали - перестало просто работать, отсутствуют проверки на этапе компиляции короче
Теорию могут заучить почти все. Применять эту теорию на практике могут немногие.а как вы это делаете? Я не совсем понял.
Вот есть вроде намек на "дополнительные вопросы", но вы сказали что они задаются "если ответ не нравится", значит у вас какие то ожидания от кандидата есть, технические, что если например вы ждете от кандидата, что он вам расскажет про барьеры в очередях, а он знает лучшее решение в организации цепочек запросов в сеть с помощью Promise? Вроде дичь, вот уже Combine есть, но в конкретной задаче Combine хуже справится, и как оценить тогда такой ответ?
Еще есть кейс, что после одного из ваши собесов сольют в сеть "правильные ответы" и будут появляться кандидаты, которым не нужно вообще задавать вопросов, потому что они чешут от зубка, как опытные синьеры. Как с этим боритесь?
Вы очень крутую вещь подсказали в статье: "иногда я меняю условия" вот это реально помогает определить софты, а вот про отсев нежелательных личностей, можете пояснить? Как он происходит? Как вы определяете не подходящего для вашей команды человека?
Спасибо большое за дополнение. Но получается, что
#Previewтеперь уже точно не компилируется? Потому что до SDK iOS 17 все попадало в билд и уже вычищалось во время архивации, соответственно нам пришлось обрамлять своими макросами такие превью, так как их компиляция могла задействовать моки, которые складываются в некомпилируемые пакеты и соответственно на CI возникала ошибка компиляции, теперь этого можно избежать с помощью такого макроса?Мне статья помогла понять, как кастомизировать данные для переходов на экраны. Спасибо.
Так же я сделал форк, чтобы продемонстрировать передачу параметров на экраны (это важный момент) и кроме того добавил диплинки, потому как использовать координатор имеет смысл именно совместно с диплинками, ссылка ниже на форк
https://github.com/sofbix/NaviTest
Вы правы, так спасти жизни можно, фича действительно моргинальная, не сколь своим явлением, сколь реализацией. Если залезть под капот SDK Localise, то там обнаруживается Swizzling, работа с Notification Center, обязывание разработчиков обновлять текстовые сообщения в специальном методе. Хочется такой SDK не использовать.
Руковожу в общей сложности с 2013, когда твой отдел достигает 25 людей, то ваще не до признания, и честно говоря, не помню чтобы возникало желание засветиться еще до внедрения, после внедрения и получения профита было дело, хочется делиться своими наработками, скоро про это напишу, кстати. Если бы следующее предложение прочитали после первого, то получили внятный ответ о моем участии в выборе стеков, так то надо мной руководитель тоже есть.
Все впорядке, дружище. Мы выпустили нативку в сентябре, рейтинг приложения с тех пор вырос, пользователи стали более довольны, акции растут. Правильный выбор сделали, главное что результат есть
Вы видимо не часто пишите движки рендеринга на эпловские продукты, раз не видите проблем в рендеринге для такой компании как Google. Может тогда Google в легкую напишет альтернативу iOS? И Apple с этим ничего не будет делать?
Зачем увеличивать штат еще больше у нас полно нативщиков так то, зачем вкладывать в технологии, которые не привели команду к успеху?, чтобы что? Я просто не понимаю, вам нравится Дарт и вы хотите чтоб Озон тоже на Дарте писал? Ну да, у нас зрелая компания которая мониторит рынок, смотрит скорость разработки продукта и знает во что вкладывать, а во что нет. Наш выбор вам кажется необоснованным, наверное у вас другая компания аля стартапа (я писал об этом), полно разработчиков Flutter, которые лезут в форточку готовы получать меньше нативщиков и задачи не требуют написания кучи плагинов и потом их еще поддерживать, нативный мир то тоже не стоит на месте
В SwiftUI встречается множество косяков, но в целом он намного приятнее для разработки и ревью кода, есть даже подозрение что верстка начиная на нем с iOS 14 меньше ресурсов тратит, чем AutoLayout и соответственно меньше тормозов. Когда вы выбираете что то отличное от MVC то на UIKit это выглядит костыльно, а здесь полная свобода и Combine помогает вам с реактивщиной даже. Если вам хочется крутых кастомизаций, то помогают backports, но чем дальше вы от iOS 13, тем их меньше будет.
Спасибо за ссылка, интересно всегда мнение со стороны узнать.
Распространение языков очень интересное, если смотреть ту же статистику сравнения Dart и Kotlin по странам, то создается впечатление что у KMM и Flutter не только разные цели но и разный контингент.
Согласен, надо исправиться. Я прокоментирую, когда Update накачу.
Way not? на Qt тоже круто попробывать, был недавний опыт. А ведь все эти V/H/Z-Stack в верстке пошли именно благодаря их наработкам. Только с каждой итерацией переработок подобных технологий происходит закрытие недостатков и новые фишки появляются.
Вопрос индивидуален, чем то лучше и Flutter в зависимости от проекта, я поэтому и привел сравнительную табличку с нативом, и привел область применения Flutter, где он сможет быть 100% полезyнее. Однако из реакции на статью я заключил, что к примеру банки пытаясь сэкономить и стараясь выглядить уникальными зачастую делают свои приложения на Flutter, которые тоже неплохо вписываются в общую тусовку.
Я согласен про инфраструктуру полностью, она немного утяжеляет нововведения. Когда в компании были борцы за Flutter, естественно они и инфраструктуру пытались модернизировать и успешно частично. И Веб затащить пытались, но я не знаю по какой причине не вышло у них изначально, не могу прокомментировать. Так что от части это наш случай - не стало борцов с целой системой, не стало и Flutter - но только от части, это один из 5-и пунктов, и он так же есть в статье.
>>Правильно, предложить вернуться к проверенной и надежной схеме.
Не вернуться, приложение изначально было на Flutter, это дало старт и быстрое развитие со своими нюансами. Вы правы, про "наш опыт" до конца не донесено видимо, это видно и по другим коментам, другие тоже думают что мы туда сюда переписываем, пожалуй стоит немного подправить статью.
>>Были проблемы со "сканером штрихкодов", "анимацией на iOS" и системой хранения на hive. Что-то ещё можете добавить?
Это все что я по опросам смог выудить по проекту ПВЗ, по опыту других товарищей (из стартапов) могу еще добавить "Странный рендеринг на iOS", когда пиксели вдруг лезут, ну то есть картинка становилась мутненькой, может сами разработчики накосячили где, я не стал это приводить в статье, но подозреваю, что "свой рендеринг" это тоже не гуд вообще, это как я писал - надо постоянно оптимизировать движек и поспевать еще и за Apple кроме своих проблем с Android.
Странно, при попытки диалога и попытке обьяснить другими словами вас минусуют, это шутка? может вы хотябы прокоментируете свою реакцию? смайликом или еще как
Тоже об этом думал. Смотря какой прототип, иначе говоря, если прототип будет состоять из различных применения всевозможных аппаратных датчиков, камер, акселерометров и прочее, +это должно работать лучше чем у всех, то тут без нетива никак, ну а если документооборот то годно. Лично свои прототипы я тоже пишу на одной из платформ, для опробации достаточно будет, позже можно масштабировать на другие.
Compose на подходе в KMM. А так согласен, Xamarin тоже пользовал, пока KMM типо того.
А вы бизнесмен? Разработчик? Чтобы понимать на каком языке обьяснить было проще.
Менеджмент из бизнеса не интерисуются такими ньюансами, которые изложены в статье, эти ньюансы скорее интересны вам как разработчику и прожект менеджеру максимум, чтобы не допустить элементарную ошибку в расчетах, которую вы допустили:
"3 - 4 разработчика на платформу (итого 6 - 8, а на Flutter обычно в два раза меньше)", почитайте комментарии, даже те кто зачем-то рьяно защищают Flutter (будто я на него напал) не считают что 2 нативных разработчика = 1 Flutter разработчику. Это все рано, что полагать, что 9 женщин родят ребенка за месяц.
На данном этапе развития KMM естественно не могильщик, я предположил что его развитие в перспективе может просто потеснить сильно Flutter, как это было с другими эффектными мультиплатформами в прошлом. Compose сделают и будет вам UI на KMM, сделали же для Андройда, у нас зашло, рекомендую кстати вам как человеку, который и в нативной разработке могет.
Вернусь к бизнесу, так вот бизнес смотрит на фундаментальные показатели: сроки (ага нтивка тянет быстрее, значит пока флатеристы баги правит в чужих компонентах эти преуспеют, надо скорее пересаживаться на рельсы), качество (не надо думать что свои сотрудники стерпят любое качество приложения, мы вообще то следим за отзывами и ходим в ПВЗ сами, интересуемся что сотрудников не устраивает). И еще есть фундаментальные показатели глобальные, а они говорят за тренд сменяемости, потому что любой мультеплатформе надо поспевать и обогнать конкурентов и поспевать за изменениями в нескольких платформах - такая нагрузка рано или поздно станент отказонеустойчивой. Вы серьезно думаете что один Dart c Flutter хотябы нагонит всех-всех?