Hi
not sure either about providing a category and hiding the lifecycle methods. I guess, with
an Xcode template that adds a "Push Support Enabled" option (with URL and ID
fields if enabled), most of the code can be generated, leaving the users to edit at will
if they wish.
Thanks,
Christos
On May 6, 2013, at 10:32 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
One thing that we _could_ also include here, is a "ag-push"
category for the AppDelegate class, which implements the iOS/APNs specific "delegate
methods".
the JS/Phonegap plugin does that for it's iOS backing.
https://github.com/phonegap-build/PushPlugin/blob/master/src/ios/AppDeleg...
Basic idea: we implement all the required hooks, for our customers/users - besides a few
bits:
- URL of the server
- ID of the (iOS) variant (since that is specific to THEIR installation of the UP
server)
Downside: I *think* overriding of that category is odd...
-Matthias
On Mon, May 6, 2013 at 3:20 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
Location of the project, is currently here:
https://github.com/matzew/ag-client-push-sdk
API:
https://github.com/matzew/ag-client-push-sdk/blob/master/push-sdk/AGDevic...
TEST (incl. OHHTTPStubs for mocking AFNetworking):
https://github.com/matzew/ag-client-push-sdk/blob/master/push-sdkTests/AG...
-Matthias
On Mon, May 6, 2013 at 11:58 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
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
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev