Можно сделать таблицу в базе данных для них, где будут соответствующие поля "время", "дата", "текст", "путь к файлу" (Тогда отслеживать, что он остался прежним).
Но мне кажется, что такой подход не совсем верный, ведь напоминания — это объекты, с которыми удобно было бы работать, непосредственно обращаясь к ним, вызывая методы, например, note1.delete().
Как решить эту задачу с помощью объектов я не представляю. Допустим, в приложении мы создали таких несколько, но как быть дальше? Надо их где-то хранить. В той же базе данных?
Если вам удобно (да так в принципе и правильно, хотя и медленнее) работать с объектами а не с записями в БД - то
для таких вещей есть такая штука как ORM. (
у вас конечно простой случай, и потому работать с записями в вашем проекте - самое то. И тем более - если вы новичок - стоит разобраться с тем, как работать с БД напрямую. Но вообще, как только сделаете учебный проект с БД - , стоит понять, что в других сложных проектах - проблем с БД будет гораздо больше и будет сложнее и лучше осваиваться с "промышленными подходами")
В общем есть ORM. Если расшифровывать - это "модель/правила" которая/которые позволяют вам сохранять состояния объектов в БД и восстанавливать их.
А на практике - это набор классом которые делают за вас всю черновую работу по взаимодействию с БД (или тем хранилищем которое под ними лежит). И вы работаете не с БД, а с некой абстракцией, которая скрывает от вас что где и как она хранит в БД или том хранилище, которая ORM использует.
Т.е. вы говорите что-то типа - "
О, мой ORM! дай мне объект типа 'МояЗаметка' c идентификатором 12345!" и он сам лезет куда-то в БД (куда именно - это его личные проблемы) и отдает вам обхект класса МояЗаметка которая заполнена данными заметки с номером 12345. А дальше - "чо хошь с ним, то и делай".
А как сделал все что надо (дургая его методы, меняя свойства или как ещё), - отдаешь его обратно своему ORM-слою ( ORM можно рассматривать как слой абстракции над БД или любым другим хранилищем ) - типа "
на вот тебе объект, сохрани его в БД." - и механизмы ORM делают всю черновую работу по генерации SQL-запросов и всего прочего за вас.
В зависимости от того что от орм хотели создатели, ORM может или нет управлять структурой БД или пытаться вытаскивать свои объекты из ранее созданной структуры; управлять метаданными ваших объектов и (например) содержать или нет данные о том, как эти свойства надо отображать или нет.
В некоторых ORM есть кодогенератор - т.е. вы даете ему описания классов, а он вам генерирует код, который сохраняет классы в БД и восстанавливает оттуда. Часть ORM-механизмов работтают отталкиваясь от аннотаций - т.е. вы над каждым из полей которые хотите сохранять в БД надписываете его имя, тип, индексацию и другие параметры - так например делает
Persistence API - но его нет на Андроиде, потому это не наш случай (да и работа через рефлекшен считается медленной).
Ещё могу дать 2 ссылки - на сравнительную статью ОРМ для Андроид и на мой сосбвтенный ОРМ-велосипед :
www.ninthavenue.com.au/android-orm-jpa
https://gitorious.org/unat/pages/SimpleORM_Overvie...
(
последнее - "на правах рекламы". творение моё, но давно не обновлявшееся в публичной репе. Сейчас много изменений, как сдаим текущий проект - опубликую что поновее. В принципе, не столько для пользования, сколько вам - для освоения идей и выдачи конструктивной критики и вопросов. если что - спрашивайте - по UnAT я вам расскажу всё)))
Средний
Простой