I am developing a program that is going to be very performance-intense for Android/smartphones. Because I do this on a pc (Windows) I do not really know how my application will perform on a mobile device. I do not want to port this program to android until I have a good working version for Windows (this will be my first Android-app and I don't want to try to troubleshoot something when I'm not even sure whether my program is working).
I am searching for some database where I can compare pc-GPUs with mobile GPUs. I know that an accurate comparison is difficult between such different architectures, however, a small hint about the expected performance would be very helpful.
By the way, I am developing on a machine with an integrated Intel® HD Graphics 4400 and ideally, I want to compare it to something like an Adreno 306.
Rather than using benchmarks for the GPU, look at existing cross-platform applications with similar performance and see how it compares. Install it on your computer to make sure the intensiveness is similar (using whatever benchmarks you want), then install it on your android device to see if it can keep up to your expectations. You can find benchmarking apps or you can use the profilers on Android Studio to see how the device in question is handling the application.
This is about as good as you're going to get. Like you said, so much relies on the implementation and the vastly different architecture. Lastly, if you're building on a framework that builds to other platforms (libgdx, xamarin, etc), you should present a specific question to other users of that framework.
I need to make an architectural decision for developing (actually porting) my embedded solution.
I will try to present my case as clearly as possible, and any advice I can get will be appreciated.
Introduction
I have an embedded system, currently developed on ARM11 architecture and ArchLinux OS. It is implemented using all kinds of technologies available under Linux, including C, C++, Bash and Python.
At this time, I would like to port my solution to a tablet, so I am trying to make some decisions about the architecture, based on the requirements of my system.
Requirements
The system is modular, and it runs multiple processes and threads. It also communicates to remote servers and controls the hardware peripherals. These are the basic requirements, at the moment, I will update as discussion develops:
Primary:
Dedicated system (minimum amount of other applications running, even in the bg)
Multiple processes, ability to set priorities
Ability to assign a process to a single CPU Core (cpu affinity)
Inter-process communication mechanisms
Complete hardware control (WiFi, 3G, GSM, mic, speaker, display, ...)
Creating sockets, etc.
Other:
Ability to connect a microphone directly to a 3.5mm plug (TRRS connector)
Mainstream solution to ensure reliability
Future-proof: minimize the porting effort for new tablets and HW
My questions
What tablet and OS combination would meet these requirements?
How to approach the "dedicated solution" requirement?
How to approach the software development, what language and tools to use?
My investigation so far
My investigation so far has been concentrated on the OS choice. The main options seem to be Android and Ubuntu Touch. Here are my thoughts:
Android
Android wins in the mainstream category obviously, but...
I have no experience of Android development, but as far as I can tell, I can either develop a Java application that runs on top of Dalvik, or I can go native via Android NDK. Maybe I can even bypass the whole thing and go native side-by-side of Dalvik, and develop in Python? I guess then I will lose the access to the API for HW access. Not sure how I would access the HW then. But if I go with Java development, this is a sandbox solution, and I am not sure if I can have such a control over the processes, HW and CPU core affinity?
Ubuntu Touch
Developing on Ubuntu Touch would be more like Linux development I am used to, since it uses Qt. The issue here is that the applications are developed using the SDK that restricts me to HTML5 and QML, which I'm not sure can allow me the same control over the system I need. If I use Python and avoid the SDK, same issue arises - how do I control the HW? Of course, there is a way to do it like on a regular embedded system I guess, but I don't want to reinvent the wheel if I don't have to.
Also, it seems that Ubuntu Touch hasn't been ported to many devices yet, only a handful of them are supported.
Finally
I am not sure how well I have presented my case, but I will update the question as needed with further explanations and requirement details. Thank you for your patience, your time and any help you may offer.
I am in the same boat as you, we are developing embedded system on ARM CPU. Currently the system is written in Python on custom built linux distro from hardware vendor.
We have been looking at Android and Ubuntu Touch for a few months. So far we didn't get any decision yet. But here what we found out from our incomplete analysis:
Android is quite heavy system, that also brings JVM into the mix. So you HW and memory requirements will significantly increase.
Android likes to take over the entire system, so sometimes you might be fighting with Android.
Android has very good IPC mechanisms, not available on mainstream linux kernel, such as Binder. Of course you can port it to another system. But this would be considerable effort.
Android has very rich GUI interface, also with things like NDK view you are not confined into the JDK box.
Android doesn't use standard GNU C library, it uses something called BioniC which is a port of C library from BSD. Usually it is not a problem for most software, but if you are using some linux specific low level features, like working with serial ports you will need to tweak your code. See what I had to do to port Java RXTX library to android https://github.com/vladistan/gnu.io.android
You can find a lot of Android developers out there who will do basic GUI programming for you, while you are concentrating on your app specific stuff. Interfacing between GUI and low level things is quite easy using binder. And of course you can bring in whatever mecahnism you want via NDK.
We have considered Ubuntu Touch. But so far it doesn't seem to be mature enough.
I am pondering the idea of a Wine-ish compatibility layer on Android.
The idea is to run Symbian apps on it as both OSes share ARM hardware.
I have no knowledge of Symbian but I think that given the hardware capabilities of Android devices this could be done with less effort than Wine's windows emulation.
What would be the most significant difference to overcome in this emulator? (threading, storage, ...)
The real problem is not going to be code execution, but the API's to do things like graphics, interact with hardware, accept input, etc. If you have documentation of the original and android has the capability, API translation layers would be possible.
But android's security model outright prevents a number of things that are possible on other phone platforms, and combined with it's "java apis only" allows only inefficient means of doing things that can be done more efficiently on others.
This is of course all about application-level emulation/api translation. If you are willing to modify the android platform itself, supporting just about anything else for which you have documentation (and licensing?) within the hardware capability of the device should be possible.
Hardware capabilities of a device have nothing to do with complexity of an emulator to be hosted. It depends on Symbian's design and complexity.
And, even more, licencing. Even if one could make a Symbian emulator for Android, its legality would be questioned.
It's difficult to answer your question in detail, but since Symbian is open sourced (and Android too), if you've got the time, it shouldn't be too hard to see what sets them apart.
QT is used for the latest symbian OS, and has been ported to Android, you could write apps in QT build for each platform
the problem for writing an emulatir are variouss.
If the Symbian apps are written in in an interpreter language like Basic or similar then an emulator couldn't be too difficult to write. I did such stuff once to make the same code run on linux and windows, and I used a translation API for all calles coming from the software directed to UI, input/output.
I wound guess that the UI capabilities of Symbian are a subset of the Android functions so it would be not too difficult to write a WINE alike thing or an interpreter that runs the Symbian code on different hardware - IF it is only in high language.
But be aware there could be some machine code in the appps and that is processor specific. Most of the Android tabs nowadays run on Tegra, Tegra2 or (soon) on Tegra3, some may run on StrongArm or Arm, some may run on Intel Atom (x86 architechture), so this might get more or less impossible if the CPU isn't binary compatible like ARM / ATOM. Then you need to emulate the CPU as well and that might eat so much performance that you need a 4-5 times stronger machine to run that stuff smoothly.
It won't be too difficult to crack Android to execute Linux-alike binaries, but for sure this "mod" will affect the ability to use or download stuff from regular appstores.
With some apps you might have even more headache, e.G. my MP3 player from Korea runs on Strongarm, but it also executes Flash games from various sources. When there is no Flash player - and Google announced something like dropping support for Adobe Flash - it won't be usable.
The "most wanted" is obviously the Ovi Maps, probably that stuff could be easily converted to another app having offline navigation capability :-) People wrote "Gaia" some years ago, an open source viewer for Google Earth (and later forced to give up) so it can't bee too difficult to realize at least this.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Note:
The VM mentioned in here is not like in VMWare or VirtualBox, it is more like Java Virtual Machine (JVM), (as well as Python and Ruby).
That is, the fact that objective c is an interpreted language, should make it easier.
For a long time I wondered if the following idea worth a nickel or just a waste of time and energy. I am willing to start a project which will provide a kind of a VM for all iPxxx apps - so developed once for iPxxx can run on a Macbook, iMac, Linux, Android and windows (desktop and mobile). You get the idea, right?
I want to do to the current iPhone SDK, the same as what Mono did to Microsoft .Net and perhaps a more complete set of implementation.
I tend to believe that if overnight all apps on appstore become available on the android market as well that would be a mini revolution. Think about running iPad apps on every tablet that will come out to the market in the future.
Wouldn't it be fantastic to all the developers, which from now on, can write once and sell everywhere?
The main questions which I ask myself repeatedly is: "Is This Legal?" - I mean, say I have done this, would apple's lawyers will start sending me all kinds of nasty emails?
I am willing to hear your opinion about this idea as well as if some of you willing and able to join forces and start this open source project.
There is not much benefit in porting from phone to desktop. While that is essentially a freebie once you write the VM, it is not compelling in itself. The touch interface does not always work well with a mouse.
The reason to write it would be to add 100k free apps to android. I say free because there would be no reason to buy them, since you could just copy them. The VM would be equivalent to a jailbroken phone in terms of piracy.
Legally, I think you would have no better standing the psystar did. If you are making a pure VM, then you are installing Apple OS on unlicensed hardware. I am no lawyer, but I cannot imagine they would embrace the project. You could also try to be like Wine, implementing the entire OS from scratch.
As far as the actual feasibility of running apps in a VM on Android, I would have low expectations. Apple hardware is better than average, while Android hardware covers a wide range. Many apps would run poorly or not at all on a lot of the android hardware out there, even if there was no overhead for the VM. And there will be overhead for the VM.
I think this task is not a trivial one. Implementing a VM (Java?, Inventing your own language?) is not an easy task. Every VM implementation has tons of hours of design and development carried out by many skilled engineers. Even if you attach to standards (i.e. you could maybe implement a Python interpreter) instead of reinventing the wheel, this is sure a lot of work (at least for a one-person-project). Moreover if you try to implement a new approach (language?) you need to take programmers into account. How would you make your language/platform popular enough to let programmers create good applications?
On the other side (leaving legal issues out, that there surely be many), instead of thinking big, haven't you wondered how would you distribute your VM installer? I do not know iPhone very well, but as far as I know you can only install applications through iPhone Market. If your VM simply does not make fun to Apple it would be turned down with the ease of a click. No matter how many hours have you invested in your project. And no matter what you fight, if Apple doesn't like it, game over. Look at Flash for instance. They are just pushing to get what you are trying to do (or just already did) with Flash 11. What happened here? Apple doesn't want to let others take a slice of control of their platform. Game over Adobe on iPxxx. Do you think that what a big Corporation with gazillions of users, money and lawyers like Adobe couldn't do, would be feasible for a bunch of passionate programers employing a few hours of their spare time and little or no financial/legal support?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am very interested in mobile application development. But which language or framework is more popular, useful and usable?
I know Java well. If you have any idea and/or experience, please help me to take my decision.
J2ME is much more popular than Android - many phones of many vendors (Nokia, Sony Ericson, Motorola, LG, Samsung and more) have it, and you can deploy application to them. The price is limited capabilities and no consolidated distribution channel (for the moment, Sun is talking about the Java Store).
On the other hand, Andriod has much more capabilities, its API is closer to the Java API, and it has more capabilities, but there is a limited number of phones. Also, you have the Android market as a distribution channel.
If you can describe what you have in mind, I can elaborate more.
Added Information
The J2ME market is quite large, but Android is rising fast - it is a true smartphone, a segment which has become more and more popular in the recent years. According to job trends, both are have roughly the same demand now:
I've dabbled in some J2ME programming, but right now I've written about 4 Android apps.
My observations:
The Android API is a lot of fun to use. J2ME is showing its age. For example, a JSON parser is built in. And you have access to SQLite. Android's SQLite access code is like an amalgam of lessons learnt from Ruby on Rails, REST and plain-old SQL.
In terms of deployment numbers, there are more J2ME apps than Android apps. However if you want to enter the smartphone market, Android is second in mindshare to iPhone (BlackBerry is reinventing itself, but its API is still looking like a J2ME++). Read this article.
The whole platform is open source. So learning it and mastering it is easy.
I think you're missing an important fact: Android is not only a platform, but also brings with it a fully fledged application framework which continues to grow and gets backing from some very big players (Open Handset Alliance). J2ME is just a stripped down version of the Java platform. That's a major difference.
Having worked with Android since over a year now, I can definitely say that is has grown into a very powerful system and decent tool support.
Only Android Can Catch the iPhone
There are something like 20 Android phones coming out before the end of the year.(*)
Networks like Verizon that ship only deliberately-crippled handsets will be hard-pressed to win sophisticated consumers. Their customers mostly make voice calls and text each other, to get fancy they might run Song ID or VZ Navigator.
I think the issue is: which phone owners actually d/l and use the apps? The walled-off Verizon customers, not so much. Right now, the action is in the iPhone, but I think Android might catch up.
(*) Here is just one.
I have to agree with others on shying away from J2ME development. I have a Motorola RAZR V3xx that I've used for a few years. It is as standard a J2ME-supporting phone as you're likely to get from most carriers. I decided to look into doing some J2ME development for the phone to give myself some helpful utilities.
Long story short, there is a reason you pretty much only see games on J2ME phones. Unless you are willing/able to shell out big bucks for signing certificates, you cannot even access the most useful APIs available on the phone. Things like File IO, PIM (contacts, calendar), Bluetooth, etc. are simply blocked unless you get your application signed using a carrier's (AT&T, T-Mobile, Sprint, Verizon, etc.) special certificate. And the cost of these certificates can easily exceed hundreds or thousands of dollars. Putting this simply out of the range of your average hobbyist.
I could go on, but a couple of sites have covered this topic in much greater detail Here and Here.
For me, this pretty much means I will be targeting the Android in the future. The iPhone is also a good place to be targeting. The current state of J2ME on handsets here in the U.S. is just not worth my time for pet projects. Which is disappointing, as most of these phones are capable of doing many useful things otherwise.
It depends on what you mean by 'popular'. If you are counting in terms of installed handsets, then J2ME wins hands down. As far as current installed handsets, Android has few mobile phone companies and only recent mobile phones (whereas J2ME has been around for the last six odd years).
However, that doesn't make working with J2ME a nice-to-have. Sadly, each manufacturer cripples it in some way, and not all phones with the J2ME badge are equal; some are more equal than others. MIDP, MIDP2.0, CLDC, CDC ... the list of acronyms goes on. And when you buy a phone, it has 'Java enabled' without actually saying what it is that it supports, so even the customer doesn't have a clue.
Despite its large installed base, J2ME remains fundamentally unpowered for the world's current generation of mobile phones; the upgrade path is usually non-existent (though it's the manufacturers to blame for that, unfortunately) and you can't even do things like access Bluetooth or contacts in any useful way; though extensions have been proposed for J2ME, they've never really lived up to the expectation of write-once-run-anywhere.
Whether Android goes down this route as well remains to be seen - the biggest concern is manufacturers are trying to 'do their own thing' (e.g. Motorolla's BLUR UI) which will further fragment the market.
Lastly, don't forget that it's in the handset manufacturer's interests for you to throw away your old phone and buy a new one every year (or two). Support, bug-fixes, and generally upgrading your old phone's software, though technically feasible, never happens. I had a P990, and despite a few rounds of updates, it remained as buggy as hell (which is why I ditched it for the iPhone when it came out).
So, from a programming perspective, Android is better than J2ME. For reaching many handsets, J2ME is better than Android. For general user interface and power, choose an iPhone.
Android and J2ME aren't exactly similar in their scope as platforms, in a way, it's like comparing apples and oranges.
When we talk about Android, we are talking about full-blown mobile OS, with much more extended capabilities than J2ME. It could be used for pretty much everything you can think about - system utilities, social network services, location-based apps, games, etc. Android has also richer UI kit and lots of available source code to learn from.
In Android you have access to many APIs, designed to be used in modern smartphones, and these APIs are being refined constantly, while J2ME has started to feel aged, and is concentrated mostly on graphics.
The penetration rate of J2ME is currently bigger than Android's, and by bigger I mean much, much bigger, but business analysis doesn't end just with number of handsets of the given platform.
If you have idea for a great app, you'd better do it for Android and/or iPhone OS - it will be easier for you and you'll be reaching to users that are more likely to need such app, and that are more likely to pay reasonable price for it.
Overall, I would recommend to start with the newer platform, even if only because it would be more interesting and a better learning experience for you.
While there is no shortage of 'feature-phones' supporting j2me in the wild, I suspect third party applications get very little market 'traction' because the users aren't looking to install new software on the phone.
Android is a breeze to develop for. I think you should try it.
There is no harm in getting the SDK and experimenting for a few hours..
J2ME is very popular because almost every phone can run these applications.
Android on the other side has just few phones and netbooks supported, but Android API/SDK is more powerful than J2ME. Android phones come with great hardware and you'll have the opportunity to work with all these "cool" touch screens, gps, accelerometers, etc. It's still in development, but I think it has a future.
From my point of view, Android is more and more better than the J2ME
Learn Android and enjoy... we have lot of fun while developing the Android apps
J2ME apps look and feel and development environment not effective compare with the Android
J2ME is the most popular. Because many mobile phones have a support for J2ME. J2ME's main advantage is that it belongs to the Java family, it is open source and widely supported by various kinds of devices.
Many mobile phones and other devices support J2ME due to its simplicity, easy to implement, etc.
The J2ME is the base for Blackberry,Android,etc.Because the others (other than J2ME) are developed after the J2ME.After eliminating the tough concepts in j2me,using some j2me concepts they build their environment like android,blackberry,etc.
J2ME is very old .It have many drawbacks,limitations,etc.
These drawbacks are overcomed in the latest technology like android,blackberry,etc.
J2me is good .It is old.It have many disadvantages,etc
Android overcome that disadvantages.Android keep on growing
The general java feature "platform independent" is failed sometimes,some scenarios in J2ME.
Android is new technology.It have many features,etc than J2ME.
Developing an application for android devices is simple,easy,etc.
We need ot get the pay liscence for developing application and deploying (applications) into the device.
The android SDK is obtained by free versions.
My opinion is Android is better than J2ME.