Спасибо, теперь понятно.
Касательно View и загрузки данных, да, конечно это вопрос архитектуры. В моем случае, этот подход кажется мне оправданым — в данном контексте View мало чем отличается от Activity — тот же элемент UI.
Интересно, а можно ли Chronos точно так же заточить для использования во View — вместо onResume и onPause можно наврное использовать onAttachedToWindow и onDetachedFromWindow?
Как принято, прошу прощения если что не так прочитал, но из статьи я не совсем понял следующее:
1. Можно ли использовать Chronos во View а не в Activity.
2. Что будет при смене ориентации (конфигурации)
3. Что будет, если система захочет убить приложение (если Activity ушла в бекграунд)
4. Можно ли запускать подтаски
И еще коммент: мне было бы удобно использовать фоновую задачу непосредственно во View. Скажем, написал View, которая грузит картинку из сети, положил ее в Layout и забыл — она сама себя грузит. При смене ориентации сама восстанавливает свое состояние не стартуя загрузку заново. Когда таких View десяток и больше, то выносить фоновые таски в Activity, ну очень не хочется.
Именно поэтому, некоторе время назад, я написал для своих нужд видоизмененный велосипед на основе AsyncTask, которй хранит пул таск в статик переменной.
При смене конфигурации View отписывается от AsyncTask и при пересоздании заново подписывается на ту же AsyncTask.
В данной реализации есть свои ограничения, но они несущественны на фоне возможности перенести фоновые таски во View.
Если в Chronos это возможно, то наверное стоит его опробовать.
Жалко что вместо поддержки железа делают акцент на подобных фиксах: «Лаунчер Unity теперь можно уменьшить до размера в 8 пикселей».
Я конечно рад обновлению, и уже делаю бекап перед установкой, но огорчает, что моему ноутбуку уже года два (Samsung 700Z), а он до сих пор не может нормально работать с убунтой из коробки. Основные проблемы которые меня беспокоят — это поддержка видео карт и сторонних устройств.
Вчера уже попробовал запустить Ubuntu 14.04, надеялся что пофиксили, но нет — в режиме простоя Power Statistic показывает потребление энергии 40 ватт/час, при том, что в винде данный показатель около 15. Кулер работает практически без остановки. Придется опять колдовать с драйверами Radeon. При подключении самсунг таблетки все так же имеется проблема с MTP.
Понятно, что система бесплатная и принимается как есть, но все же.
Спасибо, интересно и полезно.
Прошу прощения если прочитал пост по диаганали и что-то упустил.
Я добавлю свои пять копеек. Несколько лет назад я написал приложение для командной строки, которое управляет строковыми ресурсами для андройда на основе таблицы эксел. Эта таблица или ее часть отдается переводчикам, а потом практически автоматически мержится с существующими строковыми ресурсами. На мой взгляд без подобной тулзы было бы очень трудно. Так же имеется порядка 20 переводчиков, которые переводят местами как попало и сколько бы не было написано крупным шрифтом, что значения вроде"%1$s" ни удалять ни пытаться переводить не надо, все равно, их то местами поменяют, то удалят, то подредактируют для красоты. Приложение перед мержем кроме прочих проверок проверяет не были ли потряны/переделаны подобные конструкции.
Естесственно, что если ресурсы содержат пять строчек и три перевода, то подобная автоматизация не нужна, но при большом количестве строчек без автоматической валидации переводов будет достаточно грустно.
Мемори лики появятся (опять же если в вашей SDK гугл это не пофиксил еще — не следил просто за данной темой) когда сервис будет создаваться и убиваться несколько раз. Если не ошибаюсь, вот тред на данную тему: code.google.com/p/android/issues/detail?id=6426
Прошу прощения за оффтоп, но мне кажется следующие комментарии не будут лишними:
а) существует мемори лик (если это гугл еще не починил): DataSourceService::apiEndpoint надо создавать через статичный класс
б) необходимо использовать RemoteCallbackList вместо List в сервисе
в) необходимо помнить что методы объекта apiEndpoint вызывается не в главном потоке сервиса и необходима либо синхронизация, либо использовать Handler как сделано в serviceConnection::onServiceConnected
Да и последний раз когда я смотрел как запортированы библиотеки GStreamer на N900, там были баги в модуле для работы с RTCP которые не давали его воспроизводить. Может быть вероятность что что-то пойдет не так и на N9, хотя может быть все уже пофиксили.
И уберите пожалуйста this. — мешает восприятию кода :)
Да и по самому коду много замечаний.
Про загрузку в UI потоке уже писали, а про установку visibility в методе onDraw() вроде еще нет — ей там совсем не место.
Ну этого конечно стоило ожидать. Что тут скажешь — условия условиям рознь. Не совсем правда понятна необходимость логирования разбора xml дерева. Как мне кажется, необходимо логировать только ошибки парсинга (несоответствие типов и пр.), и в случае ошибки в debug версии сбрасывать либо в файл, либо в лог сам XML для последующего анализа.
Но вам виднее конечно — надо, значит надо.
Спасибо за статью — пока ни разу не приходилось использовать данный компонент.
Один минорный комментарий по коду (может кому пригодятся для будущей реализации):
Лучше, чтобы передача UI поля потоку происходила посредством WeakReference (или где-то устанавливался бы референс в null). Иначе, в случае зависания потока будет мемори лик целой активити со всем наполнением потому как потоки не обязательно сразу удаляются мусоросборщиком, а могут еще жить неопределенное время. В этом случае, если запускать приложение несколько раз, размер свободного пространства на хипе может быстро сократиться, что может привести к ООМ эксепшену.
Пишу это не потому что охото придраться к коду, а потому, что в своем большом проекте уже большое кличество времени потратили на избавление от подобных мемори ликов.
Все равно не понимаю. Если у вас непостредственно выводом на экран/принтер занимаются классы A, B, C (или ф-ции call), то их так и так переписывать придется. А если они лишь вызывают некий API для печати, то для описанного случая вроде шаблон существуют — если не изменяет память вроде он Bridge называется.
В этом случае не нади ничего переписывать — просто выставляем нужный «printer» и готово.
Я наверное не совсем понял проблему, описаную в примере и вполне заслуживаю большой минус, но зачем делать кучу методов типа call(A a), call(B b), call(C c), когда можно в классах A, B, C определить метод print().
Конечно, если эту возможность ввели в java7, то наверное это кому-нибудь нужно, но из приведенного примера это, на мой взгляд, как-то неочевидно.
Это ни в коем случае не упрек, но можно было бы так же показать как создаются кастомные свойства у самописных компонентов, как они используются в xml ресурсах и как обрабатываются в коде.
Например, для компонента, который приведен в примере, это могли бы быть и кол-во отображаемых строчек и TextAppearance заголовков и кнопочек и пр.
Не знаю как на счет камер, но я зауважал самсунг после покупки ноутбука R70 около 4х лет назад. Пару раз он падал работающим и открытым с метра-полутора. После этого вроде как работает без проблем, не считая убитого аккумулятора :)
Недавно выбирал себе мыльницу и тоже смотрел в сторону Самсунг, но все-таки остановился на Canon IS-130. Может плохо смотрел, но не смог найти достойного аналога по такой же привлекательной цене в 120$ с копейками.
Не совсем понял почему.
Если посмотреть в код RemoteViews, метод apply(), то видно, что он вызывает performApply(), котрый в свою очередь бегает по массиву mActions и выполняет нужные действия. Я полагаю, что можно переопределить метод apply() и сделать с виджетов все что угодно. Указатель на объект у которого можно будет вызвать findViewById() будет возвращен методом super.apply()
Да, RemoteViews предоставляют скудный набор методов. Однако, я бы посоветовал отнаследоваться от RemoteViews и определить недостающие методы. Написан RemoteViews не совсем дружелюбно — большинство методов private, но, как мне кажется после беглого анализа кода, проблему можно решить следующим путем:
public class MyRemoteViews extends RemoteViews {
private RemoteViews mNativeRemoteViews;
...
}
Сам написать не пробовал так как не было необходимости, но попробывать думаю стоит.
В целом, концепция у нас с вами похожа.
Касательно View и загрузки данных, да, конечно это вопрос архитектуры. В моем случае, этот подход кажется мне оправданым — в данном контексте View мало чем отличается от Activity — тот же элемент UI.
Интересно, а можно ли Chronos точно так же заточить для использования во View — вместо onResume и onPause можно наврное использовать onAttachedToWindow и onDetachedFromWindow?
1. Можно ли использовать Chronos во View а не в Activity.
2. Что будет при смене ориентации (конфигурации)
3. Что будет, если система захочет убить приложение (если Activity ушла в бекграунд)
4. Можно ли запускать подтаски
И еще коммент: мне было бы удобно использовать фоновую задачу непосредственно во View. Скажем, написал View, которая грузит картинку из сети, положил ее в Layout и забыл — она сама себя грузит. При смене ориентации сама восстанавливает свое состояние не стартуя загрузку заново. Когда таких View десяток и больше, то выносить фоновые таски в Activity, ну очень не хочется.
Именно поэтому, некоторе время назад, я написал для своих нужд видоизмененный велосипед на основе AsyncTask, которй хранит пул таск в статик переменной.
При смене конфигурации View отписывается от AsyncTask и при пересоздании заново подписывается на ту же AsyncTask.
В данной реализации есть свои ограничения, но они несущественны на фоне возможности перенести фоновые таски во View.
Если в Chronos это возможно, то наверное стоит его опробовать.
Я конечно рад обновлению, и уже делаю бекап перед установкой, но огорчает, что моему ноутбуку уже года два (Samsung 700Z), а он до сих пор не может нормально работать с убунтой из коробки. Основные проблемы которые меня беспокоят — это поддержка видео карт и сторонних устройств.
Вчера уже попробовал запустить Ubuntu 14.04, надеялся что пофиксили, но нет — в режиме простоя Power Statistic показывает потребление энергии 40 ватт/час, при том, что в винде данный показатель около 15. Кулер работает практически без остановки. Придется опять колдовать с драйверами Radeon. При подключении самсунг таблетки все так же имеется проблема с MTP.
Понятно, что система бесплатная и принимается как есть, но все же.
Прошу прощения если прочитал пост по диаганали и что-то упустил.
Я добавлю свои пять копеек. Несколько лет назад я написал приложение для командной строки, которое управляет строковыми ресурсами для андройда на основе таблицы эксел. Эта таблица или ее часть отдается переводчикам, а потом практически автоматически мержится с существующими строковыми ресурсами. На мой взгляд без подобной тулзы было бы очень трудно. Так же имеется порядка 20 переводчиков, которые переводят местами как попало и сколько бы не было написано крупным шрифтом, что значения вроде"%1$s" ни удалять ни пытаться переводить не надо, все равно, их то местами поменяют, то удалят, то подредактируют для красоты. Приложение перед мержем кроме прочих проверок проверяет не были ли потряны/переделаны подобные конструкции.
Естесственно, что если ресурсы содержат пять строчек и три перевода, то подобная автоматизация не нужна, но при большом количестве строчек без автоматической валидации переводов будет достаточно грустно.
а) существует мемори лик (если это гугл еще не починил): DataSourceService::apiEndpoint надо создавать через статичный класс
б) необходимо использовать RemoteCallbackList вместо List в сервисе
в) необходимо помнить что методы объекта apiEndpoint вызывается не в главном потоке сервиса и необходима либо синхронизация, либо использовать Handler как сделано в serviceConnection::onServiceConnected
Да и по самому коду много замечаний.
Про загрузку в UI потоке уже писали, а про установку visibility в методе onDraw() вроде еще нет — ей там совсем не место.
Но вам виднее конечно — надо, значит надо.
Один минорный комментарий по коду (может кому пригодятся для будущей реализации):
Лучше, чтобы передача UI поля потоку происходила посредством WeakReference (или где-то устанавливался бы референс в null). Иначе, в случае зависания потока будет мемори лик целой активити со всем наполнением потому как потоки не обязательно сразу удаляются мусоросборщиком, а могут еще жить неопределенное время. В этом случае, если запускать приложение несколько раз, размер свободного пространства на хипе может быстро сократиться, что может привести к ООМ эксепшену.
Пишу это не потому что охото придраться к коду, а потому, что в своем большом проекте уже большое кличество времени потратили на избавление от подобных мемори ликов.
В этом случае не нади ничего переписывать — просто выставляем нужный «printer» и готово.
Конечно, если эту возможность ввели в java7, то наверное это кому-нибудь нужно, но из приведенного примера это, на мой взгляд, как-то неочевидно.
Например, для компонента, который приведен в примере, это могли бы быть и кол-во отображаемых строчек и TextAppearance заголовков и кнопочек и пр.
Недавно выбирал себе мыльницу и тоже смотрел в сторону Самсунг, но все-таки остановился на Canon IS-130. Может плохо смотрел, но не смог найти достойного аналога по такой же привлекательной цене в 120$ с копейками.
Если посмотреть в код
RemoteViews, методapply(), то видно, что он вызываетperformApply(), котрый в свою очередь бегает по массивуmActionsи выполняет нужные действия. Я полагаю, что можно переопределить методapply()и сделать с виджетов все что угодно. Указатель на объект у которого можно будет вызватьfindViewById()будет возвращен методомsuper.apply()Опять же прошу меня извинить, если я что путаю.
Прошу прощения, если я что-то не уловил.
Сам написать не пробовал так как не было необходимости, но попробывать думаю стоит.