WIP: Initial implementation #1
Conversation
| Future.delayed(widget.fadeInDuration).then((_) { | ||
| setState(() { | ||
| _visible = false; | ||
| }); |
There was a problem hiding this comment.
you can inline this set state call
| Future.delayed(widget.waitDuration).then((_) { | ||
| setState(() { | ||
| _visible = true; | ||
| }); |
There was a problem hiding this comment.
you can inline this set state call
| widget.fadeOutDuration | ||
| ).then((_) { | ||
| Navigator.of(context).pushReplacementNamed(widget.navigateTo); | ||
| }); |
There was a problem hiding this comment.
why not add this inside the callback with only the fadeOutTime or have the three as separated invocations summing the times?
|
|
||
| void main() { | ||
| test('adds one to input values', () { | ||
| final calculator = Calculator(); |
There was a problem hiding this comment.
Some comments, I love the idea and overall looks good (have some nits).
Two bigger issues to think are:
- you are missing reamds, license, TODOs there (should be easy to add)
- and the harder question is, this impl does not allow for it to wait for stuff to load, making it a fake splash screen, right? I'm not sure, is the idea to start loading, show this for a fixed time while loading and then if necessary show a custom loading bar? Could we provide that functionality? Or is it too much? I don't know, I'm just thinking how it would work on a real game were I actually need to load dozens of futures before starting (images, sounds, config files, system calls, network connections, play games, etc).
This is WIP, I will add those after we finish discussing the APIs
Yeah, that could be a good addition, like a loadResources parameter that must return a Future, and we wait for it before fading out sounds good? |
|
Yeah, I thought of something like that. But then if we are going to control that, we need a way for the user to complement our animation with his own logos (company, game) and eventually an actual loader/spinner. Because I assume some users would use it as a quick and working loading screen, but eventually would like to show flame for fixed time, studio for fixed time, and a loading for the remaining time for the actual load, instead of waiting on flame for all the loading and then having extra wait time for the other logos and such. Makes sense? |
The custom logo I think is cool, but I think this is a plus, this is more of a way for people showing their support to Flame, by helping advertising it, it is common on games for engines to have their own splash screen, but I see no problem on letting the user add their own logo to this module. The spinner I don't like, loading things on a Splash screen, is a way to fake loading things, so it is something more natural to the player, if we add a spinner, we totally break that feeling. I think we should add the option to the custom logo, and a parameter that receives a function which returns a Future, and wait for it alongside the splash screen fade/wait times. What do you think? |
|
"fake loading things" -> that is my concern, the use case I see is:
I don't want to show only flame splash screen for 5 seconds while my whole game loads and then show a fake splash screen to show my studio. Does that make sense? |
|
I am confused, all the use cases you listed will be fullfilled if we do what I proposed on my previous comment. The only thing I have disagreed was to show a spinner, or a loading indicator, because that will kill the feeling of the "not loading, just a slpash screen" |
|
Agreed, I just exemplifying the need to add a custom logo/studio. This is just one case by the way, three requirements for the same app (just making sure it's clear). |
|
Got it, I will include all the features, optional of course so the user can
combine which one he or she wants.
Em qua, 30 de out de 2019 às 21:07, Luan Nico <notifications@github.com>
escreveu:
Agreed, I just exemplifying the need to add a custom logo/studio. This is
just one case by the way, three requirements for the same app (just making
sure it's clear).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1?email_source=notifications&email_token=AAGMAONTNAW46YSD7OVQ6Y3QRIOUVA5CNFSM4JE4LPWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECWE4WA#issuecomment-548163160>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGMAOPSCAAXTFUKVBOI2N3QRIOUVANCNFSM4JE4LPWA>
.
--
Sent from MetroMail
|
|
Closing this in favor of #2 |
This PRs adds the first implementation of this widget, my idea here is to provide a simple, easy to use Flutter widget to function as a splash screen for Flame.
I choose to make it a separate package because this widget bundles images (the Flame logo) and although they are small, I think it would be bad if this was bundled with Flame, because since we always try to make things optional there, would be annoying to add that file size to people who don't want to add the splash screen to their games.
This is result so far (be aware that this is a GIF from a recorded screen, so it may not be as smooth as it is on the device):
I would like here to discuss about the current api, if that is already good, if there is any suggestions and etc, when we finish the discussions here, I will finish writing the docs and README.