Qt 5.1 Released With Android and iOS Technology Previews

http://blog.qt.digia.com/blog/2013/07/03/qt-5-1-released/

by emwa • 13 years ago

95 50 13 years ago

blog.qt.digia.com

stevelaz• 13 years ago

This is awesome. Congrats to the Qt team for a what looks like an excellent release! I can't wait to get my fingers dirty with this.

ge0rg2• 13 years ago

Very impressive work, especially with the mobile integration! I hope this will become the next generation of multi-platform development tools, combining performance and flexibility.

However, the Android demo apps are 16MB and 23MB in size, respectively. For the larger one (Introduction to Qt5) the uncompressed sizes are: 9MB of data, 26MB native code, 134KB of dalvik code.

This looks like a major burden for low-end devices, even though I must admit the demo is looking great (and performs rather fluently on my HTC Vision, running Android 4.2.2).

pjmlp3• 13 years ago

This is what puts me away from using Qt for Android development.

One of the advices of Google IO this year was to try to keep applications small.

According to Google bigger applications are the ones that get deleted first when space gets short. Most of the time are never reinstalled.

ge0rg2• 13 years ago

I consider the memory footprint even more important, though it is hard to find strong relations between APK size and memory use -- except for the "looks like the dev did not care at all" rule.

Regarding APK size, you can do miracles by using ProGuard (even with obfuscation disabled), though it will obviously fail for native code, like in the Qt case.

peterbotond• 13 years ago

the QT team in the past constantly improves their codebase, so i believe the numbers will be better. i use qt since 3.1 and see the improvements in general.

joezydeco• 13 years ago

Something makes me think that the native code is dynamically loading in the entire QtCore, QtGui, and QtDeclarative libraries to make the native side run.

When you build a Qt app statically you can strip all the unused functions out. But doing it for loading by the Android NDK? That seems a little trickier. You'd need to rebuild the libs specifically for that application.

Maybe there will be a better solution in the future to handle this, but it also seems likely that the native side wouldn't grow much past this size (i.e. 1 line of "hello world" is 26MB but 100,000 lines of real application code would only grow to 28MB.)

icefox• 13 years ago

When silly puzzle games have hundreds of MB of assets it is okay, but this is a lot? Users don't seem to care or all of the "lets recompile our flash junk" that eats 500MB+ wouldn't do as well as they are doing. If app size matters it is usually the assets that need to be trimmed first.

What would be nice if in the app stores they showed how much space your app would you and let you sort on that, give some sort of incentive to reduce your size.

mehrzad• 13 years ago

No need to get upset at GP. A lot of low-end Android phones have little internal storage and installing to SD is not a default thing. I'd be that most Android apps are under 15MB and a lot of apps that I use are under 3.

X4• 13 years ago

That's the first official Android release! Too early to complain, but Qt is opensource, you can improve it, even if you don't know programming. Just file a bug or drop a note in the forums and help developers debug.

programminggeek2• 13 years ago

Well that's cute.

programminggeek2• 13 years ago

It's really hard to make a play on words on the internet.

pbsdp10• 13 years ago

"I wish my apps were written using a poorly integrated non-native toolkit" said no actual user, ever.

Nobody wants a Qt-based application port, for most of the same reason nobody wanted a (Java) Swing-based port. They don't want ports, they want native apps.

The only people who want to provide Qt-based apps are developers that want to put themselves ahead of their users.

[edit] Perhaps downvoters can reference a cross-platform widget toolkit that was successful in the market? So far, Java, Qt, WxWidgets, and Gtk have not succeeded as cross-platform GUI libraries. Are there any break-out successes I'm missing?

Otherwise, I don't see what the complaint is, so perhaps you can elucidate and downvote.

dman3• 13 years ago

How native are websites? Dont you use them on mobile devices?

pbsdp10• 13 years ago

How are websites holding up against the native App Store apps for apps?

maggit• 13 years ago

Is Qt 5.1 poorly integrated with Android? Have you experienced this, or are you simply assuming it?

Working with Qt could be a huge productivity boost for me compared to working with the standard Android SDK. I could have more time available to make it look and work well, and I would be able to reuse core application code (not UI code, mind you) across platforms.

Isn't it premature to declare this a categorical disadvantage for the user?

pbsdp10• 13 years ago

Isn't it premature to declare this a categorical disadvantage for the user?

No, we've had about 10-15 years to prove, repeatedly, that "write once, run everywhere" UI never works.

I would have more time available to make it look and work well, and I would be able to reuse core application code (not UI code, mind you) across platforms.

Qt brings in their own UI code, but if you didn't want to use it, you'd have to bridge to Java via the NDK. Possible, but a lot of work, and involves tossing a lot the value of both Qt and the Android SDK.

shadowmint2• 13 years ago

I wish I didn't have to write my f##$@$ing apps in java and then again in objective-C and then again in C# said every developer, ever...

Edit, for your benefit: xamarin, unity.

pbsdp10• 13 years ago

Yes. And users still don't care, and they're the ones that pay for the work.

morsch• 13 years ago

Cross platform UI tools failed in so much as they failed because a) they were reduced to the smallest common set of features of all targeted platforms and b) they failed to provide a look and feel that was indistinguishable from the native toolkit.

Neither of those two seems necessarily unsolvable, however to a certain degree it forces the developer to give up many of the benefits of using a cross platform toolkit in the first place.

Of those two, b) is the more obvious one and the issue that is typically raised. I'm not sure how well Qt5.1 solves it for desktop apps. But looking at my mobile apps, they're already varying wildly in terms of look and fee. I don't think Qt apps will stand out. Mobile platforms are also fairly similar in terms of feature sets, so there's less work to do to solve a), but developers will still have to deal with different handling of notifications, etc.

drone• 13 years ago

You act as if Qt isn't already a successful cross-platform toolkit. Qt has been successfully used for years to make native-looking apps for OSX, Windows, and Linux from the same codebase.

How are you saying Qt has not succeeded as a cross-platform GUI system, or that it produces non-native apps on the platforms it has historically supported?

And yes, my customers -do- want my software to run on Android and iOS just like it runs on Windows, Linux, and OSX - and they don't particularly care in what toolkit it is written. I do, however, care about having to re-write the same code in three different languages.

mpyne2• 13 years ago

First off, Qt is native for quite a few Linux GUI desktops. So there's no "port" for those.

But even beyond that, the toolkit you're referring to (QtWidgets) is only one part of Qt itself. In fact I rather doubt you'd ever use it for an Android application, preferring instead QtCore plus the declarative U/I handling.

Much of Qt is code you would otherwise be writing /anyways/, only they did it for you, did it right, and even documented it with examples of how to use properly. For instance, event loops, abstract I/O, Unicode string handling, concurrency, atomics primitives, networking support (including integration into aforementioned event loops and abstract I/O), and much more.

As a side effect of coding to a thoughtful, high-level API you happen to make cross-platform development easier, but that's hardly the only reason to use Qt.

Either way the fact that you don't instantly recognize Qt apps when you see them is proof positive, as they are out there in much higher numbers than you seem to realize...

pbsdp10• 13 years ago

Either way the fact that you don't instantly recognize Qt apps when you see them is proof positive, as they are out there in much higher numbers than you seem to realize...

No, they really aren't.

coldtea2• 13 years ago

First off, Qt is native for quite a few Linux GUI desktops. So there's no "port" for those.

That's because Linux has no "native" GUI. It's a hodgepodge of GUI toolkits.

That said, the de facto standard on Linux desktop has been GTK. It's what the major players, that is the most popular distros, support by default.

So QT is only "native" (in the look & feel sense that we're discussing here, not in the runs directly on the machine sense) if you target some marginal distros. Which kind of defeats the whole argument.

Much of Qt is code you would otherwise be writing /anyways/

Not if you used Google's native SDK.

Either way the fact that you don't instantly recognize Qt apps when you see them is proof positive, as they are out there in much higher numbers than you seem to realize...

Huh? Who said you don't recognize them? On the Mac they stick out like a sore thumb.

veeti• 13 years ago

Qt works excellently on desktop and is the only realistic choice for native look & feel across Windows and Linux.

I'm pretty sure it's going to be a disaster on Android and iOS because they are so radically different from each other and they don't even seem to have any plans for native L&F, but you couldn't be more wrong when it comes to PC apps.

blinkingled• 13 years ago

"I wish my apps were written using a poorly integrated non-native toolkit" said no actual user, ever.

Said the guy who's only had to write single platform, toy apps. Try dealing with complex cross platform apps some day and you will understand why Qt is a great solution at least on the desktop where complexity is much higher than mobile apps which are for the most part toys.

On mobile you have a choice - if your app is more about funky UI than complex functionality - go wild and write straight to native or limit yourself to one platform. But on the desktop - a well designed Toolkit like Qt is godsend and you would be crazy not to use it even for single platform app.

pbsdp10• 13 years ago

Said the guy whose only written Windows (and maybe Linux) apps.

frozenport2• 13 years ago

Java is extremely successful for example Matlab and Mathematica use Java for crossplatform GUI.

blub• 13 years ago

Even without using any UI code, having the possibility of writing your entire backend in a cross-platform way is a big advantage. I am rather skeptical about how well Qt UI can work on mobile, but I would definitely use the libraries that cover everything-not-Cocoa.

shadowmint2• 13 years ago

Great work! Nice seeing QT actually trying to be relevant again, now it's escaped the clutches of Nokia.

Here's hoping that Google doesn't decide to depreciate the native apis on android now there are a few options to write apps that don't involve using their crazy lock-in java api.

frozenport2• 13 years ago

Also improved opengl and opengl binaries.

Qt 5.1 Released With Android and iOS Technology Previews

Related Stories