Ну да, в случае смены конфигурации лоадер тот же, а если все уходит в background то прибивается вместе с ui, если нужно чтобы такого не было то IntentService в помощь (ну или обычный сервис). Если же речь идет о запросах то тут volley классный врапер. В любом случае они используют статические переменные для хранения результата, так что чем-то похоже на вашу реализацию.
Ну и что? execute у AsyncBean тоже 2 раза нужно будет вызывать. С id проблему не вижу, ну есть он и есть, внутри отдельного фрагмента коллизия не возникнет :)
Кажется понял, для AsyncBean идентификаторы должны быть уникальны для всего приложения, поскольку они хранятся как статическое поле, а для лоадеров они уникальны только в пределах LoaderManager'a, который привязан к фрагменту или активити. Поэтому там все проще.
На счет Bundle'ов согласен с вами, действительно многобукоф, неудобно.
Не вижу в чем проблема с AsyncTaskLoader. Id будет хранится как обычная константа, этот идентификатор как раз определяет какая из задач сейчас выполняется. Сериализовывать тоже ничего не надо, зачем? Результат будет хранится в самом лоадере.
Честно говоря не понял зачем нужная такая сложная логика внутри UidGenerator для генерации айдишников AsyncBean. Но там кстати используются интерфейс Application.ActivityLifecycleCallbacks доступный только с 14 версии, а те же Loaders доступны в support-library v4.
AsyncTaskLoader все же проще, потому что он сам (точнее LoaderManager) следит за жизненным циклом фрагмента или активити к которому привязан (не надо будет писать, то что у вас в BaseActivity в методах onSaveInstanceState, onPause, onResume), не надо отдельно создавать AsyncTask, не нужно париться на счет сериализации.
Да, вы правы. Тогда какой-либо из Acer Aspire V5-131 или ASUS X201E. К сожалению это все глянец, но по цене рядом найти матовый экран сложно. i3 тоже там за эти деньги уже не получится, но celeron или pentium все равно будут быстрей.
Про игры написал как единственный плюс A6 перед тем же 3217U (ну еще и цена конечно же).
На практике у сопоставимых по бюджету моделей в Intel решениях будет DDR3 10600, а не 12800, используемого здесь.
Высокая частота памяти — особенность Kabini как гибридного процессора, от этого напрямую зависит производительность видеокарты в играх.
В целом получается, что процессор выигрывает только в графике, но с учетом того что вы все равно не играете, то из достоинств, как уже сказал, остается цена. Как по мне, лучше взять что-нибудь подороже и матовое, например Lenovo IdeaPad S210. С установкой 16 Гб памяти под ваши нужды проблем быть не должно. Ну и всё будет работать шустрее, разве плохо?
Сравнивать с ноутбуками на CPU от Intel не вижу никакого смысла, так как это вообще решения разного уровня. Всем, кто понимает зачем нужен Linux, кто читал «Код» Чарльза Пецольда и понимает как оно работает, будет ясно, что 4 ядра Kabini под Linux это вполне приемлемое решение в сравнении с 2 ядрами от мобильного Intel под Microsoft.
Пецольда не читал, но позволю с вами не согласиться :) Количество физических ядер очень редко в каких приложениях дает существенный прирост производительности, особенно если говорить о домашних десктопах. А в этом плане у АМД не все так хорошо, удельная производительнось ядра гораздо ниже. По вашей ссылке с cpuboss это видно. Ничего против АМД не имею, но к сожалению это факт. Как плюс остается встроенное графическое ядро, но по сути играть во что-то серьезное на таком ноутбуке смысла никакого нет.
Мы можем положить зависимости рядом с нашим jar. Но тогда неизбежны конфликты библиотек разных версий, например, если мы используем одну версию support library, а в самом приложении другая. Тогда придется руками одну из них удалять.
А разве в этом случае нам не нужно просто положить support library с последней версией которую используют другие библиотеки или наше приложение? Там же нет чего-либо ломающего обратную совместимость со старыми версиями.
Вообще идея интересная, но не совсем понятно на счет неиспользуемых классов во фреймворках. Прогард может провести агрессивную оптимизацию, например если библиотека инстанциирует объекты через рефлекшн и потом в райнтайме упадет ClassNotFoundException в стороннем sdk.
И еще про саму тему поста. Аспекты конечно это мощная штука, но по-моему для решения такой проблемы в большинстве проектов достаточно придерживаться простых правил, которыми почему-то пренебрегают, например: стараться делать классы неизменяемыми (item 15) и всегда задавать значение по умолчанию, никогда не возвращать null вместо пустой коллекции (item 43), использовать паттерн special case описанный у Фаулера, которым и является по сути Optional и Collections.empty*(). Естественно это не всегда возможно в силу каких-то причин, но опять же в большинстве случаев таким образом можно устранить подавляющее число ошибок связанных с NPE (и не только!) и сделать код более красивым и читабельным.
Спасибо за статью, особенно за список источников.
Не надо ничего наследовать. Посмотрите пожалуйста код внимательней. У Optional два статических метода для создания объектов: of для не пустого значения и absent для нулевого и получается что-то вроде:
Optional<BigInteger> value = someService.getAmout();
showValueToUser(value.or(BigInteger.ZERO));
Выгода на первый взгляд не очевидна, но читается первый вариант приятней, что уже неплохо. В скале конечно это все выглядит намного лучше с паттерн матчингом.
Это было бы просто замечательно) Вообще хотелось бы наверное услышать о преимуществах/недостатках/проблемах/особенностях/фишках JVM при работе с многоядерными машинами. Как это сейчас в ней реализовано и есть ли какие механизмы по дополнительной настройке или какие-либо хаки, чтобы повысить утилизацию многоядерных cpu. Какие есть альтернативы и сравнения с другими виртуальными машинами и/или платформами, например, с тем же эрлангом и его акторами (интересно было также услышать про CLR!). Еще было бы интересно узнать как от версии к версии в JVM была улучшена возможность масштабирования на машинах с большим количеством ядер, ну чтобы, например, можно было мотивировать заказчика на переход на седьмую джаву =) Как-то так…
Еще раз спасибо большое за доклады!)
В докладах «Методологии оптимизации производительности» и «Драконы в домашнем хозяйстве: скалируемся на многоядерных машинах» ожидал совсем другого. Было много технических деталей связанных с железом. Мне, как обычному разработчику, ни разу не приходилось спускаться на такой низкий уровень абстракции. Хотя доклады от этого хуже не стали =) Особенно понравилось сравнения стандартного механизма синхронизации и через локи пятой джавы.
На докладе про тестирование JavaFX приложений рассказывали про магическую тулзу Jemmy, которая на экране сама протыкивала все кнопочки и листбоксы, а для написания сего счастья вроде надо бы не так уж и много кода.
Кстати на докладе про Котлин, тоже было очень весело. Наверное на этой презентации было самое большое количество вопросов и ответов. Спасибо Андрею за интересную беседу!
или
разницы никакой, только в случае AsyncBean нужно еще обработать onSaveInstanceState/onPause/onResume, проверить savedInstanceState.
Не вижу в чем проблема с AsyncTaskLoader. Id будет хранится как обычная константа, этот идентификатор как раз определяет какая из задач сейчас выполняется. Сериализовывать тоже ничего не надо, зачем? Результат будет хранится в самом лоадере.
Честно говоря не понял зачем нужная такая сложная логика внутри UidGenerator для генерации айдишников AsyncBean. Но там кстати используются интерфейс Application.ActivityLifecycleCallbacks доступный только с 14 версии, а те же Loaders доступны в support-library v4.
Высокая частота памяти — особенность Kabini как гибридного процессора, от этого напрямую зависит производительность видеокарты в играх.
В целом получается, что процессор выигрывает только в графике, но с учетом того что вы все равно не играете, то из достоинств, как уже сказал, остается цена. Как по мне, лучше взять что-нибудь подороже и матовое, например Lenovo IdeaPad S210. С установкой 16 Гб памяти под ваши нужды проблем быть не должно. Ну и всё будет работать шустрее, разве плохо?
Пецольда не читал, но позволю с вами не согласиться :) Количество физических ядер очень редко в каких приложениях дает существенный прирост производительности, особенно если говорить о домашних десктопах. А в этом плане у АМД не все так хорошо, удельная производительнось ядра гораздо ниже. По вашей ссылке с cpuboss это видно. Ничего против АМД не имею, но к сожалению это факт. Как плюс остается встроенное графическое ядро, но по сути играть во что-то серьезное на таком ноутбуке смысла никакого нет.
А разве в этом случае нам не нужно просто положить support library с последней версией которую используют другие библиотеки или наше приложение? Там же нет чего-либо ломающего обратную совместимость со старыми версиями.
Вообще идея интересная, но не совсем понятно на счет неиспользуемых классов во фреймворках. Прогард может провести агрессивную оптимизацию, например если библиотека инстанциирует объекты через рефлекшн и потом в райнтайме упадет ClassNotFoundException в стороннем sdk.
Спасибо за статью, особенно за список источников.
ofдля не пустого значения иabsentдля нулевого и получается что-то вроде:вместо:
Выгода на первый взгляд не очевидна, но читается первый вариант приятней, что уже неплохо. В скале конечно это все выглядит намного лучше с паттерн матчингом.
Еще раз спасибо большое за доклады!)
На докладе про тестирование JavaFX приложений рассказывали про магическую тулзу Jemmy, которая на экране сама протыкивала все кнопочки и листбоксы, а для написания сего счастья вроде надо бы не так уж и много кода.
Кстати на докладе про Котлин, тоже было очень весело. Наверное на этой презентации было самое большое количество вопросов и ответов. Спасибо Андрею за интересную беседу!