О да, это полезная штука, особенно для тестов. С помощью этих команд можно точку входа менять (интенты) - что всякие тесты по сути и делают из студии. Ещё memsys полезно очень
Проверю ещё раз, спасибо. Но мне оно как-то в мат формуле плюс с с минусом местами попутало, тут сложно сказать что ее просили придумать в векторном то произведении
Не знаю, я пробовал с ним (в смысле с gpt) разобраться в одной задаче, он меня запутал - терял контекст, менял ответы, дал вообще противоположный. В общем мне не понравилось. Но вот тесты на простые классы (не те где есть прям очень интересная логика) он пишет действительно неплохо, но контекст все же теряет - правда юзал я 3.5 модель (платную), не 4.
Я когда-то проходил стажировку в финтехе Тинькофф, и могу сказать что там самый крутой подход - там начитывали лекцию (как в универе), рассказывали об основных возможностях и давали задачу на выполнение, ты делаешь - ищешь решения, разбираешься, тебя ревьюрят после сдачи задачи. И все бесплатно. И даже сертификат выдали :)
Мтс, вы серьезно? Если с книгой Android. Программирование для профессионалов я согласен - сам ее читал и вкатывался по ней - то все остальное просто уже устарело. Лучше бы ссылки на коделабы от Гугла приложили, толку было бы больше...
Не стыдно за такую то статью? На собесах то наверное не про эти книги спрашиваете же?
С публикацией библиотек есть нюансы, исходников не будет (или как минимум туда не вынесешь изменения) и если вдруг вы поймаете баг, то искать его то ещё удовольствие...
П.с. я не уверен (у нас чуть другой подход), но чтобы не публиковать другие модули должны подойти compileOnly/debugOnly/api.
Как же это круто! Спасибо! Хоть сам давно не ковыряю железки и вообще остановился на avr/mcs-51, но прочитал с удовольствием. Особенно кусок про запуск, как же это знакомо...
Во-во, я о том же написал. Сам логику сборки из groove в kt plugin перенес по подобию nio, в целом удобно получилось - теперь его можно публиковать на локальный maven repo и просто подключать в любом проекте.
Хорошая и большая статья, но есть все же несколько очень важных но:
Не упомянут dispatcher main.immediate (а у него есть одно очень важное свойство, не просто так он используется в lifecycle scope, про viewmodel scope на память не помню). И из этого вытекает:
Не рассказано про старт корутин, а это очень важно. И из этого вытекает:
Корутин билдеры не используются для старта корутин, точнее не всегда используются - яркий пример это lazy старт корутин. Так же они не принимают блок кода который будет выполнен асинхронно - это управляется контекстом (dispatcher и scheduler)
И самое главное!!! cancel() не прерывает и не прекращает выполнение coroutine, иначе не рекомендовали бы использовать yeld(). + Не рекомендовали прокидывать cancellation exception из try catch. Ну и cancelAndJoin() появился не просто так...
Мьютекс и семафор в принципе единственное что там есть. Все остальные примитивы синхронизации используют пакеты jvm и в мультиплатформе не применимо из-за этого. Варианты flow и каналов не рассматриваем, они хоть и потокобезопасны, но вот как на них сделать потокобезопасную коллекцию я не представляю. Да и вообще синхронизировать доступ к произвольной переменной.
Там уже есть пример от сообщества на kotlin через js + flutter активно развивают.
Да, я попробовал qt, тяжело даётся после kotlin. И не сам язык, а, скажем так, архитектура приложения. И обучающих туториалов очень мало к сожалению.
Switch в M3 уже не отличается особо от iOS версии
Ещё можно всякие утечки памяти там смотреть - activity, view. Но я не часто пользуюсь, если честно.
Единственное что мне больше нравится это gfx вместо полос на экране для кадров.
О да, это полезная штука, особенно для тестов. С помощью этих команд можно точку входа менять (интенты) - что всякие тесты по сути и делают из студии. Ещё memsys полезно очень
Проверю ещё раз, спасибо. Но мне оно как-то в мат формуле плюс с с минусом местами попутало, тут сложно сказать что ее просили придумать в векторном то произведении
Ты чего такой токсичный то? Я не сильно верю в улучшения после того как оно мне несуществующую либу предложило :)
Не знаю, я пробовал с ним (в смысле с gpt) разобраться в одной задаче, он меня запутал - терял контекст, менял ответы, дал вообще противоположный. В общем мне не понравилось. Но вот тесты на простые классы (не те где есть прям очень интересная логика) он пишет действительно неплохо, но контекст все же теряет - правда юзал я 3.5 модель (платную), не 4.
@DropDrage Там свой version Catalog будет, чисто kt-ный (вроде бы этот toml файл groovy не понимает)
Там есть автодополнения в kt файлах, в целом мне понравилось больше чем чем groovy (но я сами скрипты не писал никогда, делал переезд с groovy на kt)
Плюс всю вашу логику можно будет аккуратно вынести в плагины, выглядеть будет симпатичнее.
Но первый раз переезд может занять время, там есть неочевидные (по крайней мере для меня) моменты
Я когда-то проходил стажировку в финтехе Тинькофф, и могу сказать что там самый крутой подход - там начитывали лекцию (как в универе), рассказывали об основных возможностях и давали задачу на выполнение, ты делаешь - ищешь решения, разбираешься, тебя ревьюрят после сдачи задачи. И все бесплатно. И даже сертификат выдали :)
Мтс, вы серьезно? Если с книгой Android. Программирование для профессионалов я согласен - сам ее читал и вкатывался по ней - то все остальное просто уже устарело. Лучше бы ссылки на коделабы от Гугла приложили, толку было бы больше...
Не стыдно за такую то статью? На собесах то наверное не про эти книги спрашиваете же?
С публикацией библиотек есть нюансы, исходников не будет (или как минимум туда не вынесешь изменения) и если вдруг вы поймаете баг, то искать его то ещё удовольствие...
П.с. я не уверен (у нас чуть другой подход), но чтобы не публиковать другие модули должны подойти compileOnly/debugOnly/api.
Дааа, вот он хабр где комментарии можно как вторую статью читать :)
Как же это круто! Спасибо! Хоть сам давно не ковыряю железки и вообще остановился на avr/mcs-51, но прочитал с удовольствием. Особенно кусок про запуск, как же это знакомо...
Да у самого андроида есть утечки внутри - тот же тост или soundpool захватывают ссылки на контекст внутри.
Looper.prepare() это сильно, я не сразу вспомнил что оно в Handler Tread использовалось при переопределении.
Как совет более полезны были бы leek canary, meminfo и mem dump profiler для поиска. Знать про gc при этом много не надо.
Во-во, я о том же написал. Сам логику сборки из groove в kt plugin перенес по подобию nio, в целом удобно получилось - теперь его можно публиковать на локальный maven repo и просто подключать в любом проекте.
10-ке об этом расскажите, она любит запускать его процесс на каждый чих
Да ладно, норм там в целом. Финтех Тинькофф много кому путевки в it дал.
А чем подход Гугла из nio не подошёл? Наделать kt файлов в buil-logic модуле и подключать их как плагины. Вроде норм решение же.
Но надо переезжать с groove, что в общем-то проблема только в первый раз.
Хорошая и большая статья, но есть все же несколько очень важных но:
Не упомянут dispatcher main.immediate (а у него есть одно очень важное свойство, не просто так он используется в lifecycle scope, про viewmodel scope на память не помню). И из этого вытекает:
Не рассказано про старт корутин, а это очень важно. И из этого вытекает:
Корутин билдеры не используются для старта корутин, точнее не всегда используются - яркий пример это lazy старт корутин. Так же они не принимают блок кода который будет выполнен асинхронно - это управляется контекстом (dispatcher и scheduler)
И самое главное!!! cancel() не прерывает и не прекращает выполнение coroutine, иначе не рекомендовали бы использовать yeld(). + Не рекомендовали прокидывать cancellation exception из try catch. Ну и cancelAndJoin() появился не просто так...
Мьютекс и семафор в принципе единственное что там есть. Все остальные примитивы синхронизации используют пакеты jvm и в мультиплатформе не применимо из-за этого. Варианты flow и каналов не рассматриваем, они хоть и потокобезопасны, но вот как на них сделать потокобезопасную коллекцию я не представляю. Да и вообще синхронизировать доступ к произвольной переменной.