alpha version, October 2000
Since an Epoc application uses so many system facilities (like the AIF file, the standard resource contents specifying menu, toolbar etc...) the task of creating it is probably the most complicated one. Again, the XSdk frameworks aims to simplify it as much as possible, using intuitive GUI panels and inspectors as often as possible.
Note also the difference between the XSdk system and the application generators, which are--due to the black magic needed in the plain Symbian SDK--somewhat abundant on the Web. Whilst XSdk does contain an application generator of a kind (the Assistant, described below), it is only the first step. The generator is used for as little code as possible; for example, you do not specify neither the application menu nor the application toolbar in it. Instead, an external format is used for them, to allow you not only to generate them by visual tools, but to maintain them visually as well.
Whenever a new Epoc Application is created, the Application Assistant panel pops out, allowing you to specify the main application attributes. This--and only this--part of the creation process is a true application generator: the Assistant prepares the sources for the specified task. Since you will update and change these files, it would be somewhat difficult to change the application type afterwards: if you would want to do so, you'd have to change the sources manually, without a help of the visual tools.
That cannot be helped: theoretically, the visual tools could scan the sources (prepared by the Assistant, but subsequently written by you) and try to determine what is to be changed and how; though, the process would be extremely difficult and error-prone.
The Assistant application-specific services are described here.
In the XSdk there are visual tools for setting and maintaining the application attributes, including its UID (unlike the Symbian SDK, there is only one place where you have to set the UID, and you have a rich set of UID facilities to do that), application icon, application capabilities, and even some attributes the Symbian SDK does not support at all (like versioning support).
You use the standard application inspector whenever these attributes are to be changed. This is no more "application generating": no fixed source files are generated; rather, the information is kept in the project, and used whenever the application is built to generate a proper result.
See the application inspector document for a detailed description how these attributes are maintained.
In the Symbian SDK, you have to specify these using some black magic in the resource files, and programming the command service routines by a low-level code. As usual, the XSdk offers a visual tool to do so, and quite a higher level of abstraction.
In principle, you can define a quite general set of methods, which are to be called when a commad is triggered. Independently on the code you then specify how the menu, toolbar and hot keys should look like, and which method is to be called by which command. In details, the mechanism is described in the Epoc Commands Inspector help page.
It is worth mentioning that just like above this is not an application generator: no fixed resource file is generated; instead, the information is stored in an external format, and is used again when the application is built, to generate the appropriate resource file dynamically. Therefore, you can use the Commands Inspector not only to define the initial application menu and toolbar, but you'll use the very same visual tool to maintain and change them.
See the application inspector document for the help: in short, currently the help file has to be made externally, and put into the "Other Resources" project group.
Place all other resources (like document templates, sound files, and alike) there as well. The makefile system will ensure they are copied into the application folder when the application is built.
Usually, there is a main application bitmap store, with the name of the application and a suffix .bmp. It might contain any images for the application, including the toolbar icons.
There will be soon a luxury bitmap store editor based on the MBM View in the XSdk. Until then, any standard images just have to be placed into the project folder to a file with the application name and the .mbm suffix. The tool which generated the toolbar will check whether there is this file, and if so, it adds the toolbar icons to it automatically, and places the result to the generated application folder.
Note that this behaviour is not particularly flexible, and therefore will be changed to a better support in the future XSdk versions.
Sorry, but except the Assistant ability to make the Main.view subproject automatically, there is not any view support in the alpha version. So far, you have to program them using the old plain Symbian API, even in projects made in the XSdk Extended API.
In future, there will be a visual tool for preparing views, based on the same principles as the InterfaceBuilder. It will exploit the deynamical system of calling methods, which is currently used for commands, and will make it worth the effort needed to implement it in the C++ rot. Last (but not least), it will contain an easy-to-use support for a view-based menu and toolbar definitions; such menus and tollbars will be automatically used instead of (or within) the standard application menu and toolbar whenever the appropriate view will be shown.
The application engine support looks like the current view support: the Assistant can prepare a static DLL subproject for you, if you specify that the application has to have an engine. The application code will be automatically linked against the engine link library, and the engine headers will be automatically made available for the application code.
Copyright © 1999-2000 X.soft, all rights reserved