One of the most common questions we get when we talk about new features in Delphi, C++Builder and RAD Studio is “What about Blackberry?” which is almost as common as similar questions about Windows Phone or Linux. iOS and especially Android rule the smartphone OS market, but Blackberry still has a place on most charts (unlike Symbian and some others).
Well, now RAD Studio XE6, Delphi, C++Builder and Appmethod support 96.8% of the shipping platforms thanks to the latest update to Blackberry 10 (10.2.1 or later), it now supports running Native Android APK apps without needing to port. I tested on a Z10 developer device, but it should work on Q10, Q5, Z30, or others. To be clear, Blackberry still runs their own OS, but that OS is able to run Native Android Apps.
Our IDE doesn’t recognize the Blackberry device, again because it is not running Android. But once you build your APK you can transfer it to the Blackberry device using whatever method is most convenient for you. I used Dropbox. Once you have the APK on the Blackberry you simply need to install it.
I built a few samples, including one that takes a picture, and they all more or less worked as expected. When the ShareSheet came up, the usual suspects like Facebook and Twitter were not there, but I didn’t have those set up yet on my test device, so that is to be expected.
You can take things a step further and repackage and sign your app to distribute through the Blackberry store, but that isn’t necessary. You can deploy your APK directly to the Blackberry, or distribute it through the Amazon App Store. Crackberry has a guide on installing APKs too, with a little more detail.
The Blackberry Developer site has useful pages:
- Porting Apps from Android – an introduction
- Android Tools where you can download their command line tools to sign and bundle your app for the Blackberry store.
21 replies on “What About Blackberry?”
I have a Q10. A wonderful device. With a real keyboard. That I am typing this on. Android emulation is not bad. But it’s a long way from slick. Not got the full integration a native app would have.
Now, Delphi is not even native on Android so it’s two levels of emulation!! Really, don’t kid yourself that you properly support Android.
David, how can you say Delphi is not native on Android? Delphi doesn’t run in an emulator on Android, and not even in a VM (like the Java apps). It compiles code in a binary the CPU can run.
Delphi/C++Builder create CPU-native mobile apps, not platform-native mobile apps. The fact that Delphi/C++Builder have to use their own custom-made bridge layers to interact with Android/iOS APIs is proof of that. JNI may be a part of Android, but JNI apps are not “native” Android apps, nor is JNI even a preferred API on Android. If Embarcadero had targetted the platform instead of the CPU, Delphi/C++Builder apps would be able to run on a lot more Android devices than they currently can thanks to your ARMv7+NEON hardware limitation.
The NDK is just as much a part of the Android Platform as the SDK. The JNI is provided to allow interaction between the two (the SDK is written in Java for Dalvik, thus the “interface” portion of it.) To say any one part is not part of the platform is pretty odd. http://developer.android.com/training/articles/perf-jni.html
The reason for the ARMv7+NEON requirement is because of performance optimizations for a native compiled application. NEON is an optional instruction set for ARMv7, similar to back when MMX was an optional Pentium instruction set. There were alternative CPU architectures at the time (AMD, et al.), but the smart money was to optimize for the most common architecture: Pentium+MMX.
On Android there are alternative niche CPU architectures, but the predominate one is ARMv7+NEON. Why not optimize for that? If ATOM or non-NEON CPU’s gain a significant market share, then that might change.
Why not optimize for that? It’s like saying you support an OS, but only if it runs on Motorola processors… If your solution is bound that much to the “predominate” processor, than you are not truly supporting that OS. How useful is an Android app to me when I have to tell customers: “oh yeah, sorry, you can’t use it unless you get a device with an xxx processor”? I cannot truly say my app runs on Android, unless it runs – well – on all devices that Android can run on. Otherwise the only truthful claim is to say that you have an Android on xxx processor app. Nothing more.
Although I like the idea of compiling for native, it does seem like a good idea for Android to be platform native. Won’t the apps be smaller. Firemonkey for Android apps are rather large. Compatible with more devices.
@Marco What Remy said. Native to the CPU, but not native to the platform. The UX for FMX is native nowhere! A bit like Java UI. So, yes, if native to you means an executable file that is native to the CPU, then fine. What matters to users is the experience, and that is absolutely not native.
@Jim Actually, I mis-typed in my original post. I meant to say “don’t kid yourself that you properly support Blackberry.” That’s probably a large part of the confusion. Sorry.
But, FWIW, I don’t think much of Delphi’s mobile offering. I don’t regard it is native. And I don’t much care for FMX which is still a work in progress. Even when the bugs are ironed out it will still leave a rather poor UX in my opinion.
I would suggest that the number of apps that run on “all devices that Android can run on” is so small as to be insignificant when you consider the diversity of the platform.
For example I have a WIMM One module (early predecessor to Android Wear). It is a small Android powered watch. Unless your app is specifically developed for the WIMM One, it won’t run on it, yet it runs Android 2.1: http://en.wikipedia.org/wiki/WIMM_One
Did I mention the WIMM also has it’s own UI widgets? The WIMM is far from the only outlier. Android is a diverse platform.
So am I to understand that unless an app runs on both my Nexus 10 and the my WIMM One then it isn’t “Native Android”?
The purpose of FMX is not to replace the official Android SDK. That would be silly and a waste of time for everyone involved. The only purpose that would solve is to make the trolls happy. Instead FMX brings high productivity, and high performance, app development for the majority type of apps to the majority of devices.
@David: I don’t get the impression you’ve used FMX lately. I’ve talked to a lof ot developers who shared your opinion when it was first released, but as of XE5 have changed their tune.
@Jim Are you are calling me a troll?
As for FMX, it still has far more bugs than it should. But as I said, even when they are dealt with, I don’t like the strategy that Emba chose with FMX. I think that the line that RemObjects followed is preferable since it allows for native UX on all platforms.
Not trying to call anyone specific a troll. Just saying that trying to clone the Android SDK isn’t a good idea.
It is great that there are choices out there. Use whichever tool you like most. Personally I like that I can write one project and compile it to native code on multiple platforms with a common UI.
Personally, if you have to program your entire app with the platform APIs you might as well just be using the platform vendor tools since you really are not getting much productivity enhancements, but that is just my opinion. Getting to use Object Pascal is just a plus on-top of the productivity enhancements that FireMonkey offers.
Rather than cloning the Android SDK, I think the platform native proponents would like to be able to access the native platform APIs readily. As one can with RemObject’s offerings. Anyway, it’s all very interesting and I can certainly see why developers (as opposed to users) would be attracted to the FMX approach.
“For example I have a WIMM One module (early predecessor to Android Wear). It is a small Android powered watch. Unless your app is specifically developed for the WIMM One, it won’t run on it, yet it runs Android 2.1: http://en.wikipedia.org/wiki/WIMM_One”
Turning the argument upside down, are we?
I think it is quite sad that you are turning to an example like this to justify the choices made for Delphi’s mobile offerings.
That you can cite a single device, or perhaps even more, that requires Androids Apps to cater specifically to it in order to run on that device, is hardly the same as nor justifies limiting Android Apps developed using Delphi to a single processor while there is a whole slew of devices out there that business want and need to support simply because their customers happen to use them.
I’d rather have an app that runs everywhere but on that watch, than an app that runs nowhere but on a specific CPU.
And that quite apart from what David has been saying here, which is very reflective of how I see what Embarcadero is offering the mobile development world.
Not so much Blackberry, but how about Window Store Apps ?
Wow. This is all really interesting. I haven’t jumped into the mobile world, as my software is for business/servers. But I’ve been toying with a mobile front-end. I can’t decide if “apps” are the way to go, or if HTML5 will eventually render them un-needed. In any case, I appreciate the comments regarding targeting the CPU vs the OS; as I hadn’t considered the difference between the two.
@adamjohnston705: I’ve talked to customers who have Windows Store Apps, just not Windows Phone or WinRT apps.
@Marjan: The point is there is very little that runs even close to everywhere. Many apps have some native code in them, and without support from Intel’s Houdini library that does real time translation to ATOM then it doesn’t work on ATOM.
@David: Delphi gives you access to all the Android APIs too, but also offers you huge productivity benefits. https://www.youtube.com/watch?v=TyzE0T6zOyE
@Vin: Delphi’s real benefit is the combination of high productivity app development with high performance native code apps across platforms. It is the only tool that gives you a native code with a visual designer across platforms. There are a few devices that it won’t run on because it uses native ARMv7 code, which doesn’t run on ATOM devices, which are less common processor architecture.
There are way more devices Delphi will work for then it won’t. In addition to most phones and tablets, it works on Google Glass, Amazon FireTV, Android Wear, Beaglebone Black, Ouya, and the list goes on. I encourage you to evaluate it and decide which solution is best for you. It is great that there are so many solutions to choose from. This makes the ecosystem better for everyone.
Hi jim, i need help on deploying delphi apps on blackberry, it can install and run the apps, but i can’t type any text to the edit box. I’m using the standard edit box. I’m deploying it as apk on Z10 version 10.2.1. What am i missing? I’m using Delphi XE6 Update 1.Thanks
You might try using DPF Edit controls. http://sourceforge.net/projects/dpfdelphiandroid/
Hi jim, thanks for the links, it is what i’m looking for, i’ve found the dpf ios, and was looking for the android, but did not find it :D. I haven’t tried it yet but it should works.
Iwan
DPF Edit controls are no longer needed for Blackberry OS10-devices with real keyboard (Q5, Q10, etc) as of OS10 v10.3 (roll-out since 19-2-2015), Android emulator in this update captures all keyboard-strokes. Tried it with my own apk’s (which were missing the keyboard-input), they all work now.