Hi I have been working on a blackberry app and developed about 90% of the app .But my client wants the app should work on blackberry touch also. So I just wanted to know what changes I will need to do to convert the same code to work on blackberry touch .Please help me I am new to Blackberry app development .
Just to confirm, we are talking about a Java application running on BB7 or earlier OS.
The short answer is, it depends.
If you have used standard RIM controls (buttons, ObjectChoiceField etc.) then these will work on the touch screen with no change. If you have used your own controls, for example an image button, then these might not work very well - for example the button might not be big enough to be hit easily with a fat finger.
The other problem is the virtual keyboard, it may appear at points when you do not want it to and not appear when you do. Not a problem on a lot of phones, but remember there are at least 2 non keyboard phones out there, so the Virtual keyboard is the only option for typing.
The best approach is work through each of your screens and try them in the Simulator. Zoom the Simulator so that it looks like the real device. And pretend you are using a finger, don't rely on the mouse because you can position the mouse very accurately.
I would raise new questions about specific Fields that you have problems with, rather than continue this with any issues you find.
Related
There is a problem with the sprite animation on the homepage of one of my clients, but it only appears when the site is viewed on an iOS device, namely an iPhone or iPad. I can't replicate the problem on any other device or emulator, so I'm having an issue troubleshooting it (don't own an iPhone or iPad). The problem is: what looks to be a 1px line is appearing on the right edge of the animation frame pretty much all the time, and a similar line flickers occasionally at the top of the frame as the animation runs. The animation itself is a simple javascript sprite sheet animation. I'm operating under the assumption that I have the sprite animation programmed correctly since it appears correctly on every other device, platform and browser I've checked. It even works in IE.
Two questions:
What would cause a simple sprite animation to display differently when rendered by iOS?
As a small business consultant, I don't have the time and my clients don't have the budget for me to physically test on every single device, so I have to rely on emulators. What other options do I have if the emulators don't properly demonstrate what the device will display?
I'm not entirely sure of the protocol regarding posting a link to my client's production website, but happy to send a link to anyone willing to help that responds and/or messages me.
welcome to SO.
I spend a lot of time working specifically with iOS on the web and have run into similar situations. Without tweaking an example you post I won't be able to prove it exactly, but this should at least give you direction.
Flickering or semi opaque lines are often caused by the scaling set to the asset. In the world of high DPI displays and fluid layouts, there are differences in rounding that result in fine lines, shimmers, et al. Is there any scaling set on the assets, e.g. background-size, downsampling?
The emulators are displaying the software correctly - these issues are a result of hardware. Best thing you can do is buy a flagship for all of the platforms you test on, or look into local resources like Clearleft's Device Testing Lab
I have a website that I would like to be iPad compatible. However, I use Windows, so I can't install the official emulator.
I tried iBBDemo2 (http://code.google.com/p/ibbdemo2/) which looks good, but it uses regular mouse events instead of the touch events (so I can double click with my mouse and fire a dblclick event on an element... which in this case would just cause a zoom to occur on a real iPad)
Is there any way at all to test this?
Have you tried Ripple emulator? It is a very useful chrome extension. It has accelerometer support and other features.
The link is here.
I don't know if really solves your problem, but you can try it for free.
I am implementing camera application using then example comes with blackberry plugin for eclipse named "CameraDemo" the problem is that when the screen loses focus It does not display the camera view istead of it shows like this
has anybody faced such problem whats the solution?
This way of taking picture (using the Player and VideoControl.getSnapshot()) does not work nice on all BB models. I'd even say it works nice only on a narrow set of BB models. So if you are going to use your app on a wide range of BB models, then this is not the right way to go.
Instead to take a picture use a built-in Camera app. Here is a starting point on how to do that.
Basically you invoke the built-in Camera app and listen for the file-system changes to detect a new image file path. Then you need to close the built-in Camera app somehow - it's possible to do that by simulating two 'Esc' button presses.
Yes, this sounds a bit hacky/over-complicated, but that's how BB engeneers arranged that for us. :) BTW, this is actually not so bad if compare with Android where different device manufactorers violate the common rules and implement the Camera app in their specific way so you are not able to write the code once covering all Androids.
What commonly expected user-visible design idioms need to change from an iPad app to a Mac app for an app, that is to provide basically identical functionality, to seem at least reasonably Mac OS X native?
Some of these changes, commonly expected by users, might include:
Move the Settings button and Info button to Menu selections for Preferences... and About...
Move the Settings view and Info view or popover to their own independent Preferences and About windows instead of being views in the main window.
Add some menu items and menu keys for commonly used buttons (like the forward and back buttons in a browser).
Support arrow keys for scrolling any custom view items.
Support mouse-over for help popups or dynamic menus.
If the app supports "documents", allow more than one document to be open at a time, each in their own windows.
What else? What's the minimum change required for a simple generic 2D game?
Added clarifications:
Note that I do not consider re-coding similar UI classes to NS classes (for instance UIButtons to NSButtons), with similar look, positions and behaviors, to be a significant change. Those changes are pretty much invisible to the user.
The goal is to change as little as possible so that a user who purchased app X to do Y on an iPad might purchase app X to do Y on their Mac, as a Mac application, but with as close to zero learning curve as possible. But it seems that some changes need to be made, or the app would not seem to be a Mac app (for instance, a missing About... menu item would seem a bit strange.)
to provide basically identical
functionality, to seem at least
reasonably Mac OS X native?
You've gone off the rails right there. Consider adding this to your list:
Forget everything you know about how your iPad app works. Step back and consider that a user's interaction with and expectation of a desktop application are very different from those of a tablet. Re-think what you're able to do and what the user will want to do with a faster processor, more power, significantly more available storage, less mobility, much faster text entry, and a different user interface model.
We are in the same boat and faced the same question.
Our conclusion is to start with a "fresh" real application for Mac and make it look similar, i.e. using the same or similar UI components and graphics. The app should be otherwise developed as if there was no iPad version.
First, there will be many users that don't have the iPad version. Those users expect a full-blown Mac application and it doesn't make sense to make it feel iPad in any way.
Second, users coming from the iPad version will feel ripped of if the Mac app is just a pure clone of the iPad version with no added value. Think of the first transitions from iPhone to iPad - paying again for nothing but pure upscales is frustrating and might harm your business in the long run.
Starting out designing a fresh streamlined UI and then think of what you can reuse and make similar. Functionality may differ in one direction or the other. Your model code should work in all places anyway.
Not exactly an answer to your question, but take a look at Chameleon. It's essentially a port of UIKit to the Mac. It was created by The Icon Factory to make it easy for developers to port their iOS apps to the Mac. IIRC Twitterific was ported to the Mac using Chameleon.
So here's what I did to create a Mac app from an iPad app, and have it accepted into the Mac App store.
Ignored the suggestions to completely redesign the app (users reasonably liked the iPad design).
Create a Mac app project and include a branch of all the iOS source code.
Manually recode all the UI elements with their corresponding NS elements. Resize them to Mac UI guideline sizes. Check that they all show up in some reasonable place when the main window is resized. Deleted iPad only delegates, such as rotation handlers, etc. This resulted in completely new view controller code, but almost all the code was just a parallel translation of the other paradigm.
Set the view coordinates to flipped so the Y coordinates won't have to be recalculated for any Core Graphics drawing routines. (The Model and CG drawing code pretty much ported straight over without change, except for scale factors for window size, and such.)
Remove settings and help views from the main window view controller(s). Implement a Preferences window xib and a Help window xib, and put all the settings and pref views and controls there. Add one more top level controller to show/hide the 3 windows.
Add some menu selections with hotkeys for equivalent UIButton actions that a user might want to hit without reaching for the mouse/trackpad.
Add a credits.html file.
Add an outline shape and transparency masks to the icon design, and stuff into an .icns file.
Pad the one window screen shot out to the much larger required size.
RIM has released a new Blackberry JDE4.7 after releasing the Blackberry Storm. Does the Blackberry storm support programs created using the previous versions? I've heard there have been a lot of changes in this version compared to the old ones.
And there have been complaints about Storm having many bugs.
Should I use 4.7 or keep using the older JDE?
Thanks.
Depends what you want to do. You'll actually get the rotation for free if you've designed your application's layout to be fairly resolution independent. When the device is rotated your layout and sublayout methods will be called again (or if you've just used built-in fields and managers, it's all automatic).
The big things you'll need the 4.7 JDE to do include:
Responding to specific touch events
(events which result
in e.g. focus going to a Field, or
scrolling, are automatically mapped
to the older APIs)
Detecting device
orientation (though again, layout is
already taken care of - this is more
if you want to use the accelerometer at a low level
to e.g. control a game or something)
Bottom line: backwards compatibility is in general very good, RIM has mapped the new touch interface to older APIs in a sensible way, and since the Storm hasn't quite taken off as the iPhone has (most people believe that the Bold and Curve are still better devices), stick with an older SDK unless you're doing a very Storm-specific application.
The Blackberry Storm should support programs created using the previous versions. Occasionally, though, programs will break, whether because of a bug in the new version or a now-fixed bug in the old version.
There had to be a lot of changes in the 4.7 API to support the Storm's new features.
Really, though, you should develop with the lowest JDE you can get away with, to avoid forcing people who might otherwise try your program to update first. On the other hand, of course, if you want to do a rotating interface, you're going to need the 4.7 JDE and the Storm.
Developing with 4.7 does have some issues if you've made any changes whatsoever to the way input is handled. If you've made any custom fields, you'll need to update them and have a different build for 4.7 vs < 4.7. There are more methods on fields, for example moveFocus(int x, int y).
If there's any text input anywhere, you're going to have to ensure that the virtual keyboard doesn't cover up or remove from view anything you need to be visible.
The autorotation of views is also sometimes an issue if you've done something manually on a screen and you don't want that to change during runtime, in which case there is a way to force the application into a particular orientation.
I've also noticed some issues with the simulator at least, when using GaugeField objects, that is, if you focus on a GaugeField, the focus cannot be removed. Not sure if this issue has since been fixed or what, but at least that's the way it is with my simulator.