[Push] Notification Actions (iOS8)
by Matthias Wessendorf
Hi,
as Corinne mentioned on a different thread, w/ iOS8 Apple introduces new
UIUserNotificationActions, that can be grouped into a category
(UIUserNotificationCategory).
For remote notifications (aka push) those actions can be trigger by sending
this JSON payload to APNs:
aps {
alert: {...},
category: "SOMETHING"
}
I'd like to add that feature to the UnifiedPush Server and the Java/Node
Senders.
Our own message format (see [2]) has already a categoies element, but that
is used for filtering/tagging; That element is NOT related to the actual
payload of the message (which the apple action/category is all about).
Now, I'd like to introduce an "action-category" element inside of the
"message" object, like:
message: {
.......
"alert":"HELLO!",
.......
"action-category":"SOMETHING"
}
This value will be send down to the actual device (by Apple) as part of the
message. The name is perhaps a bit Apple-oriented, but I think it may fit
other platforms as well...
Looks like Summers/Passos want to do similar for Android (see [3]).
What do you think ?
-Matthias
[1] What's New in iOS Notifications on:
https://developer.apple.com/videos/wwdc/2014/ (caution, for lame reasons
only works on Safari O_o)
[2] http://aerogear.org/docs/specs/aerogear-push-messages/
[3] https://issues.jboss.org/browse/AGDROID-258
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years
cordova plugin release
by Erik Jan de Wit
Hi,
As discussed here (http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-New-Cordova-Push-r...) we are going to release a new version of the cordova push plugin the new version 0.5.1 most important feature is the updated android libraries. There are also some community bug fixes:
fix a bug with the foreground/isInline flag
fix bug with android not sending cached message
Automate plugin testing using grunt-cordova-plugin-jasmine.
Thank you TadeasKriz and keithdmoore for contributing
12 years
Sync - Server items (JAX-RS and JPA)
by Matthias Wessendorf
Hi,
last week at our Face2Face we had a discussion about sync, moving forward
on the client (will be a different thread) and on the server.
For the server-side we had a few different approaches:
1) AeroGear Sync-Server: Dan and Luke worked on the sync-server ([1]) as a
'long term' solution
The project contains two server implementations:
- RestServer implementation that uses a simple approach of rejecting
conflicts and delegating the responsibility to resolve conflicts to the
client.
- DiffServer Based on Google's Differential Synchonrization by Neil Fraser.
This server is WebSocket based.
2) Initial quick and simple solution based on JAX-RS and JPA:
- We have versioning in JPA (optimistic locking) - Use it (send 409 on
server and send right data)
-- Use JAX-RS ExceptionMapper for exceptions around the optimistic locking ?
- Client library will have helper methods for managing data
- Use push to send notifications that data changed?
- JAX-RS Annotation to send notifications?
I'd like to follow up on that, to see where things stand
Greetings,
Matthias
[1]
https://github.com/danbev/aerogear-sync-server/tree/differential-synchron...
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years
iOS 6 and Cordova push-sdk
by Christos Vasilakis
Hi all,
in order to support users that are currently want to use our Cordova push-sdk, in versions less than iOS 7 we have been discussing two options:
a) either modify the native push-sdk that currently uses iOS 7 API for its foundation networking(as of 0.9.0), to use older API that is supported both in iOS 6 and iOS 7 (but not recommended from Apple in favor of the new networking API).
b) create a branch in Cordova push-sdk plugin (e.g. ‘branch_iOS 6')that uses an older version of the native push-sdk (0.8.1) which was the last version of the native plugin that used the old networking API supporting both iOS 6 and 7.
After discussing with Eric And Matthias [1], from cordova push-plugin perspective the native API that Cordova uses hasn’t changed and option b) can be used for users that want to still support iOS 6.
Note: This branch will be there just for community's convenience of the users that for some reason want to support iOS 6 and won’t be shipped.
Thoughts?
Thanks,
Christos
[1] http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2014/la...
12 years
LiveOak SDK
by Matt Wringe
Initial email to get some discussion going around the LiveOak SDK and
AeroGear collaboration.
Essentially in LiveOak we are going to need a few different SDK types
- Client Application SDK
This is the code which will run on the users device. Initial targets
here are javascript (+ cordova support), iOS, Android. This type of SDK
will handle things like getting and sending resources to and from the
server, handling login/logout/registration, etc. Probably some other
things like device registration would be needed as well.
Not sure if we want to provide support for some other things outside of
communicating with the server or not (eg access to device components (eg
camera, location, etc)) or if these would be best handled by using the
native environment's SDK instead.
- Server Side SDK
This is code that runs on the server side, written in JavaScript by the
application developer. This will need to be familiar to the client
application's JavaScript SDK, but may not be exactly the same. This type
of SDK will be able to access the same resources as the client side
JavaScript, as well as other internal resources and libraries.
I am not sure how to collaborate between the LiveOak and AeroGear teams
here. AeroGear makes really awesome SDKs for various mobile platforms,
but with LiveOak we are dealing with a specific type of application. The
AeroGear SDKs tend to handle the more generic case, which I don't
necessarily think makes sense for a LiveOak SDK.
I do think it makes sense that the LiveOak SDK uses the AeroGear SDK
internally, but I don't know if we want to expose these AeroGear
components to a LiveOak developer or not.
For me, I envision something like the admin setting up their application
in the LiveOak console which then generates a json configuration file
(url locations, resources available, KeyCloak settings, UPS settings,
etc). The application developer then drops this json file in to their
application, the LiveOak SDK reads the json file to set it self up and
then its really easy for the developer to start using it.
[there are also some really cool things we could be doing here as well
if we can get awesome data sync support for AeroGear. It might be
interesting to be able to fetch a resource from the server and
automatically sync its state across between the client and server. This
way the object appears as a local object: if the resource changes on the
server, it changes locally as well, if it changes locally, that change
is pushed to the server. This way you are just dealing with an object,
and not having to fetch and then push object back and forth between the
server manually]
Anyone have any thoughts on this?
12 years
AeroGear iOS meeting
by Corinne Krych
Hello iOS lovers,
1.6 is over let’s sit down together and discuss what’s next. We'll use our usual Tuesday slot. See you Tuesday 8th July at 2pm (CEST - UTC + 2hours). Here is a proposal agenda:
http://oksoclap.com/p/aerogear_ios_meeting_01072014
Feel free to add topics you would like to discuss.
See you all Tuesday!
++
Corinne
12 years
