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).
Related
This is kind of a dumb question but I've aware of classic style JDE development for Blackberry but I've never tried using WebWorks. BB website says that it's possible to build applications for both smartphones (OS 6.0+) and tablets - sounds fantastic, but what's the price?
Is here anyone using WebWorks on a daily basis and capable of describing pros and cons?
Thanks in advance
I would suggest using it if you build webOS applications before hand. It make porting to the blackberry a breeze.
Use WebWorks if you know html5, Css3 and javascript over Java and C++.
I haven't ran into any issues with the webWorks, ported two applications without running into any issues. Its your standard html5, css3 and javascript you love with blackberry APIs
WebWorks is a good development choice, particularly as it allows easy migration from earlier BB OSes to BB10. It's mostly standard web technologies (HTML5, CSS3, etc.) and the team seems focused on making it perform well (e.g. hardware accelerated WebGL graphics) while at the same time providing BlackBerry-specific APIs to make WebWork apps capable and with good UX (e.g. you can make it look like a native app).
For native apps, you should look into Cascades. This is a modern development environment with good tooling, accelerated graphics, and APIs for building snazzy apps. It's the one that will most be a "BlackBerry app".
AIR remains an option, but I would recommend WebWorks over AIR, as even Adobe is migrating from Flash to web technologies. Likewise, you can develop Android apps on BB10, but unless you are keen on Java programming, you will get more cross-platform support from WebWorks (or even AIR) so there's no particular reason to go the Android route.
WebWorks API is limited, for example it does not have socket, so you cannot port a VNC (UltaVNC, tightVNC ..) to it but you can do it with JDE.
For UI, WebWorks allowed me to write UI of acceptable quality quickly and easily, a thing that I have never succeeded with JDE.
Still on the UI side, I can make use of multi-touch (PlayBook), I don't think this one is possible with JDE.
So depending on your needs you should go either WebWorks or Native, having heard that Java may not be supported in BB10, and Air may not be future proof (Adobe favors HTML5 instead of Flash). Android appli has some lag on start up when it is run on PlayBook, some customers are sensitive to the initial even just one time slow response time.
I'm a huge proponent of Webworks. Ever since I've started using it, it quickly became the default option for my apps going forward. Especially for someone like me who is just writing a few apps on the side, I don't have the time to do it in c++.
The apps I'm writing revolve around home automation. They are client/server based from the get go.
Here's why I like it:
First and foremost, native API support. I can very easily create my own active frames, import invocation from other apps (think camera, stuff like that). I can export portions of my webworks app as an invocation card! Which means I can write say 3 unique apps (in this case home automation, lights, thermostat, security cameras). And I can very easily pull features from each app into the other. Maybe I want to turn my lights on in the living room, I can also import the camera card from my IPcam app and view the results, without having to add that code into my lights app and maintain two separate code lines.
Rapid design. Since I've been dabbling in html since I was a kid, it's now very easy for me to whip up an appealing UI in little time. Because web engines these days offer good performance in terms of graphics capability, I also can make apps that behave very fluid.
Considering the time to make something beautiful, it's hard for me to leave webworks and go for something in c++. Also the big plus is often these apps I'm making are intended for multiple devices, namely an app on my phone and being hosted on my personal website. By maintaining two slightly different css files, most of the time I need no code changes, just load a different css depending on if it's a phone or a pc. (Exactly what you'd do if you were developing a regular old website).
For that matter, I actually don't put my code on the device, I host all of my html and javascript, images etc on my server. The webworks app is just the config.xml pointing it's source to my server, and an icon. A glorified website bookmark on the homescreen, only difference is I can use native API and there's no browser bar in the app.
Also, this way I can still continue to edit the same single codeline on my server, and instantly apply changes to the in-browser app and the on-device app.
This is especially cool if you're designing an app where all of it's data is out in the "cloud", say you work for a publication and you want to write a magazine app which pulls content from your servers on the net.
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’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.
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.
Every indication I have, based on my experience in embedded computing is that doing something like this would require expensive equipment to get access to the platform (ICE debuggers, JTAG probes, I2C programmers, etc, etc), but I've always wondered if some ambitious hacker out there has found a way to load native code on a Blackberry device. Anyone?
Edit: I'm aware of the published SDK and it's attendant restrictions. I'm curious if anyone has attempted to get around them, and if so, how far they got.
I've seen this question pop up in a number of different forums over time. The original Blackberries were programmable in C++ but I think that RIM ran up against the problems of trying to implement a secure platform in the C/C++ compile to native paradigm.
The devices do have JTAG ports, but unless one could get hands on the RIM code as a place to start the problem is enormous.
I also have to wonder how useful a Blackberry with a replacement FOSS operating system would be, since it would not likely have the protocols to connect to BES or BIS, send PIN's etc. If one was simply looking for a the power of the hand held computing platform I suspect there are many more likely candidates available.
No, C++ is no longer a supported RIM development tool, as they phased it out a number of years ago. Client applications can be developed in Java (or one of a few 5GL frameworks), and web + sever-side apps can be developed using standard tools.
For those looking for updated information, the new Playbook os, also known as QNX, also known as Blackberry 10 (or it will be when the phones running it come out) is in fact c/c++ based, also using QML and a C++ add on called Cascades.
Unfortunately the official SDK website only seems to mention Java. According to wikipedia, different versions of the BlackBerry use different processors. Combined with the fact that RIM uses a proprietary operating system for the devices, it becomes pretty difficult to develop native code without official tools. There is also a partial API-level security restriction which would further prohibit advanced tinkering.
Just randomly searching for an answer to this and came across http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/Native-C-C-SDK/td-p/778009 which mentions that BB intend to release a C/C++ SDK soon, more details will be provided at the 2011 Game Developer Conference.