[AG Push] BASIC (and INITAL) use cases of the Unified Push Server
by Matthias Wessendorf
Hi,
after two weeks of prototyping and evaluating, I started the design phase
of the AG Unified Push Server.
I created a GIST [1] that defines the INITIAL (not final) first DRAFT of
the supported use cases. Yes, they are very minimal :), but once we have
something running, we can add more features. Please review and comment
here...
(COPY AND PAST FROM GIST):
AG Unified Push - Use Cases
Right now there are the following roles:
- *Developer*: Some one that setup up the backend for different mobile
applications, to enable push (e.g. iOS certs or Google API keys(more later)
- *User*: Install an AG-App on his phone
- *Admin* needed? yes, once we have a *management user interface*. NOT
part of the first iteration....
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#use-cases>Use Cases
Below are the BASIC use-cases, that the AG Unified Push needs to *initially*
support.
- Enroll AeroGear-Push-User (based on identified roles)
- Remove AeroGear-Push-User
- Developer can register mobile App (for different Push Networks, e.g.
Apple, Android)
- Developer can unregister mobile App (for different Push Networks, e.g.
Apple, Android)
- User registers his phone with the backend (Device Token + APP-ID are
send to the backend)
- User unregisters his phone with the backend (e.g. app got deinstalled,
user deleted etc)
- User receives Push Messages (handled by the native OS, once accepted
to receive messages)
- Send push messages, done by a *user* or a *developer*
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#enroll>Enroll
Register different user types (based on desired role) with the
AG-Unified-Push server. The *Developer* role always requires a
username/password. The *User* is not always required on the server. Some
mobile apps don't know the concept of a logged in user (e.g. Sport
Broadcast apps), but others do require a *User* before using the mobile app
(e.g. Twitter)
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#remove-registered-user>Remove
registered User
It should be possible to remove Users (app users). That can me their
account is erased or their device tokes are removed....
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#add-mobile-app>Add
mobile app
A registered *Developer* can register multiple Apps with the AeroGear Push
Server. Each app has a (generated) AeroGear-Application-Key, besides that,
the logical concept of a APP, on the server, requires access to the Push
Networks (Google or Apple). Therefore such a registered APP needs a
certificate and passphrase (iOS) or a Google API key (Android)
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#remove-mobile-app>Remove
mobile app
A registered *Developer* should be able to remove the apps from the server.
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#device-registration>Device
Registration
Once a *User* installs and launches the mobile app, the embedding OS
generates a *Device-Token* (or *Registration ID* on Android). The mobile
Application needs to send this Token/ID and the AeroGear-Application-Key to
the AeroGear Server, so that the server can register this phone/app with
the particular app, to be able to receive push messages.
*Note: On iOS the user as to agree to receive push messages*
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#remove-registered-device>Remove
registered Device
If an app gets uninstalled, the phone is no longer able to receive push
messages. Therefore inactive Device-Tokens/Registration-IDs should be
removed, on the server. However... there is no harm if invalid keys are
used, on the server, when trying to send push messages...
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#receives-push-messages>Receives
Push Messages
Every installed app, is able to receive Push Messages through the APIs,
offered by the platforms (iOS, Android). Initially there will be NO client
SDK.
*Note: On iOS the user as to agree to receive push messages*
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#send-push-messages>Send
push messages<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#broadcast>
Broadcast
The Unified Push server acts as a broker to deliver messages (via Native
Push) to several devices. Authorized Users (based on their roles) can send
push messages to a specific application. For instance a *Developer* that *
ONLY* owns "AeroGear-App1" is only able to broadcast messages to that
particular app. He is *NOT* able to send a message to "AeroGear-App2"...
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#filtered-messaging>Filtered
messaging
Sending message to a specific user.... We need a DSL to filter users
etc.... This will be done later...
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#in-app-messaging>In-APP
messaging
Later, there will be an option to have the app also submit push messages,
to broadcast to other users of the app (or to a specific user). This will
be done later...
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#api-access>API access
*Initial* focus is that the above functionality is *ONLY* accessable via
RESTful/HTTP APIs!
Later we will have a few more SDKs:
- Client APIs (for Android, iOS)
- Server APIs (send a push message out of your JavaEE app, without
submitting (manually) the HTTP calls)
Cheers!
Matthias
[1] https://gist.github.com/matzew/7475652fa3b0cbb11c1c
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years, 8 months
[Aeorgear Controller] Additional type support on endpoints methods
by Sebastien Blanc
Hi,
I'm currently working on scaffolding AG-controller stuff and for that I'm
relying on the REST endpoints generated by the forge REST plugin. A typical
method's signature of a generated endpoint looks like that :
*public Response findById(Long id)*
But an AG Controller route definition can't point to such a target method
since it only support Strings as parameters :
*
route().from("/customers/{id}").on(RequestMethod.GET).consumes(JSON).produces(JSON).to(CustomerEndpoint.class).findById(param("id"));
*
*
*
Of course, the quick workaround would be to change the signature of the
endpoint to :
*public Response findById(String id)*
*
*
But, in my particular case, after the scaffolding happens I can't really
tell the developers : "Well, now you have to change manually all the
signature of your endpoints and convert your Strings to Longs".
Another use case could be an application having existing endpoints used by
a Application A and we introduce Application B using AG controller. More
generally, I think it would be a nice addition to AG controller.
I've already proposed a pull request[1] that can't handle all the types
which have a constructor with a single String parameter : Long, Integer,
BigDecimal, etc ... And also added unit tests to be sure I doesn't break
Feedback is more than welcome !
Seb
[1] https://github.com/aerogear/aerogear-controller/pull/55
11 years, 8 months
Removing docs from JS lib and Gruntfile.js
by Kris Borchers
So I have spent too much time working on https://issues.jboss.org/browse/AEROGEAR-932 to no avail. I keep running into permission issues and weird errors. Couple that with the fact that I'm using a customized version of jsdoc, I don't see any reason we should be including docs building in our build, nor do I think they should be part of the repo.
The docs are duplicated on the site so if someone finds an issue, they can file an issue on the site, then we can fix in the source and regenerate. Since we're also removing the dist folder from the aerogear-js repo, this just seems like the right thing to do as well to clean up this repo completely.
Any thoughts or objections?
P.S. - The only other thing I need to do is get my modified version of jsdoc up somewhere (maybe my own repo for now) so that others can build the docs with the modifications I have made. Any thoughts on that would also be appreciated.
Thanks!
11 years, 9 months
Android Test Project
by Summers Pittman
Looks like we are pretty much in agreement on the Android test project.
Quick recap, we have been using Robolectric which allowed us to have the
Android libraries and tests bundled in the same project and run from the
JVM instead of from an emulated device. This approach has run out of
steam (Robolectric doesn't support some of the newer Android libraries
at the moment).
There are two ways to do this.
1) Two separate maven projects in different repos in github.
2) A single maven project with two sub projects. One for the library
and the other for tests. This is how Action Bar Sherlock does things.
wdyt?
11 years, 9 months
[Android] Android project structure for final
by Summers Pittman
I would like to turn the Android maven project into three separate projects.
aerogear-android: The core library with everything you need to get going
on modern (4.0+) Android devices
aerogear-android-support: Library shims for older (Android 2.3)
devices. This project will also require the android-support-library.
aerogear-android-tests: This will house all of the Aerogear tests for
Android. Currently we use Robolectric for testing, but it doesn't
accurately support some things (Android threading comes to mind) and
doesn't support others at all (Loaders). A solution is to use a project
which runs the tests on a emulator/device. This can also be the
integration test project which we want to make anyway.
wdyt?
Summers
11 years, 9 months
Re: [aerogear-dev] [AeroGear-Notifier] Client API
by gorkem.ercan
This may have been discussed earlier. What is the targeted benefit other than the unified client?
Do we see that a single app is using more than one of these backends? Or is there a target to provide a messaging channel through controller perhaps?
Just curious.
--
Gorkem
On Feb 21, 2013, at 7:38 PM, Matthias Wessendorf [via aerogear-dev] <ml-node+s1069024n1694h26(a)n5.nabble.com> wrote:
> Hello!
>
> Today, I had a brief chat with Kris about a potential AeroGear Notifier Client API...
>
> The basic idea is to wrap messaging APIs (e.g. Stomp.js, Vertx's eventbus or Socket.io/Engine.io) behind a common client 'interface'.
>
> Basically the AeroGear-Notifier should be able to connect to a messaging system in order to subscribe to a channel to reveice messages from that channel. The AG-Notifier is also able to publish messages to ANY channel. Of course,unsubscribe and disconnect are required too...
>
> Sure... the above is not (YET) really a SPEC, but it's start.... the JS API of the AG-Notifier (DRAFT 0.0.1) could looks like this:
>
> /**
> * Connects to a given URL. The callback is invoked after a connection has been established. In case of an error, an Error
> * object will be passed to the callback
> */
> AeroGear.Notifier.connect(String url, function callback);
>
> /**
> * Tears down the connection. The callback is invoked after a connection has been closed. In case of an error, an
> * Error object will be passed to the callback
> */
> AeroGear.Notifier.disconnect(function callback);
>
> /**
> * Subscribes to a channel. The callback function is invoked for every message, received on the given channel.
> */
> AeroGear.Notifier.subscribe(String channel, function callback);
>
> /**
> * Removes the subscription of the given channel.
> */
> AeroGear.Notifier.unsubscribe(String channel);
>
> /**
> * Publishes a message to a given channel
> */
> AeroGear.Notifier.publish(String channel, Object message);
> Perhaps a STATE-MASHINE would be nice as well:
>
> AeroGear.Notifier.CONNECTING = 0;
> AeroGear.Notifier.OPEN = 1;
> AeroGear.Notifier.CLOSING = 2;
> AeroGear.Notifier.CLOSED = 3;
> Implementation of the Adapters
> The different adapter implementations will be done separately: ag-notifier-vertx.js...
>
>
> Thoughts ?
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> If you reply to this email, your message will be added to the discussion below:
> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-AeroGear-Notifier-...
> To unsubscribe from aerogear-dev, click here.
> NAML
--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Re-aerogear-dev-AeroGear-Notifi...
Sent from the aerogear-dev mailing list archive at Nabble.com.
11 years, 9 months
Android CR1 Branch
by Summers Pittman
Good news everyone, I've pushed my branch into the main repository and
am welcoming comments.
The biggest change in this branch is fixing Pipes and Authentication to
work correctly inside of the Android lifecycle. Specifically, I added a
bunch of utility classes to use Loaders to manage the state of Pipes and
protect data and operations through Activities' lifecycles.
I made a gist to demo changes in usage here:
https://gist.github.com/secondsun/1b8f9f480d6f9f4453f6
In addition to this, I added several utility classes for callbacks. In
Java having Callbacks be anonymous inner classes is usually fine, but in
Android in Activities and Fragments this is a recipe for pain and
suffering (and memory leaks). So now it is strongly encouraged for
developers to extend the abstract helper classes and make them static
classes. The javadoc should reflect this, but I can make it clearer if
you guys think it is necessary.
One big omission is testing. Part of the problem is that Robolectric
doesn't support Loaders (yet). So our only option is to make a Android
test project and run the tests on the emulator. This isn't hard, just work.
For FINAL, I hope to have the test project (and possibly a support
project) as well as lots more documentation for how to use AG-Android
correctly.
So let's discuss on the PR:
https://github.com/aerogear/aerogear-android/pull/57
Happy weekend guys.
Summers
11 years, 9 months
