cross-platform cellphone app development
category: code [glöplog]
decipher, did you try it?
admittedly i played with it only a few hours total, but some friends of mine managed to create fairly decent apps pretty quickly. so clearly i'm too much of a noob to know - what did i miss?
admittedly i played with it only a few hours total, but some friends of mine managed to create fairly decent apps pretty quickly. so clearly i'm too much of a noob to know - what did i miss?
doom, that sounds like a horrible experience. the camera app loading time sucks indeed - but i never use it so probably that's why i don't mind. i can't really relate to your other experiences.
skrebbel: Did I try Qt? Yeah, I am using it day-to-day at work for high-level coding and in my free time for developing quick tools and producing cross-platform solutions. It's an amazing framework, very simple and very straightforward and works wonders.
Kudos go to Kmk / Portal Process for his and his team's (Trolltech) effort on Qt. :)
Kudos go to Kmk / Portal Process for his and his team's (Trolltech) effort on Qt. :)
Oh also in one instance I mixed some really hardcore low-level code with Qt for visualization. I can say Qt even made everything way simpler and worked really well with constructs and code that was foreign to it; and saved the reputation of a five meg… <NDA> … </NDA> fuck-up. It didn't even require significant effort to make Qt do what I want it to do using the low-level code.
kmk works on qt? damn, its a small world :)
but then what was the irony about? to my very limited experience, making symbian apps with qt isn't particularly torture.
but then what was the irony about? to my very limited experience, making symbian apps with qt isn't particularly torture.
Irony? There absolutely was no irony. Everything is seriously perfect about Qt over here. :)
oh, ah :-)
i missed the non-irony this time, then :-)
yeah i have similar experiences with qt - used it a lot more on desktop. i really dislike C++, but qt makes it all worth it (including its fixes to the language, and its replacement for that horrible standard library, of course). i'm especially impressed by its completeness.
the only part i'm not so hot about is qmake, which feels as limiting as qt itself doesn't, but it's not been a showstopper for me.
i missed the non-irony this time, then :-)
yeah i have similar experiences with qt - used it a lot more on desktop. i really dislike C++, but qt makes it all worth it (including its fixes to the language, and its replacement for that horrible standard library, of course). i'm especially impressed by its completeness.
the only part i'm not so hot about is qmake, which feels as limiting as qt itself doesn't, but it's not been a showstopper for me.
Skrebbel: I might help about that one. Skype. :)
True. Qt is damn good! Haven't tried developing mobile apps with it though...
I only wish Qt would throw exceptions instead of using error codes, booleans and "get last error" type methods.
Yes, and when exception handling is turned off then tough luck, eh?
Not to mention baby Jesus kills a kitten each time you throw an exception across the dynamic library boundaries. And finally, I am sure forcing people to deal with cleanup codes that equate to the size of a whole software itself is not exactly Qts idea of making shit simpler.
Not to mention baby Jesus kills a kitten each time you throw an exception across the dynamic library boundaries. And finally, I am sure forcing people to deal with cleanup codes that equate to the size of a whole software itself is not exactly Qts idea of making shit simpler.
Well, Jesus is a twisted motherfucker, then. ;)
All I know is I like writing code without explicitly checking the return value of every function, creating huge nests of if( functionWithReturnCode() == RESULT_OK ) statements, manually forwarding error conditions up through layers of function calls: if( function() == RESULT_FAILED ) return RESULT_FAILED, goto statements, and all the other carp that exceptions are supposed to (and can) put an end to.
The reason given for Qt not using exceptions is cross-platform compatibility, which is not really satisfying when you're coding for a platform/compiler that does have full exception support. I don't want to be handicapped on Windows just so my code will be portable to Symbian. As for exceptions from DLLs, Idunno. It works for MFC.
All I know is I like writing code without explicitly checking the return value of every function, creating huge nests of if( functionWithReturnCode() == RESULT_OK ) statements, manually forwarding error conditions up through layers of function calls: if( function() == RESULT_FAILED ) return RESULT_FAILED, goto statements, and all the other carp that exceptions are supposed to (and can) put an end to.
The reason given for Qt not using exceptions is cross-platform compatibility, which is not really satisfying when you're coding for a platform/compiler that does have full exception support. I don't want to be handicapped on Windows just so my code will be portable to Symbian. As for exceptions from DLLs, Idunno. It works for MFC.
And exceptions don't have to do with cleanup code, really. They're for directing control flow under error conditions. For cleanup we have destructors, and they should be called all the same whether you're leaving a scope with return, goto, break or throw. I know that's not how things work on Symbian, but on a good platform they do. ;)
They're fine for fatal errors which require the simplest control flow (catch them on top and do some drastic measures)
For directing control flows in case of simple errors, they're kind of messy, in a non structured programming kind of way. They remind me of intercal's sarcastic COME FROM statement.
For directing control flows in case of simple errors, they're kind of messy, in a non structured programming kind of way. They remind me of intercal's sarcastic COME FROM statement.
I prefer objects to turn into "null objects" in case of errors, I find that more robust.
doom, i normally wrap code that I want to assert at runtime ...
Code:
void SDLReportIfError(int err)
{
if (err != 0)
{
char buffer[1024];
sprintf_s(buffer, 1024, "Error: %s\n", SDL_GetError());
throw buffer;
}
}
...
try
{
SDLReportIfError(SDL_Init(SDL_INIT_VIDEO));
..
}
catch (const char *msg)
{
..
}
Looks a little risky throwing a pointer to a stack variable. ;)
Also, at least according to C++ dogma, you should use dedicated exception classes arranged in some meaningful hierarchy, and throw values rather than pointers.
Also, at least according to C++ dogma, you should use dedicated exception classes arranged in some meaningful hierarchy, and throw values rather than pointers.
_-_-__: I disagree. Exceptions add more structure to your code and eliminates a lot of redundant error checks and much of the mess of nested if statements, switches and what not that surrounds the code you actually want to execute.
The comparison to COME FROM is cute, though. ;)
The comparison to COME FROM is cute, though. ;)
i'm all with doom on exceptions. but, are you guys saying that exceptions are impossible on symbian? that would suck :)
oh btw decipher, thanks for the offer on qmake. i've no problem figuring it out, i just think that the moment you want to do something not entirely standard (in my case, turn the whole app into a lib that statically link into various test exes, using a dedicated build directory), you end up doing a fair amount of $$PWD-related hacking, where in VS2008 i'd just say "that there is the build directory. use it". qmake is well enough documented and forumcommunity'ed to work it out, it's just not entirely trivial.
admittedly though, the fact that i don't know the gcc flags by heart didn't help either (i'm used to ticking boxes and hitting 'browse...' buttons).
admittedly though, the fact that i don't know the gcc flags by heart didn't help either (i'm used to ticking boxes and hitting 'browse...' buttons).
oh btw decipher, thanks for the offer on qmake, but currently i think i'm good :-) i've no problem figuring it out, i just think that the moment you want to do something not entirely standard (in my case, turn the whole app into a lib that statically link into various test exes, using a dedicated build directory), you end up doing a fair amount of $$PWD-related hacking, where in VS2008 i'd just say "that there is the build directory. use it". qmake is well enough documented and forumcommunity'ed to work it out, it's just not entirely trivial.
admittedly though, the fact that i don't know the gcc flags by heart didn't help either (i'm used to ticking boxes and hitting 'browse...' buttons).
admittedly though, the fact that i don't know the gcc flags by heart didn't help either (i'm used to ticking boxes and hitting 'browse...' buttons).
that said, did anyone else notice how recent versions of Code::Blocks took the suck out of makefiles? its build options dialog is remarkably awesome for something made by linux people.
skrebbel: It does suck. But actually I was basing that on outdated information, as it turns out. Symbian 9.x does support C++ exceptions. It was earlier versions that only gave you the leave/trap framework, without deterministic destruction in the stack unwind, but with a separate "cleanup stack" that was so difficult to use they had to justify it by how it "forces a highly disciplined and focused coding style on developers". You know, like disfiguring your child because being ugly builds character.
*bump*
http://www.apple.com/pr/library/2010/09/09statement.html:
...good to know.
http://www.apple.com/pr/library/2010/09/09statement.html:
Quote:
In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code.
...good to know.
Yeah, it was a nice move. Let's see what comes out of it for people who want to create something other than fart-apps or RSS-readers.