You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Daniel Reicher <da...@gmail.com> on 2012/03/08 00:55:54 UTC

[Proposal] New Component: Toast Notification

Had some time this afternoon and wanted to start with something small to
get familiar with the submission process as stated in this thread:
http://mail-archives.apache.org/mod_mbox/incubator-flex-dev/201203.mbox/%3CCAE0mPOs+Qj_qhdiKS9N86m6ydDjRbx5rENVnoQ5Xs_KFcEA+Vw@mail.gmail.com%3E

The component is a toast notification with skins for web and mobile. I've
tried to follow current SDK conventions as much as possible. My ultimate
goal is to get some understanding of the process for submitting and less
about the actual component. That said, it is my feeling that something like
this could be a candidate for inclusion in the SDK. It is a first class UI
component in the Android SDK and growls are common in the Apple world (I
believe).

The code is available at:
http://code.google.com/p/flex-spark-toast/source/browse/#svn%2Ftrunk%2Fflex-spark-toast
if
you'd like to take a look and offer feedback. I wasn't sure if this should
be included in the main SDK or mobile only, but I built the MXML skin
anyway.

RE: [Proposal] New Component: Toast Notification

Posted by FRANKLIN GARZON <fg...@hotmail.com>.
Nice

 
Franklin Garzón
 
Regional Development Manager

MCITP  Microsoft SQLServer

 
*Si el hombre dejara de aprender entonces dejaría de existir*
 
094496862
 
 
 > Date: Thu, 8 Mar 2012 10:36:41 -0800
> Subject: Re: [Proposal] New Component: Toast Notification
> From: danreicher@gmail.com
> To: flex-dev@incubator.apache.org
> 
> >
> >
> > Android typically does queue notifications up. While that's a nice to have
> > I wouldn't see it as essential for a first release.
> >
> > I posted an example at:
> http://flex-spark-toast.googlecode.com/svn/trunk/flex-spark-toast/example/ToastExample.html
> with
> view source. I also made some adjustments to the mobile skin (was off a bit)
 		 	   		  

Re: [Proposal] New Component: Toast Notification

Posted by Daniel Reicher <da...@gmail.com>.
>
>
> Android typically does queue notifications up. While that's a nice to have
> I wouldn't see it as essential for a first release.
>
> I posted an example at:
http://flex-spark-toast.googlecode.com/svn/trunk/flex-spark-toast/example/ToastExample.html
with
view source. I also made some adjustments to the mobile skin (was off a bit)

Re: [Proposal] New Component: Toast Notification

Posted by Daniel Reicher <da...@gmail.com>.
>
>
> This idea of a toast component, which I'm not totally sold on in the SDK,
> got me to thinking. If there would be a reason to include well made ANEs
> into the SDK.
>
> For something like toast it would use the Android toasts on android
> devices, ios for ios, etc. And if running on the web just fall back to the
> "flex toast" for web.
>
>
I think that developing and maintaining ANEs should be something the
community strives for and I agree that there are situations where an ANE
would be a better fit. I think instead of keeping them in the SDK, they
should be leveraged by a tool like AIR Launchpad [1] where they can be
proactively included in a project based on the need of the project.

As for visual components, I think ANEs serve a purpose when you are trying
to achieve a *native* look across multiple platforms; whereas, built-in
components are for achieving a *uniform* look across multiple platforms.

Like you, I'm not sure where something like a toast fits in to that. I
think both cases are valid and cosmetically I feel like Flash/Flex devs are
more, shall we say picky, about UI consistency than your average folk. I,
for one, like the control that comes with using a built-in mechanism in
terms of styling. The last thing I would want is to use a very specific
font/color scheme only and jar the user out of that with a notification
that respects neither - or worse leads to confusion as to whether a
notification even "belongs" to the app they are using.


[1] http://labs.adobe.com/technologies/airlaunchpad/

Re: [Proposal] New Component: Toast Notification

Posted by Jonathan Campos <jo...@gmail.com>.
On Thu, Mar 8, 2012 at 1:51 AM, Justin Mclean <ju...@classsoftware.com>wrote:

> Android typically does queue notifications up. While that's a nice to have
> I wouldn't see it as essential for a first release.


This idea of a toast component, which I'm not totally sold on in the SDK,
got me to thinking. If there would be a reason to include well made ANEs
into the SDK.

For something like toast it would use the Android toasts on android
devices, ios for ios, etc. And if running on the web just fall back to the
"flex toast" for web.

Milling it over in my head I determined it may be a bad idea due to various
platforms and versions, but something to consider. It could be very helpful
for those very common use cases that span multiple platforms.

J

-- 
Jonathan Campos

Re: [Proposal] New Component: Toast Notification

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> That would leave the option open for queuing notifications, etc. 

Android typically does queue notifications up. While that's a nice to have I wouldn't see it as essential for a first release.

Thanks,
Justin

Re: [Proposal] New Component: Toast Notification

Posted by Daniel Reicher <da...@gmail.com>.
>
> It's probably a bit early to be changing manifest files until we decide on
> new component namespaces and where they should live but you do have to
> compile it somehow.
>

Agreed. I hope this gets figured out as we go forward. I'll be honest -
part of the reason behind initiating this process is the desire to bring
some of these "gray" areas to light so they can be discussed and decisions
made. There seem to be a lot of questions being kicked down the road. I've
never built a theme that "inherited" from another theme, so I don't know
how easy or difficult that is. I've always assumed they were fairly
self-contained. Perhaps they need to share a project with different build
targets.


> Just not 100% sure if the popup is already showing do you need to restart
> the timer?
>

The thought process there was if you wanted to front end this with a
"ToastManager" singleton that only ever uses one instance of the Toast all
you would need to do is change the label and call show(). That would leave
the option open for queuing notifications, etc. Presumably, if you're
explicitly calling show() more than once you'd expect to get a "full"
showing; though, I may be off on that and open to discussion on behavior.
Ultimately, it was just a guess on desired behavior and I didn't look in to
how Android handles that case.

Re: [Proposal] New Component: Toast Notification

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

Thanks for the patch. 

It's probably a bit early to be changing manifest files until we decide on new component namespaces and where they should live but you do have to compile it somehow.

It may be (for example) that extra components like this are added to a new swc so not to increase the current swc size especially as this may have limited use in iOS??? (MobileAndroid.swc or MobielExtra.swc perhaps?) Anyone else have a view on this?

> I took a second look at the show() logic and not sure what you're seeing.
Just not 100% sure if the popup is already showing do you need to restart the timer?

Thanks,
Justin

Re: [Proposal] New Component: Toast Notification

Posted by Jonathan Campos <jo...@gmail.com>.
On Wed, Mar 7, 2012 at 6:40 PM, Daniel Reicher <da...@gmail.com> wrote:

> I'll take a swing at a test set and an example project if I get some time
> tonight.
>

The first thing I was looking for was an example of the component.
Obviously the more versatile the example the better - to help show off your
component.

-- 
Jonathan Campos

Re: [Proposal] New Component: Toast Notification

Posted by Daniel Reicher <da...@gmail.com>.
Justin,

Thanks for the feedback. I checked in with the apache headers. I also added
a diff download for just integrating the component into the mobile projects
only (not the desktop) at
http://code.google.com/p/flex-spark-toast/downloads/list if that is better
for folks.

I took a second look at the show() logic and not sure what you're seeing.

I'll take a swing at a test set and an example project if I get some time
tonight.

On Wed, Mar 7, 2012 at 4:22 PM, Justin Mclean <ju...@classsoftware.com>wrote:

> Hi,
>
> > The code is available at:
> >
> http://code.google.com/p/flex-spark-toast/source/browse/#svn%2Ftrunk%2Fflex-spark-toast
>
> Great contribution.
>
> A couple of minor points.
> 1. Files need an apache header.
> 2. I think the logic in the show method regarding !showing and popupTimer
> reset may not be correct. Not 100% sure.
> 3. A simple example showing how it should typically be used would help.
>
> I've not done a lot of mobile work so perhaps some of the people on the
> list more experienced with writing mobile components can add more feedback.
>
> The biggest issue I see to having this included in a future SDK is that
> there are no tests. As we're waiting on Mustella to be donated it would be
> good to see some FlexUnit tests giving the component a workout.
>
> Before this code was accepted as part of the Flex SDK you would most
> likely need to sign and submit a CLA[1].
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/licenses/#clas
>
>

Re: [Proposal] New Component: Toast Notification

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> The code is available at:
> http://code.google.com/p/flex-spark-toast/source/browse/#svn%2Ftrunk%2Fflex-spark-toast

Great contribution. 

A couple of minor points. 
1. Files need an apache header.
2. I think the logic in the show method regarding !showing and popupTimer reset may not be correct. Not 100% sure. 
3. A simple example showing how it should typically be used would help.

I've not done a lot of mobile work so perhaps some of the people on the list more experienced with writing mobile components can add more feedback.

The biggest issue I see to having this included in a future SDK is that there are no tests. As we're waiting on Mustella to be donated it would be good to see some FlexUnit tests giving the component a workout.

Before this code was accepted as part of the Flex SDK you would most likely need to sign and submit a CLA[1].

Thanks,
Justin

1. http://www.apache.org/licenses/#clas