Porting Symbian C ++ to Android NDK
I was provided with Symbian C ++ code to connect to Android NDK.
There is a lot of Symbian specific code in the code and I have very little experience in C ++, so it doesn't work very well.
The main thing that slows me down is trying to find alternatives to use in regular C ++ for custom Symbian code.
At that moment when the compiler throws all kinds of errors for unrecognized types.
From my recent research, these are the types that I think are Symbian specific:
TInt, TBool, TDesc8, RSocket, TInetAddress, TBuf, HBufc, RPointerArray
Changing TInt and TBool to int and bool respectively works in the compiler, but I'm not sure what to use for other types?
Can anyone help me with these? Especially TDesc, TBuf, HBuf and RPointerArray.
Symbian also has a two-phase constructor using
NewL
and
NewLC
But would that change to a regular C ++ constructor?
Finally, Symbian uses a cleanup stack to help fix memory leaks. I believe that removing the stack clearing code would be acceptable, I suppose it should be replaced with try / catch statements?
a source to share
Generally, it would be a good idea to try to wire Symbian OS C ++ into standard C ++ without having a very good understanding of what Symbian idioms do.
This could very well be one such project where most of the code needs to be properly rewritten from scratch. If you are barely familiar with the language you are targeting, there is little point in fooling yourself into thinking that you can't go wrong, take the time and throw away new code. This is all part of the training.
The CleanupStack mechanism is designed to help you deal with anything that can go wrong, including power outages and lack of memory conditions. Technically, it's implemented as C ++ exceptions these days, but it covers more than the usual errors that standard C ++ code usually handles.
Descriptors (TDesc, TBuf, and HBuf all refer to a descriptor class hierarchy) and templates (arrays, queues, lists ...) precede their standard C ++ equivalent when dealing with issues like CleanupStack, coding standards, memory management, and integrity ...
Relevant plug if you want to know about it: Quick Recipes On Symbian OS is a recent attempt to explain it all in a few pages.
You should also definitely look at Foundation to get started.
Classes preceded by T must be small enough to be allocated on the stack.
The descriptor classes, suffix C, must be immutable (although it is possible that a mutable descriptor can be generated from them).
HBufC is almost the only Symbian class with an H prefix. It must always be heap allocated.
The method linked in C will add an object to CleanupStack when it returns successfully (it usually returns an object). It's up to the calling code for the pop object.
The R-prefixed classes are designed to be stacked, but they manage their own heap-based resources. They usually have some kind of Close () method that needs to be called before their destructor.
The typical way to find out about the differences between a collection of objects and a set of pointers to an object is by who owns the objects in the collection. Either the collection owns the objects when they are added, or loses them when they are deleted (and therefore is responsible for deleting every object it still contains when it is destroyed itself), or the collection does not transfer ownership, but something else must to ensure objects it will remain valid during data collection.
Another way to think about collections is how many copies of objects you want to make when you add / get objects to / from the collection.
Symbian descriptor and collection classes are designed to cover all these different ways of using memory and let you choose the one you want based on what you want to do.
Of course, it's not easy to get it right, but how does this operating system work.
a source to share
I'm not sure what you're still interested in, but one possibility is that when Symbian idioms use EUSER.DLL (i.e. derived classes TDesC, RPointer *, etc.) you can find EPL code open source from the Symbian developer site and adding it to their port is a viable option. This is the port above the required EUSER bits (and others, perhaps?).
However, if your current codebase is already using many other subsystems, you will find that this becomes very cumbersome.
a source to share
You should try reading the introductory text for Symbian development. They had some examples on the Symbian site and I'm sure you can find specific documents on how the types you want to use are intended and what they provide.
The problem is that symbian development has its own idioms that cannot / should not be directly used outside of the symbian environment, for example, a two-step construct with a cleanup stack is unnecessary in environments where the compiler has appropriate exception handling mechanisms - In Symbian a constructor that throws can lead to all kinds of chaos.
a source to share
If it's not a very large codebase, it's easier or faster to start from scratch and do everything Android style. Even if you need to NDK/C++
, this approach can be faster.
Another approach could be to use a portable C/C++
kernel, and use that in both the Symbian and Android versions when working with the user interface for each platform. Spotify has done it on Android and iPhone.
a source to share