On Mon, 31 Mar 2014 16:41:09 +0200
Matthias Wessendorf <matzew(a)apache.org> wrote:
On Mon, Mar 31, 2014 at 4:39 PM, Karel Piwko
<kpiwko(a)redhat.com> wrote:
> On Mon, 31 Mar 2014 15:25:41 +0200
> Matthias Wessendorf <matzew(a)apache.org> wrote:
>
> > Hello there,
> >
> > we recently had talks about creating some simplified quickstarts and
> > hello-word demos, related to the UnifiedPush Server and JBoss AS
> developers:
> >
> > * Hello World (No Server Code - just client receiving push, no fancy
> > (complex) UI on the client, nor integrated into a Cookbook or something
> > that has "dependencies")
> > ** Cordova
> > ** Android
> >
> > For iOS that is already there:
> >
https://github.com/aerogear/aerogear-push-ios-demo
> >
> > Yes, just usage of the "Push Registration SDKs", is the goal here:
keep
> it
> > simple, since native push can be a complicated use-case all on its own
> and
> > so it will be good to make sure we cover the basics here.
> >
> >
> > Beyond the Hello-World, we wanted some different quickstarts. The
> "server"
> > components that come to mind would be:
> >
> > *Secured CRUD + Push Integration (Java Sender)
> > ** JAX-RS + PicketLink
> > ** SpringMVC/Spring Security
> > ** JAX-RS + Apache Camel
> >
> > These need to function on both JBoss AS 7.X and EAP.
> >
> > Josh, from the JDF team, has already said he wants to help on the server
> > projects (especially the JAX-RS/PL and Spring ones). yay!
> > Note: Josh already has a simple backend started that is used in JDF
> > quickstarts that would be good to re-use to make it easier for developers
> > to transition from one to other.
> >
> >
> > The goal would be the SERVER acts same to outside (identical REST
> > endpoints, difference is only an impl. detail (e.g. JavaEE vs. Spring vs.
> > Camel))
> >
> > For these different servers, there would be mobile apps needed:
> > * Android
> > * Cordova
> > * iOS
>
> I'm not sure if I got that. You mean extra 3 apps per each supported
> backed?
> Making it 9 additional apps to test and maintain?
>
No: total of 3 server apps and 3 client apps
That's a weight off my shoulders :-)
What do you guys feel of these quickstarts having additional registration
button? E.g. it should be possible to provide UPS username/pass/variant name,
and get variantId/secret dynamically via REST, so not hardcoded in app. You
could then use one app to (re)connect to different UPS instances without
redeploy. Once registered via button, variantId/secret could go into offline
storage.
Something similar to
https://github.com/TadeasKriz/aerogear-push-test-android/blob/master/src/...
I'm not sure if it's good for a quickstart but it should be valuable for a demo.
> Should not the client be the same no matter have backend is set up?
>
> >
> >
> > The idea would be to keep them simple and straightforward as well, e.g.
> for
> > iOS that means plain usage of NSURLConnection / NSURLSession. But for the
> > "push registration" of the client,
> > the iOS-push SDK would be used (same/similar would apply to Cordova or
> > Android). Similar to the above 'Hello World', the quickstarts are
going
> to
> > be focused only on Push functionality, so for these we would leave out
> > pipes and such until later versions.
> >
> >
> > I will be creating Epics and subtasks in JIRA for this.
> >
> > For the location of all these projects, I had this "uber repo"
location
> in
> > mind:
> > *
https://github.com/aerogear/aerogear-push-helloworld
> > *
https://github.com/aerogear/aerogear-push-quickstarts
> >
> > Greetings,
> > Matthias
> >
> >
> >
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>