parent pom?
by Douglas Campos
While reviewing summers' PR I've found myself doing that tedious work of
fixing license headers again - what do y'all think part of our default
tools (like maven-license-plugin) on an aerogear parent pom (which
inherits from jboss parent pom, of course)
Thoughts?
--
qmx
12 years, 11 months
JIRA Components for AGDROID
by Summers Pittman
Pulling this over from IRC.
Right now the only components I can think of which are being actively
worked on or actively planned for the near future are pipes, auth, push,
sync, and offline. Does anyone else have any that they would like to
see added to the AGDROID Jira project?
Summers
13 years
iOS Basic/Digest Thoughts
by Christos Vasilakis
Hi,
iOS platform provides built-in implementations for authenticating against HTTP endpoints that support Basic / Digest authentication (among others). The workflow when iOS tries to authenticate against those endpoints is basically:
a) A credential storage singleton object provided by the system is consulted for authentication credentials. If credentials are found, the system proceeds with authentication. Understandably for this to work, the developer has to initially push the credentials to the system object (and remove when done).
b) If credentials are NOT found, the system tries to call the delegate method e.g. 'connection:didReceiveAuthenticationChallenge', giving a chance for the user to provide the credentials, by calling the appropriate methods on the authentication challenge object passed in.
AeroGear library, currently has a notion of pluggable authentication modules providing an interface for clients to implement 'login', and 'logout' methods, depending on the authentication scenarios that they try to support. This fits nicely with singleton credential storage approach, in the sense when doing 'login' and 'logout', we simply edit the credential storage adding or removing credentials appropriately. A branch for this work can be found here. For usage, have a look at our integration test
For testing purposes, another branch was created, this time letting the user to directly pass an NSURLCredential object initialised with the username/password combination during the Pipe configuration. Those credentials are internally stored and given back to the system by implementing the necessary callback . A usage example can be found in our integration test
advantages of using the singleton approach:
- fits nicely with the authentication mechanism we have in place (as an extension HTTPBasicDigestAuthenticationModule) so user familiarity when looking to add basic/digest support to the Pipe.
- we control the credential type e.g. 'NSURLCredentialPersistenceForSession'. This eliminates errors of using 'NSURLCredentialPersistencePermanent' and having the user to explicitly clear the keychain when trying to login with a different combination. For my search, many errors occurs because of this.
disadvantages of using the singleton approach:
- not sure if many iOS dev will like the fact of creating an Authenticator object instead of using directly an NSURLCredential object that are used to.
---
advantages of using the 'nsurlcredential' directly:
- users familiarity with the object.
- not explicit login logout request.
disadvantages of using the 'nsurlcredential' directly:
- error credential type can lead to errors.
With discussions with Matthias, we are more keen in following the HTTPBasicDigestAuthenticationModule approach instead of providing the NSURLCredential configuration option on the Pipe. Surely enough, in the documentation we will explicitly state that "login"/ "logout" methods, serve as a mean to setup internally the iOS authentication system so users don't have too (instead of calling remote endpoints)
Wdyt?
Thanks,
Christos
13 years
AeroGear Push Message Format
by Matthias Wessendorf
This document is devided in two sections:
- Native Push (Android and iOS)
- SimplePush (web-based Push)
<https://gist.github.com/matzew/98762c8d3f516e1abd38#native-push>Native Push
The Unified Push Server allows two different ways to send message to the
native Push API, of the supported devices:
- broadcast
- to all MobileVariants and their MobileVariant Instances (devices)
- to one specific MobileVariant and its MobileVariant Instances
(devices)
- seletive Send
<https://gist.github.com/matzew/98762c8d3f516e1abd38#broadcast>Broadcast
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-H "ag-push-application: {PushApplicationID}
-H "ag-mobile-variant: {MobileVariantID}
-X POST
-d '{"key":"value", "key2":"other value", "alert":"HELLO!",
"sound":"default", "badge":7}'
http://localhost:8080/ag-push/rest/sender/broadcast
If the ag-push-application header is used, a message is send to a
PushApplication and *ALL*MobileVariantIncances will receive the message.
If the ag-mobile-variant header is used, a message is send to a particular
MobileVariant and *ALL* of its MobileVariantIncances will receive the
message.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format>Message
Format
The message format is very simple: A generic JSON map is used to send
messages to Android and iOS devices. The applications on the devices will
receive the JSON map and are responsible for performing a lookup to read
values of the given keys.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#ios-special-keys>iOS
special keys
If the JSON map contains on of the following reserved keywords, Apple
specific hooks will be invoked on the device:
- alert (triggers a dialog, displaying the value - no iOS API needs to
be invoked by the app developer)
- sound (plays a given sound - no iOS API needs to be invoked by the app
developer)
- badge (sets the value of the badge icon - no iOS API needs to be
invoked by the app developer)
<https://gist.github.com/matzew/98762c8d3f516e1abd38#android-special-keys>Android
special keys
None! The JSON map is submitted as it is, directly to the device. There are
no Android specific keywords.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#selective-send>Selective
Send
A message is send to a restricted number of MobileVariantIncances, based on
a given criteria. The following example shows the correspondent HTTP
interface:
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{
"alias" : ["user(a)account.com", "jay(a)redhat.org", ....],
"deviceType" : ["iPad", "AndroidTablet"],
"message": {"key":"value", "key2":"other value", "alert":"HELLO!"}
}'
http://localhost:8080/ag-push/rest/sender/selected/{PushApplicationID}
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format-1>Message
Format
Besides the actual payload the the API accepts a few *classifiers* to
select a subset of registered devices.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#query-component>Query
component
Currently the Server will support the following query criterias:
- alias: A list of email address (or usernames) to send messages to
*ALL* devices
of the users. Thealias needs to be stored, when the device is
registering itself with the server. See here for
details<https://github.com/matzew/ag-client-push-sdk/blob/master/push-sdk/AGClien...>
- deviceType: A list of raw devices types that should receive the
message (e.g. Coupon only for iPad and AndroidTablets). The deviceType needs
to be stored, when the device is registering itself with the server. See
here for details<https://github.com/matzew/ag-client-push-sdk/blob/master/push-sdk/AGClien...>
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-payload>Message
Payload
The message format is very simple: A generic JSON map is used to send
messages to Android and iOS devices. The applications on the devices will
receive the JSON map and are responsible for performing a lookup to read
values of the given keys. Like above, iOS specific keywords are honored.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#simplepush>SimplePush
The Unified Push Server allows two different ways to send message to
SimplePush-enabled devices:
- broadcast
- seletive Send
<https://gist.github.com/matzew/98762c8d3f516e1abd38#broadcast-1>Broadcast
Sends a message to all connected devices of a SimplePush variant. The
message (aka version) will be received on the *broadcast* channel (AeroGear
specific broadcast channel, not part of the official spec).
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{"version":1234}'
http://localhost:8080/ag-push/rest/sender/simplePush/broadcast/{SimplePus...
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format-2>Message
Format
The message format is very simple: The version number is send to the
server, as a JSON object.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#selective-send-1>Selective
Send
A message is send to a selected number of channels, connected against a
specific SimplePush variant
curl -v -H "Accept: application/json" -H "Content-type: application/json"
-X POST
-d '{
"channelIDs":["someID", "moreID...."],
"version":1909
}'http://localhost:8080/ag-push/rest/sender/simplePush/selected/{SimplePush...
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format-3>Message
Format
The message format is very simple: A JSON object, containing the actual
payload (version) and an array, containing all the different channels.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#discussion>Discussion
SimplePush and NativePush do have different APIs / endpoints. However,
that's mainly because the SimplePush is really.... simple.... and not 100%
compliant with the richer APIs for Android/iOS.
We *could* (later?) try to unify the API and simply *IGNORE* everything
besides the version, when talking toSimplePush Variant.
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
13 years
Android Studio Support
by Summers Pittman
The new Android build tools (IE Android Studio) are still in beta, but
passos and I were thinking of adding support for them for the 1.2
release. I havn't given these tools more than a cursory look, but we
will have to support them sooner or later.
What do you guys think?
13 years
What is our default JDK platform?
by Karel Piwko
Hi,
Most of the code is JDK6, except PushEE which requires JDK 6. Android requires
JDK 6 API as well, thanks Summers for pointing that out. The only component
that requires JDK7 is PushEE afaict.
So, even if JDK 6 is officially EOLed (at least Oracle's one), I'd prefer to
limit our code to JDK6 features. Does it make sense?
I can setup animal sniffer plugin to enforce JDK API conformance and
send PRs if you will - btw, do you guys already have a common parent with plugin
configuration?
The other question is default runtime. Would you guys recommend JDK7 or JDK6?
I'm biased here to decide myself.
Thanks,
Karel
13 years
