Хранение состояний

Как было описано выше ОС Android позволяет приложениям хранить данные, соответствующие активити в специальном классе Bundle. Вызывается метод public void onSaveInstanceState(Bundle outState), когда устройство меняет состояние приложения с «выполняется» на «приостановлено» или «завершено». В его реализации разработчик должен сохранить данные, необходимые для дальнейшего восстановления состояния. Для этого Bundle обладает множеством методов, позволяющих отправить на хранение объект определенного типа: putBoolean(String key, boolean value), putByte(String key, byte value), putChar(String key, char value), putLong(String key, long value), putLongArray(String key, long[] value).Такая структура методов эффективна и проста для понимания: легко представляется в виде таблиц, в которой первый столбец является ключом, второй хранимым значением.

В нашем приложении приходится обращаться со сложными объектами, данные методы не подходили. Был использован метод putSerializable(String key, Serializable value), позволяющий отправить на хранение любой сериализуемый объект. Сериализация(обратная операция- десереализация) – процесс, переводящий объект в битовую последовательность, обратная- восстановление объекта из массива бит. Для того, чтобы объект некоторого класса можно было сериализовать, класс должен быть помечен специальным интерфейсом-маркером java.io.Serializable, дающим понять виртуальной машине, что объект данного класса может быть сериализован. Сущности задачи являются сериализуемыми. В приложении придется сохранять в Bundle коллекции сущностей или объектов карты, возникает неприятный момент: интерфейсы java.util.List, java.util.Map, java.util.Set не являются сериализуемыми. Классы, которые их реализуют и используются в задаче(java.util.ArrayList, java.util.HashSet, java.util.HashMap) являются сериализуемыми, поэтому пришлось при объявлении переменных указывать класс, а не интерфейс, либо проводить операцию приведения по типу при вызове метода.

Согласно спецификации, любой из методов отправления объекта в хранилище перетрет предыдущее значение, которое имеет этот же ключ, при опечатке в ключе ошибку до исполнения и получения некорректного значения отловить будет невозможно, поэтому к выбору ключей нужно подходить ответственно. Разумным способом хранения ключей будет их вынесение в константы в классе, в котором они будут использоваться, например так записан ключ в одном из фрагментов, работающих с картой: private static final String SELECTED_ROUTES_KEY = "selected_routes".

Важным является выбор тех объектов, которые нужно хранить. Не смотря на то, что основными объектами, с которыми работают формы являются сущности из локальной базы или некоторые транспортные объекты, не всегда оправдана лишняя конвертация из объектов модели в объекты, рисуемые на формах. Если везде заниматься хранением именно объектов модели, то возникнут проблемы с производительностью. В таком случае разница между созданием формы «с нуля» будет отличаться от восстановления отсутствием обращения к базе данных. Это даст существенную разницу в производительности, но остается возможность оптимизировать алгоритм работы с состояниями форм.

Показательным примером в этом плане служит работа с маршрутами. В сущности маршрута имеется список точек, в которых содержится информация не только о географическом положении, необходимом для отображения на карте, но и о временных, скоростных характеристиках. Для того чтобы нарисовать на карте линию (объект класса com.google.android.gms.maps.model.Polyline) необходимы точки карты (объекты класса com.google.android.gms.maps.model.LatLng). Их и можно хранить. Это исключает лишнюю конвертацию сущностей в объекты для работы с картой.

Важным параметром при восстановлении фрагментов, содержащих карту, является положение камеры. Как было описано выше, за положением камеры следит специальный слушатель, записывающий значения приближения, широты и долготы в SharedPreferences открытого активити.

При сохранении состояния спискового представления можно пойти двумя путями: 1) хранить объекты отображаемые в графическом элементе 2)хранить объекты модели, которые отображаются в списковом представлении. Первый способ кажется менее затратным, так и есть, но из-за специфики некоторых компонентов(таких, как планировщик маршрутов), объекты модели все равно необходимо хранить и передавать в контейнер, т.к. объекты списка не содержат многой информации и не предназначены для работы вне своей таблицы, на их основе нельзя будет сформировать данные по маршруту на карте. Поэтому был выбран второй вариант: хранятся объекты модели и идентификаторы выбранных элементов, на основе которых будет сформирован выбор элементов спискового представления после пересоздания.

Поиск по сайту: