Meego vs Android apps (C or Java?)
 

Here's something that I can't answer straightforward and it would be nice to have some comments from Nokia on this.

Let's assume that MeeGo is released and that it's awesome. Now, suppose that other vendors start using it for their phones and it becomes an Android-like OS where multiple vendors are using it. Assuming the current way MeeGo is designed, is that possible?

Let me explain that:

Android apps are written in Java while MeeGo apps in C and other languages like python, but mostly they are written in C and that's what Nokia is pushing indirectly. Even if it is Qt, it's still C. Also Nokia changed the debian packaging to RPM packaging.

Is Nokia ready to handle multiple architectures for MeeGo? Android apps are written once and they run everywhere. MeeGo apps will most probably need to be recompiled (at least) once for each architecture, just like Debian packages.

I personally find this to be a very very hard obstacle for MeeGo adoption and app development. Consider that each app creator will have to provide packages for multiple architecture, something that only Debian does well. A commercial app that is distributed outside of the official repositories will have to be provided for multiple platforms, meaning that the app creator will have to compile it for multiple platforms. Considering the number of different current and future platforms out there, this is a VERY VERY hard problem to solve (if it is solvable at all). For example, an app vendor starting to develop in 2014, will still have to support hardware that was provided in 2011.

From what I can see, this can only be solved if Nokia starts using a language that does not need recompilation everywhere, like Python and Java.

Do you have any hints/thoughts on that?

Re: Meego vs Android apps (C or Java?)
 

recompiling and fixing a few port issues is really no big deal. For C/C++ developers its part of the development cycle.Non issue for experienced devs

Re: Meego vs Android apps (C or Java?)
 

IMO: No it's not. See what happened with 64bit windows support. It's not ready yet (!).

It's not an issue of whether "it is possible" from the developer PoV. It's mostly like this: why write an app that needs adoption for 123745329876 different hardware platforms? And how can this app be supported properly? This breaks the whole "one global app repository" idea, unless something like Debian happens inside Nokia (which I doubt).

Android solves this by using Java and Apple solves this by having one platform. This is somewhat similar to the problem of supporting different OS versions.

Re: Meego vs Android apps (C or Java?)
 

With C/C++ you have to recompile, with Java you need to have a JVM compatible with the target host, so no big differences imo...

If Dalvik is so portable, why we don't have it on Maemo?

Re: Meego vs Android apps (C or Java?)
 

From the developers PoV it's a great difference. One is done by the developer (in fact: by each developer) and the other by the vendor (and only once). Android's approach seems more suited for mobiles since the support of a new device is handled by its vendor.

As for Dalvik, well.. the libraries seem to be tied to the OS.

Re: Meego vs Android apps (C or Java?)
 

Let me throw the question back at you -- why do you think the use of Java or some other interpreted language avoids the issue of different hardware platforms? Right now, if you want to develop for iOS, you can't just slap a program together and assume it will run just fine on all the iOS devices; you've got to deal with many different screen resolutions (original iPhone, retina-display iPhone, and iPad); significant differences in CPU and GPU abilities among the various devices; and lots of variance in odd bits of hardware (depending on the device, there may or may not be a camera, cell phone, GPS, microphone, etc...) With Android, it looks like manufacturers have even more liberty to play around with their hardware.

If you're trying to create a professional app for a particular hardware platform, you're going to want to put some effort into customizing it for the peculiarities of that platform, regardless of the language you prefer to use.

Re: Meego vs Android apps (C or Java?)
 

64bit ports of "old (10 years+)" server and O/S code is notoriously hard because of all the performance tricks developers use (mixing int,long and bit manipulations). Again for an experienced dev in 2011 for NEW code, its not an issue.

Re: Meego vs Android apps (C or Java?)
 

Well sure. But it's another thing to add some "if"s or configs in the code and another one to distribute different binary packages. For example, if N9 comes with meego and it has an ARM CPU and 1000 community-based apps are created and then HTC introduces another MeeGo phone with different CPU, *all* apps need to be recompiled. Do you see the problem? Why would HTC use MeeGo in that case since there will be no available apps at all (at the beggining - which is the crucial point) for its new phone?

Re: Meego vs Android apps (C or Java?)
 

Yet most major Linux distributions do so handily. Fedora, Debian, and Ubuntu all offer ARM builds alongside x86. MeeGo does as well. Hell they all do it when you get the differentiation between x86_64 and x86.

If the architectures are incompatible, sure. But, MeeGo compliance specifies architectures and the tools on hand provide the ability to build packages targeted to each architecture automatically.

Suggesting that only a VM-based language like Java is capable of clean cross-architecture operation is more than a little ridiculous.

Re: Meego vs Android apps (C or Java?)
 

You didn't get the point: It's not a matter of ARM support. It's a matter of architecture diversity and whether it will attract other phone vendors.

I don't believe you understand what you're saying here. I'm not asking if it is possible to rebuild everything. I'm asking if it will ever work and if it will be adopted, or whether Nokia has thought about this. Please read previous posts.

As it is replying without first reading the posts. Unless you consider Python as a VM-based language, that's not what I said.

FWIW, the only available methods for doing this, as far as I know, are:

• Java / VM based
• Interpreted languages (Python)
• LLVM

but you're free to correct me. Also, please don't be offensive. I could also offend you very easily for not replying correctly.

Re: Meego vs Android apps (C or Java?)
 

I can't see why it won't. At the very least, it'll mean competition and price reduction in the mobile space.

I read your posts, and it seems to be mostly wondering if anything not Java can succeed. No one knows at this point if it will be adopted or succeed. But saying that not being VM-based will hinder it is to deny the fact that most *nix based stuff already is cross architecture.

This goes back to the "Store" aspect, which is not supplied by Intel (well maybe, if they adopt an Intel CPU,) Nokia, or "MeeGo" but by the hardware vendor.

Python could be considered a VM-based language, as it can be "compiled" to some extent.

Sure, if you want to JIT your software.

Re: Meego vs Android apps (C or Java?)
 

Gee - I download tgz files all the time and compile them on my distro and hardware
which is virtually always different from the distro and hardware it was developed on.

And most of the time it just works.
When it doesn't, I lose a few hairs, but nevermind.

As long as the file structure, APIs, etc are all the same I don't see a problem.
They aren't necessarily talking about compiled apps,
and if they are then whoever mandates that paints themselves
out of the marketplace.
It is the closed-source compiled apps with trojans and other malware
that are driving the Android trainwreck
into a place where your sexy new android handphone
may not be welcome on some corporate networks.

Re: Meego vs Android apps (C or Java?)
 

I see the difference; but I don't really see it as a problem. If you're developing commercial closed-source software, you don't actually want people casually copying your software from device to device, and so the inability to run your binary on a new cpu (without you recompiling and repackaging it yourself) is actually beneficial.

And, of course, if you're talking about open-source software, there really isn't a significant difference. Honestly, recompiling is (for the author of a program, or for anyone with the source code,) a fairly trivial process these days.

I believe that reworking your interface to support different icon and text sizes, working around the existence or lack of hardware 3D support, dealing with differences in available RAM, etc. have a far more significant impact in porting apps from one machine to another, than whether that app is written in an interpreted or a compiled language.

Re: Meego vs Android apps (C or Java?)
 

Exactly! AFAIU it won't be easy (or possible) to have a common store for all different phones out-there. So, assuming that there will be multiple stores, a developer will have to upload his software to different "stores". But then again, that's not practical.

Let me rephrase the whole question: Can you (or anyone else) describe how the whole MeeGo app thing will work? I suppose that if the first device will be introduced in a couple of days, this should be already considered and decided by Nokia/MeeGo people (since they don't seem to discuss policy matters with the community).

Also, I'm not claiming that a VM (or Java) is the only solution for this. In fact I dislike Java. I'm just saying that at this point, after considering all the above, I finally understand why Google went with Java for Android.

Re: Meego vs Android apps (C or Java?)
 

Been to Apple's app store lately? Your first choice: select either the iPhone app store, or the iPad app store. Check out the Ovi store some time; it's more unified than Apple's store, but you still need to tell them which phone you have (at which point they can filter out the apps that won't run on your phone). I haven't yet tried the Google's store, but Android is still a very young system; give it a few years, and I'm sure it'll be forced to bifurcate in exactly the same way that the more mature systems have...

Re: Meego vs Android apps (C or Java?)
 

i'm not so sure on the technical aspects/development side, but you cant say things like meego devs in 2014 will have to support 2011 hardware, they won't, even android which you're comparing it to doesn't do that. there are android apps which simply won't run on the low-end phones released the same year, and every time a new build of android is released a lot of the apps need to be modified and re-uploaded.
personally, i dislike the way of building the one-size-fits-all type apps you are looking at, simply because you're catering to the lowest common denominator, instead of building for maximum performance you build for maximum compatibility which in the phone market can be a huge difference! we've been playing java games cross platform for years now, just find the right resolution for your phone, but with the n95 for example the java games came nowhere near the quality of .sis games designed specifically to utilise the n95's (at the time) power.

Re: Meego vs Android apps (C or Java?)
 

Much more straightforward. And is this how I understand it, for good or bad:

Vendors become service providers, which is what they want.

Much like how Nokia has Ovi, vendors will provide their own stores (which could be set up however they wanted) tailored to their own devices. The concern you share is shared by me, but I suspect that they'll move this way regardless and push against Google.

And Nokia's solution, regardless of architecture, will be Ovi. MeeGo is almost completely detached from the "store" concept aside from specifying what a "compliant application" and a "compliant device" are, as well as providing an upstream to base a device on.

Java wouldn't really resolve this issue, IIRC that was chosen mostly due to its popularity in the mobile space already. Google's focus has been on keeping themselves in the game,

Re: Meego vs Android apps (C or Java?)
 

To the threadcreator:

Are you saying apps written for Android 2.3 is working on old Android like 1.5? I dont think soo!

Also you saying Meego is written in C, well if you mean lowlevel API its true. If you mean highlevel API like QT then its C++ and QML(javascript based) and sometimes python(not officially supported) language like QML and python is similar to VM atleast for the developers.

Also if you think Android is just pure java in lowlevel your really are wrong. there are plenty of C++/C code in android too so I dont get your point at all. Also advanced games written for Android is non java and pure C++.

Another thing I personally dislike the fact to make a world where everyone is úsing exactly the same OS.

People want choices! Atleast me. I dont give a **** if there is plenty more apps in Android. I still prefer Maemo/Meego. I dont wanna get feeded by some company saying what I shal use.

The "Microsoft way" of feeding people with its OS is over.


BUT you have one point when I thinking. The facts that Intel is a chipmanufactor and the Meego so far has progressed mostly on Intelplatform is a bit bad in way of choices if it end with only Intel chipset support.

Re: Meego vs Android apps (C or Java?)
 

A large percentage of mobile apps will be possible in QML, as far as I understand it. It seems to be enough for the standard 'get data from $website -> fancy display' pattern that most mobile apps fit into. The ones that won't are games and such that will be dependent on hardware on any platform, so I'm not sure this will be a problem specific to meego.
On the other hand, I'd agree that a load of binary only C programs would be less than ideal for meego long term, if it turned out like that.

Re: Meego vs Android apps (C or Java?)
 

It doesn't have to be multiple stores. It could still be one store just like OVI is and support multiple platforms which OVI does. As far as a developer doing uploads it depends if they want to support multiple chipset architectures and/or devices. Qt is the common denominator so currently you would only have to compile for ARM or x86 (i.e. you could compile once and support Symbian and the N900) assuming you have the necessary ifs for differences.

Re: Meego vs Android apps (C or Java?)
 

Well, QML is very, very much more powerful than this. In fact, you CAN create games using QML and C++, and I'm not only talking about 2D games (http://quitcoding.com/?page=work#5inarow), but also 3D ones (http://labs.qt.nokia.com/2010/08/10/qml3d-demo/).

Re: Meego vs Android apps (C or Java?)
 

I have one small point to add. Isn't Symbian written in C++? I don't see any recompiling done there. The same app will run fine on an N95 and on a N85. The same app will also run fine on an N8 and C6. So why should an application, just because it is written in C need recompiling?

If the vendors stick to the same architecture and Meego is programmed to cater for these differences, I don't see why it can't succeed. If Meego gets seperated in x86 and ARM..there's the big problem then...

Besides even if apps have to BE recompiled, it might prove a good idea in a developer's point of view. It will seriously hinder piracy for one thing. In Android, there are torrents with 3000 pirated apps and games. These will work on every Android phone there is. If they needed to be recompiled, they could only work on one phone only.

In a user's point of view it would prove useful to have an app for a certain phone only. What if a phone comes out with some type of Kinect for example? Would a developer bother developing the app to use it if all other phones don't have it? But having an app specifically for that phone would prove useful.

These are all what ifs after all. There's absolutely no reason why being written in C should require any recompiling. The OS should handle everything from scaling of different resolutions to the way different architecture might handle it. I don't see any games on a PC having to be recompiled to run on a Pentium 4 or a Core I7. Or having to recompiled to run on a different resolution. It is ridiculous to suggest this should be done on mobile platforms. The OS should handle these things. The OS should be slightly modified for different platforms, but that's it. It would still be more efficient than a VM environment.

Symbian does this well. Meego should too. (I used the word should..).

Re: Meego vs Android apps (C or Java?)
 

Those are not different architechtures: they all sport ARM processors. Thus there is no recompilation needed. It would be different between Atom-based MeeGo device and an ARM-based one: there you'd need recompilation. I don't think that will be a large issue though as most portable devices where MeeGo is aimed for are ARM and will continue to be ARM.

And the OP was incorrect: native Qt apps are C++, not C.

Incorrect. Look above answer.

Re: Meego vs Android apps (C or Java?)
 

I think this is all wrong.... Nokia and Intel would not spend time, effort and resources to make an operating system that is "App-centric" but requires the developers to tweak all their apps for each device.

What is taking a long time is to make this a platform perfect from the get-go (unlike WP7 which was rushed before Android dominance became too difficult to penetrate).

Nokia and Intel are trying to make a developer kit on Qt ... that once you create an App using those libraries, it will be supported on ALL Meego devices regardless of processor diversity (ARM) or even architecture (x86 Atom). And this makes sense, nothing else does.

And if that is not the case (ie all apps need tweaks for different devices or architecture) then Meego will fail badly, along with Nokia (and at best they will be in the niche like Palm).

Re: Meego vs Android apps (C or Java?)
 

No. I' just saying tha apps written for Android 2.2 will work for all phones out there tha use Android 2.2 and most probably in most future androids (unless of course it requires specific hardware like a magnetometer).

I'talking about the application packages. Not the OS.

And python is not considered VM-base like Java. It is conasidered to be interpreted and it doesn't need recompilation, even if it uses a VM internally.

As for QML, it is not adopted yet so until I see something big written in it I prefer not to consider it.

Re: Meego vs Android apps (C or Java?)
 

Try considering the example I mentioned elsewere: MeeGo becomes an Atom-based success and HTC introduces an ARM based device. How will OVI work in that case? Will there be any application available for the HTC phone at the begginning?

For ovi to support multiple platforms:

1. The vendors must provide multiple binaries, which is only possible for phones that are already released, or
2. It must become a repository where the developers will upload source code (practically impossible for non-opensource apps).

The more I think of it, the more I believe that it will alienate other phone vendors...

But part of the original question still stands: Did Nokia and Intel consider this?

Re: Meego vs Android apps (C or Java?)
 

Qt simply doesn't work like that, it is not a VM-language nor interpreted one. A Qt app compiled for ARM will not work on x86 (Atom et al) and vice versa, it needs to be re-compiled.

Re: Meego vs Android apps (C or Java?)
 

That would mean there will be at least two developer kits. One for ARM-based and one for x86-based. And if that's the case, MeeGo will be fragmented upon birth.

I'm having a real hard time believing Nokia and Intel went to all this trouble for that. (I mean if that's the case then Nokia didn't really benefit by teaming up with Intel - contrary to what they said).

I don't know, something smells fishy.

Re: Meego vs Android apps (C or Java?)
 

A few thoughts for you.

No, it's C++.

Correct.

It isn't an obstacle at all.
In Qt Creator I can compile my app for the desktop and also ARM, all with a push of a button. AFAIK MeeGo's OBS (build system similar to Maemo's Autobuilder) also compiles for both ARM and x86 automatically.

Re: Meego vs Android apps (C or Java?)
 

No, you don't understand. I don't know if you have any programming experience or not, but anyways, the same libraries, kits, source-code and all can be used, you just re-compile the app. No need to modify anything or create two sets of source-code or anything like that. It simply means that you can't just copy the same binary file from ARM device to Atom or vice versa.

I don't see why you think there would be the need for several entire development kits, it simply doesn't work like that.

Re: Meego vs Android apps (C or Java?)
 

There is one wrong assumption in this discussion, that there won't be a Java VM under Meego.
Who knows?

Re: Meego vs Android apps (C or Java?)
 

Actually, the wrong assumption in this thread is that Nokia are interested in hosting apps for other handset manufacturers in Ovi. The MeeGo community repositories will host packages for each supported architecture. Nokia Ovi will host a repo specific for their devices. From an ISVs standpoint the benifits of using MeeGo are not being tied to Google app store, each vendor can have their own app store. This will be very liberating for vendors and will give them their power back.

Re: Meego vs Android apps (C or Java?)
 

But isn't that "old mobile"? Since the power of the phone's OS is partially its applications (like iphone's and android's), isn't that assumption a step back?

Anyway. What we really need here is a statement from Nokia people that have insight of what's happening there. The thread is not meant to be a good or bad Nokia/MeeGo/Intel/Whatever. It's just a question: Did Nokia/MeeGo/Intel thought about this? And if so, what's they're standing?

Re: Meego vs Android apps (C or Java?)
 

Yes, they've thought about it. Qt is their platform, write once deploy everywhere.

You may think having a single app store like google is the future. But given the opportunity any ISV would want their own app store, like apple, like rim and like Nokia. It's a no brainer income generator.

Re: Meego vs Android apps (C or Java?)
 

Android supports multiple non-official stores (read: APK repos). There is no requirement to use the Google Android Market to run Android.

Currently it seems that the Google Market is the largest by a wide margin, but the times they are a-changin'. Amazon is launching a Android specific app store with an interesting sales model. , Samsung, Verizon, etc, etc, also have very small stores. There are also stores unaffiliated with Android or devices like AndAppStore, App Brain, and Appslib.

I make no assertions in regard to said store's quality, but they do exist. Bottom line: Android OS is not irrevocably tied to the Android Market, though it may appear that way based on popular distribution.

The APK container format, Dalvik, and well thought out Android SDK make many apps extremely portable. I expect more stores to pop up with competing propositions, as well as a general quality to improvement given time.

Re: Meego vs Android apps (C or Java?)
 

I didn't know that, I presumed the store was just another Google service handsets were locked to, well that's good to know.

Re: Meego vs Android apps (C or Java?)
 

Honestly, this is not a problem, unless you're talking about software applications that no longer have support. If I'm a vendor, and a new hardware platform comes along whose only difference from my current platforms is a new CPU (upon which the old OS is running), I'll have no trouble rebuilding the app for that platform. If you're talking about an app whose designer has moved on to other things, well yeah, that orphaned product won't run on the new device, but that's kinda how it works for computers everywhere...

Ovi supports multiple platforms today! Search for Angry Birds; you'll be able to find it for both Symbian and the n900, and I'm sure those are not using the very same binary...

Re: Meego vs Android apps (C or Java?)
 

I Can see V13's point very clearly, As a former N900 owner, and a Former Maemo Qt developer, Now an android owner and developer,
I can already feel how much easier maintaining an android app is - compared to a C++/Qt application, and also how much more rewarding it is.

The Goal (as I understand V13 is thinking about it) - Give developers easy tools, to develop, distribute, maintain and sell applications, while rewarding them properly with income to keep them coming once more.
Once this goal is achieved, in my opinion, an OS which aims to run on multiple brands and architectures, has a good fighting chance in todays market.

Standing between that goal and the current situation are multiple aspects, let us analyze them.

1. Different form factor / onboard peripherals
2. Different CPU architecture
3. Different distribution methods.

The problem of having to take into consideration multiple form factors and added features, in the essence of peripherals, is a common one to all modern smartphone OSs. Android / Meego / And surprisingly, even apple, have this problem.
The developer must write his app to use the correct hardware, if available, and the UI needs to be able to adapt to screen size / resolution.

Different distribution methods is where so far, the N900 has been failing at, and we just don't know yet if MeeGo will address this problem with an adequate solution.
There is no doubt that the ease in which the Android market and Apple app-store allow developers to upload an application which will intern be able to be executed and used correctly on a very big quantity of end-user devices, is appealing towards developers.


As for CPU architecture :
Personally as a developer, I don't want to have to test and own 5 different devices just to be able to check if my compiled binary file really runs on all different 5 architectures. I don't have time to do it, and don't have the money to do it.
If the development IDE / SDK, allows me to select from a list of checkboxes, to which architectures I'd like to compile, and automatically upload all binaries to Ovi store, and this will really work, then we don't have a problem.
Currently in C++/Qt developers have to use #ifndef's to include/exclude hardware / distribution specific code to make things work both on Maemo and S60 and MeeGo.
If this will stop when meego is around, by supplying all the required tools via an API, this is again one step closer to allowing a batch compile to multiple architectures.

Finally, the whole thing should be easy to perform and require little time. Fast penetration with a large market of applications is necessary to succeed.

Re: Meego vs Android apps (C or Java?)
 

the reason for non JavaVM is QT(especially QtQuick) please read more on QT before all bashing about non javaVM. There is no reason to have it! writing more advanced games etc == you have to learn c++ thats the case in android too!

And about QtQuick: QtComponents(written in QML/javascript) will replace todays Libmeegotouch UI in meego that was written in C++ and now most done in QML language. also it seems symbian will use it (=arm cpu:s).

Latest release of QTCreator has already support for different targets: arm/x86 and even different os:es like Linux, Windows, Macosx, Maemo/Meego, Winmobile...

And about the progress in this areas: Public repository avaible at gitorius.

Re: Meego vs Android apps (C or Java?)
 

Except from one case: Future devices. Android apps are guaranteed to run on future devices as long as they run a compatible OS version and most probably they will run faster and take advantage of the new hardware.

But when using MeeGo, who will dare (or care) to introduce a new architecture or improved hardware? It's not only a matter of architecture. Even an improved instruction set or extra registers will be useless if you have the same binaries, just like it happens with Debian (all programs are compiled for ridiculously old hardware).