2013-04-15 1 views
0

У меня вопрос. Каков наилучший способ хранения объектов ArrayList Float, чтобы я мог перезагрузить ArrayList, когда моя активность перезапустится из-за переключения ориентации моего устройства? Я думал об использовании Bundles, но тогда мне пришлось бы расширить класс Float, чтобы он реализовал Parcelable. Поскольку класс был объявлен окончательным, к сожалению, я не могу этого сделать. Я немного поработал и нашел несколько решений для подобных проблем, таких как переопределение onRetainNonConfigurationInstance(). Я также подумал о создании моего собственного класса оболочки-оболочки для примитива float и создания его Parcelable. Следует отметить, что ArrayLists, которые я хочу сохранить, находятся внутри классов, экземпляры которых создаются внутри экземпляра DrawView моего Activity.Как сохранить объекты ArrayList Float, чтобы я мог восстановить их, когда моя активность перезагрузится?

Я еще не хотел публиковать код, потому что я ничего не сделал для решения проблемы, кроме исследования возможных решений. Если вы, ребята, должны это увидеть, сообщите мне, и я с радостью опубликую его.

Относительно примечания, причина, по которой я решил использовать ArrayLists, состояла в том, что я хотел использовать некоторую форму распределения динамической памяти. Поскольку из-за характера моего приложения я не могу предсказать, сколько объектов будет в массиве, я хотел бы иметь способ выделить столько памяти, сколько мне нужно для хранения объектов Float. По правде говоря, мне нужно хранить только примитивы float, но ArrayLists требуют непримитивов. По какой-то причине вы, ребята, знаете лучший способ сделать это, потому что использование ArrayLists с плавающей точкой только для хранения примитивных значений кажется мне немного неуклюжим.

+0

Лучший способ сохранения состояния в конфигурационных изменениях по-прежнему является подходом «NonConfig». –

+0

Я хотел бы прокомментировать статические классы на Android, также, как предложено ниже. Они не работают, как вы ожидаете на Android. Не говори, что я тебя не предупреждал. –

ответ

1

Подход NonConfig в настоящее время (по API 13/Android 3.2) устарел, но на практике это не означает многого, особенно если вы хотите поддерживать более старые уровни API, потому что устаревшие методы обычно остаются довольно долгое время. As of today, according to official Google figures, Android 2 aka APIs 8 to 10 has a market share of 43.8% (note: that page will get updated regularly) и многие 2.3 (API 9 или 10) устройства в настоящее время продаются в сегменте бюджетного рынка. Поэтому подумайте дважды, если вы не хотите их поддерживать, и будьте уверены, что Google не будет отключать методы NonConfig в ближайшее время.

Приятная часть около onRetainNonConfigurationInstance() и getLastNonConfigurationInstance() заключается в том, что они чрезвычайно эффективны как в отношении потребления ресурсов, так и для осуществления усилий. Почти 50% устройств, не предлагающих лучшего подхода, - это просто путь к сегодняшнему дню.

-1

Как насчет статического класса с массивом поплавков?

+0

Массив как статическое публичное свойство, конечно ... –

+0

Вау! Я полностью забыл о «статическом» модификаторе. Хорошая идея. – user2154603

+0

Вы имеете в виду подклассифицированный класс 'Application'? –