[Screencast] Aerogear + Forge + JBoss Tools = Hybrid app in 6 minutes
by Sebastien Blanc
Hey Folks,
I've made a screencast showing the nice stuff coming around Rapid
Application Development in the Aerogear world :
- CRUD Scaffolding
- Security Scaffolding
- Cordova support
- JBoss Tools support
This screencast is also a proof of the great complementary between the
different projects that are Aerogear, JBoss Tools and Forge.
This video is 6 minutes long and is a real time live coding session from
scratch (just one exception the android emulator loading time has been cut
:) ).
Enjoy
https://vimeo.com/65672198
Sebi
11 years
SPEC: AeroGear Unified Push Server
by Matthias Wessendorf
Hi,
I started a GIST to convert the different gists and readme's into a
server-side spec
(https://gist.github.com/matzew/b918eb45d3f17de09b8f)
* Regarding the "mobile variant instance":
We need to decide, what a SimplePush client may need on-top of the data,
described below (and in the gist). (since they have clientIDs + channels)
* Similar... we need to reflect the "" on a "selected" (and broadcast) send
as well.
* Sec: there is a different meeting, on the sec - content will be
integrated (or linked from this spec)
If this doc, looks good, I will submit it as a PR so that we get it on the
homepage
Next:
CLIENT SPEC is coming later today (or tomorrow)
Thoughts ?
Matthias
AeroGear Unified Push Server (Draft 0.0.3)
The *AeroGear Unified Push Server* is a server that allows sending native
push messages to different mobile operation systems. The initial version of
the server supports Apple's
APNs<http://developer.apple.com/library/mac/#documentation/NetworkingInternet/...>
, Google Cloud Messaging<http://developer.android.com/google/gcm/index.html>
and Mozilla's Simple Push <https://wiki.mozilla.org/WebAPI/SimplePush>.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#motivation--purpose>Motivation
/ Purpose
*Goal*: Any (JBoss/AeroGear powered) mobile application, that is backed by
JBoss technology (e.g. admin console, Errai, drools, etc.), is able to
easily work with mobile push messages. For a JBoss "backend application" it
should be as simple as possible, to send messages to its different mobile
clients.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#definitions>Definitions
Before we get into details, it's important that we have a good lexicon.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#push-application>Push
Application
A logical construct that represents an overall mobile application (e.g. Mobile
HR).
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#mobile-variant>Mobile
Variant
A mobile variant of the *Push Application*. There can be multiple variants
for a *Push Application* (e.g. HR Android,HR iPad, HR iPhone free, HR
iPhone premium or HR Mobile Web).
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#mobile-variant-instance>Mobile
Variant Instance
Represents an actual installation on a mobile device (e.g. *User1 connected
via MobileWeb* or *User2 runs HR iPhone premium on his phone*)
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#overview>Overview
The *AeroGear Unified Push Server* contains three different components:
- Registration: *Registry for Push Applications, Mobile Variants and Mobile
Variant Instances*
- Storage: *A database, storing the registered applications and instances
*
- Sender: *Receives messages and sends them to different Mobile Variant
Instances*
The graphic below gives a little overview: [image:
components]<https://a248.e.akamai.net/camo.github.com/11b903b1eea5c2ba492ee4ec759b205...>
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#functionality>
Functionality<https://gist.github.com/matzew/b918eb45d3f17de09b8f#registration>
Registration
Three different registration types are provided by the *AeroGear Unified
Push Server*.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#push-application-regi...>Push
Application Registration
Adds a logical construct, that represents an overall mobile application
(e.g. Mobile HR). The *Push Application* contains the following properties:
- Name
- Description
- A collection of Mobile Variants
The server offers an HTTP interfaces to apply a *Push Application*
registration:
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{"name" : "MyApp", "description" : "awesome app" }'
http://SERVER/applications
*The response returns an ID for the Push Application.*
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#mobile-variant-regist...>Mobile
Variant Registration
Adds a *mobile variant* for an *existing* *Push Application*. There can be
multiple variants for a *Push Application* (e.g. HR Android, HR iPad, HR
iPhone free, HR iPhone premium or HR Mobile Web).
The server supports the following variant types:
- iOS
- Android
- SimplePush
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#ios-variant>iOS Variant
An iOS variant represents a logical construct for one iOS application (e.g. HR
for iPhone *or* HR for iPad ). The iOS variant requires some APNs specific
values:
- APNs Push Certificate file
- Passphrase
The server offers an HTTP interfaces to register an *iOS varian*:
curl -i -H "Accept: application/json" -H "Content-type: multipart/form-data"
-F "certificate=(a)/Users/matzew/Desktop/MyCert.p12"
-F "passphrase=TopSecret"
-X POST http://SERVER/applications/{PUSH_ID}/iOS
*NOTE:* The above is a *multipart/form-data*, since it is required to
upload the "Apple Push certificate"!
*The response returns an ID for the iOS variant.*
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#android-variant>Android
Variant
An Android variant represents a logical construct for one Android
application (e.g. HR for Android). The Android variant requires some Google
specific values:
- Google API Key
The server offers an HTTP interfaces to register an *Android variant*:
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{"googleKey" : "IDDASDASDSA"}'
http://SERVER/applications/{PUSH_ID}/android
_The response returns an ID for the Android variant.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#simplepush-variant>SimplePush
Variant
An SimplePush variant represents a logical construct for one SimplePush
application (e.g. HR mobile Web). The SimplePush variant requires some *Simple
Push Network* specific values:
- URL of the PushNetwork server
The server offers an HTTP interfaces to register an *SimplePush variant*:
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{"pushNetworkURL" : "http://localhost:7777/endpoint/"}'
http://SERVER/applications/{PUSH_ID}/simplePush
*The response returns an ID for the SimplePush variant.*
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#mobile-variant-instan...>Mobile
Variant Instance Registration
Adds an *mobile variant instance* to an existing *mobile variant* (e.g.
User1 runs HR-iPad on his device). It is possible that one user can have
multiple devices. A *mobile variant instance* contains the following
properties:
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#required-data>Required
Data
- *deviceToken*
*The platform specific device token, that identifies the device with the
used push network, in order to deliver messages*
- *operatingSystem*
*It is required for the device to submit it's exact name of the underlying
OS.*
- *osVersion*
*It is required for the device to submit it's exact version of the
underlying OS.*
- *Mobile Variation ID*
*ID received when registering a Mobile Variant. This ID needs to be
submitted as a request header (ag-mobile-variant). NOTE: It is possible
that this ID goes away, in favor for a digital signature in a future release
*
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#optional-data>Optional
Data
- *deviceType*
*It is recommended to store the (exact) device type (e.g. phone vs tablet).*
- *alias*
*If the business application requires the conecpt of a user, the
registration must submit an unique identifier (like a username), to
identify the user. It is possible that one user has multiple devices.*
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#business-data>Business
Data
The above are technical information bits that are required to get a message
to the device. This the app wants to send notification based on a criteria,
the relevant data has to be stored in the business backend. This way the
backend app is very flexible on the criterias (e.g. max salary,
geolocation, number of children, etc). All this data is NOT directly
related to the technical functionality of sending data. The usage of the
AeroGear Pipe is *highly recommended* to store business data on the
business backend.
The server offers an HTTP interfaces to register an *mobile variant instance
*:
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-H "ag-push-app: {id}"
-H "ag-mobile-app: {id}"
-X POST
-d '{
"alias" : "user(a)company.com",
"deviceToken" : "someTokenString",
"deviceType" : "ANDROID",
"mobileOperatingSystem" : "android",
"osVersion" : "4.0.1"
}'
http://SERVER/registry/device
*NOTE*: Platform specific Client SDKs will be provided to submit the
require data to the *AeroGear Unified Push Server*.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#storage>Storage
A (configurable) database that stores all registered applications and
instances.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#sender>Sender
HTTP interface that receives messages for a delivery to different Mobile
Push Networks. A few different *Sender Types* are supported by the push
server.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#global-broadcast-sender>Global
Broadcast Sender
Sends a push message to all *mobile variants* (and all of its *mobile
variant intances*), of a given *Push Application*:
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{"key":"blah", "alert":"HELLO!"}'
http://SERVER/sender/broadcast/{PushApplicationID}
Sends a JSON map to the server. If platform specific key words (e.g. alert
for APNs) are used, they are honored for the specific platform. This
transformation is done by the *AeroGear Unified Push Server*.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#variant-specific-broa...>Variant
specific Broadcast
Sends a push message to only one *mobile variants* (and all of its *mobile
variant intances*).:
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{"key":"blah", "alert":"HELLO!"}'
http://SERVER/sender/broadcast/variant/{MobileVariantID}
Sends a JSON map to the server. If platform specific key words (e.g. alert
for APNs) are used, they are honored for the specific platform. This
transformation is done by the *AeroGear Unified Push Server*.
<https://gist.github.com/matzew/b918eb45d3f17de09b8f#selected-sender>Selected
Sender
Sends a push message to a selected list of identified users (regardless of
their variant):
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{
alias: ["user(a)foo.com", "bar(a)moz.org", ....],
message: {"key":"blah", "alert":"HELLO!"}
}'
http://SERVER/sender/selected
The alias value is used to identied the desired users. The payload (messages)
is a standard JSON map. If platform specific key words (e.g. alert for
APNs) are used, they are honored for the specific platform. This
transformation is done by the *AeroGear Unified Push Server*.
11 years
iOS Push Client: REGISTRATION
by Matthias Wessendorf
Hi,
the client side spec describes the required functionality to register
devices with the Unified Push Server.
The client SKD should be simple to use. For the iOS, I thought about a
register that takes three blocks:
- ClientDeviceInformation object/protocol (similar to our configuration
objects)
- success callback
- failure callback
// AppDelegate code/delegate function, for a push enabled
application:- (void)application:(UIApplication *)application
// deviceToken provided by APNs
didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
// the AG AGDeviceRegistration helper/class:
[registration registerWithClientInfo:^(id<AGClientDeviceInformation>
clientInfo) {
// apply the desired info:
clientInfo.token = deviceToken;
clientInfo.alias = @"mister(a)xyz.com";
clientInfo.mobileVariantID = @"123456432134564321345432";
// ... as needed more of the data;
} success:^(id responseObject) {
// invoked, on 200 HTTP response code from the Unified Push Server
} failure:^(NSError *error) {
// invoked:
// missing required data (e.g. no token submitted)
// on 4xx/5zz HTTP response codes from the Unified Push Server}];}
The above registerWithClientInfo:successfailure method uses AFNetworking to
submit the receiveddeviceToken to the *AeroGear Unified Push Server*. The
desired information data is provided on the first callback.
The concept of a "block" for setting up data/objects has been useful on
AGPipeConfig, so reusing the concept here as well.
*Note:* Class/method names may change over time...
Thoughts ?
-Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years
Client Spec - Unified Push
by Matthias Wessendorf
Hello!
I have created an EARLY version of a client spec for push. As discussed
earlier focus is offering convenience methods for the registration process.
(and unregister on some platforms).
The SEND (from client --> Unified Push Server --> other clients) is out of
scope. The Unified Push is more nofification/signaling, and not chat :)
URL: https://gist.github.com/matzew/4fcf677eb217737265a8
AeroGear Unified Push Client Spec / SDK (DRAFT 0.0.1)
This document describes the functionality of a client SDK that works with
the AeroGear Unified Push
Server<https://gist.github.com/matzew/b918eb45d3f17de09b8f>
.
<https://gist.github.com/matzew/4fcf677eb217737265a8#motivation--purpose>Motivation
/ Purpose
The AeroGear Unified Push
Server<https://gist.github.com/matzew/b918eb45d3f17de09b8f> offers
a rich set of functionality, accessible via HTTP. Instead of having to
manually/directly work with the HTTP interface a convenience client library
should be offered.
*Goal:* A client library that is easy to use for device (Mobile Variant
Instance) registration and (later) sending *Push Notification Messages*.
<https://gist.github.com/matzew/4fcf677eb217737265a8#background-push-netwo...>Background:
Push Network Token
In order to be able to receive native push messages from a Push Network
(e.g. APNs, GCM or SimplePush), the mobile application developer needs to
receive a device token (or registration ID), from a device, that is running
*his* application. The way how the different platforms do this is
*very* different
and *not* part of this document.
*TL;DR:* The token is negotiated between the device and the actual Push
Network (GCM/APNs/SimplePush) and afterwards passed to a *platform specific
callback*, where the application of the AeroGear developer has access to
it. The developer can now upload it to the *AeroGear Unified Push Server*,
to indicate there is a newMobile Variant Instance for a Push Application
Variant.
Basically, the token identifies the device, running our mobile application,
with a Push Network. Hence the token is required when the *AeroGear Unified
Push Server* is willing to submit *Push Notification Messages* against the *
supported*Push Networks: For sending out *Push Notification Messages*, the
different Push Networks (e.g. GCM, APNs or SimplePush) need to receive a
small message payload, combined with a list of tokens, to indicate those
devices that should receive the message.
When a server-side application wants to send a *Push Notification Message* it
needs to submit a small message payload, combined with a list of tokens, to
indicate those devices that should receive the message.
More details about the server-side part of this can be found in the *AeroGear
Unified Push Server* spec<https://gist.github.com/matzew/b918eb45d3f17de09b8f>
.
<https://gist.github.com/matzew/4fcf677eb217737265a8#functionality>
Functionality
*WARNING:* *The focus of this specification is to describe the abstract
minimum, not any specific requirements for one of the supported client
platforms*
The client SDK convenience methods to simplify the following tasks
- Initial Registration of a Mobile Variant Instance
- Updating a registered Mobile Variant Instance
- update the token (could be changed, by the *Push Network*)
- store/update other data (e.g. alias, OS version)
- Unregistration of a Mobile Variant Instance
<https://gist.github.com/matzew/4fcf677eb217737265a8#registration-of-clien...>Registration
of client device information
Method that helps to initially register the client device information with
the AeroGear Unified Push
Server<https://gist.github.com/matzew/b918eb45d3f17de09b8f>.
Required Data is defined in the server side spec.
The method should check if a network connection is available, if not an
'error callback' should be invoked, to immediately contact the calling code.
<https://gist.github.com/matzew/4fcf677eb217737265a8#update-of-client-devi...>Update
of client device information
Method that helps to update the client device information. One reason could
be a changed device token or a newalias of the application user.
*Note*: It's recommended by most Push Network, to ALWAYs update the
information, since a token (that identifies the device with the push
network may change). Also, all platforms invoke the hook (see above) where
the device tokenfrom the Push Network, is passed to a *platform specific
callback*, *always* on application launch.
The method should check if a network connection is available, if not an
'error callback' should be invoked, to immediately contact the calling code.
<https://gist.github.com/matzew/4fcf677eb217737265a8#unregistration-of-cli...>Unregistration
of client device information
Optional method that helps to unregister the client device information with
the AeroGear Unified Push
Server<https://gist.github.com/matzew/b918eb45d3f17de09b8f>
. *Note:* *The method is optional, since not all supported Push Networks
recommend having a client application performing an _unregister*. Apple for
instance has a Feedback Service, which the *AeroGear Unified Push Server* needs
to freequently query for inactive tokens. Tokens, with Apple, are
*inactive* when
the user:
- Disables Push (Settings)
- Deinstalls the app
On platforms a *unregistration* may be valid, hence this method is option.
The method should check if a network connection is available, if not an
'error callback' should be invoked, to immediately contact the calling code.
<https://gist.github.com/matzew/4fcf677eb217737265a8#sending>Sending
At some point, a client may trigger a push notification, however not now:
Focus is to notify clients. It's not the goal to provide a "chat client".
<https://gist.github.com/matzew/4fcf677eb217737265a8#authsecurity>
Auth/Security
To be discussed.....
<https://gist.github.com/matzew/4fcf677eb217737265a8#platform-specific-det...>Platform
specific details
Every client platform has it's own base APIs, to receive Push Message from
it's Push Network. The AeroGear client SDK may offer utilities to even more
simplify this. Example: In Android a custom Intent is required, therefore
it may make sense if the AeroGear Android Push Client Library offers a
convenience implementation for this class.
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years
Sub-project split into JIRA
by Douglas Campos
Howdy!
We've got approval to split the project on several sub-projects on JIRA.
What do this mean? Immediatelly, means that we can have more freedom to
plan and release the individual bits, and start departing from the
uber umbrella releases on AeroGear.
The idea is to gradually roll this out, and I personally think that
Android and the Push server are very good candidates for being the
first. That said, we need to choose the JIRA names too (would love to
have AGDROID for Android (duh) and AGPUSHEE for the Push Server).
Thoughts? Suggestions?
--
qmx
11 years
AeroGear.js Roadmap
by Kris Borchers
Hey everyone!
Here is the JS roadmap. https://gist.github.com/kborchers/ff2ade823d9eceb687d1 Comments welcome. I have also pasted the contents below for easier discussion. Once we have dates based on our overall roadmap, I'll move this to aerogear.org.
Thanks!
# AeroGear.js Roadmap
## 1.0.x Release(s)
* **Bug Fixes and Minor Feature Additions**
* Possibly wrapped into a 1.x release
* **Dates**
* TBD
## 1.x Release(s)
* **Pipeline**
* OData Adapter - [http://www.odata.org/](http://www.odata.org/)
* Investigate continued support / viability (Netflix dropping?)
* **DataManager**
* IndexedDB/WebSQL Adapter
* Feature detection to determine which is available
* IE9 supports neither so need to also be able to fall back to localStorage but use same API
* Probably should investigate PouchDB's implementation
* **Auth**
* OTP
* Adapter or standalone
* OAuth2 Adapter
* Customizable Provider
* **Dates**
* TBD
## 2.0.0 Release
* **Push / Notifier**
* SimplePush
* Base on Mozilla's SimplePush Protocol Specification
* WebSocket/SockJS via Notifier
* Notifier
* Used for background communication in applications
* Adapters
* WebSocket
* SockJS or some other fallback strategy
* More? (STOMP and other protocols to "unify" APIs)
* **Data Sync**
* Utility for keeping data in DataManager synchronized with a persistent server side store
* Possibly use Notifier for communication / data transfer
* **Offline**
* Support for using apps offline and detecting status
* Simplified App Cache API
* Scaffolding for proper App Cache setup
* Use DataSync when returning to online status
* **Dates**
* TBD
## 2.x Release(s)
* **Social**
* Auth
* Login via Facebook, G+, Twitter?
* AeroGear.Auth adapter or separate?
* Common API
* Posting, Profile Info, Friend List, etc.
* **Dates**
* TBD
11 years
OTP.js
by Bruno Oliveira
Morning slackers, I had a meeting with Kris, Luke and Passos about the painless way to provide an OTP implementation for JavaScript.
https://gist.github.com/abstractj/d618faceee388a9d403a
Basically the scenarios 1 and 4 were chosen to be implemented. Scenarios 2 & 3 would provide bad user experience.
I'll start to file some Jiras to myself, if you have any addition, let me know.
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
11 years
