S60 Open to new features

I'm going to interrupt the tour of the S60 UI Designer features a bit to ask for some input on the next release. One priority for the next version will be filling in support all the commonly used S60 user interface elements. One of the things under consideration is support for multi-page forms and dialogs.

There's little question about the value of multi-page forms, as they give you another easy way to get the standard tabbing UI when all your pages are forms. Here's an example multi-page form from the S60 SDK documentation:

Multi-page dialogs are another matter. S60 applications typically use forms and settings lists when displaying multiple data items in a screen -- you don't really see the basic Symbian dialog used directly. So it's not clear that there are good use cases for multi-page dialogs. One might be where the dialog pages are things like a list box, or a single editor.

So let us know in the comments if you think multi-page dialogs are important. A description of your scenario, or a pointer to an existing application would help the most.

In a previous post we saw that the UI Designer wizard can help you create forms, setting item lists, and custom control containers. Those are the top-level designs it supports. Within a design there's a variety of notes and dialogs you can use.

This post gives a quick overview of the menu editor, including attaching your own code to run when the menu items are chosen.

As Markus previously wrote, we're near code freeze on Carbide.c++ 1.1. One of the major new features is the S60 UI Designer.

We had two key goals in mind when we started work on this tool. One was to help new developers quickly get started with S60 development. It's well known that Symbian and S60 development have a rather steep learning curve. Clearly, a graphical, drag and drop designer generating correct, efficient C++ and RSS can help.

The other goal was to help experienced S60 developers create user interface code more quickly, taking some of the drudgery out of day-to-day work. In addition to having an easy-to-use interface, developers told us that it was important that the generated source code be cleanly-designed, customizable, localizable, with support for features of the latest SDKs, such as scalable UI.

This is the first of a short series of posts introducing the UI designer and showing the features targeting these goals. Wel'll start with the wizard and graphical editor.

I just found a brand new article by Alex Gusev on Developer.com that covers the basics of working with Carbide.c++ Express. Alex apparently has written all kinds of articles on mobile software development. It's cool to get people with experiences from other platforms to take a look at our tools.

Developer.com

It's taken its time but we're now extremely close to releasing our first commercial product based on Eclipse. The team is working today to get codefreeze for Carbide.c++ v1.1 Developer & Professional Edition.

And that, my friends, is very exciting indeed!

The Carbide.c++ beta end is getting closer and closer. Barring any drastic last minute action, we're a week or two away from a golden master CD (even if we won't be shipping physical product from now on, but that's a different story). Then it's up to Mike Trujillo, our marketing manager, to create as much commotion in the market about the product release so that everyone knows there's a lot of great reasons to switch from CodeWarrior to Carbide.c++ :-)

You may recall the surfacing of a plan to include platform security -related features into Carbide.c++. Specifically, the plan was to ease figuring out required capabilities, and managing the various DevCerts used for development. The result was two mockups -- The Certificate Manager and Capability Scanner prototypes.

During last week in Finland I had some meetings related to this, and it seems we may find some budget for this work -- or, not. If you feel strongly about this one way or another, now is your last chance.

Update: More specifically, if you have experience of both platsec and binary compatibility issues, and you had to pick between platsec and binary compatibility tools for post-Symbian OS 9.1, which one would you choose?

The jump from S60 2.8 to 3.0 was huge, and there's a lot of work involved in porting old apps. A tool for comparing changes in APIs would have been really useful, and it's too bad we had our hands full just focusing on getting tools support for the radically revised OS.

Regardless, some people inside Nokia have been proposing tools that would provide information on what changes have happened from SDK to SDK -- or even, phone release to phone release (since, yes, changes into device firmware happen every 2 weeks, even after product release -- and sometimes those changes may impact your app).

The resulting tool would allow you to scan all the functions used in your app, and then compare the list against a number of SDKs or device builds (e.g. S60 3.0MR and a future release like a 3.1). Ideally, the result would be a classification of the functions -- 1) known to work the same on all selected targets, 2) known to have changed, or 3) deprecated.

The functionality would work the same for UIQ or MOAP. Since S60 -- and Symbian, with its published@all APIs -- is now touting binary compatibility, I'm not sure how useful this would be as a feature. You tell me!

For all you CodeWarrior users working on S60 v3.0 apps, here's an advance copy of a screencast on how to configure CodeWarrior for on-device debugging of released/publically available S60 v3.0 phones (e.g., E70, E80, etc). The screencast isn't available via Forum Nokia just yet, but should be there in the next few days. Remember, you saw it here first! :-)

To get started, download the screencast and an updated version of the on-device debug agent (AppTRK v2.6) from below. Apologies for the .exe format; an AVI update is in the works.

A couple of things to note before you start... The screencast is missing a few tidbits of information that will make the setup easier. If you're importing your app, make sure the "Use SIS Installation Process (TRK debugging only)" option is checked...

Alternatively, if you've already imported your app into CodeWarrior, go to your target preferences, select Debugger --> Symbian TRK Debugging and check "Use SIS Installation Process".

That should do it. Let me know if it worked!

Symcity has breaking news of next summer's hot software product... Apparently, someone's working on an app that plays a high-pitch tune that drives mosquitos bonkers. This is a killer app, mark my words!