danielbigham.ca: bb10

10 Things I Love (And Dislike) About BB10 Development

24 Aug 2013 00:00:00

I haven't found much time for BB10 development in the last few months, so it has been wonderful to get about 35 hours of it in over the last three weeks. I had a very enjoyable hour today and am inspired to share some aspects of BB10 development that I really like. 1. The UI looks great! The UX team at Blackberry did a wonderful job on all of the widgets and various UI features of Cascades, and it makes it a real pleasure to create apps. BB10 is perhaps my favorite mobile OS in terms of appearance and UI functionality. I'm not sure the UI always lives up to 60 fps like the designers had hoped, but it runs well, and UI interaction is typically nice a smooth. 2. QML: Being able to quickly put UIs together using a declarative language like QML is great, and being able to call into C++ fairly simply is also great. 3. QML preview: Being able to get a real-time preview of the UI you're working on is super helpful and makes building a UI so much more efficient. (The unfortunate limitation is that this doesn't work with custom controls -- I wish there was a way for that to work) 4. Qt: Building Cascades on top of Qt was a pretty good choice, I think, if you're going to build on C++. Qt has a good set of classes, plus their signals/slots mechanism, which make building apps much more straightforward than raw C++. 5. IDE: Building the IDE on top of Eclipse was a good idea, and the IDE has gotten noticeably better with 10.2. 6. Sample code: Having a rich set of sample apps that are fun and well-written is always helpful. BB has done a great job with their sample apps. Thank you! 7. Documentation: BB's website for BB10 documentation is well laid out and looks great, making it a joy to use. 8. Developer relations and forums: BB means business when it comes to helping developers. They're on the opposite end of the spectrum as compared to Google... if you have any serious issue, just send them an email and they're right on it. This is frankly amazing. Good work developer relations! 9. Blogs: It's helpful that BB maintains a good developer blog. This makes it fun to continue to learn and be motivated by 10. Events: BB's "jam" events have been fun to attend, and a good way to meet people and get excited about Blackberry's vision. Now, to be fair, I'll also list the things that are painful about BB10 development. 1. Developer productivity with Cascades (for me, right now) is about 2x-3x slower than it was with Adobe AIR. Part of this is my own fault for being rusty on C++ and new to Qt, whereas I had relatively more experience with JavaScript upon which AIR is built, and partly it's because I write more polished code (and more substantial apps) when doing Cascades work, whereas I was happier to hack things together in AIR, but all this said, that makes a huge difference. Some of my top-grossing apps for PlayBook took 8 hours, 2 hours, even 1 hour, to create, whereas my BB10 efforts have been more in the 30 hour range to create something. What this means for hobbiest developers is that it's harder to "focus" on an app, because you might have a week or two where you have some free time, and that only gets you started on an app, it doesn't start and complete the app. Then you lose focus and forget what you created, and you get out of the groove of BB10 development, and it feels like starting from scratch when you pick it back up a few weeks later. I hope that as I progress my productivity will increase. Part of the issue here is C++/Qt. They're good languages, but they're just not as productive as languages like C#, Java, or JavaScript. Qt hags a fair bit of "cruft". Having to maintain .h and .cpp files slows you down. Adding methods is more painful, etc. 2. My first big time investment in a Cascades app took about 25 hours of my time and 25 hours of a friends time to get close to completion. Then, the app started crashing randomly if I repeated an action. Ugh. The stack trace didn't even involve my code. I must have been doing something wrong in terms of Qt and its memory management, or something, but after staring at the code endlessly I couldn't come up with any solutions to the crashing. This was super-disheartening, and frustrating for a seasoned developer. Writing programs in languages like C++ carries with it this added risk over languages like C# and Java... if you screw something up which has a very indirect affect later on in the execution of the program, and it might take you eons to solve it. This obviously makes development much less fun. I still have yet to solve my issue, and I'm low on patience to go back and spend hours trying to figure it out. Solving those kinds of issues isn't really what someone wants to be doing with their hobby time. 3. I find QML + C++ to be quite a compelling combination, but it also feels a bit "brittle" at times. If you want to do the common things, it's fairly straightforward, but sometimes I'm trying to do something that seems slightly out of the ordinary, and I'm just clueless how to pull off the plumbing to make it happen. For example wanting to send a pointer to an object from QML to C++, and it gives some cryptic answer. It seems so simple! I think the answer I found on the web was that your method should accept a QObject*, not the actual pointer type you're trying to send. Uhhh, OK, whatever. That's the joy of using a rich, built-up framework, but not having a depth of experience with it. ie. Steeper learning curve. Again, nice when hobby development isn't a steep learning curve. 4. I really wish deployment to the device was faster. Not including compile time, it takes about 10 seconds to deploy and run the app over USB. This seems silly to me. Surely that shouldn't take more than 1 second if optimized: The app isn't very large -- what takes so long!? Having to wait this long slows down development time and scatters my concentration. 5. The IDE can feel buggy at times. Currently, if I press "Run" too quickly after the compile finishes (and it is done), it gives me a NullPointerException in the IDE as a popup. Super annoying. Also, it can't currently find the simulator, even though it was working fine previously, and I haven't made any changes to the simulator. And sometimes it can't see the device over USB even though it is connected, or can't see if over Wi-Fi, even though it is there. Little bugs and unreliabilities make developers cranky. I've also had headaches with the keys that RIM issues you to sign your apps -- using them, managing them, etc. I'm having a hard time thinking of anything else to complain about, so that's a good sign :)

Getting simple BB10 AIR apps to compile

16 Aug 2012 00:00:00

I've created about 30 PlayBook apps over the last year and a half and it has come time to start getting them up and running on BB10, especially since RIM now allows them to be submitted to App World. Unfortunately, I haven't been able to get even very simple apps to compile, such as: package { import flash.display.Sprite; import qnx.fuse.ui.dialog.AlertDialog; [SWF(width="1024", height="600", backgroundColor="#FFFFFF", frameRate="30")] public class Example extends Sprite { public function Example() { var alert:AlertDialog = new AlertDialog(); alert.title = "Debug"; alert.message = "Hello, world!"; alert.addButton("Ok"); alert.show(); } } } I have attempted to compile this with: set JAVA_HOME=E:\Program Files (x86)\Java\jre7 set PATH=%PATH%;E:\Program Files\Research In Motion\blackberry-tablet-sdk-3.0.0\bin cd E:\Users\Daniel\Dropbox\Apps\ExampleBB10\ amxmlc Example.as But get the errors: Loading configuration file E:\Program Files\Research In Motion\blackberry-tablet-sdk-3.0.0\frameworks\air-config.xml E:\Users\Daniel\Dropbox\Apps\ExampleBB10\Example.as(13): col: 14 Error: Type was not found or was not a compile-time constant: AlertDialog. var alert:AlertDialog = new AlertDialog(); ^ E:\Users\Daniel\Dropbox\Apps\ExampleBB10\Example.as(13): col: 32 Error: Call to a possibly undefined method AlertDialog. var alert:AlertDialog = new AlertDialog(); ^ E:\Users\Daniel\Dropbox\Apps\ExampleBB10\Example.as(14): col: 16 Error: Call to a possibly undefined method AlertDialog. alert = new AlertDialog(); ^ E:\Users\Daniel\Dropbox\Apps\ExampleBB10\Example.as(6): col: 27 Error: Definition qnx.fuse.ui.dialog:AlertDialog could not be found. import qnx.fuse.ui.dialog.AlertDialog; I am basing this on what RIM has provided: Using the AlertDialog: https://developer.blackberry.com/air/beta/documentation/create_alert_dialog.html Compiling with the command line: https://developer.blackberry.com/air/beta/documentation/create_your_first_application_cmd_ms_2010847_11.html This is a call to RIM to please provide adequate instructions for how to compile BB10 AIR apps via the command line. I have searched the forums and found evidence of others having issues. There are some hints on how to get things working, but those hints are mostly with respect to the IDEs that some people use to develop AIR applications. It's really a sad state of affairs that a person like myself can't even get a simple BB10 AIR app to compile in August 2012! I've posted to the forums in hope of an answer. Hopefully this will all be clarified soon. Update: As recommended by someone on the forums, deleting the SDK directory and reinstalling seems to have fixed this issue. (I did notice that the version I re-downloaded was "beta 2", so it's possible that this issue was fixed at some point)

BB10 Jam Interview

02 Jul 2012 00:00:00

Hey cool, I just noticed that the interview I did with RIM's developer relations at BB10 Jam is live on YouTube!

BB10: Correlating errors to code

28 Jun 2012 00:00:00

ASSERT failure in QList::operator[]: "index out of range", file c:/bbndk-10.0.4-beta/target/qnx6/usr/include/qt4/QtCore/qlist.h, line 477 I'm glad that Qt/C++ can narrow down the error this far, but there is still definitely a disadvantage as compared to languages like Java and C# that are able to give you a stack trace and show you precisely where the error occurred.

BB10: Qt: Gotta love errors like this

28 Jun 2012 00:00:00

make[2]: *** [o-g/.moc/moc_Model.cpp] Error 1 make[1]: *** [debug] Error 2 make: *** [Simulator-Debug] Error 2 Awesome. Dear Qt folks: Thanks for the super clear error message. Finally figured it out. I had written: Q_PROPERTY(int name1Visible READ) Instead of: Q_PROPERTY(int name1Visible READ name1Visible) But yeah, completely non descriptive errors like that are not fun. One of the disadvantages of using macros so heavily, which Qt does.

Thoughts on today's news of delay to Q1 2013

28 Jun 2012 00:00:00

Maybe it's because I'm a software person and I sympathize with making good time estimates, and the complexity of birthing a whole new platform, but I'm just not surprised at the Q1 2013 announcement today. On June 12, I wrote on my blog: "And I tend to be pessimistic/conservative about tech time estimates. What I mean by that is that although the public seems to be all caught up with "October" being the magical month, I would actually be surprised to see BB10 that early. I think it's much more likely that it will be released in November or December or January or February. Heck, if it were launched in March it wouldn't be a big surprise. You can't snap your fingers and pull a whole new generation of product out of a hat, and RIM can't afford to release it half baked. So things will take time." So hearing the announcement today for me was basically what I expected to hear. The trouble is, if they had said 8 months ago "BB10 may launch as late as May 2013", they would have been dead meat. The only way they can keep people's interest is to be as optimistic as possible. I don't think they're being dishonest, they're just forced to be very optimistic. And when you're very optimistic in the software world, you have a high probability of missing your dates, sometimes by a very wide margin. Frankly it is sounding more and more like it will be Feb/March/April/May. Yes, there's absolutely no reason it couldn't be May. And before you shoot me, hear me out.... they're probably aiming now for say late February, and with something this complex, being 6 months away from your estimate and missing by slightly over 2 months is not unheard of by any stretch of the imagination. So that's my opinion: We'll probably see BB10 launch in the Feb-April window, but it is a very real possibility that it could even be May. Probably not, but it's very possible. All of the super optimism in the world doesn't make the process of developing a new platform and then building on top of them the world's best communications software any easier. Sorry folks. Patience, and lots of it, will be required. The other reaction I have to this announcement is actually a sigh of relief. Sounds weird, but one of my greatest fears about BB10 is that it will be rushed out the door before it's ready. Think about it, the company is under *tremendous* pressure to get it into the hands of customers. And because it is still many months of work until it will be done, they're therefore under tremendous pressure to let their ideals slip and ship it before it's ready. Because of that, any time I hear about a delay, even though it does hurt, it's a reminder that the people making the decisions aren't willing to make short term compromises that will damage the long term success of the platform. Thank goodness.

BB10: Rapid charge stand + BB10 dev alpha

28 Jun 2012 00:00:00

I was looking for a convenient way to prop up my dev alpha while working on an app, since it's annoying to pick it up every time I run an app. As it turns out, the rapid charge stand for the PlayBook works perfectly -- you can set your dev alpha in the stand and it hold it upright. Obviously it doesn't charge it, but that wasn't the point :)

BB10: Images animating into place when loading QML file

28 Jun 2012 00:00:00

I've noticed that when I load new QML files, the images animate into place. For example, if the screen contains an image at position X,Y and it is of width W and height H, then the image becomes visible at coordinates 0,0 and has width 0 and height 0, and then animates into place by flying over to coordinates X,Y and growing to eventually be of width W and height H. If I then click the "Back" button and go to that QML screen a second time, it doesn't animate. Is this implicit animation intended? While implicit animations are rather amazing and a great tool to have, it seems counter intuitive to have screens use implicit animations when they are first loaded. It creates a rather unpleasant business and visual distraction when the screen is loading. I thought I could disable this by adding the following to the ImageView controls: attachedObjects: [ ImplicitAnimationController { enabled: false } ] ... but they are still animating. Posted question here

BB10: onTouch

28 Jun 2012 00:00:00

To respond to a touch event, I added the following: onTouch: { navPane.deprecatedPushQmlByString ("mom_dad.qml"); } To my amazement, when I ran the code on the dev alpha device and touched the image, it loaded mom_dad.qml five times! This is because, I would assume, the onTouch event fires when your finger moves on the screen, and you need to limit your "click" event handler to the down event: onTouch: { if (event.isDown()) { navPane.deprecatedPushQmlByString ("mom_dad.qml"); } }