Messages
Bon sens!
Il y a 14 ans
20 juillet 2010
17 mai 2010
Subordinating the Scrum Team
From http://www.leadingagile.com/2010/05/subordinating-scrum-team.html
Agilists intuitively get that it's a bad idea to build an inventory of detailed specs way ahead of when they are going to get turned into software. Why? Because we know that as our product emerges, we are going to want to make changes to those requirements. There is a real risk that a lot of that work will end up being waste. That's a big part of why we document agile requirements as user stories... we want the placeholder now, but we don't need the details until we get closer to building that part of the product. It keeps our options open and our overhead low.
Building an inventory of requirements has a more insidious impact than just opening up the possibility of waste. Sure, we risk specifying stuff that the business might not need, but we also build in assumptions and risk that can't be validated. Everything that we define now, everything that can't be built and tested immediately after specification, represents something that we'll have to validate or mitigate somewhere down the road. Those uncertainties make it really hard to forecast when we are going to get to done. They make it tough to be predictable.
Furthermore, requirements gathering an analysis shouldn't be done in a vacuum. We know that we're going to want some help from our development team to discuss what's possible from a technology perspective. When we pull our team into meetings to discuss these things, we are taking their attention away from the task at hand. Our team is working on the highest priority features, and here we are pulling them away to help forecast lower priority requirements that may or may not ever make it into the product. It's a pretty solid formula for going slower than we have to.
Even though we may have some capacity to do the requirements work... and it would be nice to get ahead of the game a little... it is not something we generally do on agile projects. Managing all those requirements changes, tracking all those assumptions and risks, and absorbing all the productivity impact to the development team is just too great a cost. We KNOW it is going to cause us problems down the road. Any benefits we'd gain from getting ahead of the requirements work would be lost due to the overhead necessary to maintain our requirements inventory. That inventory slows us down and makes us more resistant to change.
We understand... in this kind of a scenario... that the team has to subordinate the requirements gathering process to the overall production cadence of the delivery team.
Now, let's extend this metaphor up a little and talk about our financial services company... and specifically our new hyper-productive Credit Card Processing Scrum team. With regard to the rest of the organization... our Scrum team is able to produce working software much faster than everyone else around them. The question we're dealing with is... SHOULD they produce working software much faster than everyone else around them? In this context, under this set of circumstances, I'm saying no.
I'm suggesting that the Scrum team in our complex product organization becomes very much like the requirements gathering function in our earlier example.
When the Credit Card Processing team builds software features faster than the rest of the organization can consume those features, they risk the possibility of waste and rework. They introduce assumptions and risks that have to be managed and mitigated throughout the life of the project. They will disrupt the other development teams around them and force those teams to multi-task. The other teams will be forced to pay attention to features that they won't be ready to build for another several months. All that code will slow us down and make us resistant to change.
While it is technically possible for the Credit Card Processing team to get a head of the game... and it might make them feel more productive... it might be great for their team morale... ask yourself what impact they are having on the rest of the organization. It might not be as positive as you think. So... for all the same reasons you might ask a PO or a BA to slow down writing requirements to fill the product backlog, you might want to ask your Scrum team to slow down building software until the rest of the organization can catch up.
It's counter-intuitive, but if you start thinking past the single team, it might be exactly what you need to do.
Agilists intuitively get that it's a bad idea to build an inventory of detailed specs way ahead of when they are going to get turned into software. Why? Because we know that as our product emerges, we are going to want to make changes to those requirements. There is a real risk that a lot of that work will end up being waste. That's a big part of why we document agile requirements as user stories... we want the placeholder now, but we don't need the details until we get closer to building that part of the product. It keeps our options open and our overhead low.
Building an inventory of requirements has a more insidious impact than just opening up the possibility of waste. Sure, we risk specifying stuff that the business might not need, but we also build in assumptions and risk that can't be validated. Everything that we define now, everything that can't be built and tested immediately after specification, represents something that we'll have to validate or mitigate somewhere down the road. Those uncertainties make it really hard to forecast when we are going to get to done. They make it tough to be predictable.
Furthermore, requirements gathering an analysis shouldn't be done in a vacuum. We know that we're going to want some help from our development team to discuss what's possible from a technology perspective. When we pull our team into meetings to discuss these things, we are taking their attention away from the task at hand. Our team is working on the highest priority features, and here we are pulling them away to help forecast lower priority requirements that may or may not ever make it into the product. It's a pretty solid formula for going slower than we have to.
Even though we may have some capacity to do the requirements work... and it would be nice to get ahead of the game a little... it is not something we generally do on agile projects. Managing all those requirements changes, tracking all those assumptions and risks, and absorbing all the productivity impact to the development team is just too great a cost. We KNOW it is going to cause us problems down the road. Any benefits we'd gain from getting ahead of the requirements work would be lost due to the overhead necessary to maintain our requirements inventory. That inventory slows us down and makes us more resistant to change.
We understand... in this kind of a scenario... that the team has to subordinate the requirements gathering process to the overall production cadence of the delivery team.
Now, let's extend this metaphor up a little and talk about our financial services company... and specifically our new hyper-productive Credit Card Processing Scrum team. With regard to the rest of the organization... our Scrum team is able to produce working software much faster than everyone else around them. The question we're dealing with is... SHOULD they produce working software much faster than everyone else around them? In this context, under this set of circumstances, I'm saying no.
I'm suggesting that the Scrum team in our complex product organization becomes very much like the requirements gathering function in our earlier example.
When the Credit Card Processing team builds software features faster than the rest of the organization can consume those features, they risk the possibility of waste and rework. They introduce assumptions and risks that have to be managed and mitigated throughout the life of the project. They will disrupt the other development teams around them and force those teams to multi-task. The other teams will be forced to pay attention to features that they won't be ready to build for another several months. All that code will slow us down and make us resistant to change.
While it is technically possible for the Credit Card Processing team to get a head of the game... and it might make them feel more productive... it might be great for their team morale... ask yourself what impact they are having on the rest of the organization. It might not be as positive as you think. So... for all the same reasons you might ask a PO or a BA to slow down writing requirements to fill the product backlog, you might want to ask your Scrum team to slow down building software until the rest of the organization can catch up.
It's counter-intuitive, but if you start thinking past the single team, it might be exactly what you need to do.
6 mai 2010
9 Web CSS Tools You Must Know
Long time no see! :)
Voici un lien intéressant vers des outils CSS en ligne
http://www.queness.com/post/3220/9-web-css-tools-you-must-know
Voici un lien intéressant vers des outils CSS en ligne
http://www.queness.com/post/3220/9-web-css-tools-you-must-know
15 avril 2010
13 simple but useful online tools for web development
http://www.queness.com/post/2959/13-simple-but-useful-online-tools-for-web-development
24 mars 2010
Test-Driven Development
One of the foundational concepts of Agile software development is ensuring that your solution is loosely-coupled, highly-cohesive, and able to respond easily to changes; in this session we will explore the fundamentals of unit testing and their application through the practice of using TDD to evolve the design of your solution such that the results are both testable and flexible in the face of changing real-world requirements.
http://www.testingtv.com/2010/03/24/test-driven-development/
http://www.testingtv.com/2010/03/24/test-driven-development/
22 février 2010
10 Things I Hate About Agile Development!
Agile development. Love it or hate it, there's no doubt that it's here to stay. I've enjoyed a great deal of success thanks to agile software development and agile project management methods, but here are 10 things I hate about Agile!
1. Saying you're doing Agile just cos you're doing daily stand-ups. You're not doing agile. There is so much more to agile practices than this! Yet I'm surprised how often I've heard that story. It really is remarkable.
2. Worrying about the difference between 'Agile' (big A) and 'agile' (small a). You mean you spell it with a big A, omg you're so not cool! The differentiation is between Agile methods and being 'agile', in the true sense of the word. Most people probably don't get the subtlety. When people split hairs about this it gets on my nerves and makes so-called agilists sound like a bunch of overly-religious nerds.
3. Thinking that agile is a silver bullet and will solve all your problems. That's so naiive, of course it won't! Humans and software are a complex mix with any methodology, let alone with an added dose of organisational complexity. Agile development will probably help with many things, but it still requires a great deal of skill and there is no magic button.
4. Claiming to be Agile when you're clearly not 'agile'. Yes, we're doing all the major agile practices, but we're not flexible and we don't seem to understand the underlying agile principles. Were agile in practice but don't demonstrate the values of openness, attention to quality, collaboration, team spirit, etc.
5. People who are anti-agile but with nothing constructive to say about why. I hate that. I've had a few turn up here and enlighten us all with their intellectual comments, such as 'snake oil' or 'agile is a hoax'. Losers!
6. Blaming agile - 'I tried it once and didn't like it'. Projects are difficult. Some projects may even fail, even if you are using agile project management methods. As I said earlier, agile is not a silver bullet. It's important not to blame agile when things go wrong, just as it's important not to claim it's the saviour for all of your ills. Don't blame the process. It's a bit like bad workmen blaming their tools. It's not big and it's not clever!
7. Using agile as an excuse - 'no we can't do that, cos it's not Agile'. 'No I'm sorry, we don't do it that way here'. Following the agile process without fail regardless of the circumstances - even if it's contrary to what the situation really requires for the business or for the customer. If the process is the most important thing, above all else, that's not agile!
8. People who think they're smart enough to adapt agile processes before they've really got enough experience to understand how and *why* it works. It's an easy trap to fall into, but one that should be resisted. Otherwise it's so easy to throw the baby out with the bathwater!
9. People who use agile as an excuse for having no process or producing no documentation. If documents are required or useful, there's no reason why an agile development team shouldn't produce them. Just not all up-front; do it as required to support each feature or iteration. JFDI (Just F'ing Do It) is not agile!
10. People who know more about agile development than me. They're so smug ;-)
Ah, that's better! I feel much better now I've got that off my chest.
Thank you for listening!
Kelly.
P.S. - one more thing! I hate people who rant about agile development on agile blogs. That's just silly.
Picture by beneneuman
1. Saying you're doing Agile just cos you're doing daily stand-ups. You're not doing agile. There is so much more to agile practices than this! Yet I'm surprised how often I've heard that story. It really is remarkable.
2. Worrying about the difference between 'Agile' (big A) and 'agile' (small a). You mean you spell it with a big A, omg you're so not cool! The differentiation is between Agile methods and being 'agile', in the true sense of the word. Most people probably don't get the subtlety. When people split hairs about this it gets on my nerves and makes so-called agilists sound like a bunch of overly-religious nerds.
3. Thinking that agile is a silver bullet and will solve all your problems. That's so naiive, of course it won't! Humans and software are a complex mix with any methodology, let alone with an added dose of organisational complexity. Agile development will probably help with many things, but it still requires a great deal of skill and there is no magic button.
4. Claiming to be Agile when you're clearly not 'agile'. Yes, we're doing all the major agile practices, but we're not flexible and we don't seem to understand the underlying agile principles. Were agile in practice but don't demonstrate the values of openness, attention to quality, collaboration, team spirit, etc.
5. People who are anti-agile but with nothing constructive to say about why. I hate that. I've had a few turn up here and enlighten us all with their intellectual comments, such as 'snake oil' or 'agile is a hoax'. Losers!
6. Blaming agile - 'I tried it once and didn't like it'. Projects are difficult. Some projects may even fail, even if you are using agile project management methods. As I said earlier, agile is not a silver bullet. It's important not to blame agile when things go wrong, just as it's important not to claim it's the saviour for all of your ills. Don't blame the process. It's a bit like bad workmen blaming their tools. It's not big and it's not clever!
7. Using agile as an excuse - 'no we can't do that, cos it's not Agile'. 'No I'm sorry, we don't do it that way here'. Following the agile process without fail regardless of the circumstances - even if it's contrary to what the situation really requires for the business or for the customer. If the process is the most important thing, above all else, that's not agile!
8. People who think they're smart enough to adapt agile processes before they've really got enough experience to understand how and *why* it works. It's an easy trap to fall into, but one that should be resisted. Otherwise it's so easy to throw the baby out with the bathwater!
9. People who use agile as an excuse for having no process or producing no documentation. If documents are required or useful, there's no reason why an agile development team shouldn't produce them. Just not all up-front; do it as required to support each feature or iteration. JFDI (Just F'ing Do It) is not agile!
10. People who know more about agile development than me. They're so smug ;-)
Ah, that's better! I feel much better now I've got that off my chest.
Thank you for listening!
Kelly.
P.S. - one more thing! I hate people who rant about agile development on agile blogs. That's just silly.
Picture by beneneuman
20 février 2010
Agile Game Development : Agile Game Development Checklists
The Agile Game Development Checklists are meant to help drive discussion about the implementation and effectiveness of agile practices (including Scrum, XP, TDD and Kanban) for a team and stakeholders.
This first version contains a checklist for the ScrumMaster role. Revisit how this role adds value to a Scrum Team and how that role can be improved.
read more
This first version contains a checklist for the ScrumMaster role. Revisit how this role adds value to a Scrum Team and how that role can be improved.
read more
12 février 2010
4 février 2010
Shutup.css Silences Web Site Comments [CSS]
While we happen to love comments and the lively discussion that occurs in them, we understand that not everybody wants to see the comments left by other internet users. Shutup.css lets you apply a custom stylesheet and eradicate comments across the web.It's as simple as it sounds. Download the Shutup.css file at the link below and apply it to your custom styles in your web browser. For most browsers you can find custom style sheets under the advanced settings. If you're a Firefox user you can download Stylish to manage styles and give you finer control over which sites the Shutup.css file is applied to—it also makes toggling it on and off easier.
Once you have the style applied to your browser nearly all web sites with comments will no longer be displaying them. The screenshot above shows the end of a Lifehacker article with the style sheet not applied and then applied, removing the comments. Easy but effective.
Have a favorite user style hack? Prefer just to silence YouTube comments? Share it in the comments below.
Shutup.css [via Make]
27 janvier 2010
26 janvier 2010
22 janvier 2010
HTML5 support from YouTube
YouTube is starting to roll out experimental support for HTML5 video playing, using native browser HTML5 support rather than relying on Flash plugins. The support is limited to certain browsers and certain videos, and can be accessed by visiting the ‘TestTube‘ area of YouTube (or directly here). While this is early stages, having such a large company like YouTube supporting this (and hopefully rolling it out soon) will certainly help drive adoption of the multimedia uses of HTML5. I’m looking forward to see what’s next!
From http://jsmag.com/blog/2010/01/html5-support-from-youtube
From http://jsmag.com/blog/2010/01/html5-support-from-youtube
17 janvier 2010
14 Mind-Blowing Mind Map applications and web services
http://www.webdeveloperjuice.com/2010/01/15/14-mind-blowing-mind-map-applications-and-web-services/
14 janvier 2010
Flash Demo on iPhone via Open Source Gordon Project
http://www.iphoneincanada.ca/iphone-news/flash-demo-on-iphone-via-open-source-gordon-project
What Is On Your iPhone 4G/OS 4.0 Wishlist?
The rumour mill has started regarding the“next” iPhone to grace our grubby hands this summer. We all know that Apple’s ability to keep every detail secret until the last minute is what gets us excited leading up the the release.
Apple is known to slowly release features (*cough* copy and paste *cough*) with regards to both software and hardware. Personally, I am looking forward to a new hardware design with a front facing camera for iChat capabilities, and LED flash with a 5megapixel camera to start. Of course we also can’t leave out better battery life and a higher resolution screen. Are any of these wants wishful thinking?
At the same time, I also enjoy not knowing what is coming next. What will Apple deliver once June/July arrives? Will they respond to the impressive hardware specs of the Google Nexus One(which offers great support through Google Groups, LOL)?
The iPhone 4G Wishlist That People Want
User ThatsMeRight over at MacRumors posted the following “wishlist” for the future iPhone. What items do you think will come true and ones that will never see the light of day?
Hardware wishlist
- 4G network (LTE probably in 2011, but WiMax is already possible).
- New camera. 5MP? Flash? etc. (+ camera shutter)
- Front camera, minimum of 3 MP for video conferences.
- New design
- New WiFi chip (802.11n) (like found in the iPod Touch)
- Better cellular chips of the 3G and 2G networks
- (AM)OLED screen (maybe some extra backlight when you’re outside?)
- Two speakers or “all-around-sound” and of course better audio quality.
- Better 3D graphics
- Up to 64GB of space. Declare 16GB the dead, 8GB ‘low-quality’ model like iPod Touch
- New processor and more RAM
- Infrared
- Higher resolution: High Definition?!
- FM transmitter
- Pedometer
- New exterior (design)
- Removable battery
- Built-in RFID (radio-frequency identification) technology
- Fingerscanner
- LED light in the home button (e.g. blue with new message, green incoming call etc.) with ability to turn it off
- Powermat support
- Touch-sensitive places at all corners (at left and right of home button and top right and top left) (so you can use an app without blocking your view with your hands and it would be a great improvement like ’scrolling’ or something like that) with easy turn on and off like double tap in corners at the same time (you won’t have an ‘accident double tap at two corners at the same time haha).
- And of course… better battery life
iPhone 4.0 software
- Redesigned UI
- Multitasking (kinda like how it’s done in Safari with multiple pages)!
- Extentions of Voice Control: what about creating an email just by telling the iPhone too?
- Flash (and of course the choice to turn it off for the people who think it’s oldfashion)
- File browsing
- Bluetooth restrictions should be lifted (file transfer)
- More abilities to customize your iPhone: what about wallpapers on your homescreen?
- File browsing
- A ‘unity inbox’ for emails.
- Spotlight extension: search the web too!
- iPhone notes app needs an upgrade
- Ability to hide applications (for example that the hidden apps just appear in a special list)
- Categories/Folders: seriously, categories/folders would be nice
- Character counter in the texting app…
- Turn things on and off easier (less steps)
- Radio application (apperently the 3Gs is able to support this for sure)
- Native editing of word and excel docs. Let alone editing of pages/numbers etc.
- 720p video out
- Google Maps navigation/latitude/etc.
- Wireless syncing
- Updates of Voice Control (especially in languages other than English) and new features (e.g. “Google Apple” and it’s going to Google for Apple or compose a mail via your voice etc.)
- Profiles
- Text message counter
- New iPod app: what about deleting a song, or naming playlists?
- Support for wider format of video files
I can guarantee you that Apple will never produce an iPhone with a removable battery. The issue with the iPhone battery is that it doesn’t last long because people actually use their iPhone all the time. Twitter, Facebook, games, apps, etc, the list goes on. No battery can keep up to our endless desire for usage unless the next iPhone can be recharged by…solar power?!
13 janvier 2010
Programming Apple Push Notification Services
One of the key limitations of the iPhone is its constraint on running applications in the background. Because of this, applications cannot keep running in the background when the user switches to another application. So, applications that require a constant state of connectivity (such as social networking applications) will not be able to receive timely updates.
To remedy this limitation, Apple released the Apple Push Notification Service (APNs). The APNs is a service that allows your device to be constantly connected to Apple's push notification server. When you want to send a push notification to an application installed on the users' devices, you (the provider) can contact the APNs so that it can deliver a push message to the particular application installed on the intended device.
In this article, you will learn how to perform the various steps needed to create an iPhone application that uses the APNs.
Generating a Certificate Request
The first step to using the APNs is to generate a certificate request file so that you can use it to request for a development SSL certificate later on.
1. Launch the Keychain Access application in your Mac OS X.
2. Select Keychain Access'Certificate Assistant'Request a Certificate From a Certificate Authority (see Figure 1):
Figure 1. Generating a certificate request
3. Enter the information required and check the Saved to disk option. Click Continue (see Figure 2).
Figure 2. Saving the certificate request to disk
4. Save the certificate request using the suggested name and click Save (see Figure 3): Click Done in the next screen.
Figure 3. Naming the certificate request
Creating an App ID
Each iPhone applications that uses the APNs must have a unique application ID that uniquely identifies itself. In this step, you will learn how to create an App ID for push notification.
1. Sign in to the iPhone Developer Program at: http://developer.apple.com/iphone/. Click on the iPhone Developer Program Portal on the right of the page (see Figure 4).
Figure 4. Launching the iPhone Developer Program Portal
2. You should see the welcome page (see Figure 5).
Figure 5. The welcome screen of the iPhone Developer Program Portal
3. Click on the App IDs tab on the left and then click on the New App ID button (see Figure 6).
Figure 6. Clicking on the App ID tab
4. Enter "PushAppID" for the Description and select Generate New for the Bundle Seed ID. For the Bundle Identifier, enter
net.learn2develop.MyPushApp. Click Submit (see Figure 7).
Figure 7. Creating a new App ID
5. You should now see the App ID that you have created (together with those you have previously created) (see Figure 8).
Figure 8. Viewing the newly created App ID
Configuring an App ID for Push Notifications
Once an App ID is created, you need to configure it for push notifications.
1. To configure an App ID for push notification, you need to click the Configure link displayed to the right of the App ID. You will now see the option (see Figure 9).
Figure 9. Configuring an App ID for push notification service
Check the Enable for Apple Push Notification service option and click the Configure button displayed to the right of the Development Push SSL Certificate.
2. You will now see the Apple Push Notification service SSL Certificate Assistant screen. Click Continue (see Figure 10).
Figure 10. The Apple Push Notification service SSL Certificate Assistant screen
3. Click the Choose File button to locate the Certificate Request file that you have saved earlier. Click Generate (see Figure 11).
Figure 11. Generating the SSL certificate
4. Your SSL Certificate will now be generated. Click Continue (see Figure 12).
Figure 12. The APNs SSL certificate that is generated
5. Click the Download Now button to download the SSL Certificate. Click Done (see Figure 13).
Figure 13. Downloading the certificate generated
6. The SSL Certificate that you download is named
aps.developer.identity.cer. Double-click on it to install it in the Keychain Access application (see Figure 14). The SSL certificate will be used by your provider application so that it can contact the APNs to send push notifications to your applications.
Figure 14. Installing the generated certificate into the Keychain Access application
Creating a Provisioning Profile
The next step is to create a provisioning profile so that your application can be installed onto a real device.
1. Back in the iPhone Development Program Portal, click on the Provisioning tab and click on the New Profile button (see Figure 15).
Figure 15. Selecting the Provisioning tab
2. Type in
MyDevicesProfile as the profile name. Select PushAppID as the App ID. Finally, check all the devices that you want to provision (you can register these devices with the iPhone Developer Program Portal through the Devices tab). Click Submit (see Figure 16).
Figure 16. Creating a new provisioning profile
3. The provisioning profile will now be pending approval. After a while, you will see it appear. Click on the Download button to download the provisioning profile (see Figure 17).
Figure 17. Pending the approval of the provisioning profile
4. The downloaded provisioning profile is named MyDevicesProfile.mobileprovision.
Provisioning a Device
With the provision profile created, you will now install it onto a real device.
1. Connect your iPhone or iPod Touch to your Mac.
2. Drag and drop the downloaded
MyDevicesProfile.mobileprovision file onto the Xcode icon on the Dock.3. Launch the Organizer application from within Xcode and select the device currently connected to your Mac. You should see the
MyDevicesProfile installed on the device (see Figure 18).
Figure 18. Viewing the installed provisioning profile
Creating the iPhone Application
1. In Xcode, create a new View-Based Application project and name it as ApplePushNotification.
2. Drag and drop a WAV file (shown as
beep.wav in this example) onto the Resources folder in Xcode (see Figure 19).
Figure 19. Adding a WAV file to the project
3. Expand on the Targets item in Xcode and select the ApplePushNotification item. Press Command-I. In the Info window, click the Properties tab (see Figure 20).
Figure 20. Entering the App ID for the application
In the Identifier textbox, type <
net.learn2develop.MyPushApp.4. Click on the Build tab and type "Code Signing" in the search box. In the Any iPhone OS Device item, select the profile as shown in Figure 21:
Figure 21. Selecting the profile for code signing
5. In the
ApplePushNotificationAppDelegate.m file, type the following code in bold:#import "ApplePushNotificationAppDelegate.h" #import "ApplePushNotificationViewController.h" @implementation ApplePushNotificationAppDelegate @synthesize window; @synthesize viewController; - (void)applicationDidFinishLaunching:(UIApplication *)application { [window addSubview:viewController.view]; [window makeKeyAndVisible]; NSLog(@"Registering for push notifications..."); [[UIApplication sharedApplication] registerForRemoteNotificationTypes: (UIRemoteNotificationTypeAlert | UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound)]; } - (void)application:(UIApplication *)app didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken { NSString *str = [NSString stringWithFormat:@"Device Token=%@",deviceToken]; NSLog(str); } - (void)application:(UIApplication *)app didFailToRegisterForRemoteNotificationsWithError:(NSError *)err { NSString *str = [NSString stringWithFormat: @"Error: %@", err]; NSLog(str); } - (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo { for (id key in userInfo) { NSLog(@"key: %@, value: %@", key, [userInfo objectForKey:key]); } } - (void)dealloc { [viewController release]; [window release]; [super dealloc]; } @end
6. Press
Command-R to test the application on a real device. Press Shift-Command-R in Xcode to display the Debugger Console window. Observe carefully the device token that is printed (see Figure 22). In the figure below, the token is:38c866dd bb323b39 ffa73487 5e157ee5 a85e0b7c e90d56e9 fe145bcc 6c2c594b. Record down this device token (you might want to cut and paste it into a text file).
Figure 22. Viewing the device token for push notification
7. If you go to the Settings application on your iPhone/iPod Touch, you will notice that you now have the Notifications item (see Figure 23).
Figure 23. Viewing the Notifications item in the Settings application
Creating the Push Notification Provider
A Push Notification provider is an application written by the application's developer to send push notifications to the iPhone application through the APNs.
Here are the basic steps to send push notifications to your applications via the Apple Push Notification Service (APNs):
1. Communicate with the APNs using the SSL certificate you have created earlier.
2. Construct the payload for the message you want to send.
3. Send the push notification containing the payload to the APNs.
1. Communicate with the APNs using the SSL certificate you have created earlier.
2. Construct the payload for the message you want to send.
3. Send the push notification containing the payload to the APNs.
The APNs is a stream TCP socket that your provider can communicate using a SSL secured communication channel. You send the push notification (containing the payload) as a binary stream. Once connected to the APNs, you should maintain the connection and send as many push notifications as you want within the duration of the connection.
Tip: Refrain from opening and closing the connections to the APNs for each push notification that you want to send. Rapid opening and closing of connections to the APNs will be deemed as a Denial-of-Service (DOS) attack and may prevent your provider from sending push notifications to your applications.
The format of a push notification message looks like Figure 24 (figure from Apple's documentation):
Figure 24. Format of a push notification message
For more details, please refer to Apple Push Notification Service Programming Guide.
The payload is a JSON formatted string (maximum 256 bytes) carrying the information you want to send to your application. An example of a payload looks like this:
The payload is a JSON formatted string (maximum 256 bytes) carrying the information you want to send to your application. An example of a payload looks like this:
{ "aps": { "alert" : "You got a new message!" , "badge" : 5, "sound" : "beep.wav"}, "acme1" : "bar", "acme2" : 42 }
To save yourself the trouble in developing a push notification provider from scratch, you can use the PushMeBabyapplication (for Mac OS X) written by Stefan Hafeneger (Get it here).
1. Open the PushMeBaby application in Xcode.
2.
Right-click on the Resources folder in Xcode and select Add Existing Files…. Select theaps.developer.identity.cer file that you have downloaded earlier (see Figure 25).
Figure 25. Adding the SSL certificate to the application
3. In the
ApplicationDelegate.m file, modify the code as shown in bold below:- (id)init { self = [super init]; if(self != nil) { self.deviceToken = @"38c866dd bb323b39 ffa73487 5e157ee5 a85e0b7c e90d56e9 fe145bcc 6c2c594b"; self.payload = @"{\"aps\":{\"alert\":\"You got a new message!\",\"badge\":5,\"sound\":\"beep.wav\"},\"acme1\":\"bar\",\"acme2\":42}"; self.certificate = [[NSBundle mainBundle] pathForResource:@"aps_developer_identity" ofType:@"cer"]; } return self; }
4. Press Command-R to test the application. You will be asked to grant access to the certificate. Click Always Allow (see Figure 26):
Figure 26. Granting access to the SSL certificate
On the iPhone/iPod Touch, ensure that the ApplePushNotification application is not running. To send a message to the device, click the Push button. The server essentially sends the following message to the Apple Push Notification server:
{ "aps": { "alert" : "You got a new message!" , "badge" : 5, "sound" : "beep.wav"}, "acme1" : "bar", "acme2" : 42 }
5. If the message is pushed correctly, you should see the notification as shown in Figure 27.
Figure 27. Receiving a Push Notification message
6. If you now debug the ApplePushNotification application by pressing
Command-R and send a push message from the PushMeBaby application, the Debugger Console window will display the following outputs:2009-11-24 21:11:49.182 ApplePushNotification[1461:207] key: acme1, value: bar
2009-11-24 21:11:49.187 ApplePushNotification[1461:207] key: aps, value: {
alert = "You got a new message!";
badge = 5;
sound = "beep.wav";
}
2009-11-24 21:11:49.191 ApplePushNotification[1461:207] key: acme2, value: 42From http://mobiforge.com/developing/story/programming-apple-push-notification-services
S'abonner à :
Messages (Atom)
