• Как правильно организовать хранение объектов в Android приложении?

    Да, верно, объекты будут создаваться всякий раз при перезапуске программы. Но я уже в самом начале написал, что это нормально. Объекты будут создаваться (пускай даже и не вами, а другим инструментом) в любом случае. Посмотрите, например, в сторону Hibernate – системы, которая сохраняет объекты в базу данных и извлекает их оттуда. С точки зрения пользователя всё происходит прозрачно, но на нижнем уровне всё равно генерируются SQL-запросы, конструируются объекты, и т.п. Так что повторного создания объектов не избежать, это, повторюсь, нормально.
    В случае с построением списка вызывать findById в цикле не нужно: надо ведь просто получить те данные, что вам в данном случае нужны (например, id заметки, её заголовок и дату последнего изменения – вы ведь не собираетесь на одном экране выводить все данные по всем заметкам, я надеюсь?) – в этом случае достаточно одного SQL-запроса, который будет получать значения нескольких нужных вам полей. Получение данных порциями можно реализовать при помощи SQL-оператора LIMIT.
    Полноценные объекты Note вам понадобятся только для работы с конкретной заметкой (создание, редактирование). Для вывода списка я создал бы отдельный класс – что-то вроде NoteHeader, который будет содержать только те данные по конкретной заметке, которые нужны для списка (см. выше). Чтобы избежать дублирования кода, можно даже сделать класс Note его потомком, потому что часть полей у них, очевидно, по смыслу будет общей. Так что и о кэшировании можно не беспокоиться: на главном экране (в стартовом Activity) у вас будет коллекция объектов NoteHeader, которые никуда не денутся, пока вы не вышли из программы (хотя эту коллекцию может потребоваться обновить, если вы, например, выберете заметку на главном экране и отредактируете её). А полноценные объекты Note будут создаваться только во время работы с конкретной заметкой, и ограничение их времени жизни этими рамками – правильно, о производительности тут не беспокойтесь.
  • Как правильно организовать хранение объектов в Android приложении?

    Riodevista:
    Это в любом случае плохая практика с точки зрения обеспечения инкапсуляции и связности. Если вам нужно использовать какие-то объекты из разных мест программы многократно, лучше их передавать в конструкторы объектов-пользователей либо как параметры соответствующих методов – смотря по ситуации.
  • Java, куда именно податься?

    Yuri Kan: не за что, надеюсь, поможет принять правильное на данный момент решение :)
  • Как правильно организовать хранение объектов в Android приложении?

    Riodevista:
    Рад, что смог помочь.
    По поводу архитектуры: не вижу большого смысла в том, чтобы создавать отдельный класс, единственной задачей которого будет хранить необходимые ссылки на менеджеры и т.п. Зачем это нужно? Чтобы иметь возможность из любого места программы работать с любыми глобальными объектами?
  • Для чего нужен внутренний класс?

    afna: пожалуйста, задавайте ещё вопросы :)
  • Проблема с обработкой Java кода?

    Приложите, пожалуйста, более полный стектрейс. И напишите, что за JVM используется.