Когда использовать новые макеты и когда использовать новые действия?

Question

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

1. Стартовый экран
2. Сложный экран выбора
3. Экран игры.
4. Экран паузы.
5. Игра закончена.

И есть несколько различных способов перехода между экранами:

1 -> 2

2 -> 3

3 -> 4 (пауза)

4 -> 1 (выход из игры)

4 -> 3 (возобновить игру)

3 -> 5 (игра заканчивается)

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

Может кто-нибудь дать мне несколько советов о том, как проще всего реализовать описанные выше экраны и переходы в Android? Все методы создания / уничтожения / паузы / возобновления заставляют меня нервничать из-за написания хрупкого кода, если я не буду осторожен.

Мне не нравится использовать Activity для каждого экрана. Это кажется слишком тяжелым, необходимость передавать данные с помощью намерений кажется настоящей болью, и каждый экран сам по себе не является полезным модулем. Так как кнопка «назад» также не всегда возвращает к предыдущему экрану, мой макет меню, похоже, не подходит для модели деятельности.

В данный момент я представляю каждый экран в виде файла макета XML и У меня есть одно занятие. Я установил различные кнопки на каждом макете для вызова setContentView для обновления экрана, который показывает основное действие (например, кнопка паузы меняет макет на экран паузы). Активность распространяется на все необходимое состояние (например, текущий уровень сложности и высокий балл игры), что позволяет легко обмениваться данными между экранами. Это похоже на пример LunarLander, за исключением того, что я использую несколько экранов.

Звучит ли то, что у меня в данный момент, нормально, или я не делаю что-то типичное для Android? Могу ли я использовать класс (например, что-то вроде ViewFlipper), который мог бы облегчить мою жизнь?

Кстати, мой игровой экран реализован в виде SurfaceView, в котором хранится состояние игры. Мне нужно, чтобы состояние в этом представлении сохранялось между вызовами setContentView (например, для возобновления из приостановленного режима). Является ли правильной идеей создать вид игры в начале игры, сохранить ссылку на нее, а затем использовать эту ссылку с setContentView всякий раз, когда я хочу, чтобы экран игры отображался?

Answer 1

Этот вопрос задавался много. Вы читали эти другие сообщения?

Android: что лучше - несколько действий или переключение видов вручную? . В частности, эта ссылка рассказывает о Руководстве по дизайну Android , в котором "вообще не упоминается переключение видов; оно сосредоточено вокруг дизайна" Активность как представление ".

Android - следует ли использовать несколько действий или несколько видов контента

Android-приложение с несколькими действиями

Как передать значения из одного действия в предыдущее действие

Я не уверен, что вы подразумеваете под кнопкой «Назад», не всегда правильно возвращающейся на правильный экран. У меня есть игра с такой же структурой, как и у вас, и кнопка «Назад» всегда правильно поднимает пользователя вверх по цепочке действий.

Кроме того, использование onResume, onPause и т. Д. Несколько необходимо. Что происходит с вашим приложением, если звонит телефон? (Да, я знаю, некоторые люди все еще делают странные вещи, например, используют свой телефон для приема звонков!: P) ОС пытается вызвать метод onPause в вашей активности, но если он не реализован, ваше приложение будет работать не так, как ожидается , Еще одна полезная вещь в onResume - она ​​позволяет обновлять таблицы, как только пользователь возвращается к представлению. Например, ваш игрок только что прошел уровень и затем возвращается на экран выбора сложности. Если вы просто восстановите предыдущий экран из памяти, он, возможно, не был обновлен, чтобы учесть, что уровень был только что завершен. Однако, если вы добавите некоторый код в onResume для его обработки, он всегда будет выполняться до того, как игрок увидит экран.

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