pouët.net

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?
added on the 2010-08-30 22:35:51 by skrebbel skrebbel
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.
added on the 2010-08-30 22:38:33 by skrebbel skrebbel
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. :)
added on the 2010-08-30 22:43:43 by decipher decipher
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.
added on the 2010-08-30 22:48:17 by decipher decipher
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.
added on the 2010-08-30 22:48:44 by skrebbel skrebbel
Irony? There absolutely was no irony. Everything is seriously perfect about Qt over here. :)
added on the 2010-08-30 22:54:02 by decipher decipher
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.
added on the 2010-08-30 23:04:04 by skrebbel skrebbel
Skrebbel: I might help about that one. Skype. :)
added on the 2010-08-30 23:08:17 by decipher decipher
True. Qt is damn good! Haven't tried developing mobile apps with it though...
added on the 2010-08-31 00:12:37 by raer raer
I only wish Qt would throw exceptions instead of using error codes, booleans and "get last error" type methods.
added on the 2010-08-31 08:22:47 by doomdoom doomdoom
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.
added on the 2010-08-31 08:54:39 by decipher decipher
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.
added on the 2010-08-31 09:24:16 by doomdoom doomdoom
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. ;)
added on the 2010-08-31 09:34:15 by doomdoom doomdoom
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.
added on the 2010-08-31 09:45:03 by _-_-__ _-_-__
I prefer objects to turn into "null objects" in case of errors, I find that more robust.
added on the 2010-08-31 09:46:42 by _-_-__ _-_-__
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.
added on the 2010-08-31 12:14:17 by doomdoom doomdoom
_-_-__: 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. ;)
added on the 2010-08-31 13:05:17 by doomdoom doomdoom
i'm all with doom on exceptions. but, are you guys saying that exceptions are impossible on symbian? that would suck :)
added on the 2010-08-31 14:09:11 by skrebbel skrebbel
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).
added on the 2010-08-31 14:15:28 by skrebbel skrebbel
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).
added on the 2010-08-31 14:15:50 by skrebbel skrebbel
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.
added on the 2010-08-31 14:18:03 by skrebbel skrebbel
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.
added on the 2010-08-31 15:16:43 by doomdoom doomdoom
*bump*

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.
added on the 2010-09-09 17:19:12 by gasman gasman
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.
added on the 2010-09-09 22:25:25 by gloom gloom

login