Можно вопрос, а почему вы решили идти по такому сложному пути, а не решились просто сделать кастомный адаптер и LayoutManager для того же RecyclerView? Это скорее всего решило бы ваши проблемы, так и дало бы больше гибкости.
Ну, к MVVM душа лежит не у всех)
Все равно выглядит слишком сложно, а все ради чего, чтобы уйти от findbyid, onclicklistener`or да нескольких кастомных атрибутов? Ну не знаю. Реально интересная вещь, это слежение за данными и автоматическое изменение состояния view, но опять же, без данной библиотеки это просто еще 1 строчка в коде. Про KISS тоже забывать не нужно)
p.s. Хотя честно говоря, мое знакомство с databinding было уже довольно давно, может они там чего нового придумали, но я увы не в курсе. А все выше сказанное, так, мысли в слух, не более.
ORM же для этого придумали. Практически любая библиотека дает примерно такое же удобство в использовании, а разница в скорости для большинства проектов будет не существенна.
N5. По поводу кнопок — кнопки можно создавать и в XML и программно и как вашей душе угодно, а есть еще такая замечательная вещь как data binding…
Воу, это же мрак, особенно для новичка. Сколько не общался с людьми, все только и плюются от этой «фичи».
Лучше уж рассказать про тот же Butter Knife, который делает примерно тоже самое. Но в разы удобнее и понятнее.
Ну а чо, когда 3 андроид вышел, все и так кинулись использовать эти фрагменты. Казалось, что делать 1 активити и 150 фрагментов в нем, это спасение. Потом правда попустило)
На телефоне под андроид 4.1 видно как создаётся ещё одно окно.
До андроида 3.0 вообще жили на одних активити, и ничего, делали плавные приложения)
И ещё я сравнивал по ОЗУ. Фрагменты экономнее.
Пользователи себе телефоны с 3+гб оперативы покупают, чтобы мы им по 5-10мб экономили чтоли?)
Можно увидеть Методы onCreate и onStart одного из ваших фрагментов? Просто интересно что вы там загружаете.
К примеру, если вы там каждый раз дергаете SharedPref подобным образом
это будет давать лаг.
SharedPref лучше вообще инициализировать один раз при запуске, через контекст приложения, а потом обращаться к уже созданному объекту.
А что вы отображаете во фрагментах можно узнать? Просто судя по вашему предыдущему посту, у вас приложения на 3-4 активити без какой-то сложной графики. Не могу понять, что там может тормозить.
Используйте константы же. В этих цифрах запутаться легче легкого.
А вообще, большая часть проблем решилась бы сама собой, если бы вы просто ушли от фрагментов, от них реально получить пользу можно только в очень редких случаях, а в основном одни проблемы.
Тут больше вопрос не к Rx, а к используемому шаблону проектирования.
Используя MVP, вы делаете любую реализацию какого-нить «кеша» в презентере. А потом просто опрашиваете презентер, если данные есть, берете готовые, если нет загружаете новые. Если загрузка в процессе, то просто ждете конца.
В Rx же так же в onResume идет подписка и в onPause отписка?
Извиняюсь за «наезд», прочитал ваш код еще раз и все таки увидел переписанный App и все стало на свои места)
Целый день за монитором дает о себе знать. Надо идти спать…
Ну, во-первых.
Какой практический смысл разделения метода getInstance на 2 отдельных? Где может понадобиться инициализировать его, но не вызывать?
Во-вторых.
Вы предлагаете привязывать класс хелпера к контексту каждого нового активити и фрагмента? Так, а зачем вам тогда синглтон в данном случае?
Каждый раз вы будете дергать новый SharedPreferences, я наоборот уводил от этого автора.
Вариант чего? Инициализации SharedPreferences? Ну для примера.
Наследуетесь от Application, инициализируете SharedPreferences. Данный App нужно также прописать в манифесте, чтобы работало.
public class App extends Application {
public static SharedPreferences sSharedPreferences;
@Override
public void onCreate() {
super.onCreate();
sSharedPreferences = PreferenceManager.getDefaultSharedPreferences(this); // или ваш вариант, с кастомным именем
}
public static SharedPreferences getSharedPreferences() {
return sSharedPreferences;
}
}
После, например создаете синглтон, что-то вида.
public class PreferencesHelper {
private static PreferencesHelper INSTANCE = null;
private SharedPreferences mSharedPreferences;
private SharedPreferences.Editor mEditor;
public static PreferencesHelper getInstance() {
if(INSTANCE == null) {
INSTANCE = new PreferencesHelper();
}
return INSTANCE;
}
public PreferencesHelper() {
this.mSharedPreferences = App.getSharedPreferences();
this.mEditor = this.mSharedPreferences.edit();
}
//для примера сохранение данных в SharedPreferences
public void saveStatusCheckbox(String name, boolean status){
mEditor.putBoolean(name, status);
mEditor.apply();
}
//для примера загрузка из данных из SharedPreferences
public int loadStatusCheckbox(String name){
return mSharedPreferences.getBoolean(name, false);
}
}
А с переменной vip_status прыгать по методам дальше. И при изменении самого чекбокса менять ее, а не значение в Preferences. Его сохранять при выходе из активити, например в том же onDestroy.
Но это чисто работа с Preferences. Важнее продумать работу например при повороте экрана, или вариант того, что пользователь начнет упорно клацать кнопку ручного запуска задачи, тогда ваше приложение скорее всего упадет из-за нехватки памяти)
1. Я имел ввиду текст на кнопках и чекбоксах, не вынесенный в strings, хотя это скорее мои придирки учитывая что это тест проект на коленке.
3. Вам не нужно постоянно лазить в SharedPreferences. Он вам нужен чтобы загрузить/сохранить «статус» элементов, а для работы в коде нужно использовать какую либо переменную. А SharedPreferences лучше вообще один раз инициализировать при запуске приложения.
Хороший вы ресурс нашли для оттачивания кода)
Вам в прошлом посте вроде советовали Rx, гляньте на него, ну правда.
А теперь вопросы.
1. Разметка активити, хардкод текста
2. Класс Utils (который больше похож на «Constants»), часть переменных final, часть нет. Создается впечатление что вы не видите разницу.
3. Метод verify(). Во первых, повторяется 2 раза, принцип DRY считай нарушен. Насколько я понимаю метод дергается при каждой новой попытке, и каждый раз создает новый экземпляр SharedPreferences, как-то это не правильно. Да и вообще хранить данные переменные в SharedPreferences не совсем верно.
4. Я даже боюсь думать, что будет если запустить все это, и начать крутить телефон)
Почитайте про Rx и MVP, вы сможете упростить и укоротить свой код в разы)
Все равно выглядит слишком сложно, а все ради чего, чтобы уйти от findbyid, onclicklistener`or да нескольких кастомных атрибутов? Ну не знаю. Реально интересная вещь, это слежение за данными и автоматическое изменение состояния view, но опять же, без данной библиотеки это просто еще 1 строчка в коде. Про KISS тоже забывать не нужно)
p.s. Хотя честно говоря, мое знакомство с databinding было уже довольно давно, может они там чего нового придумали, но я увы не в курсе. А все выше сказанное, так, мысли в слух, не более.
ORM же для этого придумали. Практически любая библиотека дает примерно такое же удобство в использовании, а разница в скорости для большинства проектов будет не существенна.
Воу, это же мрак, особенно для новичка. Сколько не общался с людьми, все только и плюются от этой «фичи».
Лучше уж рассказать про тот же Butter Knife, который делает примерно тоже самое. Но в разы удобнее и понятнее.
До андроида 3.0 вообще жили на одних активити, и ничего, делали плавные приложения)
Пользователи себе телефоны с 3+гб оперативы покупают, чтобы мы им по 5-10мб экономили чтоли?)
Можно увидеть Методы onCreate и onStart одного из ваших фрагментов? Просто интересно что вы там загружаете.
К примеру, если вы там каждый раз дергаете SharedPref подобным образом
это будет давать лаг.
SharedPref лучше вообще инициализировать один раз при запуске, через контекст приложения, а потом обращаться к уже созданному объекту.
Ну не так же логи выводятся в андроиде то) Вот, почитайте.
Используйте константы же. В этих цифрах запутаться легче легкого.
А вообще, большая часть проблем решилась бы сама собой, если бы вы просто ушли от фрагментов, от них реально получить пользу можно только в очень редких случаях, а в основном одни проблемы.
Используя MVP, вы делаете любую реализацию какого-нить «кеша» в презентере. А потом просто опрашиваете презентер, если данные есть, берете готовые, если нет загружаете новые. Если загрузка в процессе, то просто ждете конца.
Нет, Rx не привязан к контексту активити.
Целый день за монитором дает о себе знать. Надо идти спать…
Какой практический смысл разделения метода getInstance на 2 отдельных? Где может понадобиться инициализировать его, но не вызывать?
Во-вторых.
Вы предлагаете привязывать класс хелпера к контексту каждого нового активити и фрагмента? Так, а зачем вам тогда синглтон в данном случае?
Каждый раз вы будете дергать новый SharedPreferences, я наоборот уводил от этого автора.
Наследуетесь от Application, инициализируете SharedPreferences. Данный App нужно также прописать в манифесте, чтобы работало.
После, например создаете синглтон, что-то вида.
и используете его в Activity вот так.
А с переменной vip_status прыгать по методам дальше. И при изменении самого чекбокса менять ее, а не значение в Preferences. Его сохранять при выходе из активити, например в том же onDestroy.
Но это чисто работа с Preferences. Важнее продумать работу например при повороте экрана, или вариант того, что пользователь начнет упорно клацать кнопку ручного запуска задачи, тогда ваше приложение скорее всего упадет из-за нехватки памяти)
3. Вам не нужно постоянно лазить в SharedPreferences. Он вам нужен чтобы загрузить/сохранить «статус» элементов, а для работы в коде нужно использовать какую либо переменную. А SharedPreferences лучше вообще один раз инициализировать при запуске приложения.
Вам в прошлом посте вроде советовали Rx, гляньте на него, ну правда.
А теперь вопросы.
1. Разметка активити, хардкод текста
2. Класс Utils (который больше похож на «Constants»), часть переменных final, часть нет. Создается впечатление что вы не видите разницу.
3. Метод verify(). Во первых, повторяется 2 раза, принцип DRY считай нарушен. Насколько я понимаю метод дергается при каждой новой попытке, и каждый раз создает новый экземпляр SharedPreferences, как-то это не правильно. Да и вообще хранить данные переменные в SharedPreferences не совсем верно.
4. Я даже боюсь думать, что будет если запустить все это, и начать крутить телефон)
Почитайте про Rx и MVP, вы сможете упростить и укоротить свой код в разы)