BlackBerry Push Overview
-
Upload
ashwani-dhaka -
Category
Documents
-
view
77 -
download
0
Transcript of BlackBerry Push Overview
1December 16, 2009
BlackBerry Push Service
Overview – March 2010
Taking a step back: Differentiating mobile information transmission methods→ Polling
A technique where a client periodically asks a server whether an event of interest has occurred
Inefficient – increases OTA costs and traffic there may be many polling attempts to fetch a single event
Delays in getting data due to polling latency (interval) Depending on polling interval, received data may be outdated Wastes battery life checking whether an event of interest has
occurred Generates extra server traffic and load for your application
1,000,000 devices x 12 polls/hr x 24 hours = 288,000,000 requests per day
Doesn’t scale
→ Alert A notification to the device to wake up an application to do
something Like Push, but no content, or content limited to a application
activity code
Taking a step back: Differentiating mobile information transmission methods (continued)
→ Poke-Pull A technique where a notification and URL are pushed to a device
(poke) and the and device fetches the content at the URL (pull) Less efficient than true push
→ Push Push allows the delivery of content to a device without the device
having to request it The data is sent asynchronously to a port on the device where an
application is listening for it Push is generally server based/mediated (server typically is the
Push Initiator) The Push Initiator submits a request to the Hosted Data Push
Service which contains delivery instructions and the payload The delivery instructions describe where the data is to be sent and
how The payload may be any data-type (images, text, audio, video, other
formats)
The Push Paradigm The data is on the device when the user needs it
The data is delivered as soon as it is available (an event of interest occurred)
Application is always actively listening for data arrival (event)
The user is alerted (play tune, vibrate, blink, pop-up, icon overlay) when all the data has been delivered, processed, and ready to view, appearance of zero latency
→ The user experience is that it just happened, automatically and reliably
Why use Push?
The BlackBerry® Push Service…… represents a most efficient way to quench customer information
needs!… saves device battery life and customer data budgets!
… creates more immediate user experiences!
Polling Alerts Poke & Pull
Description
Application will use resources on the device to open connectivity to a server at regular intervals, whether new information is actually available or not.
A very small piece of information is sent to the device, that provides the customer with a notification that something new is available for the respective service.
A very small piece of information is sent to the device, triggering the respective application to “wake up” and download the data specified in the initial information.
Effects / Experience
→ Needs to occur in very tight intervals to mimic a push experience.
→ Constant connections opening / closing on the device increase drain on battery.
→ Most connections are opened / closed unnecessarily, as there is no new information available.
→ Albeit minimal, customer data plans area effected by empty polling requests.
→ While initial alert is very adequate, customers have to wait for relevant (richer) information to download in separate, disconnected (and at times lengthy) step.
→ Lack of multiple, unique ports contributes to lost alerts / information, as new alerts overwrite unread old alerts.
→ Great way to deal with large files, but inefficient, as device has to work on every content delivery (even for small data packets).
→ If used at all times, this will lead to similar effects as Polling
Push Paradigm used at BlackBerry→ Mail
The original push infrastructure Enterprise (BlackBerry® Enterprise
Server) and BIS-E
→ Enterprise through MDS Enterprise version of Data Push
infrastructure Supports PAP and MDS push
interfaces
→ Web Signals Push browser icon to home screen
(for web sites) Predecessor to Data Push
infrastructure
→ BlackBerry Push Service Push any data type to a specific,
registered java-application or web widget on the device
The BlackBerry Push Service
→ Provides transport infrastructure for Server to Device pushed data
→ Primary focus on consumer applications Can be used for cross company
applications (Enterprises)
→ Server to Server interface for the push initiator Server-side application is required
→ Pushes are initiated on the Server Utilizes Research In Motions push
infrastructure
→ Sends data to a specified Port on the device Client side Java® application required
Basic Flow
1. Content provider sends a push request
2. BlackBerry service returns a response
3. BlackBerry service pushes data to an
assigned, specific port on device(s)
4. Device returns response to BlackBerry
service
5. BlackBerry service forwards
acknowledgement to content provider
6. Read notification is returned to the
BlackBerry service
Who can benefit from the BlackBerry Push Service?
→ (Consumer) Applications that require: Alerts Poke-Pull model Event driven systems Near real-time notifications Replace polling to improve performance &
reduce costs
→ Generally, every use case that offers (business critical) information: Weather: updated forecasts, severe weather
warnings News, Sports (scores), Traffic Banking & Stocks Social Networking Gaming
Key Features→ Allows up to 8kB payload → Dedicated application ports avoid port
collisions→ Uses standard push protocols (WAP PAP 2.2) → Supported requests (via HTTPS XML):
Submit Push (to PIN) , Cancel Push Query for Status Query for Device Capabilities
→ Response: Result notification
→ Different submission modes: Point-to-Point (submit push to single PIN) Multicast (submit push to list of PINs) Broadcast (submit to all PINs for a registered
application) → Developer-controlled expiry time (Push
system will automatically store push requests until expiry time)
→ Supports delivery notifications → Developer-set quality of service:
Application (“message reached application” ) Transport (“message reached port on device”) Fire & Forget (no acknowledgements) Items in red are unique to the BlackBerry Push Service and
Platform
Options
→ Push Service Essentials has been optimized for broadcasting less critical information (if the end user does not receive the message, it doesn’t matter)
→ Push Service Plus represents the current gold standard push service, and provides content providers the ability to know where their critical information is every step of the (push) way
Push Service Plus Push Service Essentials
8kB Content Yes Yes
Single Port Yes Yes
Multiple Casting Methods
Yes Yes
Status Query Yes No
Quality of Service Yes No
Configurable Return URL
Yes No
Controllable Expiry Time
Yes – up to 8 hours Yes – up to 30 days
Pricing
Free1 (1 – if 100,000 or less pushes per day)
Tiered Pricing2 (2 – if above 100,000 pushes per day;
negotiated at time of registration)
Free (at all levels)
BlackBerry Push Service provides options depending on the use-case, target market and intended budget:
Enablement
1. Content Provider registers in section “Pricing & Registration” at: https://www.blackberry.com/developers/pushservice/
2. Content Provider obtains documentation: Downloads Push Service SDK from website Eval App ID, PW provided by RIM
3. Content Provider develops & tests A separate “eval” infrastructure is provided by
RIM
4. Content Provider requests production
5. RIM reviews application Follows Tech Schedule guidelines? Provide Production credentials when accepted
6. Content Provider launches service Distribution through all applicable distribution
models (incl. VPL / App Centre / App Store)
Features In Depth
Application Registration→ Pushes can only be submitted to devices, that have
registered with the push service Registration
Enables the device to receive Pushes for a specific application from provider
Deregistration Disables the device from receiving pushes Push initiators must be sure to deregister if the application is no
longer being used
→ We accept multiple push requests for a device - but we don’t guarantee order
→ For acceptance, the application must have a mechanism for the user to register / deregister when needed (push on / off switch)
Submit Push→ Sent to PIN→ Up to 8K payload→ Mode:
Point to Point:Information is sent to single PIN
Multicast:Information is sent to a list of PINs
Broadcast:Information is sent to all PINs that are registered for a given application
→ Data Push Service will attempt to deliver the message until expiry time Device is monitored for returning to coverage Push only occurs if device is actually in coverage
→ Deliver Before (expiry) Up to 8 hours (Plus Option) / 30 days (Essentials Option)
before the message is timed out
Quality of Service→ Push Plus option allows to set delivery notifications :
Notifications are sent to push initiator, via content provider’s notification URL
Typically base URL is used from content providers domain (unless otherwise specified by content provider)
Be prepared to receive a response for each message sent!
→ Quality of Service / Acknowledgements to push initiator Application-level (Push Plus Option only):
Information reached the application – acknowledged all the way back to the push initiator
Transport-level (Push Plus Option only):Information reached the device – acknowledged to push initiator
Server-level (Push Plus Option only):Information reached the BlackBerry Push Service servers – acknowledged to push initiator
Fire & forget:No acknowledgements are provided (at any level)
Reliability→ Choose the appropriate QoS for your application
There are tradeoffs for performance and battery life
→ Be sure to handle all request failures in your application
→ Result notifications Your server app must be prepared to handle these, if you
request them Server outages - RIM infrastructure will retry deliveries … for a
while
→ Always provide an unsubscribe option in your device application
→ Highest reliability can be achieved by application acknowledgement direct to your server
Security and Spam Prevention
Security BlackBerry Push Service is content agnostic – will push any
content the push initiator submits in the payload (up to 8kB): we deliver what we get!
Content provider is responsible for content encryption (and un-encryption in the application), if the content submitted is sensitive
Users should be authenticated to the Push Initiator’s server application as part of the registration process
Each push request is authenticated to push Infrastructure
Spam Prevention 1:1 relationship between push initiator and application Push initiator can only push to their applications All applications must be registered to the Push Infrastructure Push initiator is authenticated to the Push Infrastructure Unique listening port for each application Push initiator can only push to devices registered for their
application
Building and Testing Applications
Build Use BlackBerry Push Service SDK to initiate development
Contains installable client and server applications Addresses some of the issues inherent to a push based
architecture (registration, listener, et al.) Implement credentials obtained by RIM (App ID, PW, device
port)
Test Your application must be registered in our infrastructure A separate (shared) “eval” infrastructure is provided for
development and testing Eval system is shared with other content providers testing, has
limited capacity - Upgrade from eval environment to production environment
can occur at any time This service will have limited capacity
Appendix
References and Resources Push Application Protocol, OMA-WAP-TS-PAP-V2_2-20071002-
C.pdf,URL: http://www.openmobilealliance.org/Technical/release_program/push_v2_2.aspx
"Uniform Resource Locators (URL)", T. Berners-Lee, et al., URL: http://www.ietf.org/rfc/rfc1738.txt
"Wireless Application Group User Agent Profile Specification", Open Mobile Alliance™, WAP‑248‑UAProf. URL: http://www.openmobilealliance.org/
"Resource Description Framework (RDF) Model and Syntax Specification", W3C Recommendation, 22-February-1999. URL: http://www.w3.org/TR/REC-rdf-syntax
"Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", N. Freed, et al., URL: http://www.ietf.org/rfc/rfc2046.txt