on 01-17-201202:58 PM - edited on 01-23-201211:32 AM by MSohm
When creating an application for the BlackBerry® PlayBook™ the development possibilities are endless. There will usually be several ways to approach any one development task; some will be entirely supported and recommended approaches, but with the platform being extremely open there are also many ways that may work but are not recommended and could have trouble with future OS releases.
The following list of items explains both some of the recommended and potentially problematic approaches to developing in native. Following these points will help to ensure your native applications will continue to function properly with both current and future OS releases.
Applications must not statically link against any system libraries. Statically linking system libraries may cause applications to crash in PlayBook OS 2.0.
When writing audio data for playback, you must check the audio hardware block size first to ensure that the block sizes match. You cannot assume the block size is static between OS releases.
Applications must handle audio buffer underruns to audio PCM playback issues. Please refer to the PlayWav sample.
Applications should handle cases where background applications consume device resources. It is recommended that developers test their applications under high system load to ensure that they can handle the situation. Capture what priority application threads are running at to ensure that they are not starved.
New events can be generated with newer device builds. Please ignore these events if they are not applicable.
Certain application lifecycle events should be handled to ensure longer battery life. For example, WINDOW_INACTIVE should be handled by placing the application in a suspended state.
Capture CPU load and memory usage while the application is running and while it is deactivated to ensure they are as expected.
Test the application under all system states (e.g. rotation, notifications, minimized) to ensure that the behavior is as expected.
Monitor files and devices that the application uses to ensure that the behavior is as expected.
Do not use any undocumented APIs as they may change. This can cause your application to crash unexpectedly.
Final releases of applications should be compiled without debug info. Compiling with debug info can degrade the performance of the application.
For enhanced security, compile the application with PIE and -fstack-protector flags.
Applications must be fully signed before publishing to BlackBerry App World™.
Applications should have their own icon specified.
The use of PPS objects with the Native SDK is not supported and will not be supported in the future. Do not directly manipulate PPS objects. Use the APIs provided in the BlackBerry Platform library.
Applications must not use the direct filesystem path (ex /account/1000/...). All paths have to be relative to the sandbox (ex ./shared/... or ./app/...).
Application binaries must be built for the armle-v7 target. This is the architecture used by the PlayBook device. Note that the simulator is x86-based.
The above list is not exhaustive but provides a good base of common issues to avoid. As with any system, the best way to know that your application works to its optimal capacity is through testing. The closer your application conforms to best practices the less likely it will be to experience issues.