Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
02-19-2013 08:20 AM
What is the rationale behind the Java Push API JARs not providing the *.java source relating to them along side the classes ?
If there are "black box" parts and "public API parts" then making two different JARs or even using *.internal.* conventions but providing source to the public API parts would in many cases be far more useful documentation than the JavaDoc I have seen so far.
In particular the *.commons.* and any interfaces and classes intended to be subclassed.
Maybe I just have not found the really good programmer reference documentation some topics to cover:
* Replacing the persistance layer (reimplementing DAOs, with Hibernate/JPA), I am not against using direct JDBC but I don't wish to use direct JDBC for interogating the data and would rather test a reimplementation by injecting it for use by BB libraries.
* How to move all the resources the default examples pile into the toplevel classpath into an OSGi compliant location inside an authorized package namespace.
* A complete documentation run down of all the externally visible Servlet's, including those provided in demo/examples, the classes for base-class use DO and DO NOT aspects of each servlet.
Solved! Go to Solution.
02-19-2013 09:30 AM
In terms of replacing the persistence layer - this is a more detailed response that will take a bit of time to write up so I will post a subsequent reply with more detailed instructions later on.
I am afraid we don't work with OSGi so I wouldn't be able to give you a qualified answer for this question.
We can get you more documentation for the externally visible servlet's. But for your last question can you clarify what you mean, "the classes for base-class use DO and DO NOT aspects of each servlet."?
02-19-2013 09:47 AM
Here's a list of the externally visible servlets for the high-level - more info can be found for these servlets in the Javadoc:
2. net.rim.pushsdk.subscription.web.SubscribeServlet: Handles incoming subscribe requests.
4. net.rim.pushsdk.subscription.web.SuspendServlet: Handles incoming suspend requests.
5. net.rim.pushsdk.subscription.web.ResumeServlet: Handles incoming resume requests.
Here's a list of the externally visible servlets for the low-level - more info can be found for these servlets in the Javadoc:
02-19-2013 10:24 AM
Thanks for your reply.
You don't actually need to officially support OSGi to be doing/designing things such that they work in conjunction with OSGi as they generally follow good practice when designing 'java modules' even without OSGi. One of these things is that all constant resource artifacts (XML DTD properties) should be moved away from the toplevel and into a package. namespace. Maybe you already provide a setter to specify the resource location for that file.
Maybe there isn't an issue in this area at all, if the DTDs are provided but not needed or used at runtime and the rest of the *.properties files are a configuraion data source.
The DO and DO NOTs is a kind of best practice coming from someone who understands each Push API feature and the way it is intended to be used. Here is a kind of brainstorm on the areas:
The externally facing aspects:
* Covering level4 firewalls, http methods used, use of compression
* Recomendation / requirements for persistance connection and HTTP/1.1 and timeouts.
* Expected max request size and max response size and computations for overhead and working with bulk communications. Maybe if users could read the source they simple write a test case once they found the appropiate classes.
The software facing aspects:
* Each Push API feature has its own Servlet implementation ?
* Each of these Servlets is expected to be implemented by subclassing a provided default implementation ?
* The action interface method on the servlet and points relating to that.
* A kind of walk through wiki page covering each individual servlet that implements the function being demonstrated from the example/demo code pointing out.
* Which method calls are allowed to block, for what period of time, what kind of processing is expected to take place while inside this Java interface callback. Maybe some interfaces should only block to persist data and any slow processing should take place at another time. Maybe some interfaces are designed to allow slow processing to take place (I'm gussing the background bulk processor).
* Threading concerns, if any. I guess there isn't any, outside the expected 1 thread per request model and use of background bulk processing threads (which manages itself).
Aspects concerning interaction with RIM/BB servers:
* Persistance connection timeouts.
* Policy on SSL use and verification (i.e. RIM perform verification of the remote SSL)
* Policy on allowed or disallowed SSL ciphers (or other such negotiated options)
* Published IP netblocks of RIM servers (to allow an additional authorization check by IP for backend).
02-19-2013 12:23 PM
The Push Service SDK is a set of Java APIs with two "levels" of APIs you can use.
The high-level APIs offer more features such as subscription, push management, result notification handling so that it's easier and quicker for you to implement your own Push Initiator. There is a dependency on storage (e.g. using a database, memory, etc.) and on Spring. There are some servlets we provide that can be used to handle / process incoming subscription requests and result notification requests. You do not have to use these servlets if you do not want to. You can write your own handlers by, using subscription as an example, getting the "subscriptionService" Spring bean and calling the applicable method to subscribe, unsubscribe, etc.
We also offer low-level APIs which do not require a database or storage and simply offer the raw APIs you need for sending a push and handling responses from the PPG. It allows you more control over your Push Initiator implementation and you do not have to use Spring to use these APIs.
As for the DTDs, the ones we provide are the PAP DTDs that contain the XML tags used by the low-level APIs to send out pushes, handle incoming responses from the PPG, etc. They are provided for reference. They are not actually used by the SDK. We do not do DTD validation.
There is a developer guide that might help clarify how things are structured:
02-19-2013 01:18 PM
Please use this installation guide to install a Push service sdk. After you installed it, you will find it in both java war and tomcat webapplication. http://developer.blackberry.com/devzone/develop/pl
02-19-2013 01:23 PM - edited 02-19-2013 01:24 PM
Thanks for the information but... I have found this info (from a search of JavaDoc for *Servlet and such).
Your comment sounds like there is useful information in the example
However there is only a compiled class and no source code to see what it is actually doing. So while the sample may work it is not that useful to show me anything of value other than getting a proof of concept working as a black box. I don't really need proof BBs Push SDK works, I trust you on this, what is needed it an example that can be inspected.
02-19-2013 01:43 PM - edited 02-19-2013 01:54 PM
The source code is at YOUR_INSTALLATION_PATH/BPSS/pushsdk-high-level/hig
If you can find a old version of BlackBerry Push SDK say 1.0, the file structure is different from this version. That version contains source code only and you have to build by yourselves. Maybe that is what you exactly need. The old version is also working properly for BB10.
02-19-2013 02:02 PM
It is possible to implement the entire data access layer of the SDK with your own implementation and its actually quite easy. It’s as simple as implementing the interface of all the SDK DAOs and then injecting your instance into the corresponding service classes. You can implement your DAOs any way you want using any technology you want. There are no other requirements other than implementing the APIs as specified by their documentation. You may want to consider implementing a cache mechanism in certain DAO implementations that have high volume API access such as PushStatsDAO, PushApplicationDAO and SubscriptionDAO. There is nothing you need to implement in the commons package if you implement the DAOs yourself. If using the SDK service layer objects the following DAOs must be implemented:
net.rim.pushsdk.PushSDKBaseDAO - Base DAO for all other DAOs. Provides some convenience methods such as to allow the DAOs to use Spring's SimpleJdbcTemplate to take advantage
of Java 1.5 varargs and autoboxing.
net.rim.pushsdk.push.count.PushCountDAO - Interface defining data access methods needed to manage PushCountService objects in the store. If a push is sent to more than one address then and the track last notification or auto-delete flags are turned on for a PushApplication then this DAO is used to help determine when the last notification has been received for a particular push.
net.rim.pushsdk.push.request.PushRequestDAO - Interface defining data access methods needed to manage PushRequest objects in the store. The PushRequest object model captures the high-level attributes that overall define a push message at push time. For one PushRequest object, there will be one to many PushRequestDetail objects saved to storage (one for each subscriber). In other words: PushRequest -> (1..n) PushRequestDetail
net.rim.pushsdk.push.request.PushRequestDetailDAO - Interface defining data access methods needed to manage PushRequestDetail objects in the store. The
PushRequestDetail object model captures the attributes that define a specific address of a push message. For one PushRequest object, there will be one to many PushRequestDetail objects saved to storage (one for each subscriber). In other words: PushRequest -> (1..n) PushRequestDetail
net.rim.pushsdk.push.stats.PushStatsDAO - Interface defining data access methods needed to manage PushStats objects in the store. The PushStats object keeps statistics for the push application with the specified id and provided running push count, running content sum, and daily push count.
net.rim.pushsdk.pushappmgmt.PushApplicationDAO - Interface defining data access methods needed to manage PushApplication objects in the store.
net.rim.pushsdk.subscription.SubscriptionDAO - Interface defining data access methods needed to manage SubscribeRequest objects in the store.
02-19-2013 02:40 PM
Btw, we will take your suggestion back and look into what it will take to get the SDK open sourced but I expect the process will take some time. In the meantime we will beef up documentation to address some of your concerns.