Я бы добавил в README инструкций как завести вашу библиотеку под proguard, а то он выпиливает все ваши контрактные public void onOperationFinished(ResultType) методы как неиспользуемые
Бегло почитал документацию, с ходу не нашел, может подскажите:
— в каком контексте выполняется операция? сервис?
— есть ли доступ к Context внутри операции?
— если захватить этот контекст ничего не потечет?
— очередь выполнения операций последовательная или параллельная? есть ли возможность влиять на параллельность? что-нибудь вроде тредпулов? Если запустить 100 операций — очередь не забьется?
— можно ли задавать операциям приоритет?
— как я понимаю, никакого IPC?
Спасибо
Спасибо за статью, я всё никак не мог понять, по какому принципу монитор мне окрашивал эти точки. Ну т.е. понятно, что красный цвет это плохо, но как он определял, что такое-то время measure/layout/draw это уже много было загадкой :)
От себя бы добавил:
1. Если нужно заполнить место каким то холдером/пустым местом, есть специальная вьюшка Space, которая участвует в процессах measure/layout, но ничего не рисует, тем самым не отнимает ресурсов.
2. Бывают случаи, когда нужно нарисовать сложный, но не очень изменяемый layout и в таких случаях есть смысл подумать: «а не написать ли мне свой ViewGroup с легким и быстром measure/layout/draw процессом»
Это не всегда так. К примеру, RelativeLayout'у приходится выполнять measure-процесс 2 раза и если он содержит детей со сложным measure-подсчетом, то он может оказаться медленнее, чем несколько других более «простых» ViewGroup.
По моему какая то сумбурная статься получилась. Конечно AsyncTask не подходят для длительных операций, если Вы их запускаете и храните в Activity. Конечно Robospice подходит для длительных операций, если использует сервис для их выполнения. Никто не мешает запустить AsyncTask в сервисе. Никто не мешает запустить сервис в отдельном процессе. А о каких асинхронных запросах вообще речь? Если HTTP/REST, то тут только ленивый не написал своего решения :) Уже упоминался Volley, я тоже его порекомендую: очередь с приоритетами, кеширование, можно использовать для картинок, можно подсовывать любой HTTP-stack, от UrlConnection до OkHttp. Только не понятно тогда, почему Вас интересуют длительные запросы. Pdf-ку скачать?
У операторов бомбит от того, что при таком большом распространении интернет-телефонии и IM все их тарифы на мобильную связь и смс идут лесом, т.к. юзер может позвонить хоть на другой конец света по скайпу и туда же отправить сообщение через hang out просто за цену интернет-доступа.
Шанс выпадения орла на каждом отдельном броске 0,5. Шанс получить последовательность из трех орлов при трех бросках 0,125 (0,5 ^ 3), потому что всего различных последовательностей из трех бросков 8 (2^3).
Если говорить в целом про автоматизацию, а не только про модульное/системное тестирование, то можно упомянуть и про статический анализ кода. Из своего опыта: gradle из коробки умеет запускать lint, а дженкинс, в свою очередь, через соответствующий плагин умеет отчеты от lint публиковать. Для gradle и для дженкинса еще есть плагины findbugs, checkstyle, pmd, которые можно тоже включить в процесс CI, отправляя письма и включая зелёную/красную лампочки :)
Полностью согласен. Работа с MediaPlayer в андроиде доставляет в первую очередь боль. Из своего опыта: в реализации плеера на многих самсунгах методы getDuration() и getCurrentPosition() могут возвращать что угодно, только не duration и position (проигрывали ауди и видео стримы). Что бы OnBufferingUpdateListener и OnErrorListener возвращали что-то вменяемое вместо 0 и MEDIA_ERROR_UNKNOWN остается только мечтать.
— в каком контексте выполняется операция? сервис?
— есть ли доступ к Context внутри операции?
— если захватить этот контекст ничего не потечет?
— очередь выполнения операций последовательная или параллельная? есть ли возможность влиять на параллельность? что-нибудь вроде тредпулов? Если запустить 100 операций — очередь не забьется?
— можно ли задавать операциям приоритет?
— как я понимаю, никакого IPC?
Спасибо
От себя бы добавил:
1. Если нужно заполнить место каким то холдером/пустым местом, есть специальная вьюшка Space, которая участвует в процессах measure/layout, но ничего не рисует, тем самым не отнимает ресурсов.
2. Бывают случаи, когда нужно нарисовать сложный, но не очень изменяемый layout и в таких случаях есть смысл подумать: «а не написать ли мне свой ViewGroup с легким и быстром measure/layout/draw процессом»
Это не всегда так. К примеру, RelativeLayout'у приходится выполнять measure-процесс 2 раза и если он содержит детей со сложным measure-подсчетом, то он может оказаться медленнее, чем несколько других более «простых» ViewGroup.