I’m just starting black berry development using eclipse and jre version 6.0.
What would be a good black berry device used to test the apps. I went to amazon and the prices ranges between
I’m looking at BlackBerry 8530 - Verizon Wireless, Blackberry Tour 9630 Unlocked GSM Cell Phone (Black), Sprint Blackberry Curve
Will all the black berries run the app with jre version 6.0, or must I buy certin ones?
-Ted
That's a really difficult question to answer as there are so many different devices and OS versions that there is no one device you could test to give you 100% confidence across the range.
You also need to consider whether your app will/should support features that are only available on some devices, e.g. the touch-capabilities of the newer Storm and Torch models.
As a first step (assuming you haven't already) I'd recommend thoroughly testing the application on the simulators available from RIM: https://swdownloads.blackberry.com/Downloads/entry.do?code=060AD92489947D410D897474079C1477
These simulators are limited in that it's not always possible to see exactly how the app will look on the real device - but realistically you're probably not going to be able to test enough different devices yourself to achieve this.
I'd therefore suggest a two-pronged approach:
By all means get the best/newest device you can afford and make sure it looks great on that
Recruit friends/colleagues/acquaintances with BB's - as many as possible - and get them to test the app for you, perhaps in exchange for a free copy (or coffee, or beer, if that would be more appropriate)
I realise that doesn't directly answer the question, but hopefully it helps in some way.
Related
Inspired by an exchange on a recent question, I wanted to know whether there is any good reason to develop Windows Phone 7 applications that target pre-Mango models, i.e. by creating applications that target the 7.0 APIs rather than the more recent 7.1 APIs.
My impression was that because the Mango update has now been fully rolled-out, there is very little reason why anyone would have a phone with a pre-Mango OS. My guess is anyone with a pre-Mango phone probably never connects it to their computer and probably does not download applications.
Are there any good statistics on OS version demographics that can inform this decision?
I know from the analytics of my apps that there are still people out there using pre-Mango versions of Windows Phone, but as you point out, they are unlikely to be connecting their phone to their PC to perform updates or even update apps they've already downloaded (my wife for example would still be on the original shipped version if I hadn't updated her phone myself!).
With that in mind, personally, I don't see the point in creating applications now that target pre-Mango versions of the operating system. The return is highly unlikely to warrant the effort.
There isn't much of a reason to target pre-Mango as opposed to Mango as the upgrade is available to all models of phone currently, and for free.
It is worth keeping on the latest SDK for no other reason than there is no reason not to... lol, made sense in my head. Things like performance improvements, bug fixes, new features etc are all reasons to keep up with the latest, as you are likely aware.
The only reason I would target an older SDK is if a particular version of the phone OS was not available to a certain piece of hardware for any reason.
Then again, if you can make your app with the lowest common SDK, why not - it will in theory only increase your user base as backwards compatibility is enforced, over choosing a newer and not-completely-rolled-out version. You just personally suffer the older APIs and miss out on new features. However, I see this counter-point as a largely academic argument and adds little weight to the choice of older versions.
Save yourself the headache, go with the new stuff. Anyone actively using their phone enough to also use your app is likely hot on updates.
I don't do 7.0-specific programming any more since the roll out of Mango is now available pretty much everywhere I'm interesting in deploying apps. This question will rear it's head again when vNext is released (with potentially updated hardware requirements / sensors, etc), but for now I can't see much reason to target the old version.
i am new to Blackberry apps development, and see that there are lot of different resolutions of display on different Blackberry types.
is there some survey which types are most used ? which resolutions is good to support ? thanks
You probably don't need to worry so much about which specific devices you will support (unless you need specific features like touch capability). However, you do want to consider which OS version(s) to target to get the right combination of audience and feature set.
RIM provides "Choosing a target OS" with lots of good data to at least get you started.
You dont have to worry about the resolution of the blackberry Mobile Screens... We can programmitically give the resolution by checking the series of the blackberry devices...
Do you want the java code to find out the series of the blackberry mobile devices
The link that #Scott W provided is a good start in deciding which OS to support. Let me dig into this a little further, assuming you are creating an app for consumption by non-Enterprise users (delivery through App World);
As of March, devices running pre-5.0 OSs make up less than 20% of the total, and for paid apps, this figure is 10%.
By percentage, paid apps are consumed by those with newer devices than for free apps, for every OS across the board.
Keeping all this in mind, I recommend the following to you;
Don't consider targeting pre-5.0 devices, it's a waste of your time (I know, I've done this before).
Consider the time it will take you to create an app and release it (anywhere between 2 to 6 months) and imagine what the BB OS market share will look like (OS 7 will be released by then).
Start developing targeting BB OS 5.0, and if you encounter an issue whereby OS 6 provides functionality you need that is not available in 5.0 (you'll have to implement your own solution), seriously consider dropping 5.0 support or not including such feature in your 5.0 build.
If your core competencies are in Java, stick with that, otherwise, seriously consider developing in WebWorks, as that has the advantage of running on PlayBook and you'll have reusable code if you're building a mobile website.
As for devices, the Curve series is easily the most popular amongst BlackBerry's devices (as it's cheap to buy). However, if you write your UI code to be mindful of container sizes, your interface could look the same on all devices (if you want it to be).
How do you handle a bug in a specific SDK version in a released application? Say for example I've reported and received notification that a bug is known in a specific version of an SDK. Say the SDK engineers fix the problem in the next release. Do I then need to check if the user is running the buggy release and display an error message that they can't use a specific feature with a bug in it because it will crash their hardware? Is there a more graceful way? Do you display an alert and tell them to upgrade to the latest SDK? Do you completely remove the feature? Advice would be appreciated.
This is phrased to be agnostic as possible, but I am asking for the purposes of iPhone application development at this time. General answers for other platforms would be nice as well.
It depends on the nature of the bug and on the nature of the platform. With the iPhone, for example, you cannot just tell the user to upgrade his or her phone. If your goal is to support iPhone version X.Y, then you will need to support the corresponding SDK; whereas, targeting browser X version Y.Z or Java version X.Y, it may sometimes be acceptable to tell users to upgrade.* Giving the impression that your application can do something only to give an error message saying that it cannot support it for that version of the platform does not make for a good user experience. If possible, try to work around the deficiency in the platform (by possibly reimplementing code that supposedly works in the SDK) and provide the feature to the user. If that isn't possible, then disable it when running on the deficient version of the platform, but be sure to remove all traces of that feature from the application (so that users don't click on a button only for it to tell them that the button is completely useless). I should add that conditionally enabling/disabling features is only sensible in the case where the feature is not essential to application; if a feature is a core aspect of the application, then you'd better find a workaround or raise the minimum requirements as it would not be appropriate to ship a deficient application to your users.
*An example where telling users to upgrade is not reasonable would be business applications, since business sys admins tend to be unusually lazy and users have no power to upgrade by themselves.
I am developing a Netflix application for BlackBerry mobile devices. I need to make a decision as to the minimum OS version that I should develop for - depending on which I choose will have some design impacts (such as what browser field classes I can use, etc.)
What it comes down to is..should I support anything lower than OS 5.0?
I would say 4.5 and newer. see also:
OS - What market share do each of the BlackBerry models have?
OS - Which BlackBerry OS version to target for?
OS - What is the best practise in blackberry for reaching the widest range of smart phones?
I think there a few things to consider. First off, you need to have a clear vision of what you are hoping to achieve - features/functionality. Then evaluate the various API revisions, and determine which API level will provide the facilities needed to achieve your goals. Depending on the outcome of this, you may have to revise your goals. Maybe even consider using a lower API version, rolling out with a reduced feature set to help get your foot into the market, then in parallel be working on the full bells and whistles release utilizing a higher API version. But most importantly, you need to evaluate your market. The question becomes: "Does your target API provide you will enough of a potential market for your app?" But sometimes it becomes a difficult juggle, especially if you embrace the concept of "Build it and they will come" and you develop your app for the bleeding edge - waiting for the masses to arrive. You need to be sure to have the coverage in place (ie. financial, and political if you are in a large corporate environment) to survive until the day arrives. If you haven't already, you may want to look into becoming a Blackberry Alliance member. Also, don't be afraid to engage the major carriers in your market and push them a bit. They should be able to give you a bit of visibility into handset/platform penetration. Evaluate all of the variables both technical and business plan, and document it - the answer will come to you. Hope this helps.
RIM have created an official page with statistics that help you figure out the answer to this question: http://us.blackberry.com/developers/choosingtargetos.jsp
For example, as of November 2010, OS 5.0+ made up less than 50% of the market share of all active Blackberry devices, but OS 5.0+ accounts for 75% of free app downloads and 86% of paid app downloads from App World.
ON the basis of API similarities and supports i can divide os range like this
(A).<4.2
(B). 4.2< and <5.0
(c). 5.0
We deploy to 4.3, 4.7, and 5.0 with our app and that covers almost every in-market device being used today. There may be a few people still running 4.2 but not many.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
iPhone Development on Hackintosh
I really want to get started, but man are those Macs expensive...especially for a non-US like me.
I'm thinking about trying to run OS X in VMWare. But would this prohibit me from doing iPhone development? I will gladly buy a copy of OS X to give Apple their due...
Thanks,
Makil
The answer is yes.
To develop iPhone applications, you need the iPhone SDK, which in turn requires Mac OS X version 10.5 (Intel). If you can satisfy this requirement in your OS X installation, then you can build iPhone apps. Whether you can test them just as easily depends on USB support in your installation.
The fact that the Mac Mini is $599 is irrelevant to the question and how inexpensive it is, is relative. What is inexpensive to one may not be to another (especially since the OP states that he is not in US, where it might be much more than $599).
Yes, its possible. But, issue is that iPhone SDK gets frequent updates and requires updated version of Mac OS X - updating hackintosh is pain (you can do better development on MacMini instead of wasting time to upgrade) and you will never know when your hackintosh will be unbootable!
USB, Audio are another issues I have seen in hackintosh.
It's definitely possible, and it's not even that hard if you're buying the parts with the intention of running OS X on them.
Most of the difficulties and incompatibilities people experience are due to attempting to try out OS X on hardware they already have. They may have an AMD system which needs a Voodoo kernel, they may have a Radeon 4xxx which will only work in VESA mode without hardware acceleration. Of course these things can be made to work, and it is getting easier all the time, but it's more effort and it's where the bulk of the problems come from.
Once you do get your Hybrid Mac working (as I affectionately prefer to call them) it still won't be as perfectly painless as the ideal (note: not actual!) Mac owning experience. But still, with a little common sense you get a lot more computer for a half or less of the price.
Edit: as for running OS X in a VM on a PC, it's really not very nice at all. It's a tremendous hassle to get it to boot at all, and even then it's not very usable as an environment, often without working sound/LAN/etc. You can obtain complete VMWare images of OS X which may not even work inside different virtualised environments!
Technically: yes. Legally: no. The OSX EULA doesn't permit it.
Note that having the right tools for your job is important, and the unknowns of running OSX on non-Apple hardware could lead to problems down the road. The Mac Mini isn't that expensive at $599, assuming you've already got a keyboard, mouse and monitor.
I know it will work, if you can get the damn thing to install and your able to get usb working.
I currently own a G4 mac mini and had a 2nd gen intel IMac (had to sell it to pay the bills). I paid for my iphone developer lic., bought a 2nd gen touch, booted my mini, downloaded the iphone sdk... Oh no, you need 10.5. Bought and installed 10.5... Oh no, you need an intel mac. Forced sdk install, apps build great for the simulator, but what is this, I can't sign my code. More hacking... Oh no, provisioning error. Connected the touch, unable to mount dev partition. I now left with no job, no money and no way to release my apps to try to make some money.
Oh, yeah, I'm going to try to install hackintosh in vmware, but only because I'm flat broke. Also, I wouldn't buy a another mini knowning that my g4 mini cost $599 (back in the day) but once I was done making it usable, I spent over $1000 ($200 aftermarket 1gig ram upgrade, $99 keyboard/mouse, $150 monitor, etc). Of course it's cheaper for better hardware now, but the mini nickel and dimes you to death. Do yourself a favor and just get a macbook, that will be my next buy.
And the funny and/or worst part about all of this is, I don't even like OSX or the iphone/touch.
I've tried, but I haven't successfully run OS/X in VMware. I do know someone who's successfully developed iPhone apps on a hackintosh, but getting your hackintosh set up is quite difficult.
I'm in the same boat, I don't want to shell out foir a Mac until I know I'm comfortable with the toolchain, and I'd like to get a feel for iPhone development using my current hardware. Interested to hear of others experiences.
I was (with some effort) able to install OS X, snow leopard, as well as the dev tools onto my IBM X61 and have had no issues with it or developing IPhone apps on it. I have the OS fully functioning. Note: I bought a retail copy of Snow Leopard for my project.
Why? I had more time than money. If I had to choose again and I had the $1500 beans (+tax, + whatever) to buy a mac book pro I would have as it certainly wasn't 'simple'. But I didn't.
But now that I have done it, I have an immensely cool IBM MacBook :) and am quite proud of the accomplishment. I also learned an awful lot in the process. Was it hell? Yes.. Was it worth it? Yes...
Hope that helps!
A Mac Mini is $599 and comes with OS X ($129 by itself). The specs on the Mac Mini aren't awe-inspiring but they're perfectly usable. I just wouldn't be able to justify saving a few hundred bucks (max) by buying a bargain basement PC and running it as a Hackintosh. You lose all ability to get support from Apple, you have no guarantees it won't break compatibility in the future, and you are highly unlikely to get the same relatively seamless experience of a real Mac.
Bottom line, whatever money you save, you'll probably end up paying for/regretting later. I own both a Mac Mini and a Macbook and I've had a better experience with both than with any PC I've bought or built in the past. I just wouldn't recommend trying to make an end run around this for the sake of a few hundred bucks. Heck, if you add up VMWare ($189) and Leopard ($129) and the cost of even a bargain PC, you're pretty close to a Mac Mini already, so I can't see this being worth it.