Where does Xcode download and install its simulators?


I need to fire off a quick tip before I go to bed tonight. I was stuck on a bad build of an XCode Simulator and I wanted to reinstall it. (Sometimes the downloaded sim is corrupted. This is common in the beta/pre-release builds of XCode.) I had downloaded and installed both 8.4 and 8.1 simulators. Hi, I’m Cliff. You’re here reading this because you suck at uninstalling Simulators in Xcode.

I had the worst luck trying to remove what I’d downloaded and installed. First I tried drilling into the Xcode.app folder to find and remove the downloaded simulator here:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/PhoneSimulator8.1sdk
However, after restarting XCode it still “thought” the simulators were downloaded. I even tried deleting the cache folder here:
~/Library/Caches/com.apple.dt.Xcode
But I had the same results after restarting. The actual path to the downloaded and installed Simulators (since version 6.x) is:
/Library/Developer/CoreSimulator/Profiles/Runtimes

Talking Web Views


You got this one web view with Javascript and you want to talk to Javascript running in another web view, for reasons that I’m totally unsure of. Maybe you want to impress the girl in the coffee shop with your hard core coding expertise. Maybe you wanna go for a promotion and your manager is all like, “I need to see you innovate!” Maybe you think it’s just cool to load two web views that know one another. Hi, I’m Cliff, you’re here because you want to tote two web views. I’m here to show you how it’s done.

I haven’t posted anything in a month of Sundays. I never understood why people use dumb phrases like “a month of Sundays”. If there were only Sunday “days” in the month then it would be kind of short because you only get four of them… and that doesn’t seem like it makes much sense. I say that because people use that phrase to indicate long elapsed periods of time and a month of Sundays is only four days. People should just get over themselves and say I haven’t seen you in four days without all of the, “I need you to do the Maths and figure out what I’m talking about”. People are dumb. I digress.

I was beginning to tell you about this thing I’m doing with web views. I did it because I’ve been asked how to do it like two times. I got tired of pretending to know what I’m talking about so I prototyped it and I’m going to post my stuff here and just point to this page from now on. Plus, like I said earlier it’s been a month of Sundays (or four days if you don’t like Maths). So here goes. For those three of you who visit regularly I’m sorta back but not quite. Testing the waters a bit.

Back to these talking web views… the idea is simple. a mobile app with Javascript in one web view makes something happen in a second web view in the same app. To make it work you need to know two things, how to call from Javascript into native code and how to call from native code into Javascript. Tonight’s example will demonstrate how we will demonstrate how this is done on Android but I can show the same example on iOS.

Let’s start with main layout saved in a file call main.xml

<?xml version="1.0" encoding="utf-8"?>

<FrameLayout
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    xmlns:android="http://schemas.android.com/apk/res/android">

    <LinearLayout
        android:orientation="vertical"
        android:layout_width="fill_parent"
        android:layout_height="fill_parent">

        <WebView
            android:layout_width="fill_parent"
            android:layout_height="250dp"
            android:id="@+id/myWebView"
            android:layout_gravity="center"/>

        <WebView
            android:layout_width="fill_parent"
            android:layout_height="250dp"
            android:id="@+id/secondWebView"/>
    </LinearLayout>
</FrameLayout>

We have a linear layout set to vertical orientation. There are two nested WebViews defined, “myWebView” and “secondWebView”. Each will appear one above the other. Next we define a main activity.

package com.example.JavascriptBridge;




import android.app.Activity;
import android.os.Bundle;
import android.webkit.WebView;




public class MainActivity extends Activity {
    /**
     * Called when the activity is first created.
     */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        WebView myWebView = (WebView) this.findViewById(R.id.myWebView);
        myWebView.getSettings().setJavaScriptEnabled(true);
        //Magic Javascript handling class to be defined later
        final JavaScriptHandler scriptHandler = new JavaScriptHandler(this);
        myWebView.addJavascriptInterface(scriptHandler, "MyHandler");
        myWebView.loadUrl("file:///android_asset/view1.html");
        WebView otherWebView = (WebView) this.findViewById(R.id.secondWebView);
        scriptHandler.setRelayWebView(otherWebView);
        otherWebView.getSettings().setJavaScriptEnabled(true);
        otherWebView.addJavascriptInterface(scriptHandler, "MyHandler");
        otherWebView.loadUrl("file:///android_asset/view2.html");
    }
}

We set Javascript enabled on both views. We have a magic Javascript handler class which we will define next. This is a custom class which we stuff inside the first WebView using the addJavascriptInterface() method on the WebView class. This method makes ordinary Java objects appear as Javascript objects to code running inside a WebView. (We will soon add Javascript code that makes calls on the magic class.) Next we load an HTML file, “view1.html” into our first view. We grab our second WebView and give it to our JavascriptHandler which will relay information from the first WebView. We setJavascript enabled on the second WebView and put our magic JavascriptHandler object in it as well, just for good measure. We load view2.html as the content for the second view.

Let’s see our first HTML file, view1.html:

<!DOCTYPE html>
<html>
<head>
    <title>Javascript Bridge</title>
</head>
<script>

</script>
    <body>
        Java/Javascript Bridge example
        <form id="inputform">
            Value to pass: <input type="text" name="user_input">
            <input type="button" name="pass" value="relay!" onclick="window.MyHandler.setValue(inputform.user_input.value)">
        </form>
    </body>
</html>

Not much here. There’s a typical HTML form with an input text field and a button. The onClick() action of the button has Javascript that talks to a special object called “MyHandler”. This object was defined in the Activity above, if you recall these lines:

        final JavaScriptHandler scriptHandler = new JavaScriptHandler(this);
        myWebView.addJavascriptInterface(scriptHandler, "MyHandler");

The handler, which we’ll define next, exposes a setValue method. We call this method and supply the value from the earlier input text field. Let’s see the magic inside the custom JavaScriptHandler class definition.

package com.example.JavascriptBridge;

import android.webkit.WebView;

public class JavaScriptHandler {
    MainActivity parentActivity;
    private String value = "unset";
    private WebView relayWebView;

    public JavaScriptHandler(MainActivity activity) {
        parentActivity = activity;
    }

    public void setValue(String val){
        this.value = val;
        relayWebView.loadUrl("javascript:second_inputform.second_user_input.value='" + value + "'");
    }

    public String getValue() {
        return value;
    }

    public void setRelayWebView(WebView relayWebView) {
        this.relayWebView = relayWebView;
    }
}

Inside the JavaScriptHandler custom class we have a WebView property, relayWebView which we saw used in the MainActivity. There is also a value property but inside the property set method we have additional logic to relay the value to the relayWebView property. We do this by calling the loadUrl() method on the relayWebView and passing in javascript code using the “javascript:” protocol. (When you ask a WebView or web browser to load a Url prefixed with the “javascript:” protocol is will execute any javascript included after the protocol prefix.) The Javascript assumes there is a “second_inputform” with a “second_user_input” text field and attempts to set the value of this text input. Let’s look at the view2.html which we load into the relayWebView from the MainActivity.

<!DOCTYPE html>
<html>
<head>
    <title>Javascript 2nd Page</title>
</head>
    <body>
        Passed value shows here!
        <form id="second_inputform">
            Value Received: <input type="text" name="second_user_input">
            <input type="button" name="button" value="reset" onclick="second_inputform.second_user_input.value='enter text above'">
        </form>
    </body>
</html>

Here you see the “second_inputform” with the “second_user_input” text input. So when the earlier Javascript is injected and executed you will see the text from the first WebView relayed to the second WebView. That’s the entirety of it! Since I haven’t posted source in what we used to describe as a “month of Sundays” but now understand should be much more than a four day-long month, it’s going to take me a while to figure out how to glue my example project to this blog post.

I used to be so much better at gluing code to blog posts but these days I don’t even remember how to log in to my site as the administrator. With any luck, the code will be found as an attachment or maybe something with a little paper clip icon hanging on the side bar. I’m not really sure but I’ll figure that out now. There! I just remembered the Box widget on the right hand side. You can find my Jvascriptbridge.zip project there. Until next time… which might not take an entire month of Sundays if I get my act together…

Getting one’s act together is another one of those things people say. I’ve never acted nor do I belong to a drama club, so I would have a hard time getting my act together. For example, if I had an “act” how did it become disassembled in the first place? I would imagine various pieces of what would have been “my act” scattered randomly on the floor. I would probably hire somebody to piece it back together because I suck at act assembly. That would take a while because last time I looked in the Yellow Pages there was no section for “Act Assemblers”. I could find “Plumber”, and “Doctor” just fine. “Mechanic” was there, as well as “Actor” but not “Assembler”. It’s late, and I probably should go now. If you’re into programming stuff, check back. I promise I won’t ramble senselessly on my next post… unless you like my rambling. And if you do like it maybe I’ll put up one of those PayPal links so people can pay me for rambling. Yes it’s late. I should do other stuff like sleep. Thanks for reading! 🙂

How to get images in your cod for Blackberry


Such a painful problem it is to create Blackberry software from anything other than their proprietary JDE. There are options, however. There’s some blackberry Ant tools (an independent project and also there’s a few things in the Antenna project). Then there’s RIM’s rapc docs, which aren’t too informative. Finally there’s the post I made a while ago detailing some of the inner workings of rapc. In the post and also in the comments I hint at ways to get images and other resources into the final cod file. To save you the pain of reading there I’ll write about it here. Once you figure out how to compile with RAPC and at least get a working cod file, you need to compile again. The trick is to pickup the jar file that RAPC creates next to your cod and stick images and resources in there. Finally, remove some rapc generated .csi and .cso files before you pass the jar back to rapc. (If you forget to remove these files rapc will complain and list them in the error output, though you might not understand what it’s trying to tell you. Just know if you get an error recompiling jar and you see mention of a file ending in .cs-whatever that you’ll need to remove the file(s) in question.) Here’s some pseudo-code since I’m too lazy/busy/uncertain/tired/vitamin-B-deficient/loaded-with-excuses to post the real solution:

call rapc net_rim_api.jar -midlet -codename MyApp MyApp.jad @myJavafilesList.txt
updateJar MyApp.jar (use images/resources)
removeRapcFilesFromJar MyApp.jar
call rapc net_rim_api.jar -midlet -codename MyApp MyApp.jad MyApp.jar

How to use rapc from RIM… dirty details!


What’s really going on in rapc, Blackberry’s crazed compile tool? Let me begin by telling you that everything you’ve read until this point is not entirely accurate. There are those that will tell you that you have to run preverify.exe prior to running rapc. Then there are those who will tell you that the bb-ant-tools are sufficient. There are people that complain that the RIM compiler has bugs in it. (This may be true but I’ve so far been able to fix broken builds by using all of the advice I’m including here.) I’ve also found a blog that claims you can build from non-Windows operating systems. I’ve read in some places that either WTK or the JDE must be in the PATH so that rapc can find a preverifier. While some of these tips, tools, tutorials work they all have limits. Eventually you’ll find your application either throws random NPE’s, verification errors, or infinitely reboots the device! Now pay attention!

Now let me explain my project. I have a little bit of dependency injection going on via source generation. Then I also have some external jar dependencies. All of this creates a bit of a challenge for basic rapc invocation. In order to generate my midlet cod file I need to:

  • Run a source generator
  • Include the generated source in my list of things to compile
  • somehow include my external jar dependencies in the compile.
  • Include resources in my compiled output
  • Pick up my suit from the cleaners
  • Get the entire thing to run on my Mac?

While the last bullet is entirely optional and irrelevant, I include it because its the only way to get completely familiar with rapc. That is, if I can meet/greet/beat the challenge of cross platform compilation of Blackberry then I’ll really understand the intracacies of compiling with rapc. Now onto the juice.

How Rapc works… I think…
There are various approaches to compiling Blackberry applications that I know of.

  • Compile your app against the MIDP and CLDC APIs (include either WTK or MPowerplayer or someother party’s midp and CLDC jars on your bootstrap classpath for javac… making sure you use javac1.3 or below), preverify with JDE preverify.exe (found in %JDE_HOME%/bin), jar and finally compile with rapc.
  • Compile your application source files entirely with Rapc.

The first option has problems because there’s the possibility that javac will generate class files that will cause verification errors or (as my team discovered recently) the white screen of death when loaded onto the device. The second option has problems because it’s very tricky and prone to the same errors unless you are very dillegent. It took a lot of head banging and trial/error to come up with these details so read closely.

How do we use rapc? This is the question that still plagues me. There’s little documentation around the nuances you’ll encounter when invoking the rapc compiler from the command line. The rapc compiler is an executable (.exe) file in the JDE install directory living under the bin subfolder. First thing to note is the rapc.exe just delegates everything to rapc.jar. That means the same exact command line parameters you would use with rapc.exe will work with rapc.jar. (Call the jar with the “java -jar” command.) The most important thing to understand is that you cannot mix and match. That is you cannot use the output of javac/WTK preverify to fuel rapc. Furthermore you need to pay strict attention to the version of the JDE you use because it must be the same (or earlier) version of your target platform. For eg., if you intend to target Blackberry devices running a 4.2.2 OS you should use the compiler tools from the JDE version 4.2.2 or earlier. If you don’t pay attention to this step your product will work just fine until it’s time to ship… at which time you’ll experience weird, impossible to track/reproduce on a developer workstation, errors. There are other important tools in the JDE that you’ll need as well. The preverify tool is required (unless you’re using JDE 4.3.0 and targeting OS 4.3+) as well as the SignatureTool.jsr. Finally there is the net_rim_api.jar which lives under the lib folder in the JDE install directory. The next big thing to understand is the command line options.

import
Use the import= to specify the location of the net_rim_api.jar. This flag takes the relative or absolute path of not only the rim APIs but any other jar or cod dependencies your application has. (I haven’t tried cod dependencies but the docs say you can list cod files.) Be careful because this is only for resolving dependencies. Anything you list here will not be included in the final output cod. What this means is any jar files listed here must either be compiled as separate cod libraries or their source files somehow inlined in the final compiled. Dependencies listed here are scope as provided. In other words it is assumed they will be made available at runtime by either the RIM platform or by some pre-installed package.

codename
(codname for 4.3.0+)
This parameter threw me for a minute when I attempted to roll back to an earlier version of the RIM compile toolchain. I believe (and I need to double check and update this fact later) that rapc version 4.3.0 and higher expect a codname flag while versions prior to 4.3.0 expect a codename flag. The value you specify here will be the value used in the output codfile name. Paths can be relative to the working directory (the folder rapc is called from) or possibly absolute paths. For instance if you give build/MyApp as the value then rapc will spit all of its output into the build folder relative to the working directory giving you a final MyApp.cod file there. (you’ll also have MyApp.jar, MyApp.csi, MyApp.debug and other files in this folder.)

midlet
This is the application type. Use this flag if you plan to develop a J2ME spec compliant midlet. Blackberry support another application type, cldc, which provides RIM specific features (more on that in possibly another post) and is specified by the mutually exclusive -cldc flag. A You have to -midlet or -cldc to specify which kind of application you are building.

cldc
Use this flag if your are building a CLDC application that adheres to RIM’s proprietary launching interfaces. CLDC apps offer abilities to run in the background and be started at device boot time. There are other hidden gems here that I’d have to get into with another post.

jad
Use this parameter if you have a JAD file that includes your application’s meta data. This parameter is optional as you may substitue a .rapc file to include the meta data. Application meta data includes things like the icon to display on the desktop, the midlets contained in your aplication bundle, runtime properties, etc. Referr to the J2ME midlet spec for more detail.

rapc file
This would be the path to a “.rapc” file that includes meta data about your application. I’ll probably follow up with another post to explain the details behind this proprietary RIM spec. While a JAD file also includes meta data there are certain properties that can be included in this file that cannot be included in the JAD file and vice-versa.

class or java files
The last parameter should specify either a jar file containing the compiled classes or be a list of the .java files you intend to compile. Here’s where rapc gets really interesting. If you precompile your “.java” files you had better be certain you run the RIM preverify tool against these class files prior to invoking the compiler. Also I will repeat that you must use the same (or earlier) version preverify as your target platform. For eg., if you intend to target Blackberry devices running a 4.2.2 OS you should use both RIM’s rapc and preverify tools from the JDE version 4.2.2 or earlier. If you don’t pay attention to this step your product will work just fine until it’s time to ship… at which time you’ll experience weird, impossible to track/reproduce on a developer workstation, errors. (I said this before didn’t I?) Rapc is very picky here and the behavior varies between versions. It first calls out to javac assuming that the Java compiler is in the PATH. It then passes the output from javac to preverify. Note that in JDE 4.3.0 both “.java” source compiling and preverification is done from within the rapc.jar while earlier versions of rapc call out to the command line using the command “preverify” (not “preverify.exe”… this is an important distinction) and passing standard preverify parameters. Finally it creates the final “.cod” that will run on the device. What is included in the cod file depends on what is passed on the command line and what’s available from the working directory. For instance, your application icon (and I found this through trial and error) must be locatable from the working directory unless you specify an absolute path in the jad file. If you compile a jar file (not recommended for rapc prior to 4.3.0) then everything in that jar file (images, multimedia files, application resources, etc.) will be included in the final cod file. If you compile “.java” files directly from rapc then no application resources will make it into the final output cod file, only the compiled .class files will be there (along with the application icon specified in the jad if it can be found from the working directory). It took a lot of banging my head to figure this out. Finally instead of a jar file or space delimited list of “.java” files, you can specify a text file that lists (new line delimited style) all of the “.java” files you wish to pass to the compiler. This is a potential work-around to command line size restrictions that may be present on some versions of Windows. This file should be given with an @ prefix. For eg. if your have a MyApp.txt file then the last parameter for rapc will be @MyApp.txt. This is the preferred method of giving files to rapc because as your application grows so will the list of files.

One last got’cha I found was with trying to use rapc.jar directly instead of rapc.exe. If you are running a JDE earlier than 4.3.0 then you’ll get into trouble here because there is a secret parameter passed from rapc.exe that RIM won’t tell me about. Because the command line syntax for the jar is identical to the command line syntax for the “.exe” you can almost get away with it but because of a secret exchange happening between the Jar and exe you’ll get undefined behavior and weird errors in certain circumstances. This last gotcha is what makes it impossible to compile on an OS other than Windows while targeting a RIM OS earlier than 4.3.0.

In the end I’ve determined that it is not possible to accurately build a blackberry application on an operating system other than Windows. Also while there may be some truth to the myth of bugs in rapc I believe it all boils down to a bunch of nasty assumptions the RIM developers made during the design. (they assumed everyone would be so thrilled with their Swing based IDE that they would throw away Eclipse/Idea/Netbeans and burn their Macintosh laptops in celbration of the obviously superior RIM tool chain.) I do believe that if you pay close attention to the details outlined above you can diagnose most preverification and random erros you may be suffering from. I plan to revist this topic in the future as I’ve taken a break from mobile and begun work on some other things. However I do not plan to let rapc defeat me entirely. Keep an eye out because I’ll likely be updating this very same post with more details.

GMaven for Blackberry development on a Mac?


Ok, it’s been a while but I finally posted the code for GMaven-Blackberry in another blog post.

I’ve gone clear outta my mind. I’m thinking let’s build a blackberry native app on the Mac. Sure! Why not? I mean there’s only the long-standing platform incompatibilities between J2ME and OS X, the windows-oriented nature of Blackberry tools, the mismatch of typical J2ME project structure and Maven project structure and looming deadlines to worry about. And while I’m at it, throw Groovy into the mix, because everybody knows that Groovy has everything to do with writing embedded apps right?

This week I’ve bounced between a Gant build, a legacy Ant build, our multi-module maven JEE project, and brand new GMaven plugin projects. Let’s just say I’m becoming very familiar with the build process in general. Project structure is important. The build system is critical. It is at the root of every successful and failed project in history. Many problems, and resolutions to problems stem from the build/deployment system in place on a given project. It makes sense that as a developer you pay close attention to what’s involved in the building and deployment of your software. Yet soooo many people fail to understand the variables involved in the build tool chain. Many a problem can be tracked to system incompatibilities resulting from version mis-match and/or conflicts. Something as simple as a micro point release difference in your web container or JDK can cause an app to behave wildly different. (Today I tracked a bug down to Tomcat 5.0.28 on a dev box where version 5.5.25 is running in production.) The version numbers of your build tool chain is often the last place developers look when researching a problem. It is the first thing I look for when trying to isolate an issue. I digress.

With all the build tools ranging from Ant to GAnt to Maven to Gradle… (BuildR anybody?) it’s easy to get overwhelmed. I had a buddy remind me how important it is to refrain from going overboard in leading edge-multi-faceted-combined technologies. Stick with proven products yet always look for the next thing. That’s how I feel about Maven. There are alternatives some have better features. However Maven is mature and ubiquitous. I don’t have to pull in yet another runtime to build my project. I don’t need to learn yet another platform. It does its job and does it well. So well that I try to use it for all of my Java work, bringing me to my point. J2ME Blackberry development can be done with Maven. It can be done on a Mac. And at the end of my ordeal it should be painless to do on a Mac.

So why Maven? Why not Ant? The app I’m working on includes several JEE complimentary pieces and I’m sorry but I would rather not touch Ant on a web app project. No way, no how. Furthermore with JEE making up over half of the codebase Maven is the perfect solution for managing the project. We currently have it in use and we have a wrappering pom around the Ant build we use for our J2ME client. That wrapper has been a source of utter pain. So I’ve been looking to figure this out for the longest.

What does Groovy have to do with it? Well I have the Pyx4ME J2ME plugin for Maven working pretty well but there are some obvious holes. First off is a decent deployment mechanism. I need to tie deployment into the modified Antenna OTA servlet we have. Secondly there is no support for Blackberry in the plugin so somebody needs to add it. I started to write a plugin and I just knew I wouldn’t want to be bothered writing it in Java. A couple of minutes after I finished bouncing between 20 different reference articles, APIs, and PDFs and I had the beginnings of the RIM plugin for Maven complete with OS X compatibility. It’s not totally finished yet. I still have issues running the jar signing tool on the Mac. (It should run fine on Windows, and possibly Linux.) But it runs the compiler. I’ve generated a .cod file in the target folder of a prototype project. Interesting stuff indeed.

If that’s not enough, I’ve also managed to launch GAnt from within Maven! Why would anybody want to do this? Maven is become widespread like Ant. If you or your team already use Maven but you want to toy with Something else like Gant you would have immediate access. You don’t need to open your browser, don’t launch Safari, just run Gant:

mvn gant:run

That’s it! And that’s perfect for my current situation where I’m trying to spread Gant across my team. The same applies for Groovy. Don’t go to the codehaus site, just run it!

mvn groovy:console

There’s something to be said about the convenience of a one stop shop. That’s my thing for now. Stop back because I’m gonna continue to post updates on not only Groovy, but Blackberry, GAnt, Maven, maybe even Gradle if I get that far. Holla!

Debug mode on Blackberry


Shamelessly I copy something I found in the Blackberry forums. I don’t know what it means but I DO know it’s one of those things that you have to search far and wide for. Some guy wanted to get into some debug mode that I’d never heard of so he posted his question then later his own answer to the forum thread. Read the solution below:

You must:

1. Have a login/password to https://www.blackberry.com/EngineeringScreens/ (updated 5/30/2008)
2. On the BlackBerry pres ALT+CAP+H and leave it on this screen.
3. Once logged in to the link on #1, you will be asked to enter your PIN#, Uptime and Zip code of where your device is.
4. You will then receive a unlock code that is specific to this information (if you exit out of this help screen on the blackberry, the uptime number will be different thus your code will be different.)
5. Then enter the unlock code on the BlackBerry, holding the ALT key for numbers, capitals are not necissary.
6. This will give you access to the Trace Mode Engineering App
7. Select “Radio Engineering” screen
8. Select “CDMA Engineering” screen
9. Select “Operational Info” (2nd line ec/io, 3rd line rss)
10. Scroll down to “Neighbor Set Details” and get 1st line Active Pilot, 2nd through 20th will give Neighbor sites with ec/io for each.

*This code will only work for 30 days, then you will need to get a new code in the same way.

I got it!


I just ran the Blackberry compiler from Maven… on my Mac. Two cans of Pabst Ice and one Mike’s hard cranberry lemonade into my dev cycle and I finally see a “.cod” file show from a pyx4Me project! It’s in the wrong folder, project root vs. projectroot/target but I can live with that for now. Anyone know a groovy way to set the working directory from a command string run by the overloaded String.execute() method? I don’t wanna call out to Runtime.exec and I don’t wanna write a bunch of platform checks in my plugin. Right now I’m one too many drinks swallowed to know whether or not String.execute() implies platform. In other words I don’t know if I need to code a prefixing “cmd /c ” on my string and check for Windows before calling String.execute(). I’m not happy with the impl because there were a few things I wanted to do better. Right now I’m spawning a java process because the GMaven plugin doesn’t set the rootLoader, which means I can’t dynamically append to my classpath. I’ll either have to set the rapc.jar as a dependency or figure something else out. I’m just glad I got this far! More updates later…

Build Native Blackberry apps natively on a Mac… using Maven!


Click here for the Maven Blackberry code behind this post.

Aight, I can’t help it! I’ve been itching to get this done for sooo long. If you’re into Blackberry development then you’ll understand just how absurd the above title sounds. Let me just throw intelliJ Idea into the mix as well then you’ll begin to see the big picture. Starting to do J2ME development, an experienced Java guy like myself has naturally gravitated towards a certain set of tools. Maven2 is hands down the only acceptable build system for a Java project, while Idea beats the pants off of Eclipse, and Windows boxes…? Forget it! Java runs practically double speed on a *Nix OS plus with the flash of OS X there’s no question as to what boots on a typical knowledgeable hard working Java developer’s box. All of these tools work well, and most of them work well together. BUT… BUT!!! Doing J2ME implies Windows and Ant all around so there’s gonna be either a divorcing of the toolchain or a boatload of integration issues. This weekend I fought through the biggest of the integration issues. And this morning I finally managed to build a Blackberry .cod deployable program… completely without Windows… using a Maven2 pom… natively on my Mac! I’ve been updating my blog incrementally with all of the individual pieces so I won’t go into too much detail here. At a high level I’ll explain the tools involved.

  • One Apple Macintosh (iBook, MacPro, MacbookPro, MacAir, whatever…)
  • One Blackberry (Preferably not Verizon because I don’t think they support J2ME)
  • One Windows install (I know, but this is only to extract the Blackberry tools! You can throw the whole thing away once you got the goods out of the JDE downloads. If you have a buddy that already has the JDE just steal it from him and skip this piece all together.)
  • One install of the Blackberry Java Development Environment (JDE).
  • One bottle of scotch (or wine) for to celebrate with.
  • One install of Maven2
  • Two tablets of asprin (to handle the hangover after you’ve spent the entire rest of the day celebrating with scotch or wine.)

I think that’s everything in the ingredients list. I’ll post back later with the recipe as time allows.

Didn’t get far


I was trying to develop J2ME with Maven on my Mac and blogging about it at the same time this past weekend. As an update I didn’t get too far. Fow what it’s worth, I did get a jar to build and I was able to manually upload it to a web server and then install it on my phone. The app worked but I still need to work out the kinks in automating the deployment process. I’m not sure if my Blackberry supports bluetooth installs and if it does I can’t find any documentation on it anywhere. On my drive in this morning I got to thinking about going the rest of the way and building a Blackberry plugin for Maven, one that would execute rapc and SignatureTool. I’ll have to prototype that from the command line first. More on that later. Back to regular work for now.

8830 + 8010 = Hitz4Dayz!


I mentioned my new Jabra toy a while back and I’ve been meaning to include a follow up post on it. Ya’ see I’ve had this company issued Blackberry for a minute now. And I bought one of those SD mini cards, the kind that holds about 1GB but is smaller than the tip of your finger. It was the only way I knew (at the time) to put my jamz on my 8830. I’ve been rapping about MOP for a while I figured it’d be a good idea to hear some M.O.P. once and a while… without teaching my little girls bad words. So that’s where the 8010 comes in. I can put this little trinket on my right ear and stream “Downtown Swinga” Blackberry 8830while my left ear is tuned to the kids… making sure they are well behaved. The device does more than that. It pairs with multiple devices so I can use it to record audio over my screencasts on my Mac. I can also stream audio from iTunes (though for some reason Bluetooth audio from the MacBook sounds like it uses voice audio encoding which makes everything sound like it’s played over the phone… something I’m still trying to figure out….) and take a phone call right in the middle of K.R.S. 1’s “The Bridge is Over” without missing a beat. Well I might miss a few bars because iTunes will continue during my phone call but when paired to Blackberry music automatically pauses for phone calls. Speaking of calls I love the vibrate alert on incoming calls. It takes some getting used to and still makes me jump out my skin on occasion but what an un-ignorable way to announce a call! If you’re too jumpy, like I am, you can disable vibra-alert and save face in public places. (Nothing says “I’m need a straight jacket” louder than a guy paying for a gallon of Clorox Bleach and some M&Ms who suddenly decides to pull his head into his torso “Ninja Turtle” style while jamming both shoulders in his head while some indecipherable blue text appears on his right ear.)

I’ve read that the 8010 includes noise reduction but I don’t know because I’m on the noisy end. I believe my calls come through more clear but I’ve yet heard someone take notice. I don’t make many phone calls anyhow and when I do I’m almost always in one of those Sprint spotty coverage areas. I’ve also heard that it has caller id which is one of the dumbest features I could imagine on such a device. Unless you can fold your face down the center and peek at your ear from one eye I don’t understand how caller id can do anything for you. I still don’t know if mine works. Maybe if you had a girl friend or a wife with an ear fetish you’d have a clue who’s buzzing you but then again, what if you decided to cheat on Mrs. I-Love-your-ear?

The thing I like most about the 8010 is how it plays stereo with the optional attached secondary ear piece. You can stream audio in mono with just one piece but everything sounds so much better in stereo. Jabra 8010Even phone calls come through in stereo. You get that in the machine feeling when you favorite song is cranked way up then you get a call which comes through in surround sound. Tap the button to pick up the call, tap again to end the call, then tap mode then the main button again to resume Reggae ’94.

Paired with an 8830 you get the added benefit of voice dialing. I’ve been in a few situations where I need to join a conference call while driving down Route 30 and not wanting or able to pull to the side. One tap then speak, “call meeting place” give me a friendly voice prompt, “Did you say call Meat and Place?” to which I reply, “Hell no!” The follow up prompt, “Did you say call Me-Jing Prace?” eventually connects me to our conference room (the Text To Speech on the 8830 has some minor pronunciation issue that you learn to appreciate over time). That’s all for now, it’s past my bed time and I need to rest up. If you’ve had some fun with Bluetooth drop a line. I’d love to hear ’bout it.