Миллионы мух не могут ошибаться и для мелких проектов выбирают fabric.io А можно самому купить VDS и все логи отправлять туда

лучший вариант? пасибки

юзал кто app.crittercism.com? какой беслптаный сервис по ловле эксепшенов лучше всего? мб кто-нибудь что-нибудь посоветует

https://firebase.google.com/docs/crash/

Тоже вариант, если есть время разобраться

Всем привет, меня тут спросили и я не знаю что ответить "Скажи, пожалуйста, можно как-то посмотреть какие действия выполняются на Gmail и с какого устройства?"

К почте есть доступ у 20+ человек

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

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

Ты ведь слышал про кэши изображений?

Самый тупой пример: для всяких аватарок и превьюшек битмапы хранят в LruCache - я его, например, выношу в синглтон. Глайды и прочие Пикассо делают примерно так же.

это самое эффективное решение? интересно вот стало как решить задачу за минимально возможное время

это самое эффективное решение? интересно вот стало как решить задачу за минимально возможное время

У тебя есть другие варианты как передать кучу объектов, кроме как "засунуть их в оперативную память, участок которой будет виден всем"?

оперативная память конечна

я в основном работаю с китайскими телефонами, где 1 гб - максимум

70-80% оперативки занято

я бы в кеш выбросил ввидей файлов

я в основном работаю с китайскими телефонами, где 1 гб - максимум

Если у тебя огромные файлы - тогда лучше диска для тебя ничего нету

окей, спасибо большое, тогда так и сделаю

Блин, зашел на developer.android.com/training/articles/perf-tips.html и там пишут типа use enchanced for loop syntax. Видео еще не смотрел.

Сеттеры и геттеры действительно настолько сильно влияют на производительность? Придётся приучиться в джаве использовать public-поля по возможности :(

хмм, а я давно их по alt + enter слздаю.

Сеттеры и геттеры действительно настолько сильно влияют на производительность? Придётся приучиться в джаве использовать public-поля по возможности :(

Гугл говорит, что внутри класса использовать прямое обращение, а не через геттера-сеттеры.

Гугл говорит, что внутри класса использовать прямое обращение, а не через геттера-сеттеры.

Не, ну внутри-то понятно, но вот снаружи это тоже наверное на перфоманс влияние оказывает?

Ой.

Не, ну внутри-то понятно, но вот снаружи это тоже наверное на перфоманс влияние оказывает?

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

Ну не настолько же всё плохо.

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

Привет

Что это?

Что это?

Скорее всего, надо деактивировать предыдущую версию

А ты какую версию в манифесте, тьфу, в билд.грэдл указал?

Воу

Про сеттеры интересно

А ты какую версию в манифесте, тьфу, в билд.грэдл указал?

2, 1.1

Предыдущая была 1,0, 1

Скорее всего, надо деактивировать предыдущую версию

А почему так?

Я на 100% не уверен, но по-моему, если две версии приложения полностью совпадают с точки зрения требований к железу/разрешениям/версиям API - то гуглплей заставляет отключать более старую перед публикацией новой

Т.е. смысл держать опубликованной версию 1.0, если все равно 100% пользователей увидят версию 1.1

а если нужно 2 разных версии поддерживать, API 16 и API 19, плей умеет их раздавать или нужно отдельно загружать? (два разных приложения заводить)

Насчет версий API я не уверен, может и фигню сморозил(

Щас вот глянул, у нас у одного приложения опубликованы одновременно аж 4 версии приложения)

а если нужно 2 разных версии поддерживать, API 16 и API 19, плей умеет их раздавать или нужно отдельно загружать? (два разных приложения заводить)

Да, умеет

В таком случае, правда, маркет лихорадит немножко и он показывает в поле "Версия Android" значение "Зависит от устройства"

Одна под API 5-7, две под 8+ (отличаются только набором требуемых функций и разрешений) и одна (ныне разрабатываемая) 15+

Щас вот глянул, у нас у одного приложения опубликованы одновременно аж 4 версии приложения)

Странно, столько раз публиковал приложения и не замечал)

Да, умеет

два флавора делать? загружать подряд обе с разными version code ?

два флавора делать? загружать подряд обе с разными version code ?

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

Странно, столько раз публиковал приложения и не замечал)

Ну вообще все логично) Вот допустим в приложении не изменился API level, но добавилась работа с геолокацией) Логично опубликовать новую версию, но и оставить старую для тех, у кого внезапно нет GPS)

А поделитесь докой, если кто такое делал. Я что-то в самом интерфейсе консоли не нашел.

а если нужно 2 разных версии поддерживать, API 16 и API 19, плей умеет их раздавать или нужно отдельно загружать? (два разных приложения заводить)

А поддерживать = прям разрабатывать и выпускать новые версии?

Т.е. вы параллельно пилите новые версии и для 16, и для 19?

А поддерживать = прям разрабатывать и выпускать новые версии?

угу, правда это в основном какие-то фиксы, не зависящие от функционала, требующего более новых версий апи

По-моему, в таких случаях нет никаких тонкостей, все равно все само разрулится на уровне совместимости девайсов

Но уникальность кода версии надо, конечно, поддерживать

Поэтому, тут версионирование по принципу "код версии 1, название версии 1.0", "код версии 2, название версии 1.1" уже не пойдет

Точнее, заработает, но будет хаос :)

хм, ок

Мы используем названия версий по такому шаблону: 2.3.1

Соответственно, код для такой версии будет выглядеть как-то так: 2030199

99 - условно, номер билда)

а как считают номер сборки?

Позволяет, собственно, гарантировать уникальность версий и выпускать апдейты для старых версий

Учитывая, что я могу билдить что-то каждые 5 минут, использовать я это не особо собираюсь, но узнать интересно :)

Тут не совсем-то) в последних цифрах обычно у нас номер сборки, которую мы выкатили в тестирование

Т.е. в гуглплее у нас, например, версия 2.2.0

Соответственно, первый раз, когда мы собрали сборку с новой минорной функциональностью, залили ее в Fabric и тестеры уже могут ее оттуда вытягивать, они увидят как номер версии что-то в духе "2.2.1.rc1"

А код этой версии будет 2020101

ERROR: S client not available

Тестеры, допустим нашли баги, мы их пофиксили, плюс доделали че-нибудь еще - выкатываем очередную версию в тестирование - 2.2.1.rc2, код 2020102

И так далее, пока не катим релиз. В релизе уже фиксируем номер версии последнего релиз-кандидата, но это уже непринципиально :) Гуглплею уже пофиг на последние цифры, т.к исходя из нашего процесса, у нас туда никогда не должны попасть две версии с одинаковыми первыми тремя цифрами)

Естественно, если нет тестеров, то можно ограничиться 2-3 цифрами и этого хватит за глаза

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

Естественно, если нет тестеров, то можно ограничиться 2-3 цифрами и этого хватит за глаза

Вы версии через Fabric распространяете? Мне просто он не очень понравился (не функционал, а внешний вид). Я вообще не занимался публикацией альфа/бета версий. Какие плюсы у системы тестирования фабрик по сравнению с гугл плей?

Вы версии через Fabric распространяете? Мне просто он не очень понравился (не функционал, а внешний вид). Я вообще не занимался публикацией альфа/бета версий. Какие плюсы у системы тестирования фабрик по сравнению с гугл плей?

Только тестовые сборки

В гугл плей льем руками)

Fabric у нас в основном ради crashlytics

Только тестовые сборки

Да, я о тестовых. Видимо, не заметил когда писал текст

А вот почему именно он - затрудняюсь сказать, так еще до меня было)

А вот почему именно он - затрудняюсь сказать, так еще до меня было)

А как именно у вас проходит коммуникация между тестерами и разрабами? Если можно поподробнее)

Вроде у фабрика какая-то подсистема для фидбэка есть А самое простое - это когда тестер отписывает разработчику в телеграм или куда-то ещё, что у него не так и как он это делал

Народ, заметил странную штуку, у меня при первом открытии экранов (фрагментов в табах) они как буд-то подлагивают. Systrace показал подвисание на 1 сек, там нет ничего такого, нет графики почти, никаких зависимосте, может кто знает где искать проблему?

Причем все последующие открытия - моментальные

Т.е. так единоразово

А как именно у вас проходит коммуникация между тестерами и разрабами? Если можно поподробнее)

Да все просто) Просто приходят и говорят) Либо отписываются в канал в Slack)

Но в конечном итоге все равно все заканчивается таской в JIRA

Ну и чтоб никого не путать - мы Fabric юзаем для сбора крэшей (Crashlytics), но тут тестеры ни при чем, крэши разработчики чаще всего смотрят сами. А для тестеров мы юзаем Beta (тоже штука в составе Fabric), которая позволяет тестерам быстро получать новые тестовые сборки.

Т.е. Fabric непосредственно для поиска ошибок у нас тестеры не юзают

widget_player не пустой

0 поменяй на ченить другое 231231 например, прокатит ?

0 поменяй на ченить другое 231231 например, прокатит ?

не прокатило(

не прокатило(

А в чем проблема?

Ты знаешь что, ради эксперимента задай свой ремоут вью напрямую в поле объекта нотификации

Я как то раз тоже проблем наелся с этим всем

Ты знаешь что, ради эксперимента задай свой ремоут вью напрямую в поле объекта нотификации

не сработало

Notification notificationBuilder = new NotificationCompat.Builder(this) .setSmallIcon(R.drawable.ic) .setContentTitle("text") .setTicker("text") .setContentText("text") .build();

Попробуй без контента

если сработает копай свой layout

да, так работает, спасибо)