Win a copy of Rust Web Development this week in the Other Languages forum!

Carol Hamer

author
+ Follow
since Sep 17, 2010
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Carol Hamer

If you use any methods from the restricted API, you can't test the app on the device without signing it. In order to test it without signing it, you must remove all calls to restricted functionality. (The restricted functions are marked with a lock symbol in the JavaDoc).

Sometimes there are alternate functions you can use to replace a restricted function, but in most cases you'll probably have to sign the application. It really isn't that complicated to get the signing credentials, and you'll need them if you intend to sell your app.
11 years ago
So, you want it to work such that if you type the <ABC> key once, it gives "a", twice in a row gives "b", and three times gives "c", right?

I suspect that you would have to implement this behavior yourself if you're implementing your own text field.
11 years ago
If it's just a form, you could potentially just create a web page and have people access the page from the BlackBerry's browser, without installing an app on the BlackBerry smartphone.

If it really needs to be a whole application (and the data transfer is just one of the features), then it's a bit complicated to explain in a single comment (though I guess from your other thread that you're already making progress). The BlackBerry JDK comes with sample code for making http connections. Also, I talked about making HTTP connections in Chapter 9 of my book (including sample code).
11 years ago
To narrow down exactly where the problem is, I'd recommend the following tests:

1. Try accessing your servlet from a browser on the BlackBerry. If the servlet is accessible from IE on a computer but not from the BlackBerry's browser, then it's probably a network-level problem. (For example: the mobile operator may have restrictions on accessing non-standard ports via HTTP).
2. If you can access the servlet from your BlackBerry's browser, then try a test MIDlet -- with the same code -- but have it load another URL (one that you know should work like Google or JavaRanch). If you still get an exception, then the problem is the MIDlet code.
11 years ago
I don't see anything wrong with the code. The fact that it works on some devices and not others is quite interesting -- it may be that the handset has a bug. Does the same handset have problems with adding commands to other Items?
11 years ago
RIM has some APIs that extend the MIDlet user interface APIs -- I would start there.

Have you tried using net.rim.device.api.lcdui.BlackBerryCustomItem? The JavaDoc says "This class extends the functionality of the javax.microedition.lcdui.CustomItem class to include full touch support."
11 years ago
Look in net.rim.device.api.ui.Keypad, especially getHardwareLayout()
11 years ago
p.s. here are a couple of blog entries that give examples of points where I learned something from the device that didn't show up in the emulator: Experimenting with BlackBerry Graphics! and The BlackBerry Red Key!
11 years ago

Nikos Pougounias wrote:Do you think having a real device from the first place is an essential part for game development in BlackBerry?



Yes, I do. The emulators are good for most of your development cycle, but there are unexpected behaviors that will only show up on the actual device.

The same is true for other mobile devices. You need to have at least one representative device. There are important technical issues (especially, but not confined to, network communications) that will only show up on a target device.
11 years ago
Sure, why not? Just because you select a phone that's optimized for business doesn't mean you're all business. Everyone knows executives like toys (maybe a golf game? )

Also note, many people have a BlackBerry because their work requires them to (or gives them one). A company can place security restrictions on company devices to prevent people from loading third-party apps on the device, but they don't always do it.
11 years ago
As you move towards later and higher-end models, BlackBerry smartphones increase in capabilities -- but RIM has done a good job of making higher-end devices backwards-compatible.

The differences in the API correspond to the different BlackBerry OS/JDE versions (4.2, 4.6, 5.0, 6.0, etc.). I'd recommend that you download various JDE versions, look over the specs (or JavaDoc) and decide which is the lowest one that has all of the features you need for your game. Then just program for that one -- your game will run on all devices that have that OS version or higher.

Aside from that, the one separate customization you might consider is a separate version for touchscreen models.
11 years ago
MIDP wasn't designed with smartphones in mind -- it was essentially designed for (somewhat lower-end) mobile phones.

One of the main problems with MIDP is that the user interface API is totally inadequate. The standard lcdui widgets give you almost no flexibility over the look-and-feel, and the look-and-feel they give you is ugly and unprofessional-looking on most devices. For a professional MIDP application, you generally have to implement your own widgets by drawing them onto a blank canvas (which means you have to do a lot of per-manufacturer customization). Plus, the UI is not the only place where the API is like that. It's designed to be simple for the lowest-common-denominator without giving you flexibility for higher-end devices. RIM's proprietary APIs give you easy access to everything the BlackBerry can do.

It's convenient that RIM supports MIDP in case you want to write one simple MIDlet that runs on BB and on other phones. But when programming an app just for BlackBerry, I would recommend going with the RIM APIs every time.
11 years ago
Just to clarify: You're writing this as a MIDlet, and not as a CLDC application? So your custom text field extends javax.microedition.lcdui.CustomItem instead of being a net.rim.device.api.ui.component? Is there a reason you're using the MIDlet API instead of using RIM's user interface classes?

It's probably simpler to use the net.rim.device.api.ui classes. In that case you can implement your custom field's onFocus and onUnfocus methods to show and hide the virtual keyboard (net.rim.device.api.ui.VirtualKeyboard).
11 years ago
BTW, I say "as far as I know" because I haven't gone over all of the specs for the new version (6.0) yet. Logically they ought to provide an API to allow you to securely connect to BlackBerry App World and bill the user's account (showing the appropriate warning message to the user). If they haven't implemented such a thing yet, they should.
11 years ago

Felipe Andrade wrote:sorry, what do you mean when you talk that we have to implement the billing... Is there an App World API to help developers get payments directly from the app?



I haven't seen one. If you want to sell the app or the license keys through BlackBerry App World, then BB App World will handle the billing. On the application itself (as far as I know) they don't have an API to help you with automatic billing. But you have standard options like SMS, plus it's not hard to integrate with a browser and redirect the user to PayPal, etc.
11 years ago