gradlew dependencyUpdates — вроверяет и показывает какие зависимости могут быть обновлены, эта команда больше ничего не делает. Дальше вам руками нужно обновить. То есть вы бы уже точно знали какие библиотеки были обновлены.
Например:
The following dependencies have later milestone versions:
— com.android.support:support-annotations [19.1.0 -> 21.0.0-rc1]
— com.android.support:support-v4 [19.1.0 -> 21.0.0-rc1]
— com.fasterxml.jackson.core:jackson-annotations [2.3.3 -> 2.4.1]
— com.fasterxml.jackson.core:jackson-core [2.3.3 -> 2.4.1.1]
Что то не пойму, то есть вы и половины не используете из того что там написано?
В общем, что вам нужно:
1. указать конкретные версии для всех зависимостей (без +). Что бы избежать эти проблемы в будущем.
2. у вас уже стоит плагин gradle-versions-plugin. Поэтому что бы проверить на наличие новых версий, нужно запустить: gradlew dependencyUpdates
3. Обновить конкретные версии плагинов
Ух я смотрю у вас тут полный фарш, если вы это все осилили, почему тогда про + столько вопросов то?
У вас даже уже gradle-versions-plugin стоит, и все равно куча библиотек с + в версиях, почему?
> Пол рабочего дня, вместо того, чтоб писать код содержащий мою семью, я потратил на то, чтоб узнать что в одном месте вместо '+' надо поставить '0.10.1'.
Вот мне интересно, если разработка так важна для вас, что вы делали последние полтора года тогда?
Проблема с количеством dpi которые нужно поддерживать. Я не знаю сколько было разных dpi на симбиане, но подозреваю что одно, поэтому и проблем не было, так как рисовалось все 1 к 1.
Даже если и добавят поддержку svg, все равно нужно будет создавать svg отдельно для каждого dpi или как минимум для кратных.
Скажем есть у вас картинка c линией, на xhdpi она будет 2px, и она так же будет нормально показана на mdpi, линия будет 1px. Но вот уже на hdpi будут проблемы, так как нужно будет отрисовать 1.5px. Обычно в этом случае рисуется отдельный свг уже с правильной линией равной 1 или 2px, в зависимости что выглядит лучше.
Другая проблема, если много деталей на картинке, то она может хорошо выглядеть на xxhdpi, но отвратительно на mdpi. То есть снова нужна отдельная картинка.
Даже в этой статье подход не правильный (только, если конечно качество приложения не важно), картинка будет мыльная на большинстве dpi, так как все картинки штампуются из одного svg.
Я обычно создаю отдедельный svg для каждого разрешения и подгоняю их в ручную, что бы не было мыла. Если сильно лень, то тогда только для кратных dpi, то есть достаточно сделать две «правильных» картинки для xxhdpi и xhdpi и уже из них нарезать. Из xxhdpi нарезаются hdpi и ldpi, а из xhdpi: mdpi
Для конвертации svg в png пробовал:
1. imagemagic — качество картинки странное,
2. inkscape — качество картинки приемлемо, но вот хотелось бы только больше опций по управлению svg, например, поменять цвет определенного объекта, будь то слой или что то другое.
3. В итоге остановился на библиотеке batik (http://xmlgraphics.apache.org/batik/) качество достаточно приемлемое. Так как эта библиотека парсит весь svg, то вы по сути можете делать что угодно, менять цвета, изменять размеры линий и тд, затем растеризовать конечный svg в png. Но этот способ требует больше времени чем все остальные.
p.s. Но да, при наличие поддержки svg уже не нужно было бы конвертировать в png.
Ну а я то здесь причем? В посте на картинке моторола? Моторола. Начинали с моторолы? С моторолы.
То что фотографии выложили только несколько дней после новостей, кто виноват?
Хотите что то доказать/исправить, пишите автору темы пусть обновит картинки, на худой конец, напишите новую статью с обновленной информацией.
Спасибо.
1. картинка на которую вы ссылаетесь нет в этом посте, к тому же статья на которую вы ссылаетесь от 7 июля, а мой пост от 4го, так что у нас все телепаты в отпуске.
2. речь шла собственно о планшете в посте и она 1 в 1 как моторола xoom.
Я могу понять почему так случилось, просто потому что надо было что то показать и взять xoom это самый быстрый способ начать разрабатывать. А все остальное можно перенести уже потом, когда все готово на реальный планшет, каким бы он не был.
Планшет с картинки больше похож на Motorola Xoom. Тем более в aosp уже все драйвера для нее есть.
Кидается новая обоя и собирается все одной командой, а потом fastboot -w flashall
В качестве тренировки конечно классно написать свою библиотеку, но вот если начать использовать ее, то:
1. сильно многословная, что бы привести все к меняемому виду(retrofit), нужно будет писать кучу оберток.
2. почему для результата нужно создавать именно хэндлер, не поимеем ли мы кучу утечек с таким «калбэком»?
3. конвертер нельзя просто взять и подключить, его нужно обязательно делать базовым классом для всех респонзов + тягать парсер библиотеку(jackson, gson etc) кругом
4. парсер класс, создается еще до того как известен ответ от сервера
5. куча ручной работы по передачи параметров и чтению результатов
К сожалению оно того не стоит, есть куча библиотек, с апи по лучше, из не упомянутых добавлю: volley, ion.
Но retrofit, имхо, один из лучших, он именно решает ежедневные проблемы, заметно уменьшает количество писанины, так еще и тестировать достаточно легко.
p.s. официальный андроид стиль, рекомендует использовать 4 пробела для исходных кодов. Если вы решили использовать табы, то возможно стоит научиться ими пользоваться, у вас сорсы везде разъехались. Классическая проблема при использовании табов.
Гуглу не нужна масса, пока что, им нужны заинтересованные люди, готовые помочь с тестированием и идеями. Отсюда и закрытая программа и цена в $1500, что бы отсеять случайных прохожих.
А текущая акция, видимо что бы дать возможность тем кто очень хотел купить, но не мог получить приглашение.
Ну вот у нас есть сетка с картинками, видно сразу 20+ картинок, то есть мне нужно запостить 20 runnable просто что бы подождать пока будет известен размер для ImageView? А потом мне что нужно хранить флаг, и больше это не делать, или каждый раз при прокрутке пулять 20 + runnable?
Как то это все не правильно.
Вообще это какой то не правильный подход. Зачем ограничивать размеры вью? Что бы потом изобретать велосипед с ручным расчетом на разных размерах экранов? Для этого и придуман wrap_content/match_parent/ layout_weight.
Все что написано вами выше, должно быть опционально и выключено по умолчанию. Потому что, большинство рест апи позволяет:
1. тянуть картинки разного качества, а это значит что нам не нужно дополнительно, что либо еще делать на клиентах. Экономим память, диск, сеть, батарейку и тд.
2. ImageView, без труда может и сам масштабировать картинку, если нужно.
Итого, самый популярный способ показать картинки: GridView с автоматическим расположением картинок (количество столбцов, размер и тд), и uil тут явно не ваш друг.
Note: In this example, one eighth of the application memory is allocated for our cache. On a normal/hdpi device this is a minimum of around 4MB (32/8). A full screen GridView filled with images on a device with 800x480 resolution would use around 1.5MB (800*480*4 bytes), so this would cache a minimum of around 2.5 pages of images in memory.
Например:
The following dependencies have later milestone versions:
— com.android.support:support-annotations [19.1.0 -> 21.0.0-rc1]
— com.android.support:support-v4 [19.1.0 -> 21.0.0-rc1]
— com.fasterxml.jackson.core:jackson-annotations [2.3.3 -> 2.4.1]
— com.fasterxml.jackson.core:jackson-core [2.3.3 -> 2.4.1.1]
В общем, что вам нужно:
1. указать конкретные версии для всех зависимостей (без +). Что бы избежать эти проблемы в будущем.
2. у вас уже стоит плагин gradle-versions-plugin. Поэтому что бы проверить на наличие новых версий, нужно запустить: gradlew dependencyUpdates
3. Обновить конкретные версии плагинов
Пробовали:
1. пересобирать проект?
2. пересобрать из командной строки или запуском соотвествующего таска из Android Studio?
3. перезапустить демон: gradlew --stop?
У вас даже уже gradle-versions-plugin стоит, и все равно куча библиотек с + в версиях, почему?
Chapter 8. Dependency Management Basics
www.gradle.org/docs/current/userguide/artifact_dependencies_tutorial.html
Первый же пример:
Вот мне интересно, если разработка так важна для вас, что вы делали последние полтора года тогда?
Даже если и добавят поддержку svg, все равно нужно будет создавать svg отдельно для каждого dpi или как минимум для кратных.
Скажем есть у вас картинка c линией, на xhdpi она будет 2px, и она так же будет нормально показана на mdpi, линия будет 1px. Но вот уже на hdpi будут проблемы, так как нужно будет отрисовать 1.5px. Обычно в этом случае рисуется отдельный свг уже с правильной линией равной 1 или 2px, в зависимости что выглядит лучше.
Другая проблема, если много деталей на картинке, то она может хорошо выглядеть на xxhdpi, но отвратительно на mdpi. То есть снова нужна отдельная картинка.
Даже в этой статье подход не правильный (только, если конечно качество приложения не важно), картинка будет мыльная на большинстве dpi, так как все картинки штампуются из одного svg.
Я обычно создаю отдедельный svg для каждого разрешения и подгоняю их в ручную, что бы не было мыла. Если сильно лень, то тогда только для кратных dpi, то есть достаточно сделать две «правильных» картинки для xxhdpi и xhdpi и уже из них нарезать. Из xxhdpi нарезаются hdpi и ldpi, а из xhdpi: mdpi
Для конвертации svg в png пробовал:
1. imagemagic — качество картинки странное,
2. inkscape — качество картинки приемлемо, но вот хотелось бы только больше опций по управлению svg, например, поменять цвет определенного объекта, будь то слой или что то другое.
3. В итоге остановился на библиотеке batik (http://xmlgraphics.apache.org/batik/) качество достаточно приемлемое. Так как эта библиотека парсит весь svg, то вы по сути можете делать что угодно, менять цвета, изменять размеры линий и тд, затем растеризовать конечный svg в png. Но этот способ требует больше времени чем все остальные.
p.s. Но да, при наличие поддержки svg уже не нужно было бы конвертировать в png.
То что фотографии выложили только несколько дней после новостей, кто виноват?
Хотите что то доказать/исправить, пишите автору темы пусть обновит картинки, на худой конец, напишите новую статью с обновленной информацией.
Спасибо.
2. речь шла собственно о планшете в посте и она 1 в 1 как моторола xoom.
Я могу понять почему так случилось, просто потому что надо было что то показать и взять xoom это самый быстрый способ начать разрабатывать. А все остальное можно перенести уже потом, когда все готово на реальный планшет, каким бы он не был.
Кидается новая обоя и собирается все одной командой, а потом fastboot -w flashall
Вот вам и принципиально новая отечественная ос.
Видимо сделано, что бы они не слушали команды пока находятся в этом режиме.
github.com/square/okhttp/issues/50
В качестве тренировки конечно классно написать свою библиотеку, но вот если начать использовать ее, то:
1. сильно многословная, что бы привести все к меняемому виду(retrofit), нужно будет писать кучу оберток.
2. почему для результата нужно создавать именно хэндлер, не поимеем ли мы кучу утечек с таким «калбэком»?
3. конвертер нельзя просто взять и подключить, его нужно обязательно делать базовым классом для всех респонзов + тягать парсер библиотеку(jackson, gson etc) кругом
4. парсер класс, создается еще до того как известен ответ от сервера
5. куча ручной работы по передачи параметров и чтению результатов
К сожалению оно того не стоит, есть куча библиотек, с апи по лучше, из не упомянутых добавлю: volley, ion.
Но retrofit, имхо, один из лучших, он именно решает ежедневные проблемы, заметно уменьшает количество писанины, так еще и тестировать достаточно легко.
p.s. официальный андроид стиль, рекомендует использовать 4 пробела для исходных кодов. Если вы решили использовать табы, то возможно стоит научиться ими пользоваться, у вас сорсы везде разъехались. Классическая проблема при использовании табов.
Вы же не будете играть в гугл очках, и вы так же не будете ехать в машине с окулс рифт на голове.
А текущая акция, видимо что бы дать возможность тем кто очень хотел купить, но не мог получить приглашение.
Ну вот у нас есть сетка с картинками, видно сразу 20+ картинок, то есть мне нужно запостить 20 runnable просто что бы подождать пока будет известен размер для ImageView? А потом мне что нужно хранить флаг, и больше это не делать, или каждый раз при прокрутке пулять 20 + runnable?
Как то это все не правильно.
/* com.nostra13.universalimageloader.core.ImageLoader:194 */
String memoryCacheKey = uri; // MemoryCacheUtil.generateKey(uri, targetSize);
Не очень красиво, за то эффективно. Но будет здорово, если можно будет это решить как то в конфигурации по умолчанию, без лишних движений.
Все что написано вами выше, должно быть опционально и выключено по умолчанию. Потому что, большинство рест апи позволяет:
1. тянуть картинки разного качества, а это значит что нам не нужно дополнительно, что либо еще делать на клиентах. Экономим память, диск, сеть, батарейку и тд.
2. ImageView, без труда может и сам масштабировать картинку, если нужно.
Итого, самый популярный способ показать картинки: GridView с автоматическим расположением картинок (количество столбцов, размер и тд), и uil тут явно не ваш друг.