On Sun, Feb 23, 2014 at 1:04 PM, Matthias Wessendorf <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: Hi, over the weekend I spoke w/ a friend: His company is doing some mobile (iOS/Android) apps which also support receiving push notifications. Two examples he told me. After receiving push notification: * One of their apps basically fetches the latest version of a CSV file, stored on a public HTTP Server. * Another app is used to tell sales guys new brochure files (PDF) are available on a protected resource of a webserver (which they _can_ than download from w/in the app, if the like to) The company build a simple console (PHP) which allows them to send new push messages, when ever their customers want to. I showed them our UnifiedPush Server and its usage via our AeroDoc example (iOS / backend). They really liked the UnifiedPush Server. Especially that it does store all the device metadata. But since a lot of their mobile apps don't have a backend requirement, they would still have to use their own console (which than connects to UPS) for submitting all the push messages they want. This brings me to [AGPUSH-38] and I really think we should implement that feature. Not only for sending test messages! If our UnifiedPush Server allows its users to simple send push messages to all of their mobile apps, it would make the server even more attractive. I regret a bit that I was against [AGPUSH-38] in the beginning, I guess that's due to my Java enterprise background, where you typically find complex setups, and server talk to servers :-( Anyways, now I really think that the UPS has to have such a 'send push' facility inside of the Admin UI :-) I believe that we could reach way more potential users with something like that +9001 and I already started thinking about this for a while. I will try to submit some mockups/POCs this week so we can discuss that and I have quickly a first working version on master. Any thoughts? Greetings, Matthias [AGPUSH-38] https://issues.jboss.org/browse/AGPUSH-38 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mon, Feb 24, 2014 at 12:52 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: > Sounds good. > Let me know if you need any help with the mockup designs. ;) > Sure, I will ASAP submit a "raw" mockup on which you can work on. What I would like is a dedicated page for the "Compose Push Message" feature. We wil have a criteria section to choose to who we want to send the message. I really like for instance how Jira do that like here http://postimg.org/image/5ur2j9wh5/ In our case we could have the drop downs for : "Variants", "Device Type", "Alias" and "Categories" And then below w will have a free text area to send a custom value. > > Hylke > > > > On 23/02/2014 12:08, Sebastien Blanc wrote: > > > > > On Sun, Feb 23, 2014 at 1:04 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > >> Hi, >> >> over the weekend I spoke w/ a friend: His company is doing some mobile >> (iOS/Android) apps which also support receiving push notifications. >> >> Two examples he told me. After receiving push notification: >> >> * One of their apps basically fetches the latest version of a CSV >> file, stored on a public HTTP Server. >> >> * Another app is used to tell sales guys new brochure files (PDF) are >> available on a protected resource of a webserver (which they _can_ than >> download from w/in the app, if the like to) >> >> The company build a simple console (PHP) which allows them to send new >> push messages, when ever their customers want to. >> >> I showed them our UnifiedPush Server and its usage via our AeroDoc >> example (iOS / backend). They really liked the UnifiedPush Server. >> Especially that it does store all the device metadata. >> >> But since a lot of their mobile apps don't have a backend requirement, >> they would still have to use their own console (which than connects to UPS) >> for submitting all the push messages they want. >> >> >> >> This brings me to [AGPUSH-38] and I really think we should implement >> that feature. Not only for sending test messages! If our UnifiedPush Server >> allows its users to simple send push messages to all of their mobile apps, >> it would make the server even more attractive. >> >> I regret a bit that I was against [AGPUSH-38] in the beginning, I >> guess that's due to my Java enterprise background, where you typically find >> complex setups, and server talk to servers :-( >> >> Anyways, now I really think that the UPS has to have such a 'send >> push' facility inside of the Admin UI :-) I believe that we could reach way >> more potential users with something like that >> > +9001 and I already started thinking about this for a while. I will try > to submit some mockups/POCs this week so we can discuss that and I have > quickly a first working version on master. > > >> Any thoughts? >> >> >> Greetings, >> Matthias >> >> >> [AGPUSH-38] https://issues.jboss.org/browse/AGPUSH-38 >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >

Hello Sebi Great idea! Would it be possible to have a dropdown box for all possible variants?

Corinne On 25 Feb 2014, at 10:06, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > Hi, > I started to work on a new "Compose Message" page. The idea is that you can add criterias to your message , as you can see here on this screenshot : > > I've also deployed a live version but *DICSLAIMER* this is just UI / Mockup work sending will not work for now : http://newpush-sblanc.rhcloud.com => Select an App and you will have a "Copomse Message" link on the next page. > > Feedback is welcome. > Sebi > > > On Mon, Feb 24, 2014 at 1:25 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > On Mon, Feb 24, 2014 at 12:52 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: > Sounds good. > Let me know if you need any help with the mockup designs. ;) > Sure, I will ASAP submit a "raw" mockup on which you can work on. > What I would like is a dedicated page for the "Compose Push Message" feature. > > We wil have a criteria section to choose to who we want to send the message. I really like for instance how Jira do that like here http://postimg.org/image/5ur2j9wh5/ > In our case we could have the drop downs for : "Variants", "Device Type", "Alias" and "Categories" > And then below w will have a free text area to send a custom value. > > > > Hylke > > > > On 23/02/2014 12:08, Sebastien Blanc wrote: >> >> >> >> On Sun, Feb 23, 2014 at 1:04 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> Hi, >> >> over the weekend I spoke w/ a friend: His company is doing some mobile (iOS/Android) apps which also support receiving push notifications. >> >> Two examples he told me. After receiving push notification: >> >> * One of their apps basically fetches the latest version of a CSV file, stored on a public HTTP Server. >> >> * Another app is used to tell sales guys new brochure files (PDF) are available on a protected resource of a webserver (which they _can_ than download from w/in the app, if the like to) >> >> The company build a simple console (PHP) which allows them to send new push messages, when ever their customers want to. >> >> I showed them our UnifiedPush Server and its usage via our AeroDoc example (iOS / backend). They really liked the UnifiedPush Server. Especially that it does store all the device metadata. >> >> But since a lot of their mobile apps don't have a backend requirement, they would still have to use their own console (which than connects to UPS) for submitting all the push messages they want. >> >> >> >> This brings me to [AGPUSH-38] and I really think we should implement that feature. Not only for sending test messages! If our UnifiedPush Server allows its users to simple send push messages to all of their mobile apps, it would make the server even more attractive. >> >> I regret a bit that I was against [AGPUSH-38] in the beginning, I guess that's due to my Java enterprise background, where you typically find complex setups, and server talk to servers :-( >> >> Anyways, now I really think that the UPS has to have such a 'send push' facility inside of the Admin UI :-) I believe that we could reach way more potential users with something like that >> +9001 and I already started thinking about this for a while. I will try to submit some mockups/POCs this week so we can discuss that and I have quickly a first working version on master. >> >> >> Any thoughts? >> >> >> Greetings, >> Matthias >> >> >> [AGPUSH-38] https://issues.jboss.org/browse/AGPUSH-38 >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Based on this current UI mock-up: I see most of the fields you added as "advanced" options.

By default, I, the newbie, have just added a variant, just deployed the app to my phone, just hit "yes" to receive notifications, just seen the device token in the web UI - so I just need to hit a single button to send a test message. For your multi-field (app, variant, device, alias, category, etc) UI, can that be "hidden" under Advanced Options? So that I, the newbie, only get a simple text area to edit the default "Hello Push World" message? On Feb 25, 2014, at 4:22 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: On Tue, Feb 25, 2014 at 10:19 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > Hello Sebi > > Great idea! > Would it be possible to have a dropdown box for all possible variants? > :) Sure, I had that in a previous version I worked on this morning, but for simplicity for now I just choosed the "Free text" option for all the criterias. Later we will make that nicer ++ > Corinne > On 25 Feb 2014, at 10:06, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > Hi, > > I started to work on a new "Compose Message" page. The idea is that you > can add criterias to your message , as you can see here on this screenshot : > > > > I've also deployed a live version but *DICSLAIMER* this is just UI / > Mockup work sending will not work for now : > http://newpush-sblanc.rhcloud.com => Select an App and you will have a > "Copomse Message" link on the next page. > > > > Feedback is welcome. > > Sebi > > > > > > On Mon, Feb 24, 2014 at 1:25 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; > wrote: > > > > > > > > On Mon, Feb 24, 2014 at 12:52 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: > > Sounds good. > > Let me know if you need any help with the mockup designs. ;) > > Sure, I will ASAP submit a "raw" mockup on which you can work on. > > What I would like is a dedicated page for the "Compose Push Message" > feature. > > > > We wil have a criteria section to choose to who we want to send the > message. I really like for instance how Jira do that like here > http://postimg.org/image/5ur2j9wh5/ > > In our case we could have the drop downs for : "Variants", "Device > Type", "Alias" and "Categories" > > And then below w will have a free text area to send a custom value. > > > > > > > > Hylke > > > > > > > > On 23/02/2014 12:08, Sebastien Blanc wrote: > >> > >> > >> > >> On Sun, Feb 23, 2014 at 1:04 PM, Matthias Wessendorf < > matzew(a)apache.org&gt; wrote: > >> Hi, > >> > >> over the weekend I spoke w/ a friend: His company is doing some mobile > (iOS/Android) apps which also support receiving push notifications. > >> > >> Two examples he told me. After receiving push notification: > >> > >> * One of their apps basically fetches the latest version of a CSV > file, stored on a public HTTP Server. > >> > >> * Another app is used to tell sales guys new brochure files (PDF) are > available on a protected resource of a webserver (which they _can_ than > download from w/in the app, if the like to) > >> > >> The company build a simple console (PHP) which allows them to send new > push messages, when ever their customers want to. > >> > >> I showed them our UnifiedPush Server and its usage via our AeroDoc > example (iOS / backend). They really liked the UnifiedPush Server. > Especially that it does store all the device metadata. > >> > >> But since a lot of their mobile apps don't have a backend requirement, > they would still have to use their own console (which than connects to UPS) > for submitting all the push messages they want. > >> > >> > >> > >> This brings me to [AGPUSH-38] and I really think we should implement > that feature. Not only for sending test messages! If our UnifiedPush Server > allows its users to simple send push messages to all of their mobile apps, > it would make the server even more attractive. > >> > >> I regret a bit that I was against [AGPUSH-38] in the beginning, I > guess that's due to my Java enterprise background, where you typically find > complex setups, and server talk to servers :-( > >> > >> Anyways, now I really think that the UPS has to have such a 'send > push' facility inside of the Admin UI :-) I believe that we could reach way > more potential users with something like that > >> +9001 and I already started thinking about this for a while. I will > try to submit some mockups/POCs this week so we can discuss that and I have > quickly a first working version on master. > >> > >> > >> Any thoughts? > >> > >> > >> Greetings, > >> Matthias > >> > >> > >> [AGPUSH-38] https://issues.jboss.org/browse/AGPUSH-38 > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> > >> aerogear-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

It's a good start. Before designing the actual form, maybe we should take a step back and think about why we'd want to send a message? I can think of some cases: 1. Testing whether your newly created app variant and push network combination work correctly. It's good to have the immediate confirmation right after you've created a new application variant and have configured a push network. We could have some kind of test dialogue, which can be skipped. 2. Debugging network issues and general testing. A fixed message could do the trick, but people may want to test all kinds of content to a variety of devices to see if there are any issues. 3. Code generation. Other than sending messages, Sebastien's form looks like a good way to generate code that the backend can use directly. It could be a sort of small visual design tool, to make using the UPS even easier.

There may be more? Thoughts? Hylke On 25/02/2014 09:06, Sebastien Blanc wrote: > Hi, > I started to work on a new "Compose Message" page. The idea is that you can add criterias to your message , as you can see here on this screenshot : > > I've also deployed a live version but *DICSLAIMER* this is just UI / Mockup work sending will not work for now : http://newpush-sblanc.rhcloud.com => Select an App and you will have a "Copomse Message" link on the next page. > > Feedback is welcome. > Sebi > > > On Mon, Feb 24, 2014 at 1:25 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > On Mon, Feb 24, 2014 at 12:52 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: > Sounds good. > Let me know if you need any help with the mockup designs. ;) > Sure, I will ASAP submit a "raw" mockup on which you can work on. > What I would like is a dedicated page for the "Compose Push Message" feature. > > We wil have a criteria section to choose to who we want to send the message. I really like for instance how Jira do that like here http://postimg.org/image/5ur2j9wh5/ > In our case we could have the drop downs for : "Variants", "Device Type", "Alias" and "Categories" > And then below w will have a free text area to send a custom value. > > > > Hylke > > > > On 23/02/2014 12:08, Sebastien Blanc wrote: >> >> >> >> On Sun, Feb 23, 2014 at 1:04 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> Hi, >> >> over the weekend I spoke w/ a friend: His company is doing some mobile (iOS/Android) apps which also support receiving push notifications. >> >> Two examples he told me. After receiving push notification: >> >> * One of their apps basically fetches the latest version of a CSV file, stored on a public HTTP Server. >> >> * Another app is used to tell sales guys new brochure files (PDF) are available on a protected resource of a webserver (which they _can_ than download from w/in the app, if the like to) >> >> The company build a simple console (PHP) which allows them to send new push messages, when ever their customers want to. >> >> I showed them our UnifiedPush Server and its usage via our AeroDoc example (iOS / backend). They really liked the UnifiedPush Server. Especially that it does store all the device metadata. >> >> But since a lot of their mobile apps don't have a backend requirement, they would still have to use their own console (which than connects to UPS) for submitting all the push messages they want. >> >> >> >> This brings me to [AGPUSH-38] and I really think we should implement that feature. Not only for sending test messages! If our UnifiedPush Server allows its users to simple send push messages to all of their mobile apps, it would make the server even more attractive. >> >> I regret a bit that I was against [AGPUSH-38] in the beginning, I guess that's due to my Java enterprise background, where you typically find complex setups, and server talk to servers :-( >> >> Anyways, now I really think that the UPS has to have such a 'send push' facility inside of the Admin UI :-) I believe that we could reach way more potential users with something like that >> +9001 and I already started thinking about this for a while. I will try to submit some mockups/POCs this week so we can discuss that and I have quickly a first working version on master. >> >> >> Any thoughts? >> >> >> Greetings, >> Matthias >> >> >> [AGPUSH-38] https://issues.jboss.org/browse/AGPUSH-38 >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Envoyé de mon iPhone Le Feb 25, 2014 à 14:36, Hylke Bons <hbons(a)redhat.com <mailto:hbons@redhat.com>> a écrit : > It's a good start. > Before designing the actual form, maybe we should take a step back > and think about why we'd want to send a message? > > I can think of some cases: > > 1. Testing whether your newly created app variant and push network > combination work correctly. It's good to have the immediate > confirmation right after you've created a new application variant and > have configured a push network. We could have some kind of test > dialogue, which can be skipped. We can think about this bit most of the time just after creating an app/variant you haven't any devices registered yet.

> 2. Debugging network issues and general testing. A fixed message > could do the trick, but people may want to test all kinds of content > to a variety of devices to see if there are any issues. > 3. Code generation. Other than sending messages, Sebastien's form > looks like a good way to generate code that the backend can use > directly. It could be a sort of small visual design tool, to make > using the UPS even easier. We have already some ideas around this ;) like generating the client code for the registration (iOS/android/js) and also generated curls for sending but that will be the next step.

> There may be more? > Thoughts? > > Hylke > > > > On 25/02/2014 09:06, Sebastien Blanc wrote: >> Hi, >> I started to work on a new "Compose Message" page. The idea is that >> you can add criterias to your message , as you can see here on this >> screenshot : >> compose2 >> I've also deployed a live version but *DICSLAIMER* this is just UI / >> Mockup work sending will not work for now : >> http://newpush-sblanc.rhcloud.com => Select an App and you will have >> a "Copomse Message" link on the next page. >> >> Feedback is welcome. >> Sebi >> >> >> On Mon, Feb 24, 2014 at 1:25 PM, Sebastien Blanc >> <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote: >> >> >> >> >> On Mon, Feb 24, 2014 at 12:52 PM, Hylke Bons <hbons(a)redhat.com >> <mailto:hbons@redhat.com>> wrote: >> >> Sounds good. >> Let me know if you need any help with the mockup designs. ;) >> >> Sure, I will ASAP submit a "raw" mockup on which you can work on. >> What I would like is a dedicated page for the "Compose Push >> Message" feature. >> >> We wil have a criteria section to choose to who we want to send >> the message. I really like for instance how Jira do that like >> here http://postimg.org/image/5ur2j9wh5/ >> In our case we could have the drop downs for : "Variants", >> "Device Type", "Alias" and "Categories" >> And then below w will have a free text area to send a custom value. >> >> >> >> Hylke >> >> >> >> On 23/02/2014 12:08, Sebastien Blanc wrote: >>> >>> >>> >>> On Sun, Feb 23, 2014 at 1:04 PM, Matthias Wessendorf >>> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: >>> >>> Hi, >>> >>> over the weekend I spoke w/ a friend: His company is >>> doing some mobile (iOS/Android) apps which also support >>> receiving push notifications. >>> >>> Two examples he told me. After receiving push notification: >>> >>> * One of their apps basically fetches the latest >>> version of a CSV file, stored on a public HTTP Server. >>> >>> * Another app is used to tell sales guys new brochure >>> files (PDF) are available on a protected resource of a >>> webserver (which they _can_ than download from w/in the >>> app, if the like to) >>> >>> The company build a simple console (PHP) which allows >>> them to send new push messages, when ever their >>> customers want to. >>> >>> I showed them our UnifiedPush Server and its usage via >>> our AeroDoc example (iOS / backend). They really liked >>> the UnifiedPush Server. Especially that it does store >>> all the device metadata. >>> >>> But since a lot of their mobile apps don't have a >>> backend requirement, they would still have to use their >>> own console (which than connects to UPS) for >>> submitting all the push messages they want. >>> >>> >>> >>> This brings me to [AGPUSH-38] and I really think we >>> should implement that feature. Not only for sending >>> test messages! If our UnifiedPush Server allows its >>> users to simple send push messages to all of their >>> mobile apps, it would make the server even more attractive. >>> >>> I regret a bit that I was against [AGPUSH-38] in the >>> beginning, I guess that's due to my Java enterprise >>> background, where you typically find complex setups, >>> and server talk to servers :-( >>> >>> Anyways, now I really think that the UPS has to have >>> such a 'send push' facility inside of the Admin UI :-) >>> I believe that we could reach way more potential users >>> with something like that >>> >>> +9001 and I already started thinking about this for a >>> while. I will try to submit some mockups/POCs this week so >>> we can discuss that and I have quickly a first working >>> version on master. >>> >>> >>> Any thoughts? >>> >>> >>> Greetings, >>> Matthias >>> >>> >>> [AGPUSH-38] https://issues.jboss.org/browse/AGPUSH-38 >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> <mailto:aerogear-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> <mailto:aerogear-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, Feb 25, 2014 at 3:06 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: > On 25/02/2014 13:58, Sébastien Blanc wrote: > > > > Envoyé de mon iPhone > > Le Feb 25, 2014 à 14:36, Hylke Bons <hbons(a)redhat.com&gt; a écrit : > > It's a good start. > Before designing the actual form, maybe we should take a step back and > think about why we'd want to send a message? > > I can think of some cases: > > 1. Testing whether your newly created app variant and push network > combination work correctly. It's good to have the immediate confirmation > right after you've created a new application variant and have configured a > push network. We could have some kind of test dialogue, which can be > skipped. > > We can think about this bit most of the time just after creating an > app/variant you haven't any devices registered yet. > > No, but we need some code there to quickly register one as well, and > keep the setup flow going. We can link to the compose for from there as > well, we can decide on the details later once we decide if this is > something we'd like to have. > Well, once you have a first device connected (which is most-likely the phone of the dude setting up the shindig), you can send a push. Note, we also talked about generating markup (for the each variant overview) so the guy can copy/paste the code into his app, and launch it on the device: https://issues.jboss.org/browse/AGPUSH-260 > > > > 2. Debugging network issues and general testing. A fixed message could > do the trick, but people may want to test all kinds of content to a variety > of devices to see if there are any issues. > > You can send a TEST to _your_ device (using the criteria (e.g. give it a funny unique alias/ID). That's already part of sebi's UI > 3. Code generation. Other than sending messages, Sebastien's form looks > like a good way to generate code that the backend can use directly. It > could be a sort of small visual design tool, to make using the UPS even > easier. > > Yes, we could generate the java-code for the backend. But really the goal is to also give apps an easy to actually deliver push (see original thread).

> We have already some ideas around this ;) like generating the client > code for the registration (iOS/android/js) and also generated curls for > sending but that will be the next step. > > Great! > > Hylke > > > > There may be more? > Thoughts? > > Hylke > > > > On 25/02/2014 09:06, Sebastien Blanc wrote: > > Hi, > I started to work on a new "Compose Message" page. The idea is that you > can add criterias to your message , as you can see here on this screenshot > : > [image: compose2] > I've also deployed a live version but *DICSLAIMER* this is just UI / > Mockup work sending will not work for now : > http://newpush-sblanc.rhcloud.com => Select an App and you will have a > "Copomse Message" link on the next page. > > Feedback is welcome. > Sebi > > > On Mon, Feb 24, 2014 at 1:25 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > >> >> >> >> On Mon, Feb 24, 2014 at 12:52 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: >> >>> Sounds good. >>> Let me know if you need any help with the mockup designs. ;) >>> >> Sure, I will ASAP submit a "raw" mockup on which you can work on. >> What I would like is a dedicated page for the "Compose Push Message" >> feature. >> >> We wil have a criteria section to choose to who we want to send the >> message. I really like for instance how Jira do that like here >> http://postimg.org/image/5ur2j9wh5/ >> In our case we could have the drop downs for : "Variants", "Device >> Type", "Alias" and "Categories" >> And then below w will have a free text area to send a custom value. >> >> >>> >>> Hylke >>> >>> >>> >>> On 23/02/2014 12:08, Sebastien Blanc wrote: >>> >>> >>> >>> >>> On Sun, Feb 23, 2014 at 1:04 PM, Matthias Wessendorf <matzew(a)apache.org >>> > wrote: >>> >>>> Hi, >>>> >>>> over the weekend I spoke w/ a friend: His company is doing some >>>> mobile (iOS/Android) apps which also support receiving push notifications. >>>> >>>> Two examples he told me. After receiving push notification: >>>> >>>> * One of their apps basically fetches the latest version of a CSV >>>> file, stored on a public HTTP Server. >>>> >>>> * Another app is used to tell sales guys new brochure files (PDF) >>>> are available on a protected resource of a webserver (which they _can_ than >>>> download from w/in the app, if the like to) >>>> >>>> The company build a simple console (PHP) which allows them to send >>>> new push messages, when ever their customers want to. >>>> >>>> I showed them our UnifiedPush Server and its usage via our AeroDoc >>>> example (iOS / backend). They really liked the UnifiedPush Server. >>>> Especially that it does store all the device metadata. >>>> >>>> But since a lot of their mobile apps don't have a backend >>>> requirement, they would still have to use their own console (which than >>>> connects to UPS) for submitting all the push messages they want. >>>> >>>> >>>> >>>> This brings me to [AGPUSH-38] and I really think we should implement >>>> that feature. Not only for sending test messages! If our UnifiedPush Server >>>> allows its users to simple send push messages to all of their mobile apps, >>>> it would make the server even more attractive. >>>> >>>> I regret a bit that I was against [AGPUSH-38] in the beginning, I >>>> guess that's due to my Java enterprise background, where you typically find >>>> complex setups, and server talk to servers :-( >>>> >>>> Anyways, now I really think that the UPS has to have such a 'send >>>> push' facility inside of the Admin UI :-) I believe that we could reach way >>>> more potential users with something like that >>>> >>> +9001 and I already started thinking about this for a while. I will try >>> to submit some mockups/POCs this week so we can discuss that and I have >>> quickly a first working version on master. >>> >>> >>>> Any thoughts? >>>> >>>> >>>> Greetings, >>>> Matthias >>>> >>>> >>>> [AGPUSH-38] https://issues.jboss.org/browse/AGPUSH-38 >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

Let's do it. I was asked that question at my talk the other night. Sent from my iPhone On Feb 23, 2014, at 7:06 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: Hi, over the weekend I spoke w/ a friend: His company is doing some mobile (iOS/Android) apps which also support receiving push notifications. Two examples he told me. After receiving push notification: * One of their apps basically fetches the latest version of a CSV file, stored on a public HTTP Server. * Another app is used to tell sales guys new brochure files (PDF) are available on a protected resource of a webserver (which they _can_ than download from w/in the app, if the like to) The company build a simple console (PHP) which allows them to send new push messages, when ever their customers want to. I showed them our UnifiedPush Server and its usage via our AeroDoc example (iOS / backend). They really liked the UnifiedPush Server. Especially that it does store all the device metadata. But since a lot of their mobile apps don't have a backend requirement, they would still have to use their own console (which than connects to UPS) for submitting all the push messages they want. This brings me to [AGPUSH-38] and I really think we should implement that feature. Not only for sending test messages! If our UnifiedPush Server allows its users to simple send push messages to all of their mobile apps, it would make the server even more attractive. I regret a bit that I was against [AGPUSH-38] in the beginning, I guess that's due to my Java enterprise background, where you typically find complex setups, and server talk to servers :-( Anyways, now I really think that the UPS has to have such a 'send push' facility inside of the Admin UI :-) I believe that we could reach way more potential users with something like that Any thoughts? Greetings, Matthias [AGPUSH-38] https://issues.jboss.org/browse/AGPUSH-38 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I think it would be a huge win for the getting started experience - the docs can say 1) the iOS device will prompt the end-user (will you accept push notifications) - say Yes 2) now look for the device token in the admin console - is it there? 3) now send it a quick test message, with the app in the foreground, background, app shutdown, phone on lockscreen, etc - to learn about the behaviors.

On Feb 23, 2014, at 2:15 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: So I sart playing with it> If you browse to http://newpush-sblanc.rhcloud.com/ with admin / 123 and select (or create) an application, in the "Send notifications ..." section you will see a link "test Message", that will open an overlay with a default send message that is valid. Change it (add criteria / custom values) or just hit the "Send test Message" and it will send a push notification to the registred devices. :) On Sun, Feb 23, 2014 at 1:52 PM, Luke Holmquist <lholmqui(a)redhat.com&gt;wrote: > Let's do it. I was asked that question at my talk the other night. > > Sent from my iPhone > > On Feb 23, 2014, at 7:06 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > Hi, > > over the weekend I spoke w/ a friend: His company is doing some mobile > (iOS/Android) apps which also support receiving push notifications. > > Two examples he told me. After receiving push notification: > > * One of their apps basically fetches the latest version of a CSV file, > stored on a public HTTP Server. > > * Another app is used to tell sales guys new brochure files (PDF) are > available on a protected resource of a webserver (which they _can_ than > download from w/in the app, if the like to) > > The company build a simple console (PHP) which allows them to send new > push messages, when ever their customers want to. > > I showed them our UnifiedPush Server and its usage via our AeroDoc > example (iOS / backend). They really liked the UnifiedPush Server. > Especially that it does store all the device metadata. > > But since a lot of their mobile apps don't have a backend requirement, > they would still have to use their own console (which than connects to UPS) > for submitting all the push messages they want. > > > > This brings me to [AGPUSH-38] and I really think we should implement that > feature. Not only for sending test messages! If our UnifiedPush Server > allows its users to simple send push messages to all of their mobile apps, > it would make the server even more attractive. > > I regret a bit that I was against [AGPUSH-38] in the beginning, I guess > that's due to my Java enterprise background, where you typically find > complex setups, and server talk to servers :-( > > Anyways, now I really think that the UPS has to have such a 'send push' > facility inside of the Admin UI :-) I believe that we could reach way more > potential users with something like that > > Any thoughts? > > > Greetings, > Matthias > > > [AGPUSH-38] https://issues.jboss.org/browse/AGPUSH-38 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mon, Feb 24, 2014 at 8:15 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > > > > On Mon, Feb 24, 2014 at 12:08 AM, Burr Sutter <bsutter(a)redhat.com&gt; wrote: > >> I think it would be a huge win for the getting started experience - the >> docs can say >> 1) the iOS device will prompt the end-user (will you accept push >> notifications) - say Yes >> 2) now look for the device token in the admin console - is it there? >> 3) now send it a quick test message, with the app in the foreground, >> background, app shutdown, phone on lockscreen, etc - to learn about the >> behaviors. >> > I like this flow but what you want here is to send only to a single > device, right ? For that we have to solve this ticket before > https://issues.jboss.org/browse/AGPUSH-420 > well - he means test to a new app. Which most likely contains just one device :-)

> >> >> On Feb 23, 2014, at 2:15 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >> wrote: >> >> So I sart playing with it> >> If you browse to http://newpush-sblanc.rhcloud.com/ with admin / 123 >> and select (or create) an application, in the "Send notifications ..." >> section you will see a link "test Message", that will open an overlay with >> a default send message that is valid. Change it (add criteria / custom >> values) or just hit the "Send test Message" and it will send a push >> notification to the registred devices. >> :) >> >> >> On Sun, Feb 23, 2014 at 1:52 PM, Luke Holmquist <lholmqui(a)redhat.com&gt;wrote: >> >>> Let's do it. I was asked that question at my talk the other night. >>> >>> Sent from my iPhone >>> >>> On Feb 23, 2014, at 7:06 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> Hi, >>> >>> over the weekend I spoke w/ a friend: His company is doing some mobile >>> (iOS/Android) apps which also support receiving push notifications. >>> >>> Two examples he told me. After receiving push notification: >>> >>> * One of their apps basically fetches the latest version of a CSV file, >>> stored on a public HTTP Server. >>> >>> * Another app is used to tell sales guys new brochure files (PDF) are >>> available on a protected resource of a webserver (which they _can_ than >>> download from w/in the app, if the like to) >>> >>> The company build a simple console (PHP) which allows them to send new >>> push messages, when ever their customers want to. >>> >>> I showed them our UnifiedPush Server and its usage via our AeroDoc >>> example (iOS / backend). They really liked the UnifiedPush Server. >>> Especially that it does store all the device metadata. >>> >>> But since a lot of their mobile apps don't have a backend requirement, >>> they would still have to use their own console (which than connects to UPS) >>> for submitting all the push messages they want. >>> >>> >>> >>> This brings me to [AGPUSH-38] and I really think we should implement >>> that feature. Not only for sending test messages! If our UnifiedPush Server >>> allows its users to simple send push messages to all of their mobile apps, >>> it would make the server even more attractive. >>> >>> I regret a bit that I was against [AGPUSH-38] in the beginning, I guess >>> that's due to my Java enterprise background, where you typically find >>> complex setups, and server talk to servers :-( >>> >>> Anyways, now I really think that the UPS has to have such a 'send push' >>> facility inside of the Admin UI :-) I believe that we could reach way more >>> potential users with something like that >>> >>> Any thoughts? >>> >>> >>> Greetings, >>> Matthias >>> >>> >>> [AGPUSH-38] https://issues.jboss.org/browse/AGPUSH-38 >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

> On Mon, Feb 24, 2014 at 8:33 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > >> On Mon, Feb 24, 2014 at 8:15 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> >> >> >>> On Mon, Feb 24, 2014 at 12:08 AM, Burr Sutter <bsutter(a)redhat.com&gt; wrote: >>> I think it would be a huge win for the getting started experience - the docs can say >>> 1) the iOS device will prompt the end-user (will you accept push notifications) - say Yes >>> 2) now look for the device token in the admin console - is it there? >>> 3) now send it a quick test message, with the app in the foreground, background, app shutdown, phone on lockscreen, etc - to learn about the behaviors. >> >> I like this flow but what you want here is to send only to a single device, right ? For that we have to solve this ticket before https://issues.jboss.org/browse/AGPUSH-420 > > well - he means test to a new app. Which most likely contains just one device :-) works great - just tested w/ my iPhone :-) No more curl - yay !!! :))) > > > > >>> >>> >>>> On Feb 23, 2014, at 2:15 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>> >>>> So I sart playing with it> >>>> If you browse to http://newpush-sblanc.rhcloud.com/ with admin / 123 and select (or create) an application, in the "Send notifications ..." section you will see a link "test Message", that will open an overlay with a default send message that is valid. Change it (add criteria / custom values) or just hit the "Send test Message" and it will send a push notification to the registred devices. >>>> :) >>>> >>>> >>>>> On Sun, Feb 23, 2014 at 1:52 PM, Luke Holmquist <lholmqui(a)redhat.com&gt; wrote: >>>>> Let's do it. I was asked that question at my talk the other night. >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Feb 23, 2014, at 7:06 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> over the weekend I spoke w/ a friend: His company is doing some mobile (iOS/Android) apps which also support receiving push notifications. >>>>>> >>>>>> Two examples he told me. After receiving push notification: >>>>>> >>>>>> * One of their apps basically fetches the latest version of a CSV file, stored on a public HTTP Server. >>>>>> >>>>>> * Another app is used to tell sales guys new brochure files (PDF) are available on a protected resource of a webserver (which they _can_ than download from w/in the app, if the like to) >>>>>> >>>>>> The company build a simple console (PHP) which allows them to send new push messages, when ever their customers want to. >>>>>> >>>>>> I showed them our UnifiedPush Server and its usage via our AeroDoc example (iOS / backend). They really liked the UnifiedPush Server. Especially that it does store all the device metadata. >>>>>> >>>>>> But since a lot of their mobile apps don't have a backend requirement, they would still have to use their own console (which than connects to UPS) for submitting all the push messages they want. >>>>>> >>>>>> >>>>>> >>>>>> This brings me to [AGPUSH-38] and I really think we should implement that feature. Not only for sending test messages! If our UnifiedPush Server allows its users to simple send push messages to all of their mobile apps, it would make the server even more attractive. >>>>>> >>>>>> I regret a bit that I was against [AGPUSH-38] in the beginning, I guess that's due to my Java enterprise background, where you typically find complex setups, and server talk to servers :-( >>>>>> >>>>>> Anyways, now I really think that the UPS has to have such a 'send push' facility inside of the Admin UI :-) I believe that we could reach way more potential users with something like that >>>>>> >>>>>> Any thoughts? >>>>>> >>>>>> >>>>>> Greetings, >>>>>> Matthias >>>>>> >>>>>> >>>>>> [AGPUSH-38] https://issues.jboss.org/browse/AGPUSH-38 >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> _______________________________________________ >>>>>> >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev