+1

that sounds like a better Option


On Tue, May 7, 2013 at 8:34 AM, Christos Vasilakis <cvasilak@gmail.com> wrote:
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@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.


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@apache.org> wrote:


On Mon, May 6, 2013 at 11:58 AM, Matthias Wessendorf <matzew@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf