Я так понял, он хочет напихать в проект мусорных методов, чтобы заставить multidex работать

а вот он понял

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

GMS/Firebase.

все возможные support library

кто нибудь работал с coordinator layout и скрывающимся при скроле тулбаром? столкнулся с проблемой - хочу закрепить вьюшку внизу, а она начинает кататься вместе с тулбаром. Можно ли ее как нибудь закрепить?

ооо бля стартаперы подьехали))

вам сюда: https://t.me/mobile_jobs

ооо бля стартаперы подьехали))

Мне кажется норм так искать рабов для выполнения чьих нибудь mvp

Но при этом рабу не платить,а бабло с заказчика брать

Народ кто нибудь знает как можно быстро обходить битмап попиксельно?) Чтобы яркость каждого пикселя можно было дёрнуть...

Может откроешь документацию и сам посмотришь?

хахаххахаха

чувак, завязывай с аудиосообщениями, ну неудобно же

тем более с дурацкими

завязывай с аудиосообщениями

и флудить

@DenisIzmaylov админ приди, порядок наведи

@Molbert

зачитай еще

@InjectViewState Забань его чтоль

@InjectViewState Забань его чтоль

кого?

кого?

Igor

ну и иди в чат по ноде

задолбал он меня

ещё мне звонит

ушел в бан короче

❤️

Самое оптимальное (может и не простое)решение будет - делать minApi 19 - и заюзать MediaCodec - отправлять nal-чанки потоком. Ну или записать в файл MediaRecoder-ом и аплоадить на сервак. В любом случае у медиа-фреймворка - точно было настроечка "задать битрейт" В обмен на потерю качества - можешь зажимать скок хочешь Ну и плюс - аппаратная обработка всего этого добра. Прям из коробки

Спасибо, так и делал (юзал MediaRecorder и указывал битрейт) но столкнулся с тем что не все телефоны умеют записывать в разрешениях, которые выдал метод getSupportedVideoSizes / getSupportedPreviewSizes + нельзя заранее узнать, поддерживается ли H.265 кодек например в обоих случаях будет крэш с нативным сишным кодом ошибки + хотелось бы более тонкую настройку кодека иметь, как в ffmpeg т.к. на full hd (а некоторые телефоны отказываются снимать в чем-то кроме full hd) битрейт меньше 5-7 Mbps выглядит очень печально имхо это оверкилл, и много трафика съест при заливке на сервер таким образом, даже не знаю стоит ли юзать MediaRecorder API, слишком уж много проблем но сжатие на лету - очень вкусно и заманчиво конечно может правильнее после записи видео стандартной камерой уже сжимать чем-то? попробовал ffmpeg, но почему-то дико медленно сжималось

Задумался: много вьюх, которые наследуются от кастомного textview. Всегда использовал для тач эвента var imm = (InputMethodManager)context.GetSystemService("input_method"); imm.ToggleSoftInputFromWindow(view.WindowToken, ShowSoftInputFlags.Forced, 0);

Но был ли более простой способ вызывать клавиатуру, наследуясь от textview?

Народ кто нибудь знает как можно быстро обходить битмап попиксельно?) Чтобы яркость каждого пикселя можно было дёрнуть...

придётся конвертнуть в array

Народ кто нибудь знает как можно быстро обходить битмап попиксельно?) Чтобы яркость каждого пикселя можно было дёрнуть...

а зачем?

придётся конвертнуть в array

так это вроде как уже аррей

можно же bitmap.getPixel(x,y)

а зачем?

мне нужно посчитать среднюю яркость по картинке, а потом посчитать среднеквадратичное отклонение каждого пикселя от средней яркости ^_^

вы бы для этого либы использовали, всё же реализовано уже.

мне нужно посчитать среднюю яркость по картинке, а потом посчитать среднеквадратичное отклонение каждого пикселя от средней яркости ^_^

а зачем это делать на андройде?

а зачем это делать на андройде?

оценка качества изображения перед распознаванием

вы бы для этого либы использовали, всё же реализовано уже.

надо так) заказчик требует

можно же bitmap.getPixel(x,y)

юзай getPixel потом прикрутишь либу в след версии

юзай getPixel потом прикрутишь либу в след версии

2 прохода по 8мпкс картинке это пара минут выйдет

тогда opencv

что бы вы ни сделали в java, у вас выйдет пара минут

что бы вы ни сделали в java, у вас выйдет пара минут

ну от языка это не зависит просто такую хрень софтварно делать всегда не аллё

особенно на андройде

ещё как зависит. на плюсах сильно быстрее сработает. Но вообще да, opencv

2 прохода по 8мпкс картинке это пара минут выйдет

тебе не надо делать проход по 8mpx картинке сожми пикчу то 512x512

ещё как зависит. на плюсах сильно быстрее сработает. Но вообще да, opencv

нет не быстрее )

"а вот в плюсах все быстрее..."

"а вот в плюсах все быстрее..."

особенно отладка

ага

ща захоливарим про медленность джавы

и выяснится что посоны пишут java-говнокод и он медленно работает или используют java 1.5

@ikomarov я тебе гист закоментил там. Какой смысл вырубать встроенный механизм синхронизации в скайлате и делать свой через ринтран лок а потом его врубать? Ты думаешь это даст огромный прирост в перфоманс склайта?

да норм джава) насчёт сильно быстрее я погорячился, правда.

есть какая-нибудь стабильная либа, реализющая свайп для закрытия активити. как в android версии телеграма?

ERROR: S client not available

есть какая-нибудь стабильная либа, реализющая свайп для закрытия активити. как в android версии телеграма?

Я юзал Slidr, работает

Народ кто нибудь знает как можно быстро обходить битмап попиксельно?) Чтобы яркость каждого пикселя можно было дёрнуть...

Ща конечно скажут "ТЫ ЗАДОЛБАЛ" - но .... .... ? бери RenderScript - для этого его и придумали

Я юзал Slidr, работает

круть, спасибо

нет не быстрее )

а у тебя есть основания так говорить? я как-то по умолчанию считаю что длинную математику надо в нэйтив-часть, но может я ошибаюсь? расскажи

@InjectViewState

понаехали флудерасты

всем привет, делаю приложениенаподобие трекера может быть кто подскажет как правильнее сделать определение старта и финиша движения устройства? желательно только через gps данные, без activityrecognition? особенно интересуют моменты например остановка на светорфоре, как правильнее такое обрабатывать?

или хотя бы в какую сторону копать?

а у тебя есть основания так говорить? я как-то по умолчанию считаю что длинную математику надо в нэйтив-часть, но может я ошибаюсь? расскажи

ну я писал computer vision на джаве в 2007, было ок джава скидывает матан в найтив

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

хардкор вычисления делаются на видеокартах быстро засчёт распараллеливания, но это уже были не мои проблемы

в джаве тока эксепшоны тормозят по скорости операций

понятно, спасибо

Народ кто нибудь знает как можно быстро обходить битмап попиксельно?) Чтобы яркость каждого пикселя можно было дёрнуть...

https://medium.com/@qhutch/android-simple-and-fast-image-processing-with-renderscript-2fa8316273e1

https://smartapps.egeniq.com/speed-up-the-computations-of-your-android-app-by-writing-renderscript-code-7c36280a8bc1

понятно, спасибо

кароче как это было в 2005

https://ru.vingrad.com/Ocherednyye-dannyye-o-medlennosti-JAVA-id50bb516e6ccc19b03703c2e7

щас все ещё лучше

https://medium.com/@qhutch/android-simple-and-fast-image-processing-with-renderscript-2fa8316273e1

спасибо, ща покопаемся

Спасибо, так и делал (юзал MediaRecorder и указывал битрейт) но столкнулся с тем что не все телефоны умеют записывать в разрешениях, которые выдал метод getSupportedVideoSizes / getSupportedPreviewSizes + нельзя заранее узнать, поддерживается ли H.265 кодек например в обоих случаях будет крэш с нативным сишным кодом ошибки + хотелось бы более тонкую настройку кодека иметь, как в ffmpeg т.к. на full hd (а некоторые телефоны отказываются снимать в чем-то кроме full hd) битрейт меньше 5-7 Mbps выглядит очень печально имхо это оверкилл, и много трафика съест при заливке на сервер таким образом, даже не знаю стоит ли юзать MediaRecorder API, слишком уж много проблем но сжатие на лету - очень вкусно и заманчиво конечно может правильнее после записи видео стандартной камерой уже сжимать чем-то? попробовал ffmpeg, но почему-то дико медленно сжималось

Ну ... смотри - тут есть два подхода Максимально нативный Максимально свой Максимально нативный (Плюсы): Практически не влияет на размер apk(всё уже на борту) Хардварная реализация: соответственно - скорость, потребление батареи, ну и вендор лучше работает со своим железом. Официальный Android API - то есть минимум порога вхождения в код (Минусы): Всё довольно низко уровнего, много писанины. Соответственно чем ниже - тем больше девайсо-зависимости соответственно придется подыскивать битрейты и резолюшны - максимально популярные. Ну тоесть нащупывать какие-то усредненные значения, приемлимые всем. Мало гибкости и тюнинга - ибо никогда не знаем какие HW Capabilites доступны, либо покрывать всё свичами на конкретные модели у стройств Максимальной свой (или 3rd part): Плюсы Свобода действий, модификации - код полностью твой. Возможно это будет очень популярное,авторитетное с++ решение в целом в мире разработки (как н-р ffmpeg). Возможно даже меньше кода писать придется. Поддержка всего что позволяет либа, девайсо-независимо. Минусы Очень большая прибавка к размеру апк. Очень долгий билд всего этого добра. Часто очень медленная в итоге работа (потому что всё CPU разгребает, соответственно бешеный расход батареи) В итоге выглядит это всё как слон в посудной лавке. Порог вхождения в такой код - высокий(надо знать плюсы, плюсовые либы, и весь NDK - CMake билдабельно конфигурабельные геморои)

Приветствую, есть ли пример, ScrollView + ConstraintLayout, вообщем надо ConstraintLayout который скроллится

и в чём проблема?

раньше был баг, но его починили

Сделал ScrollView(корень) -> Constrainlayout, но не скроллится пока не поставишь руками Сonstrainlayout заведомо большой размер, например, 500dp. Размер Сonstrainlayout явно больше размера экрана, внутри есть фрагменты которые вставляются в ViewPager, но т.к. скролл не работает, часть контента Сonstrainlayout невидно.

Ну ... смотри - тут есть два подхода Максимально нативный Максимально свой Максимально нативный (Плюсы): Практически не влияет на размер apk(всё уже на борту) Хардварная реализация: соответственно - скорость, потребление батареи, ну и вендор лучше работает со своим железом. Официальный Android API - то есть минимум порога вхождения в код (Минусы): Всё довольно низко уровнего, много писанины. Соответственно чем ниже - тем больше девайсо-зависимости соответственно придется подыскивать битрейты и резолюшны - максимально популярные. Ну тоесть нащупывать какие-то усредненные значения, приемлимые всем. Мало гибкости и тюнинга - ибо никогда не знаем какие HW Capabilites доступны, либо покрывать всё свичами на конкретные модели у стройств Максимальной свой (или 3rd part): Плюсы Свобода действий, модификации - код полностью твой. Возможно это будет очень популярное,авторитетное с++ решение в целом в мире разработки (как н-р ffmpeg). Возможно даже меньше кода писать придется. Поддержка всего что позволяет либа, девайсо-независимо. Минусы Очень большая прибавка к размеру апк. Очень долгий билд всего этого добра. Часто очень медленная в итоге работа (потому что всё CPU разгребает, соответственно бешеный расход батареи) В итоге выглядит это всё как слон в посудной лавке. Порог вхождения в такой код - высокий(надо знать плюсы, плюсовые либы, и весь NDK - CMake билдабельно конфигурабельные геморои)

Может апи какое-то есть, которое бы отдавало хотя б поддерживаемые разрешения и кодеки для всех моделей устройств? типа devicespecifications.com (у него нет апи) Тогда можно б было без опаски словить креш в рантайме заюзать MediaRecorder наверное

и в чём проблема?

Если есть пример, разметки, был бы благодарен