Persistent Toasts

[jameskuyper]

For each type of toast, we currently have the option of having either short or long toasts. Unfortunately, even with the long toasts, I sometimes miss them, especially when several show up in a row while my ship is on autopilot, or while I'm busy in the middle of combat. Despite that, sometimes the long toasts take too long to disappear; I'd like some way to get rid of them as soon as I've read them.
What I'd like to have is an additional option: persistent toasts. A persistent toast will stay on the screen until I acknowledge it in some appropriate fashion, and then promptly disappear. If my ship is on autopilot, it should halt until I've acknowledged a persistent toast; and I should also have the option of stopping the ship so I can change course as a result of the information contained in the toast. If I've selected persistent combat toasts, the combat buttons should be disabled until I've acknowledged a toast. I've done a number of stupid things in combat because a toast telling me about something important didn't show up until after I'd carried out two or three additional rounds of combat.

[Cory Trese]

The core challenge here is the Google gives you 2 types of Toasts -- short and long. Persistent Toasts aren't in their playbook.

I have been trying to build my own Toast Framework but it is slightly less easy than you might think at first glance.

[jameskuyper]

I'm an expert computer programmer, but for the past 15 years my specialty is writing scientific data processing software to run in a batch environment; I know nothing about Android programming. I wasn't sure what a "toast" actually was, but if they have such restrictions, than I should have worded my request differently.
Let me use the word "notice" to refer to the test that is displayed by a toast.

What I want is a new option for each kind of notice. For backwards compatibility, if for no other reason, this new option should probably be turned off by default. Whenever Startraders decides that it's time to send out a notice, if the persistent option is selected, then it should NOT send out the notice as a toast, but by some other mechanism. I don't know the proper name for this mechanism, but I know how I'd like to have it behave:

• If the autopilot is on, put it in pause
  
• If the player currently involved in combat, temporarily disable the combat buttons.
  
• Display the text of the message, so I can read it and provide at least two options: "Status" and "Dismiss". If the autopilot is on, there should also be a third option, "Stop".
  
• If "Dismiss" is selected, the notice disappears immediately. If the autopilot was on, the ship should continue on it's way. If in the middle of combat, the combat buttons should be re-enabled.
  
• If "Status" is selected, it works just like the Status buttons elsewhere in the game. As soon at the player has returned from consulting his status, the notice should be be displayed, along with the same 2 (or 3) options listed above.
  
• If "Stop" is selected, the notice disappears immediately, and the autopilot is stopped.
  
• The notice should never disappear until one of the 2 (or 3) options is selected.
  

[shellee]

Jul 8, 2011 10:18:33 GMT -5 Cory Trese said:

The core challenge here is the Google gives you 2 types of Toasts -- short and long. Persistent Toasts aren't in their playbook.

I have been trying to build my own Toast Framework but it is slightly less easy than you might think at first glance.

Could you implement a Toast's Log? I simply want to go find the ones I may have missed . Perhaps keep record of the last 10 toasts? May name it the. Capitans Log... Not to be confused with the Ship's log ;-)

[mordechai]

Jul 8, 2011 10:18:33 GMT -5 Cory Trese said:

The core challenge here is the Google gives you 2 types of Toasts -- short and long. Persistent Toasts aren't in their playbook.

Many apps give pop-up messages which require a response. Perhaps give the option for this instead of a toast? I'm often missing part of some toasts or find that I'm several steps ahead of others.

[Cory Trese]

Those applications are probably maintained by better programmers than I am.

I ended up using the core Android OS Toast system, which while easy to use, does paint you into a corner in a lot of situations.

For example, the part of the application that generates the notifications in the main map doesn't have any ability to pause / stop the map's drawing or animating. To have Toast/Notifications optionally require a response will require a substantial re-write of the map system.

I am currently looking into a Toast Log option of some type.