Developing and Deploying Java Applications for BlackBerry Making Sense of it All Eric GiguèreSenior Software Architectgiguere@ianywhere.com
Overview • Understanding J2ME in general • The BlackBerry perspective on J2ME • Gathering the necessary pieces • Programming tips • Moving beyond the BlackBerry
About iAnywhere iAnywhere is the acknowledged leader in mobile databases, mobile middleware, and mobile management
About Eric • Practicing software developer, extensive experience with mobile platforms and with all kinds of Java-based technology • Author of three books, including the first book on Java 2 Micro Edition -- over 5 years of J2ME! Don’t buy these, they’re way out of date!
A Question Q: Why did the chicken cross the road? A: She was too busy browsing her AvantGo channels on her BlackBerry. Point your BlackBerry Browser to:rim.avantgo.com
At the Sybase Booth • Visit the Sybase booth in the Solutions Showcase for a demonstration of the new MobiLink Client API • Sync relational data down to the device and back • SQL Server, Oracle, DB/2, ASE, SQL Anywhere • Ask for Liam • Or talk to me after the session (my code)
Understanding J2ME • Java 2 Micro Edition (J2ME) is an umbrella term for a set of Java technologies created to run Java on less capable devices • Key concepts of configurations, profiles and optional packages: • configuration = VM + runtime classes (horizontal) • profile = domain-specific classes for building standalone applications (vertical) • optional package = domain-specific classes that expose specific functionality but not applications (horizontal or vertical)
Configurations • Only two configurations defined: • Connected Limited Device Configuration (CLDC) • Connected Device Configuration (CDC) • CLDC is a stripped-down VM and runtime environment • no finalization, no reflection, only a few classes • CLDC 1.0 didn’t even support floating-point • CDC is a superset of CLDC • full language and VM support • a much broader set of standard Java 1.3 classes
Profiles • Profiles built on the CLDC: • Mobile Information Device Profile (MIDP) • Information Module Profile (IMP) • “Headless” MIDP (no UI) • Profiles built on the CDC: • Foundation Profile • Personal Basis Profile • Built on top of Foundation Profile • Personal Profile • Build on top of Personal Basis Profile • The transition profile for the old PersonalJava
Optional Packages • Many released or in development, some examples: • PIM Optional Package • File Connection Optional Package • Wireless Messaging API • Mobile Media API • Problem: not every device supports every optional package
Who Does All Of This? • All J2ME standards are developed using the Java Community Process (JCP) using formal Java Specification Requests (JSRs) • JSRs developed by an expert group (EG) representing the J2ME community at large • RIM is on the EGs for several of the important standards • For more info, see http://www.jcp.org
BlackBerry and J2ME • BlackBerry devices (Java-based) run MIDP and CLDC • MIDP 1.0/CLDC 1.0 for 3.6/3.7 devices • MIDP 2.0/CLDC 1.1 for 3.8/4.0 devices • Custom Java VM • Additional APIs available • Some optional packages • Many BlackBerry-specific APIs (vendor extensions) • Built-in apps written in Java • RIM eats it’s own food
Application Models • MIDlets • Applications built using MIDP application lifecycle and user interface classes • Portable to other platforms unless BB APIs used • BlackBerry applications • Standard “public static void main( String args )” entry point • Tied to BlackBerry, but more control over the application • BlackBerry-specific UI classes • Can run in background (no UI), on startup, etc.
How Applications Are Built • Classes are compiled as usual • CLDC requires a separate preverification step • Output then transformed using RIM tools into a .COD file that can be installed on the device • Applications can be loaded directly through BlackBerry Desktop Manager, the javaloader tool, or wirelessly via over-the-air (OTA) provisioning
How Applications Are Built • Standard tool is the Java Development Environment (JDE) • integrated editor, debugger • Can also use Ant with Antenna tasks • See http://antenna.sourceforge.net • Eclipse also possible using Ant+Antenna • Getting the classpaths right can be tricky • See http://eclipseme.org for the EclipseME project
BlackBerry APIs • Rich set of BlackBerry-specific classes • Utility classes to deal with missing J2SE classes • Different UI model than MIDP • Encryption classes • A persistent object model loosely patterned on Java serialization • More communication protocols, not just HTTP • Many APIs require your app to be signed
Gotchas • Occasionally classes are documented but not implemented until someone pesters RIM • Only documentation is from RIM • Javadocs needs some work, lacking many details • The only BlackBerry books available so far are about using the device or making blackberry wine. • But at least one BlackBerry programming book is coming • Pester RIM for better docs and tool enhancements!
Getting Started • Download the JDE from http://www.blackberry.com • Versions for 3.7 or 4.0 • If you’re going to target 3.6 or 3.7, use JDE 3.7 • You’ll also need Java SDK 1.4.2 • http://java.sun.com/j2se/1.4.2/download.html • New to Java? Find some old books • Ideally covering Java 1.1, not 1.2 or higher • You won’t get seduced by all the new classes, especially new 1.5 features like generics and enums • But important concepts like inner classes are covered
Do You Need a BES? • RIM ISV partners can purchase a BES for development purposes • useful for testing apps • can enable things that corporate BES disallows • and for understanding how things are done • IT may raise concerns • not that easy to setup • don’t forget a mail server is required • Exchange needs its own NT domain
Code Signing • Most “interesting” APIs protected, app won’t run on device without being signed • But you can run them in the simulator • Signing requires certificates obtained from RIM • Small fee ($100) involved • Certificates needed for each build machine • Signing is an online-only process • Communicates back to RIM • Certificate owners gets email every time
Reduce, Reuse, Recycle • Don’t create lots of objects • Garbage collection eats up CPU time • Can run out of object handles • Look for opportunities to reuse objects • Invariant classes good in theory, but more realistic to allow changes • Remember arrays are objects!
Use Threads • Always do I/O operations on an application-defined thread • Don’t block the system event thread • Not only slows things down, but may also cause the app to freeze as system tries to prompt user for permission • Java threading mechanisms are quite good • Take the effort to learn them • Good book is Concurrent Programming in Java by Doug Lea
Keep Applications Small • Don’t go overboard with inner and nested classes • Think carefully about class interactions and dependencies • Can you get away with using a built-in class instead of your own?
HTTP or Sockets? • If you’re using MDS, sockets are a great option • Can also open a server socket and listen for data to be pushed to your app • Extra complexity of defining your own protocol • For non-MDS, HTTP is the best • Easier to get through the firewall • Support varies greatly by carrier, though • HTTPS may also be available • Easy to write servlet that shares the same data classes (Java on both ends)
Start the MDS Simulator! • If you’re doing network I/O, remember to start the MDS simulator before you run your app in the device simulator
Moving Beyond the BlackBerry • Non-BlackBerry J2ME devices becoming more powerful • Still mostly consumer-oriented • In the future, more will be running the BlackBerry environment (BlackBerry Built-In) as well • Your BlackBerry apps will work on BlackBerry Built-In without any changes • Things you take for granted in an MDS environment are not there • Have to get through the firewall • Not as secure
MIDP-Only Is One Option • You can write an application that only uses APIs from MIDP and perhaps an optional package or two • Application gets packaged as JAR file and an accompanying JAD file • Will run on most J2ME-enabled cellphones • Except that there are many buggy implementations
Other Option: Split the Source • Alternatively, build two different apps, one for BlackBerry, one for MIDP • Split code into three parts • One common (no BlackBerry APIs, no user interface) • One for BlackBerry • One for MIDP • More complex code due to use of factories and more interfaces and abstract classes