I still wonder if a usable listing of restricted APIs exist. I mean a
comprehensive list of so-called capabilities along with their relation to
Symbian 9 API functions. If that list would be in the form of a table then
its columns would consist of:
(1) The name of the capability (e.g. ReadUserData, SwEvent, etc.).
(2) The kind of signing necessary to enable that capability.
(3) A list of _all_ API classes/functions that depend on that capability.
In my opinion, item (3) above is absolutely necessary to make a plan about
having an app signed. To me this sort of info seems to be absolutely basic
and essential to all developers who intend to port code to Symbian 9. So, is
that kind of list available somewhere?
zol wrote:
> I still wonder if a usable listing of restricted APIs exist. I mean a
> comprehensive list of so-called capabilities along with their relation to
> Symbian 9 API functions. If that list would be in the form of a table then
> its columns would consist of:
>
> (1) The name of the capability (e.g. ReadUserData, SwEvent, etc.).
> (2) The kind of signing necessary to enable that capability.
> (3) A list of _all_ API classes/functions that depend on that capability.
>
> In my opinion, item (3) above is absolutely necessary to make a plan about
> having an app signed. To me this sort of info seems to be absolutely basic
> and essential to all developers who intend to port code to Symbian 9. So, is
> that kind of list available somewhere?
You can find all these in the SDK (beta) docs.
--
David Caabeiro
www.PushL.com
> > (3) A list of _all_ API classes/functions that depend on that
capability.
....
> You can find all these in the SDK (beta) docs.
I wish I found... I really meant a table of [capability] -
[dependant-function-list] pairs, not the sort of accidental info that exist
in the SDK docs. Don't you really think it would be better?
zol wrote:[color=green][color=darkred]
>>> (3) A list of _all_ API classes/functions that depend on that[/color]
> capability.
> ...
>> You can find all these in the SDK (beta) docs.
>
> I wish I found... I really meant a table of [capability] -
> [dependant-function-list] pairs, not the sort of accidental info that exist
> in the SDK docs. Don't you really think it would be better?
>
>[/color]
Yes that would be great unfortunately I don't see it happening anytime
soon. I think it's best we wait till the public (non-beta) releases of
the SDKs are out. I also agree with you a table of the sort you suggest
would make things much more simpler.
AMK
The things are never black or white ... The same API may (not) need a
capability depending on the use case. Creating a "table" in this case may
not be the most "readable" solution.
The current approach is, I think, OK if the work is 100% completed by the
time the final SDK is being published. The API documentation should contain
the capability requirements (in various use cases if needed) as the
capability is more like an default argument to a method call than anything
else.
A list of APIs per capability (actually several but incomplete) is already
available in the SDK as a doxygen dump. It does not hurt to have it but I
don't think it really helps. Just search for a give capability and then look
for the entries starting with "Doxygen Analysis of capabilities ...."
"AMK" <[email protected]> wrote in message news:GRMa$O#$FHA.996@extapps30...
> zol wrote:[color=green][color=darkred]
> >>> (3) A list of _all_ API classes/functions that depend on that
> > capability.
> > ...
> >> You can find all these in the SDK (beta) docs.
> >
> > I wish I found... I really meant a table of [capability] -
> > [dependant-function-list] pairs, not the sort of accidental info that[/color][/color]
exist[color=green]
> > in the SDK docs. Don't you really think it would be better?
> >
> >
> Yes that would be great unfortunately I don't see it happening anytime
> soon. I think it's best we wait till the public (non-beta) releases of
> the SDKs are out. I also agree with you a table of the sort you suggest
> would make things much more simpler.
>
> AMK[/color]
Thanks for the insight and advices. Let's take a very practical example.
Let's say my UIQ application uses the RWindowGroup::CaptureKey() function to
provide a hotkey. When porting to UIQ 3, I notice that CaptureKey() does not
work as it used to in UIQ 2, and see in the docs that CaptureKey() is bound
to the SwEvent capability. Then I include a CAPABILITY SwEvent line in the
..mmp file, and after rebuild the CaptureKey() function starts working fine
in the emulator. The question is what this new line in the .mmp file will
cost when it's coming to distributing the application to an UIQ 3 device,
that is:
- Can the application be installed and used without signing?
- If yes, then will the user see a warning, and what kind?
- If no... well, then using such a basic function like CaptureKey() produces
all the hassle that signing means in terms of testing, time and cost (good
news).
"zol" <[email protected]> wrote in message
news:4Ig$RBVAGHA.1036@extapps30...
> Thanks for the insight and advices. Let's take a very practical example.
> Let's say my UIQ application uses the RWindowGroup::CaptureKey() function
> to
> provide a hotkey. When porting to UIQ 3, I notice that CaptureKey() does
> not
> work as it used to in UIQ 2, and see in the docs that CaptureKey() is
> bound
> to the SwEvent capability. Then I include a CAPABILITY SwEvent line in the
> .mmp file, and after rebuild the CaptureKey() function starts working fine
> in the emulator. The question is what this new line in the .mmp file will
> cost when it's coming to distributing the application to an UIQ 3 device,
> that is:
>
> - Can the application be installed and used without signing?
S60 SDK documents state that SwEvent is granted through Symbian signed.
I would expect UIQ & S60 follow same rules, but I have not checked this.
> S60 SDK documents state that SwEvent is granted through Symbian signed.
> I would expect UIQ & S60 follow same rules, but I have not checked this.
What does all that mean in practice? What will I experience if my
application uses CaptureKey() and I include a CAPABILITY SwEvent line in the
..mmp file, but do not get the application signed? Namely:
- Will I be able to build a .sis file?
- If yes, then will it be possible to install the .sis file on an UIQ 3
phone?
- If it can be installed at all, then will the user see a warning at install
time? What kind? Does he have choices when that warning is issued?
- If it can be installed and the user chooses to do so, then will the
CaptureKey() function work?
- If it will not work, then will the user be informed by the system about
the restriction at runtime when the restricted function (CaptureKey in this
case) is called?
- If yes, then will he be able to grant the right to enable the restricted
function, or he is completely excluded, so the application becomes limited?
Still regarding the last question: are there capabilities at all that the
end-user can give permission for? If yes, then how to know what are those?
"zol" <[email protected]> wrote in message
news:KCVy7ckAGHA.2128@extapps30...[color=green]
> > S60 SDK documents state that SwEvent is granted through Symbian signed.
> > I would expect UIQ & S60 follow same rules, but I have not checked this.
>
> What does all that mean in practice? What will I experience if my
> application uses CaptureKey() and I include a CAPABILITY SwEvent line in[/color]
the
> .mmp file, but do not get the application signed? Namely:
>
> - Will I be able to build a .sis file?
Yes.
> - If yes, then will it be possible to install the .sis file on an UIQ 3
> phone?
With capabilities like SWEVENT assigned but not signed - NO. With some
others, like NetworkServices, yes, a sefl-signed sis will do.
> - If it can be installed at all, then will the user see a warning at
install
> time? What kind? Does he have choices when that warning is issued?
Someting like "Cannot grant capability." And as I said at this poitn the
installation fails.
> - If it can be installed and the user chooses to do so, then will the
> CaptureKey() function work?
If you do not specify the capability in the MMP then you can install the
application but as you said before the app will not work. Usualy the API
call leaves with KErrPermissionDenied (-46)
> - If it will not work, then will the user be informed by the system about
> the restriction at runtime when the restricted function (CaptureKey in
this
> case) is called?
>
> - If yes, then will he be able to grant the right to enable the restricted
> function, or he is completely excluded, so the application becomes
limited?
>
> Still regarding the last question: are there capabilities at all that the
> end-user can give permission for? If yes, then how to know what are those?
>
This would be true for the basic set of capabilities but the only point the
user can grant them is at install time. So, they have to be specified in
MMP, the app has to be self signed ... and the user will accept or not to
install your app after a proper warning message... See
https://www.symbiansigned.com/How_has_Symbian_Signed_evolved_with_Symbian_OS
_v9.pdf for details