This time you can trust us

Corporate Lucy and naive developer Charlie. Every time she gives you a ball to kick at, or a 'leap of faith', she moves the ball away. Charlie runs for it an kicks only to end up flat on his backside with the ball just as far away as ever. Lucy wonders why noone else wants to play.

In this story Charlie has been worn out staying up all night working out how to use the 'supported' framework, signing process and app approval system. He despairs as he has to find information by trawling support forums, interpreting rumours and fishing for corporate leaks on mobile websites. He dreams of the day when his app is being used, getting feedback and he can enjoy improving it. The cause of his problems, Lucy, is the very thing that should be helping him.

Why is it that great technologies are exploited by these corporate Lucys, yet at the same time neglected? Is it that they don't understand the motivation behind developing apps? Charlies can see potential and are excited by it. The possibility of achieving something is there - but Lucy's not bothered that it's tantilisingly out of reach for Charlie. In fact, she finds fun in making it unavailable. Is there an inate need for corporate Lucy to feel superior and powerful? She demonstrates it at conferences, in Youtube videos and on technology websites. But will Lucy ever make these technologies truly available?

Take these problems Charlie (and others) might face with a Lucy's hypothetical company:

(i) two similar devices, from the same company, with similar operating systems, use different IDEs, different versions of the same framework and subtley different signing processes. One device, which has been available for longer, has worse support for the heralded framework than the first. But Lucy says come and develop for one and you'll effectively be developing for both. "Same framework. Same OS. Same signing process. Don't believe me? We'll eventually provide an update for the first device. It'll be great. Thanks for your loyalty." What she doesn't say is that there are still, now, many seemingly 'secret', badly documented, methods necessary to get the earlier IDE installed, the app compiled in release mode and signed for the app store (not to mention bugs in the newer OS). Implicitly Charlie has to run all over the place just because Lucy won't tell him where the ball is or indeeed where it will be and when.

(ii) so you got your app to compile? Great! Oh, but Charlie found a bug with the OS. No problem - just stick it in our bug tracker. What's that? Other people have the bug with the 'supported' framework too? And when will we look at it? Well we're very busy right now. Why? Well we're launching a new operating system. Oh, but wait, you're not sure if you'll get bad feedback because of the bug? Oh well. We'll fix it Charlie, don't worry...

(iii) so you've got a signed, compiled app? Great! (How did he do that?!) Just submit it on the app store and we'll take a look at it. When will you find out if it's been approved? Oh, well we'll let you know. [Hours go by. Days go by.] What's that Charlie you want to update a bug? Okay, yes just wait for this version to be approved. [Weeks... A month...] We're very busy right now. Lots and lots of apps. [Moment of luck] Hey, hang on - how did you get that approved??! Okay but didn't you want to get a new improved release on there? Okay ...

Never mind Charlie, at least this Lucy is seemlingly playing some kind of ball. Even if the rules aren't clear, it feels extremely slow and you don't trust them 100%.

It shouldn't be like this though. It should be EASY to play ball and developers shouldn't be made to feel suckers because they got undermined at the last moment. What Lucy doesn't realise is that people get fed up and go elsewhere.

The last Lucy really made people feel like they fell on their backside. That was a real way to wreck  brand loyalty. Mind you she's suffering now (these days people don't like play ball as much with 'Redmond' Lucy).

But hang on there's a Lucy from Finland and a Lucy from Africa that want to play. Rumour has it they'll be along in a year. And their devices might be available in Europe. What do you think Charlie? Charlie? ...

Hopes for Qt/C++C on BB10

I had only moderate hopes this morning when downloading the latest Dev Alpha updates (Native SDK 10.0.9.2318 and Dev Alpha A with OS 10.0.9.2320). My app suffers a bit on BB10 as the Qt4.8 integration doesn't seem to be fully integrated yet.

The NAVIGATOR_EXIT, grabGesture() and landscape orientation bugs I've suspected for a while weren't fixed. This is frustrating as I end up spending hours trying all sorts of permutations of code and Natice SDK options to get the thing to work. I could do with spending the time elsewehere on the app to be honest.

The night before I discovered a summary of what BB understand the latest Qt/C++ support to be. This is a positive move because it recognises that there are issues for people that use this approach and implies that more will be done to address this issue. The post is here: http://developer.blackberry.com/native/documentation/bb10/porting_qt_apps.html 

I'm still disappointed that my issues don't seen to have been fixed. Not sure how this affects my app submission either. However, it seems that the overall message is still positive, so still looking forward to  BB10 release. And Jolla... And UbuntuPhone...

I prefer QtCreator and Playbook

It's been a frustrating weekend. Even though there are many other Qt based Blackberry projects out there it still feels like mine is the first and I'm breaking new ground. Issues to date:

(i) what do I licence my project under? Luckilly apart from some LGPL libraries and other more permissive code the rest is mine so I can pretty much use whatever I like. Oh, except for GPL. And a whole load of other licences. (see here)

(ii) Qt Gestures don't seem to be being picked up correctly from one instance of my program to another. I can fire the app off once and it's fine - the QGLWidget works a treat. Next instance - doesn't work - gestures aren't handled. I don't want to release my app in this state. The problem is less obvious on my Harmattan build, but I think I've had it once or twice before. On Playbok it's pretty much 50:50. Qt help seems a bit vague about what's going on here. I sporadically look at the help for things such as this, but always give up once I realise it's not ready yet.

EDIT: it appears this is a problem others have had here

(iii) whatever debugger is in the QtCreator Playbook edition doesn't want to run on my Windows 7 desktop. Debugging and QtCreator (i.e. GDB) always seems a bit flakey to me.

That's the state of play at the end of today. But I don't want to end on a downer, so my positive from this weekend of hacking away at my app is:

QtCreator edition for Playbook is fantastic and I really prefer it to Momentics. I hope people at RIM are listening :O)

Building for the Playbook - Tweak 1

Starting to try and compile for my new Playbook and just encountered this error:

Deployment Failed: Info: Sending request: Install and Launch
failure 533 Application-Requires-System: version [DevAlpha version number][Playbook version number]

Well, anyway, the solution was to open the bar-descriptor.xml file using the graphical interface (click the 'General' tab at the bottom of the screen) and select the 'Blackberry Tablet OS 2.1.0.xxxx' option under 'Required Platform'.

I'm looking forward to having one IDE for Playbook, Dev Alpha etc and being able to get rtid of multiple installations of the NDK scattered across my hard drive!!

BB10 and QNX Momentics IDE - Polished Simplicity?

First off - BB10 looks like it will be fantastic and I'm eagerly awaiting their new phones early next year. However, one worry I have is that amateur developers might be being frustrated by an overly complicated development process because it's not quite refined enough yet. Developers want to achieve things and fussy little problems can make what should be an enjoyable, creative, process, more of a chore.

My experiences of using the BB10 Dev Alpha device and the QNX Momentics IDE have been frustrated by some of the hoops you have to jump through before you can get your latest code up and running on the device. For instance some typical issues when I fire up the PC and the Dev Alpha:

(i) why does the USB connection to the Dev Alpha always have a different IP address?
(ii) why does my project remember the last USB IP address but need a thorough search of menu options - followed by deletion of the new connection then a restablishement of the connection - to connect to the device?
(iii) why do I have to enable the security settings on the device with the new USB IP address? (especially fiddly as the Dev Alpha GUI assumes you have a Playbook size screen)
(iv) why do I need several passwords to get through to the device (device password, developer password ...)
(v) Can I compile my existing Qt/C++ native project using a makefile on Linux? Answer - maybe one day. Jaffa has some instructions here for a QML project, but the QNX Momentics IDE doesn't work for some reason on my version of Linux (OpenSUSE 11.x) so I'm stuck with Windows 7 for now.
(vi) why do projects not recognise new connections easily? I get the message "Unable to create BBTTargetDescriptor from launch" and have to follow the solution here.

There are further little niggles that I'm going to add to this list at a later date in the hope that someone might see them and act on them. I hope that BB10 isn't hamstrung by a corporate need to potentially control everything. I understand that for RIM to open up BB10 to many different development routes probably complicates things for them. However, I hope they can refine the process to make it polished and simple. It will benefit us all in the long run.

Step 2: Helpful & knowledgable BB10 dev relations

It seems like BB are keeping an eye out for developers (as they suggested they were going to at the #BB10Jam recently. Got an informative, responsive reply to my query on the BB developer site regarding my Qt fonts issue:

To specify the Qt fonts directory I needed to add this line to my bar-descriptor.xml file:

<env var="QT_QPA_FONTDIR" value="/usr/lib/qt4/lib/fonts"/>

Full text here [BB Dev Forum]. 

Thanks BB! 

Update: Code still not working yet, but it's now quitting gracefully via one of my own error messages!!) 

Update: (The app is running now - albeit it doesn't have icons, a maths library, example files or any help files yet!) 

Step 1: Use a shoe horn ...

So I'm not used to Momentics, ECLIPSE, QML 2.0 etc etc. My app is written in C++, Qt4.8 and OpenGL ES2.0.

I just want to get the thing running on the Dev Alpha. Much of the BB10 developer website is written (probably necessarily) in generic, bland terms and what I really want right now is a video showing me what to do to import my existing project.

Here's what I can remember of yesterday:

Sigh 1: Why can't I just point to my existing Qt project file - where it already exists -  open it within Momentics and then just build, run and deploy??
Start a new C++/Cascade project. Step by step, remove the default helloworld code and copy across source directories from old project. I've kept the default main.cpp file and am copying in the code from my old main.cpp file. Copy across new project file and pick out paths to CPP, .H and .UI files. Add INCLUDEPATH paths.

I'm finding the concept of these workspaces annoying. I've already tried downloading the CookBookApp (in QML and C++) but haven't worked out how to easily open the thing as a new project. I still prefer Qt Creator but will persevere.

Click build. Multiple errors. Sigh...

Sigh 2: Where is the Makefile produced by QMake? The makefile in the project appears to be minimalist and not contain the standard compiler flags

It actually points to another makefile in the 'translations' directory. I know the ultimate goal is to get versions of the app that aren't restricted by language barriers, but right now this is just another thing to think about and I don't understand the inrteractions between the makefiles. (more later).

Still not sure where the Makefile with compiler flags lives.


Error 1: Compiler is complaining about not liking my templates which dump template variable to std::cout.

error: no match for 'operator<<'

Workaround: Haven't resolved this yet, but just commented out the template variable part for now.

Error 2: Weirdo error that Google has two possible answers for

excess closing brace in C++ code

through trial and error it transpires this is something to do with the translations and lupdate program It seems as if I haven't been using Qt's tr() function as often as this system would like.

Workaround: Comment out the LUPDATE and LRELEASE functions in the translations makefile mentioned earlier. i.e.:

QMAKE_TARGET  = mercury
LUPDATE       = $(QNX_HOST)/usr/bin/lupdate
LRELEASE      = $(QNX_HOST)/usr/bin/lrelease

update: $(QMAKE_TARGET).pro FORCE
#    $(LUPDATE) $(QMAKE_TARGET).pro

release: $(QMAKE_TARGET).pro $(QMAKE_TARGET).ts
#    $(LRELEASE) $(QMAKE_TARGET).pro

FORCE:


Error 3: Fonts in the wrong directory
On my BB10 Dev Alpha device the Qt fonts seem to be located in:

/base/usr/lib/qt4/lib/fonts

but my app is looking for them here:

/base/usr/lib/qt4/fonts

How do I make my app look for them elsewhere? How can I set an environment variable to do this please?

I've tried pointing Qt to the correct location but it still crashes (possibly not a font problem now?)

       QFontDatabase::removeAllApplicationFonts();
       QString Fpath = "/base/usr/lib/qt4/lib/fonts/helvetica_80_75i.qpf";
       QFontDatabase::addApplicationFont(Fpath);

Moo baa double quacked on the BB10 developer forums - will have to see if help comes...