Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (6)
to General by Kalatti - 5 days, 8 hrs ago - more...
 |
|
2011-01-22
, 15:37
|
|
Posts: 702 |
Thanked: 334 times |
Joined on Feb 2010
@ Israel.
|
#52
|
Originally Posted by Copernicus
I have just stated that I'm talking from experience, I used to be an N900 developer, but as the phone has not fulfilled my needs, I have sold it and purchased one that does, For that simple reason, and some others, I do not develop for other OSs such as Maemo.
Congratulations! (But are you really interested in only developing apps for one platform? If you, for example, wanted to port one of your apps to iOS, would that mean you'd drop all support for Android? I'm just kinda surprised at the implicit statement here that developing for one platform means not developing for any other platform.)
It is not directly related to my opinion, or the points I have named out, but more to conveying that I am indeed speaking from experience.
If my application is successful enough for me to start porting it to another OS, i'll probably quit my 40 Hours a week daytime job, and have time and money to purchase other phones and develop for more then one platform.
So, you are going to just assume that your app works fine on both Android phones and on Android tablets?
Originally Posted by eitama
Obviously this needs to be tested, but it's not such a hard process, and you can do it all on 1 device, for example, buy a tablet, and constrain your entire UI in a 320x240 frame, see if it works, change size in the emulator.. etc.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.
What amount of RAM are you targeting, and will you warn users of devices with less than optimal RAM that you haven't tested on their devices?
If it is indeed a power hungry application, you will face the same problem on all platforms that feature multiple brand / hardware setups.
True, Google has done everything right for creating a superb environment for development, as one would expect from the braniacs at that company. But I just wouldn't be so complacent about just assuming any given Android app will be a "write-once, run-everywhere" experience...
With MeeGo, unless the SDK/IDE provides for, this won't be possible.
There is a reason why Android Market and Apple appstore are so successful. They are dead easy to use, and do extend the programmers reach to a great portion of consumers, with little effort.
If meego does the same, in one way or another, Kudos, and Great!
__________________
| Developer of Horizontal-Call - Call your contacts, fast! |
| Reverse SSH - access your N900 from anywhere, anytime |
| Using Samsung Galaxy S GT-i9000 and Nokia N900 |
| DonateMe - If you feel I helped you in a very good way, feel free to donate |
| Reverse SSH - access your N900 from anywhere, anytime |
| Using Samsung Galaxy S GT-i9000 and Nokia N900 |
| DonateMe - If you feel I helped you in a very good way, feel free to donate |
Last edited by eitama; 2011-01-22 at 15:39.
 |
|
2011-01-22
, 15:51
|
|
Posts: 1,986 |
Thanked: 7,698 times |
Joined on Dec 2010
@ Dayton, Ohio
|
#53
|
Originally Posted by v13
Oh, no, once again let me state for the record, I fully admit that when moving to a new CPU, a Java app does not need to be recompiled, and a C++ app does need to be recompiled. I believe this is what you are worried about, right? In this, you are entirely correct.
You still confuse the OS and its versions, the peripherals and the architecture.
What I am saying, is that cross-compiling a program is, in today's world, quite trivial. FAR easier than adapting that program to, say, changes in display size or GPU ability.
Heck, you can see this for yourself, simply download and try out the QT SDK from Nokia's site. Years ago, I remember beating my head against the desk trying to figure out how to configure GCC to cross-compile even a trivial program, where to get the correct libraries, how to even get the compiled binary onto the target machine and try running it. Today, they've got this fabulous "scratchbox" environment, and you can create binaries for all your various targets at the push of a button. Try out one of their example programs, like the cute little "drag and drop robot", and it runs just the same on an ancient AMD Atlhlon x2 CPU as on the n900. (The QT SDK can also create binaries for Symbian, but as I don't have a Symbian device, I haven't been able to try it out yet.)
It's true that I haven't done any serious development work in years, though.
Originally Posted by v13
Honestly, do it -- download the QT SDK for yourself, and write a hello world app. Heck, just choose one of their apps. See for yourself just how incredibly hard it is to press a button and have binaries automatically generated for vastly different CPU architectures.
If I write a hello world app for android and upload it to the app store it will run everywhere. If I do this with MeeGo I'll have to do a lot of other work. Of course it is doable, but it doesn't help me at all.
| The Following 2 Users Say Thank You to Copernicus For This Useful Post: | ||
|
|
2011-01-22
, 15:58
|
|
Posts: 3,319 |
Thanked: 5,610 times |
Joined on Aug 2008
@ Finland
|
#54
|
Okay, let me put down a few words on this (disclaimer: these are my personal thoughts, no idea about Intel/Nokia policies, etc, etc).
For the tl;dr people: If you believe the promises of a VM, you've been suckered
It's the typical case "if I don't see the problem, it doesn't exist !". Java programmers should know better - sure, Java has been mostly compatible, but the key word is MOSTLY. There have been plenty of breaks, both binary and source. Dalvik has had the luck of being fairly new and not overly widespread until the past 2 years, so it came with little baggage - but it has baggage now, so any promise 'current Android apps will work on all future Android devices' is marketing talk - it's something to make you feel cosy and comfortable. The idea is that if the changes are small and infrequent enough, you will be forgiving as your time investment is huge, and in reality, nobody runs 10+ years old binary blobs except for retro-IT nerd creds and banks stuck with cobol code anyway. However, wrt to this discussion it's the same thing - it doesn't matter if I have to recompile because of a tiny Dalvik API deprecation, or because of a huge CPU architectural shift. And to appeal to the compiler geek crowd - it's not like C++ can't be translated into bytecode - it's just that it didn't make sense so far, architectures and extensions shifted so fast that your code grew obsolete faster than the architecture changes (think about that one).
Additional disclaimer: My favorite programming language is Python, was a Java guy a while back but nowadays I do C++ based Qt sprinkled with QML.
For the tl;dr people: If you believe the promises of a VM, you've been suckered
It's the typical case "if I don't see the problem, it doesn't exist !". Java programmers should know better - sure, Java has been mostly compatible, but the key word is MOSTLY. There have been plenty of breaks, both binary and source. Dalvik has had the luck of being fairly new and not overly widespread until the past 2 years, so it came with little baggage - but it has baggage now, so any promise 'current Android apps will work on all future Android devices' is marketing talk - it's something to make you feel cosy and comfortable. The idea is that if the changes are small and infrequent enough, you will be forgiving as your time investment is huge, and in reality, nobody runs 10+ years old binary blobs except for retro-IT nerd creds and banks stuck with cobol code anyway. However, wrt to this discussion it's the same thing - it doesn't matter if I have to recompile because of a tiny Dalvik API deprecation, or because of a huge CPU architectural shift. And to appeal to the compiler geek crowd - it's not like C++ can't be translated into bytecode - it's just that it didn't make sense so far, architectures and extensions shifted so fast that your code grew obsolete faster than the architecture changes (think about that one).
Additional disclaimer: My favorite programming language is Python, was a Java guy a while back but nowadays I do C++ based Qt sprinkled with QML.
Originally Posted by v13
I personally know guys in a team who are working on the MIPS port of MeeGo. It's fairly underground as MIPS does not have any wildly popular public reference boards or hardware, but rest assured, MeeGo exists for far more architectures than you think.
Would this be possible for MeeGo? Such a port instantly makes available all android programs. Would mips care to port MeeGo? Would anyone care using MeeGo on mips devices (since there would be no available apps and not available central app repository)?
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
| The Following 6 Users Say Thank You to attila77 For This Useful Post: | ||
|
|
2011-01-22
, 16:06
|
|
Posts: 1,986 |
Thanked: 7,698 times |
Joined on Dec 2010
@ Dayton, Ohio
|
#55
|
Originally Posted by eitama
Exactly. It isn't a very hard process; but, it is something every developer really should take into account. The reason I brought up this consideration in the first place is that v13 worries about the cost involved in recompiling a program for new hardware. My point is that adapting to a new display or new GPU or new RAM takes much more effort than recompiling a program does. Java lets you avoid the recompiling step, but in my mind, that isn't nearly a good enough reason to choose Java over C++ (there are many better reasons for that).
Obviously this needs to be tested, but it's not such a hard process, and you can do it all on 1 device, for example, buy a tablet, and constrain your entire UI in a 320x240 frame, see if it works, change size in the emulator.. etc.
It is true that Microsoft Windows became a monopoly in the desktop OS world by allowing you to run old binaries on new machines, but I think those days are long over. It is far easier to retarget a piece of software to multiple systems today, regardless of the language you use to write the program, and it'll only get easier into the future...
Originally Posted by eitama
I agree completely.
There is a reason why Android Market and Apple appstore are so successful. They are dead easy to use, and do extend the programmers reach to a great portion of consumers, with little effort.
If meego does the same, in one way or another, Kudos, and Great!
|
|
2011-01-22
, 16:10
|
|
Posts: 376 |
Thanked: 511 times |
Joined on Aug 2009
@ Greece
|
#56
|
Originally Posted by attila77
I also am a fan of python (and really dislike java).
Additional disclaimer: My favorite programming language is Python, was a Java guy a while back but nowadays I do C++ based Qt sprinkled with QML.
Originally Posted by attila77
Fair enough. But what about the apps? And I'm really dying to listen some official comments from Nokia's on this...
I personally know guys in a team who are working on the MIPS port of MeeGo. It's fairly underground as MIPS does not have any wildly popular public reference boards or hardware, but rest assured, MeeGo exists for far more architectures than you think.
 |
|
2011-01-22
, 16:22
|
|
Posts: 1,366 |
Thanked: 1,185 times |
Joined on Jan 2006
|
#57
|
The answer the OP is looking for is YES They have thought about this, hence all of the discussions about Meego certification and branding. A key tennet of Qt is ABI forwards compatbility.
As long as the ABI stays stable recompilation is all that is needed (which I need to do whenever I add features). Linux has worked like this for years and runs on everything from mainframes to handhelds, so already a proven model (with well understood issues that cause ABI breaks).
However cockups do happen (like recent hardfp issues with ARM Meego) but in principle as a developer I would feel comfortable to trusting the Qt crew in limiting issues that create ABI breaks.
As long as the ABI stays stable recompilation is all that is needed (which I need to do whenever I add features). Linux has worked like this for years and runs on everything from mainframes to handhelds, so already a proven model (with well understood issues that cause ABI breaks).
However cockups do happen (like recent hardfp issues with ARM Meego) but in principle as a developer I would feel comfortable to trusting the Qt crew in limiting issues that create ABI breaks.
__________________
N900_Email_Options Wiki Page
N900_Email_Options Wiki Page
| The Following 2 Users Say Thank You to mikec For This Useful Post: | ||
 |
|
2011-01-22
, 17:01
|
|
Posts: 255 |
Thanked: 160 times |
Joined on Oct 2010
@ Finland
|
#58
|
What amount of RAM are you targeting, and will you warn users of devices with less than optimal RAM that you haven't tested on their devices?
This is an interesting question, but I doubt it really is anything you need to be concerned about unless you are creating a really, really heavy applications or game. The minimum RAM requirement AFAIK is 256MB for MeeGo and that's pretty plenty.
Not to mention the fact that C++/Qt is less memory-hungry than interpreted or VM-like languages. The difference isn't big by any means, but it still does exist.
This is an interesting question, but I doubt it really is anything you need to be concerned about unless you are creating a really, really heavy applications or game. The minimum RAM requirement AFAIK is 256MB for MeeGo and that's pretty plenty.
Not to mention the fact that C++/Qt is less memory-hungry than interpreted or VM-like languages. The difference isn't big by any means, but it still does exist.
__________________
HAND, n.
A singular instrument worn at the end of the human arm and commonly thrust into somebody's pocket.
HAND, n.
A singular instrument worn at the end of the human arm and commonly thrust into somebody's pocket.
|
|
2011-01-22
, 17:07
|
|
Posts: 1,986 |
Thanked: 7,698 times |
Joined on Dec 2010
@ Dayton, Ohio
|
#59
|
Originally Posted by WereCatf
Very true. I'm just trying to point out, when moving between hardware platforms, there are far more important issues to consider than whether you need to recompile your code or not.
What amount of RAM are you targeting, and will you warn users of devices with less than optimal RAM that you haven't tested on their devices?
This is an interesting question, but I doubt it really is anything you need to be concerned about unless you are creating a really, really heavy applications or game. The minimum RAM requirement AFAIK is 256MB for MeeGo and that's pretty plenty.
|
|
2011-01-22
, 17:29
|
|
Posts: 282 |
Thanked: 337 times |
Joined on Dec 2009
@ Austin, TX, USA
|
#60
|
As mobile processors get better (and we might already be at the point where they are good enough), devices are going to be more like computers and less like iPhones. Multitasking and OS functionalities will become more important and the iPhone/Android paradigm of a single, one-function, full-screen app running in the foreground (with everything else on pause or disposable) will be less important. An OS which can spawn independent OS processes and natively handle multicore processing will win out over an OS which puts everything in the same VM and heavily abstracts the OS from the programmer.
To grow beyond a small screen, single-processor, one-task-at-a-time model, the Dalvik/VM system has a load of changes to make. Linux, and consequently Meego, are already there. Qt and QML are great and--especially if QML ends up running on Android and Windows Mobile in addition to Maemo/Meego and desktop OS's--but the real stuff that is going to make Meego powerful and flexible are DBus, Telepathy, the Linux filesystem and security model, and the years of development on freedesktop.
Don't think just "Angry Birds". Think about having an email/text/im/video communications platform with extensions like Firefox has. Think about Dropbox being integrated into the platform like it is on your desktop instead of a website front-end like it is on iPhone and Android. Don't just think about some remember-the-milk front-end, but think about Cisco writing a VPN client or HP writing printer drivers or Bank of America writing a secure handheld payment system. Basically, a JVM lets you write "apps" that run on lots of phones whereas Meego will let you write both applications and systems that can be deployed to lots of phones.
If I wanted to make more phones like iPhone and Droid, I would probably choose Android. If I wanted to make the next generation of phone that makes iPhone and Droid look like toys, I would use meego.
To grow beyond a small screen, single-processor, one-task-at-a-time model, the Dalvik/VM system has a load of changes to make. Linux, and consequently Meego, are already there. Qt and QML are great and--especially if QML ends up running on Android and Windows Mobile in addition to Maemo/Meego and desktop OS's--but the real stuff that is going to make Meego powerful and flexible are DBus, Telepathy, the Linux filesystem and security model, and the years of development on freedesktop.
Don't think just "Angry Birds". Think about having an email/text/im/video communications platform with extensions like Firefox has. Think about Dropbox being integrated into the platform like it is on your desktop instead of a website front-end like it is on iPhone and Android. Don't just think about some remember-the-milk front-end, but think about Cisco writing a VPN client or HP writing printer drivers or Bank of America writing a secure handheld payment system. Basically, a JVM lets you write "apps" that run on lots of phones whereas Meego will let you write both applications and systems that can be deployed to lots of phones.
If I wanted to make more phones like iPhone and Droid, I would probably choose Android. If I wanted to make the next generation of phone that makes iPhone and Droid look like toys, I would use meego.
 |
| Tags |
| bada rox, dalvik, future, java haters, meego, meego?fail, nokia, sandbox sucks |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 12:01.
NOT
I am just realist. You have same porting problems in with and VM too.
Just look at java/flash on desktop different issues on different OS. An I am sure you have even more fragmentation on mobile platform that probadly is one reason many phonemanufactors doesnt even upgrade android on phones.
Last edited by mikecomputing; 2011-01-22 at 15:35.