Здравствуйте!
Пока ни одного не посетил. Действительно, всё ограничилось просмотром вакансий, после чего возникла проблема, которая и породила мой вопрос.
Александр P:
Позволю себе ещё один вопрос :)
Получается, что с такой реализацией объекты Note не будут храниться в течение выполнения всей программы. Они будут заново создаваться с помощью менеджера при необходимости и умирать, когда действие этой необходимости закончилось.
В случае с построением списка я буду в цикле вызывать findById и полученные объекты сохранять в какую-нибудь структуру данных, а на основе их атрибутов строить сам список. В пределах этой Activity заметки прокэшированы, грубо говоря. Но допустим, что появится другая активность, там ведь этих объектов уже не будет — придётся снова инициализировать необходимые заметки. Возможно, что некоторые из них уже в списке были инициализированы, и мы могли бы этим воспользоваться, но выходит так, что мы повторно занимаемся тем, чем уже заняты были. Тогда не совсем ясно, зачем вообще эти объекты Note. Для удобства разве что? Конечно, работать с объектом Note через аксессоры приятнее, чем получать в руки какой-нибудь Cursor с набором данных, смысл которых известен лишь разработчику NotesManager'a.
Не напрашивается ли здесь всё же отдельный класс, который будет являться хранилищем (кэшем) этих заметок, где они будут лежать в какой-нибудь структуре данных (кстати, какой?)? Или всё это лишнее и издержки на повторную работу невелики?
Александр P:
Чтобы лишний раз не инициализировать менеджер заметок, хелпер базы данных и т.д. Учитывая, что тот же менеджер будет использоваться довольно часто, мне кажется, такой подход неплохим. Хотя, может, он и вправду неверен, ведь так можно пасть до того, что начать объявлять заранее все нужные приложению переменные глобальными, ссылаясь на увеличение производительности.
Идея с менеджером действительно хороша и удобна, воспользуюсь ей.
В целом, вижу архитектуру приложения теперь такой, что есть некий общий класс синглтон, в котором определены глобальные объекты: экземпляры необходимых менеджеров (работа с заметками, настройками), объекты, необходимые этим менеджерам (база данных), и есть множество объектов класса Note, непосредственно с которыми общаться может только менеджер, самостоятельно заботящийся об их существовании и хранении в базе данных.
Я написал то, что "Обновить драйвера Windows не даёт, ссылаясь на то, что всё самое лучшее уже стоит". Это происходит именно при нажатии на это "ссылку".
Вы правы насчет setInterval: лаги появляются от того, что канвас не успевает отрисовываться, однако requestAnimationFrame теоретически не уберет тормозов. Вернее, программа будет работать корректно, не будет «проскоков» шагов и т.п., но канвас по-прежнему будет долго рисоваться браузером, так что это скорее борьба со следствием.
Сам по себе процесс появления тормозов явно указывал на то, что со временем в программе накапливается какой-то «мусор», из-за которого, как указал sdevalex, не успевает отрисовываться канвас. Им и оказалась эта сетка. Добавление gDrawingContext.beginPath(); (ну, и gDrawingContext.closePath();) решает эту проблему.
Премного благодарен вам за столь быстрый ответ, решающий проблему.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Пока ни одного не посетил. Действительно, всё ограничилось просмотром вакансий, после чего возникла проблема, которая и породила мой вопрос.