В детали не вникали, а минусовать, смотрю, горазды. В моем коде используется IntentService, который основан внутри на хендлере. Этот хендлер создается на лупере WorkerThread'a. Ознакомьтесь с исходниками IntentService.
Во-первых, как я уже сказал, я не претендую, что это — единственный верный способ. Я использую интенты, т. к., во-первых, это самый рекомендованный и стандартный способ посылки сообщений сервису, во-вторых, это самый простой, не требующий boilerplate кода способ. Локальный биндинг — вещь в целом неплохая, но он привязывает сервис к жизненному циклу активити, напрямую связывает их, требует отслеживания событий биндинга/анбиндинга и т. п. Я вообще восхищаюсь системой сообщений в андроид, и считаю, что по возможности лучше придерживаться ее. Кроме того, используя способ в статье, вы сможете очень легко перенести сервис в другой процесс, если надо (одной строчкой в манифесте). ResultReceiver бьет через процессы, все работает, а вот локальный биндинг тут уже придется менять на AIDL или Messenger, что не так тривиально.
По-поводу делать как хотим в сервисе — а сейчас разве не так? В данном примере у меня IntentService, он работает через Handler. Если надо, можно заменить на свой сервис, который будет работать, скажем на ExecutorService, все точно так же.
Да, этот доклад мне в свое время очень помог, всем рекомендую. Проблема этого доклада, что там совершенно не описывались детали обратного взаимодействия сервиса с хелпером, т. е. он сказал «binder callback», а что это такое, как его писать — нет.
Спасибо за вопрос. Я сильно не вдавался во многие open source приложения, но в них все по-разному, в зависимости от качества. Где-то люди используют AsyncTask, где-то броадкаст ресиверы, где-то — что-то похожее на описанное в статье. Тут, поймите, проблема не в самом походе в сервер, а именно в организации связанной архитектуры в своем приложении, где надо ходить на сервер.
Ну, статья-то как раз о работе с БД. Поэтому и вопрос об ArrayAdapter шел именно в этом контексте. Не имеет смысла в целом расписывать преимущества AA и юзкейсы, когда он действительно нужен. В Андроид нету ненужных компонентов, просто каждому свое применение.
Нет. Стандартный курсор внутри устроен достаточно сложно и держит определенное окошко, которое по мере итерации обновляет. Поэтому у вас может быть много много данных, но за счет окна в курсоре и реюза вьюх в ListView, с отображением этого больших проблем не возникнет.
Лично считаю, что на Андроиде подобные вещи — от лукавого, курсор по эффективности ничего не обгонит. У меня есть несколько вопросов и комментариев. Начну с комментариев.
Первый комментарий по-поводу метода onTerminate в Вашем Application. Проблема с этим методом, что он не вызывается на реальных устройствах, и это явно прописано в документации. Ваше соединение будет жить все время, пока живо приложение, т. е., пока процесс жив, и висит в кэше.
Второй комментарий имена методов SetHelper, GetHelper — это страшно!
Вопросы:
1. Если у Вас имеется список в 1000 элементов (допустим, фид какой-нибудь), будут ли все эти 1000 элементов загружены в память из базы данных для отображения при запросе? Как это дело уживается с AdapterView? Не говорите мне, что используете ArrayAdapter
2. Насколько это дружит с ContentProvider?
3. Как у этого дела с транзакциями, особенно, при вставке в БД 1000 записей?
Спасибо за статью. Я так понимал, в Amazon Appstore публиковать свои приложения могут только американские разработчики не так ли? Расскажите пожалуйста, каким образом обходится это ограничение (особенно в плане вывода денег)? У меня есть приложение, более-менее успешное на Google Play Android Market, и пользователи иногда пишут, почему его нет на амазоне под киндл фая. Вот подумывал попробовать Амазон… Заранее спасибо.
Приведенная ссылка не является верной. Существует два перечня товаров, не подлежащих обмену. Первый, по ссылке, приведенной автором, применяется для товара «надлежащего качества». Второй, по этой ссылке http://ozpp.ru/laws2/postan/post1.html применяется в случае ненадлежащего качества.
Заметьте разницу в пунктах:
«Технически сложные товары бытового назначения, на которые установлены гарантийные сроки (станки металлорежущие и деревообрабатывающие бытовые; электробытовые машины и приборы; бытовая радиоэлектронная аппаратура; бытовая вычислительная и множительная техника; фото- и киноаппаратура; телефонные аппараты и факсимильная аппаратура; электромузыкальные инструменты; игрушки электронные, бытовое газовое оборудование и устройства)»
и
«6. Оборудование навигации и беспроводной связи для бытового использования, в том числе спутниковой связи, имеющее сенсорный экран и обладающее двумя и более функциями»
По-этому пример с телефоном является неудачным. Т. к., если телефон не несет в себе две функции, например, навигатора и телефона, или не оборудован сенсорным экраном, то он подлежит замене.
Да, своеобразный набор слоев, у каждого свое название — normal, pressed, disabled, и т. д., рисуется один раз найнпатч, а потом на выходе получаем N файлов имя-normal.9.png, имя-pressed.9.png. Как вариант и XML тут можно сгенерить с селектором, ну это уже совсем халява.
А по-поводу dpi — да, скорее просто возможность организовать все *dpi наборы в один «проект» с возможностью его сохранения в набор папок drawable-*dpi, внутри которых состояния.
Спасибо, выглядит здорово. На мой взгляд, самой полезной и недостающей фичей является возможность batch-редактора. Т. е., чтобы в один экран можно было бы загрузить несколько состояний одного StateListDrawable, нарисовать границы (они, зачастую, одинаковые) и выгрузить одним выстрелом.
А если он еще и позволит переключаться между *dpi… Я бы купил такой, не задумываясь.
По теме. Во время разработки сервисов доступа к данным в приложении всегда ставлю им приоритет THREAD_PRIORITY_BACKGROUND, это значительно, повторюсь, значительно улучшает производительность UI. Проверено уже не на одном проекте :)
Как я уже сказал, в андроиде нет никакого публичного апи для работы с почтой. Вы считаете, что самому реализовывать классы для общения с почтой, т. е. фактически, реализация имейл клиента, отладка этого дела, это меньше затрат, чем один сервлет на бесплатном аппенджине на 10 строчек и столько же строчек по отправке ему данных в приложении?
Спасибо за идею :) как будет время — обязательно напишу.
По-поводу стартап-бизнес, наверное, это все вопрос понятий. Я имел ввиду свое дело, свой собственный проект, на который тратишь все свое время. И это не обязательно должно быть что-то, требующее огромных начальных инвестиций.
По-поводу делать как хотим в сервисе — а сейчас разве не так? В данном примере у меня IntentService, он работает через Handler. Если надо, можно заменить на свой сервис, который будет работать, скажем на ExecutorService, все точно так же.
Лично считаю, что на Андроиде подобные вещи — от лукавого, курсор по эффективности ничего не обгонит. У меня есть несколько вопросов и комментариев. Начну с комментариев.
Первый комментарий по-поводу метода onTerminate в Вашем Application. Проблема с этим методом, что он не вызывается на реальных устройствах, и это явно прописано в документации. Ваше соединение будет жить все время, пока живо приложение, т. е., пока процесс жив, и висит в кэше.
Второй комментарий имена методов SetHelper, GetHelper — это страшно!
Вопросы:
1. Если у Вас имеется список в 1000 элементов (допустим, фид какой-нибудь), будут ли все эти 1000 элементов загружены в память из базы данных для отображения при запросе? Как это дело уживается с AdapterView? Не говорите мне, что используете ArrayAdapter
2. Насколько это дружит с ContentProvider?
3. Как у этого дела с транзакциями, особенно, при вставке в БД 1000 записей?
Google PlayAndroid Market, и пользователи иногда пишут, почему его нет на амазоне под киндл фая. Вот подумывал попробовать Амазон… Заранее спасибо.Заметьте разницу в пунктах:
«Технически сложные товары бытового назначения, на которые установлены гарантийные сроки (станки металлорежущие и деревообрабатывающие бытовые; электробытовые машины и приборы; бытовая радиоэлектронная аппаратура; бытовая вычислительная и множительная техника; фото- и киноаппаратура; телефонные аппараты и факсимильная аппаратура; электромузыкальные инструменты; игрушки электронные, бытовое газовое оборудование и устройства)»
и
«6. Оборудование навигации и беспроводной связи для бытового использования, в том числе спутниковой связи, имеющее сенсорный экран и обладающее двумя и более функциями»
По-этому пример с телефоном является неудачным. Т. к., если телефон не несет в себе две функции, например, навигатора и телефона, или не оборудован сенсорным экраном, то он подлежит замене.
А по-поводу dpi — да, скорее просто возможность организовать все *dpi наборы в один «проект» с возможностью его сохранения в набор папок drawable-*dpi, внутри которых состояния.
Тогда был архинаикрутейший редактор 9-patch. :)
А если он еще и позволит переключаться между *dpi… Я бы купил такой, не задумываясь.
По-поводу стартап-бизнес, наверное, это все вопрос понятий. Я имел ввиду свое дело, свой собственный проект, на который тратишь все свое время. И это не обязательно должно быть что-то, требующее огромных начальных инвестиций.