Денис Загаевский: databinding - посматривал, но все тож руки еще недоходили(интересная штука). ...тоже верно... не везде у них у самих прослеживается "единство" (взять material design))) ну... ок ... понял
xmoonlight: Интересное мнение .... конечно, хотя очень похоже на правду.
Про фреймфорк-времянку, про js и молчание прямо подозрительное))
80/20 - так и есть))
Просто все вокруг кричат этот RX - пишут - восторженно хвалят.
Сначала думал - ну юзаете либу - и юзайте, их сто тыщ от Robo-спайсов до ретрофиксов -что ж кричать-то. А сейчас наблюдаю Хабр, кишащий - "манифестами" и "призывами" - вакансии почитал.... и вот решил, думаю, у пацанов на Toster поспрашивать, где я не там свернул или проспал что ли)))
Спасибо Вам!
Да, вы правы, есть механизмы из Content Provider-а уведомляться. и др. Loader's опять таки.... Service - не асинхронен - от него сложно получить результат - только события.
Асинхронности в UI - не должно быть, возможно не очень корректно. Я имел ввиду - что в Activity и фрагментах - никаких трейдов, executors, даже асинктаскков - максимум подтянуть данные Loaderom - ну это единственное место, потокам в UI.
Глядя, через эту призму - конечно не понятно, зачем RX решает проблему многопоточности, когда если её исключить)) и решать не нужно.
В целом, я понял Вас, Александр, thanks!
Agera заинтересовала(но она вот тока-тока еще свежая)
Конечно, если б была хоть мало-мальски какая-то официальная отмашка от них.
А так, rx конечно при первом знакомстве - создает очень неприятное впечатление*
и прежде чем нырять - хочется дважды подумать - мож и в лоадерах и хандлерах разобраться на 100%- они хоть ... ну ... типа "одобрено и рекомендовано" авторами оси.
Ps: неприятное - простите, никого не хочу обидеть. Но это факт, что - смотришь в код, в logcat - пошагово ничего не дебажится, и одни лишь классы U, A ))) и какие-то занебесные абстракции.
2) Возможно. На кругозор, времени сейчас мало(да и не гонюсь особо за широтой). Пока фокус на том, что кормит)
Асинхронность - "все тяжелые операции - в потоке, отдельном от UI."
Всё верно, такие операции называют "фоновыми задачами" - всегда во все времена (по крайней мере, в документации, во всех официальных примерах) - учат сервисам поручать эту работу, а уж внутри служб - все может быть и линейно и попорядку(синхронно).
Ну ок ... для более гладкого "стыка" "фона" и "нефона" есть еще Loaders и Broadcasts
3) "пишешь много, а делаешь мало" - есть такое. Конечно досадно, но если открыть коды стоковых (вроде простеньких) апов - "Календарь" "Контакты" - понимаешь что это нормально. Я вижу что, для Android - это так - да, много писанины - для вполне тривиальных вещей. Ну вот такая ОС...
Может RX это и решает - вот и хочется понять/послушать/взвесить - понимаете на кону ж не один вечер.... а месяцы, а то и год активной практики, вникания (бесплатного)- а жизнь и так коротка)
Просто странно... с развитием платформы - Google перекрывает потихоньку дыры.... и видится, что все "неровности" в разработке и коде - в максимально удачном духе уже перекрыты. То что впринципе возможно было как то подточить - потихоньку подтачивается.
Вряд ли бы они выбрали неправильный путь. Видится что на данном этапе эволюции - код Android Open Sorce достаточно хорош и вышлифован - и это вроде как лучший источник подходов и примеров. Ну ....из того что можно было из него вообще сделать.
Rou1997, Еще раз спасибо, возьму на заметку ваши доводы.
Я думаю, нельзя смотреть на Android через призму Битриксов, и прочих конструкторов.
Если вы собираетесь реализовывать он-лайн магазин - смотрите в сторону реализации хорошего мобильного сайта - это самое лучшее в вашем случае + поддержка на всех мобилах.
Вам нужно четко представлять - зачем вам писать нативное приложение - каковы плюсы и минусы - отсюда - сами ответите на вопрос "откуда заходить".
А здесь уже скорее подскажут конкретнее.
Технически можно сделать каждую кнопку отдельным классом. Но если вы ждете от каждой кнопки одного и того же поведения - пишется один класс для всех таких кнопок. Вам нужно учесть что класс "Кнопка" в андроиде уже есть - и его писать с нуля не нужно. Вам нужно лишь понять как вы хотите расширить поведение стандартной кнопки и создать класс-наследник от класса Button который будет реализовывать нужное вам поведение.
Если вам нужен горизонтальный скролл в кнопке, которая в прокручеваемом списке - это очень популярное поведение называется swipe. В андроиде - это называют SwipeListView - и он содержит не "кнопки" а двух-слойные контейнеры - где верхний слой текст с картинкой - а нижний при "сдвиге" верхнего - содержит 2-3 кнопки с действиями. "Сдвиг" можно провоцировать пальцем - или программно - это уже как вам нужно.
К сожалению, SwipeListView - не стандартный компонент - есть много библиотек на GitHub - которые реализуют такое поведение - ищите выбирайте что вам больше по душе.
Если избранное - это список чего - то ознакомьтесь для начала с принципами работы списков в андроиде, да и вообще - всех элемнтов интерфеса - будет яснее.
Если картинка нужна только твоему приложению - сохраняй в internal storage(openFileOutput) - никто не запретит)) Но и другим апам - будет недоступна.
Если нужно "поделится" картинкой с кем-то, напрем с почтовым аппом который ты откроешь для отправки почты - тут два пути - либо external storage(плохо - потому что надо будет за собой её оттуда у бирать - и всем она будет доступна, и через total comander - зайдут еще и удалят)
Либо - более правильный путь - как в первый раз - internal storage - но дописываешь к этому свой ContentProvider - для предоставления доступа внешним апам к твоему файлику
жаль что, вменяемых ответов до сих пор нет.