Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
1)
2) Для БД особого смысла использовать ORM нету (под Android). Если есть опыт, когда сие упростило разработку, хотелось бы послушать.
3) Про ActionBarSherlock… Лучше почитайте автора компонента.
Это отняло у меня больше всего времени, из-за несистематизированности и неполноты информации, включая документацию Google.Странно, но используя официальную документацию реализовал за пару минут.
2) Для БД особого смысла использовать ORM нету (под Android). Если есть опыт, когда сие упростило разработку, хотелось бы послушать.
3) Про ActionBarSherlock… Лучше почитайте автора компонента.
1) Что-то очень странное было у меня. После того Guide, я постоянно получал исключение с одним словом «Unknown», вероятно, что-то я делал не так, но не понял, что именно. В конце концов остановился на варианте из поста.
2) Здесь вопрос выбора и предпочтений, я, как .net разработчик, не хотел касаться Cursor или ContentProvider, и ORM мне нравится на любых, даже самых мелких проектах
3) Я поддерживаю Android с версии 2.3, так что цитирую разработчика ActionBarSherlock: If you are writing an application right now with a minSdkVersion lower than 14 you should be using it.
2) Здесь вопрос выбора и предпочтений, я, как .net разработчик, не хотел касаться Cursor или ContentProvider, и ORM мне нравится на любых, даже самых мелких проектах
3) Я поддерживаю Android с версии 2.3, так что цитирую разработчика ActionBarSherlock: If you are writing an application right now with a minSdkVersion lower than 14 you should be using it.
Здесь вопрос выбора и предпочтений, я, как .net разработчик, не хотел касаться Cursor или ContentProvider, и ORM мне нравится на любых, даже самых мелких проектах
Прошу прощение за наглость, но UcaOrm совсем не рассматривали?
Выглядит шикарно: вложенные сущности, запросы, миграции кодом, а не скриптами. Просто не попадалась мне, когда выбирал инструменты. Так это ваша библиотека! На вид — крутая вещь для одного человека. В каком-нибудь новом проекте попробую воспользоватся.
На вид — крутая вещь для одного человека.
Спасибо! Orm родился как сопутствующая библиотека к другому проекту и, поскольку проект пока забросил, то и orm с марта не обновлял.
В каком-нибудь новом проекте попробую воспользоватся.
Буду рад, если моя библиотека еще кому-то пригодится. Если вдруг не будет хватать функционала — обращайтесь, — доработаю!
А потом вы узнали, что с вроде как 4.4.2 блокировщики смс перестали перехватывать смски?
Вообще, очень спорное решение, на мой взгляд. Например, сейчас делаю приложение, которое общается с удаленным устройством через СМС. И вот эти технические СМС будут просто засорять ленту пользователя. Лучше бы уж ввели дополнительный permission. Ну предупреждал бы он пользователей большими красными буквами об опасности, но зачем вообще убирать эту возможность?! Как обычно, гугл лучше пользователя знает, что нужно этому самому пользователю…
Я точно знаю, что в KitKat изменился порядок работы с СМС. И старый софт, несомненно, перестанет работать. Сейчас мое приложение не установится на 4.4, указал это в манифесте.
Но в 4.4 это точно можно делать. Я, думаю, к концу следующей недели буду иметь рабочий код и дополню статью.
Но в 4.4 это точно можно делать. Я, думаю, к концу следующей недели буду иметь рабочий код и дополню статью.
Не прибегая к хакам и костылям? Было бы очень интересно об этом почитать.
А такие хаки существуют? Единственное решение это сделать приложение месседжером, но большинство пользователей с этим не согласятся.
Я выпустил свой смс фильтр где-то за месяц до выхода 4.4 и это был фейл, потому что пока я искал решение этой проблемы пользователи 4.4 успели наставить колов.
В итоге заблокировал установку на 4.4 и более новых, но сейчас это потеря 40% новых устройств и с каждым годом будет только увеличиваться (40% взято из статистики установок в день в гуглплей в категории инструменты).
Еще не уверен что происходит после обновления, судя по статистике активных устройств и оценкам оно просто перестает работать и его удаляют.
В общем единственный вариант развития который я вижу: объединиться с разработчиком месседжера, либо забить на приложение.
Я выпустил свой смс фильтр где-то за месяц до выхода 4.4 и это был фейл, потому что пока я искал решение этой проблемы пользователи 4.4 успели наставить колов.
В итоге заблокировал установку на 4.4 и более новых, но сейчас это потеря 40% новых устройств и с каждым годом будет только увеличиваться (40% взято из статистики установок в день в гуглплей в категории инструменты).
Еще не уверен что происходит после обновления, судя по статистике активных устройств и оценкам оно просто перестает работать и его удаляют.
В общем единственный вариант развития который я вижу: объединиться с разработчиком месседжера, либо забить на приложение.
Да вот я тоже других способов (кроме как дефолтный мессенджер, что в моем случае вообще не вариант) не нашел. Поэтому фраза
Но в 4.4 это точно можно делать.и заинтересовала. Ждём «конца следующей недели».
Я сижу с бутылкой виски и думаю о жизни и о KitKat, а ведь так хорошо все начиналось…
Изначально, я запретил приложению установку на 4.4, зная что там всё не так. И решил заняться KitKat после релиза для старых версий.
После этого релиза, я стартанул разработку под KitKat. Я радостно сделал свое приложение дефолтным СМС приложением. Спокойно реализовал все требования к манифесту и настройкам приложения. Красиво разрулил в манифесте и коде активность сервисов (чтобы один APK работал на обоих версиях), запросил у пользователя право стать дефолтным приложением. Принял первое смс обработчиком, и эээ… Сначала мне пришлось руками его класть во входящие, так как теперь Messaging (нативное приложение) не прослушивает входящие СМС. Потом думать, как сделать нотификацию, которая вела бы на смс в Messaging (я не собирался делать читалку смс). А потом… я додумался проверить, а может ли Messaging слать СМС, будучи не дефолтным… Нет! Как и Hangout и многие другие.
И да, как писал uxgen, выход один — полноценный СМС менеджер. Что я не потяну. А если и потяну — это будет УГ, по сравнению с конкурентными и нативным… Как можно так сфейлится… Я в январе-феврале проводил «аналитику», понял лишь, что в KitKat все еще можно ловить смс, но никак не выяснил подробности и не опробовал на эмуляторе… и начал долгими весенне/летне/осенними вечерами ваять… Epic fail…
Если интересно, могу добавить в статью «рецепты» того, что удалось сделать, хотя там ничего особого.
Изначально, я запретил приложению установку на 4.4, зная что там всё не так. И решил заняться KitKat после релиза для старых версий.
После этого релиза, я стартанул разработку под KitKat. Я радостно сделал свое приложение дефолтным СМС приложением. Спокойно реализовал все требования к манифесту и настройкам приложения. Красиво разрулил в манифесте и коде активность сервисов (чтобы один APK работал на обоих версиях), запросил у пользователя право стать дефолтным приложением. Принял первое смс обработчиком, и эээ… Сначала мне пришлось руками его класть во входящие, так как теперь Messaging (нативное приложение) не прослушивает входящие СМС. Потом думать, как сделать нотификацию, которая вела бы на смс в Messaging (я не собирался делать читалку смс). А потом… я додумался проверить, а может ли Messaging слать СМС, будучи не дефолтным… Нет! Как и Hangout и многие другие.
И да, как писал uxgen, выход один — полноценный СМС менеджер. Что я не потяну. А если и потяну — это будет УГ, по сравнению с конкурентными и нативным… Как можно так сфейлится… Я в январе-феврале проводил «аналитику», понял лишь, что в KitKat все еще можно ловить смс, но никак не выяснил подробности и не опробовал на эмуляторе… и начал долгими весенне/летне/осенними вечерами ваять… Epic fail…
Если интересно, могу добавить в статью «рецепты» того, что удалось сделать, хотя там ничего особого.
Welcome to Android hell! Только зачем так мучиться-то было? Это же всё описано здесь.
А совет разработчикам приложений для «SMS backup & restore» иначе как издевательским и назвать не могу:
1. Выясните, какое приложение сейчас является дефолтным
2. Попросите сделать себя дефолтным приложением
3. Обработайте СМС и попросите вернуть дефолтное приложение.
Удобнее просто некуда!
P.S. Но СМС можно отправлять и не будучи дефолтным — просто в этом случае СМС будет обязательно записано в SMS Provider. Или Вы имеете в виду, что это в конкретных приложениях не реализовано?
А совет разработчикам приложений для «SMS backup & restore» иначе как издевательским и назвать не могу:
1. Выясните, какое приложение сейчас является дефолтным
2. Попросите сделать себя дефолтным приложением
3. Обработайте СМС и попросите вернуть дефолтное приложение.
Удобнее просто некуда!
P.S. Но СМС можно отправлять и не будучи дефолтным — просто в этом случае СМС будет обязательно записано в SMS Provider. Или Вы имеете в виду, что это в конкретных приложениях не реализовано?
По запросу «смс фильтр» мое приложение 5е, а по «sms filter» где-то на 3-4 странице. Русскоязычных пользователей 70%, изначально приложение разрабатывалось под особенности русских спамеров, которые конкуренты не учитывали. Без русской локализации приложение бы затерялось в куче аналогичных.
Как вариант можно делать отдельно версию с русской локализацией, чтоб не влияли на общий рейтинг, но тогда продвигать будет тяжелее.
Как вариант можно делать отдельно версию с русской локализацией, чтоб не влияли на общий рейтинг, но тогда продвигать будет тяжелее.
Я считаю, что для новых проектов лучше использовать не ActionBarScherlock, а AppCompat SupportLibrary v4 от Google.
Warning:
1 — очень плохая практика. Не делайте так если хотите сделать приложение совместимое по UI со всеми версиями ос.
4 — не правда про фракгменты. Для долгих фоновых задач я бы рекомендовал RoboSpice
1 — очень плохая практика. Не делайте так если хотите сделать приложение совместимое по UI со всеми версиями ос.
4 — не правда про фракгменты. Для долгих фоновых задач я бы рекомендовал RoboSpice
Какие ужасные советы
А запись задачи в базу не гарантирует? Сколько вы еще столь стандартный и очевидный вариант решения проблемы будете игнорировать?
Не все задачи требуют записи в базу. вы что, каждый чих будете поддерживать, чтобы код обязательно выполнился? Что если юзер запросил адрес по координатам, но при повороте к примеру приложение выгрузилось? Вы что, это будете сериализовывать? Да это же бред.
И это никакое не громоздкое решение, а вполне нормальное, которое поддерживается стандартными средствами, при этом имеет такие фичи, как ContentProvider, CursorLoader и прочее (что позволяет автообновлять списки автоматически и прочие плюшки).
И более того, я не встречал в последнее время выгрузку приложений при поворотах. Ну работают они во многих случаях правильно. Поэтому я спокойно какие-то задачи пишу через лодеры и прочие штуки. Слышали про правило 80/20?
И это никакое не громоздкое решение, а вполне нормальное, которое поддерживается стандартными средствами, при этом имеет такие фичи, как ContentProvider, CursorLoader и прочее (что позволяет автообновлять списки автоматически и прочие плюшки).
И более того, я не встречал в последнее время выгрузку приложений при поворотах. Ну работают они во многих случаях правильно. Поэтому я спокойно какие-то задачи пишу через лодеры и прочие штуки. Слышали про правило 80/20?
в местах плохого приема, к примеру на границе зоны действия Wi-Fi или в подвальчиках. Тогда человек, ожидая загрузки, может переключиться на какое-то другое приложение, а вернувшись в ваше, получит глюк.
Еще раз повторю — тогда пишем в базу задачу и пока не выполнится — не удаляем. И человек не получит глюк. Когда-нибудь вы поймете, что это тоже решение. Я что 100500 раз в вашем топике об этом писал, что тут. Толку ноль. Пожалуй прекращу копипастить свою мысль.
1. Вы мне заплатите за потраченное время?
2. Вы знаете что такое ContentProvider, CursorLoader и как они взаимодействуют с забой и автоматически обновляют записи?
2. Вы знаете что такое ContentProvider, CursorLoader и как они взаимодействуют с забой и автоматически обновляют записи?
Ну я просто не хочу писать то, что не хочу. А если мне говорят написать, то уж извольте платить.
Ну мне нечего вам сказать, если вы не знаете в чем преимущества таких вещей, о которых я написал и как они помогают работать с базой и какие плюшки несут. Ставлю минус вам за ваши знания.
Могу лишь благословить вас на использование вашего велосипеда и пожелать успехов.
Зы ни какого отношения лоадеры не имеют к задачам, которые решаются в моей демке.
Ну мне нечего вам сказать, если вы не знаете в чем преимущества таких вещей, о которых я написал и как они помогают работать с базой и какие плюшки несут. Ставлю минус вам за ваши знания.
Могу лишь благословить вас на использование вашего велосипеда и пожелать успехов.
(промахнулся немного с ответом, ответил сам себе)
Ну а зачем отмазка? Я предложил вам заплатить мне за работу и я её сделаю. Вы же меня заставляете её сделать бесплатно? С чего вдруг? Почему я ваши требования должен выполнять? Вы мне кто? Я указал на ваши промахи, а вы пыжитесь. Это сейчас разговор с этой оперы.
Не вижу смысла вам доказывать знания азов Android. Но если вас так интересуют мои знания, то можете посмотреть мою статью в конце концов, да сделать логическое умозаключение (не эмоциональное, а логическое), знаю ли я детские вопросы по Android. Или в конце концов посмотрите комментарии на сайте стартандроид, я там часто разжёвывал новичкам этот вопрос.
Не понимаю вашего негодования. Вы говорите что ваше решение лишено недостатков. Но что если, допустим взять ваш пример, что если ваш бин содержит не простые вещи внутри себя как в примере, а явные вызовы методов наших классов? Что если наш телефон выключился, а после включения маркет нам обновил приложение и эти методы изменились? Мы однозначно получим ошибку выполнения. И даже если мы бин изменили, то изменилась структура класса и сериализация не пройдет успешно. Может ли быть такая ситуация? Вполне.
Я же говорю про то, что лучше писать в базу сам факт запуска задачи, нежели сериализовывать саму задачу. Понимаете разницу? Есть какие таблицы, мы там добавляем флаг со статусом задачи, а дальше при запуске телефона просто смотрим, есть ли у нас задачи на выполнение. Это хорошо очень многими вещами. Мы лишены недостатков сериализации, мы можем безпроблемно импортировать базу и другие фишки, касающиеся базы.
Я в принципе всегда рад новым решениям всяких проблем (да вять тот же паттерн ViewHolder) и воспринимаю это всегда с позитивом, но тут не вижу плюсов пока что
Ну а зачем отмазка? Я предложил вам заплатить мне за работу и я её сделаю. Вы же меня заставляете её сделать бесплатно? С чего вдруг? Почему я ваши требования должен выполнять? Вы мне кто? Я указал на ваши промахи, а вы пыжитесь. Это сейчас разговор с этой оперы.
Судя по вашим комментриям вы даже цикла приложения не знаете, «знаток».
Не вижу смысла вам доказывать знания азов Android. Но если вас так интересуют мои знания, то можете посмотреть мою статью в конце концов, да сделать логическое умозаключение (не эмоциональное, а логическое), знаю ли я детские вопросы по Android. Или в конце концов посмотрите комментарии на сайте стартандроид, я там часто разжёвывал новичкам этот вопрос.
Не понимаю вашего негодования. Вы говорите что ваше решение лишено недостатков. Но что если, допустим взять ваш пример, что если ваш бин содержит не простые вещи внутри себя как в примере, а явные вызовы методов наших классов? Что если наш телефон выключился, а после включения маркет нам обновил приложение и эти методы изменились? Мы однозначно получим ошибку выполнения. И даже если мы бин изменили, то изменилась структура класса и сериализация не пройдет успешно. Может ли быть такая ситуация? Вполне.
Я же говорю про то, что лучше писать в базу сам факт запуска задачи, нежели сериализовывать саму задачу. Понимаете разницу? Есть какие таблицы, мы там добавляем флаг со статусом задачи, а дальше при запуске телефона просто смотрим, есть ли у нас задачи на выполнение. Это хорошо очень многими вещами. Мы лишены недостатков сериализации, мы можем безпроблемно импортировать базу и другие фишки, касающиеся базы.
Я в принципе всегда рад новым решениям всяких проблем (да вять тот же паттерн ViewHolder) и воспринимаю это всегда с позитивом, но тут не вижу плюсов пока что
Отмазка — потому что вы не сможете решить проблему, которую я описал, при помощи лоадеров, и вы это понимаете или смутно догадываетесь.
Причем тут лодеры?! Где я писал что они помогают решить проблемы? Они никак не помгают решить проблему, ибо они работают в ОЗУ. Прекратите нести ахинею. Я нигде не писал что лодеры помогают решить эту задачу.
Если до сих пор не поняли о чем я, повторю: ContentProvider И CursorLoader дают отличные вещи для работы с базой. Понимаете такое слово как база? База — это такая вещь, куда вы можете засунуть свою задачу и где она не потеряется, а лодеры и контентПровайдеры вам помогут удобно, удобно работать с базой.
И при обновлении никакого рассинхнона с сериализацией не будет,
О каком рассинхроне идет речь? Что вы тут понимаете под рассинхронизацией? Почитайте лучше про InvalidClassException и serialVersionUID
1. модификация бина не даст в дальнейшем дессериализоваться бину.
2. Модификация методов в бине (допустим мы переименовали методы нашего вызывающего класса)
В этих ситуациях бины перестанут работать и вылезет ошибка. Это очевидно как пить дать.
И хватит писать про указание кода, я не собираюсь на халяву вам писать код. Прекратите страдать фигнёй, вы меня просите написать решение для работы с базой через провайдеры, куда я буду писать задачи на выполнение. Если не умеете, то и мой код вам не поможет. Сначала деньги, а потом стулья.
Вы, что, извините, дурак (ну так, мягко)?
Каким образом связана модификация класса и жизненный цикл активности? Это вообще к Java относится! Я уже и указал на всё, что можно. И тут нет никакой связи с жизненным циклом приложения.
Вы пишете про поворот экрана. Причем тут к черту поворот экрана, когда я пишу о другом?! Я пишу о ситуации, когда допустим приложение выключилось и остались сериализованными какие-то задачи. Тут маркет обновляет приложение и обновляет классы или сам бин приложения! И дессериализация не пройдет. И еще раз повторю, это никак не относится к жизненному Android циклу. Сериализация — это чистой природы Java. Учите Java!
Каким образом связана модификация класса и жизненный цикл активности? Это вообще к Java относится! Я уже и указал на всё, что можно. И тут нет никакой связи с жизненным циклом приложения.
Вы пишете про поворот экрана. Причем тут к черту поворот экрана, когда я пишу о другом?! Я пишу о ситуации, когда допустим приложение выключилось и остались сериализованными какие-то задачи. Тут маркет обновляет приложение и обновляет классы или сам бин приложения! И дессериализация не пройдет. И еще раз повторю, это никак не относится к жизненному Android циклу. Сериализация — это чистой природы Java. Учите Java!
Мда… Никакого отношения Java не имеет к Андроиду. Это Android использует гибрид языка Java и свой SDK, не более того. Даже виртуальная машина Dalvik не проходит по стандартам Оракла, за что Оракл судится с гуглом.
Для таких как вы, я написал небольшую заметку когда-то: А тот ли ты путь выбрал, разработчик?
Учите Java господа, а потом лезьте в Android.
Для таких как вы, я написал небольшую заметку когда-то: А тот ли ты путь выбрал, разработчик?
Учите Java господа, а потом лезьте в Android.
Что вы ушли в абстракции? Я много кода написал в помощь другим, как и статьи писал. Я указал на ошибки ваши, которые нерешаемы в сериализации, а вы в домик спрятались после того, как поняли что ваших тут знаний не хватает и теперь начали писать требование меня написать вам код. Мне вам противно в ответ уже сообщения писать из-за вашего общения, а вы мне про код. Научитесь писать нормально, приходите. А я удаляюсь окончательно. С вами кашу не сваришь.
Мда. Человеку не надо было вам отвечать еще после совета «писать ActionBar самому и не использовать фрагменты». Не удивлюсь, если вы скажете: «Нечего пользоваться готовыми классами, хотите гибкости — наследуйтесь от Object и пишите все сами, это лучшее решение, лишенное костылей от Oracle/Google/etc».
Это из разряда «не пишите на C++, там утечки памяти». Фрагменты — великолепная задумка. А то, что программист неправильно жизненный цикл реализует, так это не проблема фрагментов.
Соглашусь, что фрагменты не всегда работают одинаково на разных версиях Android.
И да, утечки в памяти тоже наблюдались.
Тем не менее, фрагменты — очень важный и неотъемлемый класс Android SDK. Совсем не тяжело заставить работать фрагменты как нужно, и подстроиться под особенности LifeCycle.
Custom View хоть и является альтернативой, но по-моему есть велосипед и игнорирование опыта многих хороших разработчиков.
И да, утечки в памяти тоже наблюдались.
Тем не менее, фрагменты — очень важный и неотъемлемый класс Android SDK. Совсем не тяжело заставить работать фрагменты как нужно, и подстроиться под особенности LifeCycle.
Custom View хоть и является альтернативой, но по-моему есть велосипед и игнорирование опыта многих хороших разработчиков.
Посмотрите на порт joda-time под Android, который, по словам автора, решает проблемы с захламлением памяти, возникающим при использовании оригинального joda-time (причины указаны в readme) и добавляет некоторые дополнительные плюшки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Советы и рецепты начинающему Android программисту