Develop Reference

Android Development: Java and C/C++ Compiling Functionality In an Application, Possible?

I was wondering if it's possible to make an IDE-like application for Android where users can write some Java or C/C++ code and be able to compile it, run it and be given the output in an Android application? (Not desktop!).
If it is possible, what are the limitations? I presume there'd be limits like the user wouldn't be able to make GUI's and execute them, or am I wrong?
Thanks,
Alex.

Yes, it is possible. Those applications are called IDE's. There's no special magic behind those - an IDE is just another program, albeit typically a rather big and complicated one.
That said, why would you want to do that? There are plenty of IDE's out there already. If you want an exercise, maybe something less ambitious would be a better choice.
There's no reason why your IDE should prevent the user from making GUI programs. After all, existing IDE's would let you.
Also, there are IDE's out there that are highly customizable (Eclipse and Visual Studio come to one's mind first), so if you're missing a bit of functionality, sometimes you can write/find an IDE plug-in for that.
If you don't have an IDE and want a free one, Eclipse is free. It supports Java and C++ all right. That would be much freer that creating another from scratch - time costs, too.
EDIT: I see. Now, the limitations are: small screen, lack (typically) of a hardware keyboard, limited memory, limited and slow disk, battery lifetime, overheating... App development is an expensive task.
EDIT2: looks like you're not after general purpose application development on Android, but want your app to be scriptable by end user. If that's indeed the case, C++ and Java are not the best languages to support. Android already comes with an interpreter for a scripting language - the language is JavaScript, and the interpreter is WebView.

As time goes there are more and more possibilities here.
AIDE, the Android Java IDE is quite successful, free environment. You can create Android applications on your Android device. It is in a continuous development by a German team. Now there is syntax highlight, fix imports, code completion, refactoring, compatibility with Eclipse, connection with Dropbox, git pull (and push in the premium version).
You can also find (non-free) C/C++ compiler like this or this. I have no experience with them, the first is really good according to the user responses.
The main limitation can be the screen size and if you have no external keyboard then it gets worse. The performance seems to be OK on a Tegra device - I use a 7-inch Iconia Tab A100 with Tegra2 -, however I think right now it is an auxiliary solution to a desktop/laptop based development. I now that the last sentence soon may become obsoleted.

Text to speech converter

I am going to create a Text to speech converter, which can be executed in both Windows, and Linux based systems. Can someone please help me answer the following questions;
What language should i use; Java, C++ or any other?
The program i am going to create should be able to read large chunks of data.
There should be good sound quality.
What are the libraries available to achieve this?
Please share your experiences as well.

Use the language you're most comfortable with. I learned the hard way when I tried to re-code my raytracer in C++, coming from a Python background. It took me weeks to get it to function...
Basically, you'll get frustrated by the nuances of a new language before you can get to coding something, so I suggest you stick with what you know.
That's independent of the language. Just makes sure to read the data in chunks (like 2048 kilobytes at a time). Reading a big file to RAM is not a great idea, as you can't be sure your end user has enough RAM (audio files can get BIG).
This is trivial. I can't help you program good sound quality. That's up to you.
There exist a few implementations of TTS for Linux, so that's all I can recommend. Look at Festival, as it is one of the ones you can actually understand.

Long time ago i had that same idea. I think it is not too complicated and can be done. This is how i would do it:
1- I would use Java, because it is platform independent.
2- If you are going to create an standalone application, it will be the local computer that will do the processing an not an application server, as in the case of web apps. Also i suppose that your program, will be used only by one user at a time. I think you will not have big issues with the amount data to process, if u implement some buffering mechanism.
3- The quality of the sound will depend in various factors such as: noise when recording,format, speed of the sound... Notice that many text to speech applications that exist on the web, the sound quality is ok, but you will never get the feeling that it is a real person, who is reading. (I recommend you a female voice, it sounds better).
4- Regarding to the libraries and another gadgets, this is what i think you might need:
-Java Standard Development Kit(To be able to work with java)
-A good IDE: There a many out there you can get for free. My favourite is eclipse but if you are a beginer with java, you might like to start with netbeans many people say it is more intuitive for learning.
-JLayer Mp3 library This will help you play the sounds in java.
-javax.swing Is a java library that is included in the development kit and allows you to create rich graphical user interfaces. Also if you are new to swing, i would recommend you a great swing IDE, called JFormDesigner, have a look at it, im sure it will speed your development alot(It is a great tool).
I hope my answers can give you some tips.
Update
I think it would be correct to mention also, that the only minimum requirement the users of your app will have in order to run the app is:
JRE(Java runtime enviroment)

This project of text to speech can be made using computer generated voice
so no problem of storing a database for each word and its pronunciation.
Just use the language in which u feel master to urself and apply the concept.....

I do not know anything about text to speech except that it's not easy. That being said, I suggest you stick with the language you are most familiar with. I'm sure Java and C can do it.

Emacs java-mode: malabar, jdee, or eclim?

I want to use emacs for java coding, but I'm confused on what mode to use for java coding. There's jdee, which seems ide-like; malabar, who is said to be more well versed in java 1.5 constructs than jdee; and emacs-eclim, which is an eclipse backend for emacs. There are also a wealth of completion extensions for emacs, and I'm also confused on which one to use. In fact, I'm so confused that I deferred using any of them until I get recommendations.
What is the current best option for java-mode + completion in emacs? And, if ever I decide to use a combination of what I mentioned above, will conflicts happen?

For those used to the power of Emacs text manipulation then Eclipse can seem like pedaling a bicycle with one foot. The Emacs+ plugin from http://www.mulgasoft.com/ is excellent for getting Emacs key bindings into Eclipse.
I use both Eclipse and Emacs a lot, but if I only did Java development I might use only Eclipse with Emacs+. It takes some work to get many Eclipse features enabled on Emacs.
My advice is to use Emacs >= 23. If you are on a Mac, look at AquaMacs. I use JDEE as the Java plugin. This has the serious drawback of not playing well with generics. It's not that it stops working, it's just that a lot of stuff isn't recognized. Do not use the old 2.3.5 JDEE plugin (that comes with most Linux distributions), but get the 2.4 version from the sourceforge site. Also get the Emacs Code Browser (ECB); this is a plugin that will give you stuff like Eclipse's Project Explorer and Outline views (other developers will look at this and not believe you when tell them that it's Emacs). I've used this setup for commercial projects on Windows, Mac, and Linux in the past year.
In fact, Eclipse plays pretty well with Emacs and I often switch between the two. Eclipse has some nice refactoring tools that I used to use sed for, and it has a good debugger interface. You can use them simultaneously. I find that I use Eclipse when working with other people's code and Emacs when I am writing my own code---Emacs is that much faster. Note that for me, a lot of the value of Emacs is the non-Java functionality, like editing Tomcat configuration files on remote servers from my local Emacs, writing professional documents with LaTeX, developing in Python or Bash or MATLAB or XML, and the odd text manipulation task (e.g., converting CVS files into String[] arrays).
I haven't used the other two projects you mention. It is possible to use the Eclipse compiler with Emacs already, so I'm not sure I see the point of the emacs-eclim project, which seems to be moribund anyway. The Malabar project might be interesting, but seems to be the product of one somewhat cranky developer (e.g., the warning "if you're not using Maven (why?) you should not consider malabar-mode"---I'll tell my clients that?).
Java on Emacs is in a sad state. I wish for JDEE to be revitalized, but it's not clear when or if that will happen. The web site and mailing list offer few clues.

I use emacs-eclim with auto-complete-mode support and java-mode highlighting exclusively for Java programming. 90% of my work is done in emacs, but I switch to eclipse when I need to debug, run unit tests or do major refactorings. All in all, this setup works very well for me.
I haven't tried JDEE for years, but I remember it was a b*tch to set up. I didn't care for the UI very much, as it put up lots of prearranged windows that were locked in place. I like to be able to switch back and forth between editing buffers, often showing just one window, but splitting and rearranging on the fly when it becomes necessary.
Note: I am an emacs-eclim maintainer, and this has probably coloured my judgement.

If you're using Maven, then I'd recommend malabar-mode. It will set everything up for you automagically, no need for editing project files like you'd have to do with JDEE. The downside I've found with malabar, is that it can consume a lot of memory if you've got a lot of multi level module projects open.
Both Malabar and JDEE will give you "true" completion, i.e. only completions that are possible. However, there are two amazing "intelligent guessing completion frameworks" in Emacs. hippie-expand and auto-complete.
The former is great (can complete whole code blocks for you, making it possible to e.g. cycle through all if-tests in your projects), but auto-complete mode is even better. It'll give you a nice intelli sense style menu, will "learn" as you use it, and allows you to define a file with the completions you'd like to be available in the various languages.

Baffling Failure to Call External Executable From Within Java Program

All right, I've hit a bug that has simply confused the bejeebus out of me. I'm looking for ideas about what it could be that I can investigate, because right now, I got nothing. It goes something like this:
I have a standalone Java application that occasionally needs to twiddle the Line-In volume of the computer it's running on (a WinXP machine). It does this by calling a pair of external executables (written in VB6*) that can get and set various component volumes. (They can handle Line-In, Mic, Wave, CD, and the master volume control.)
There are several hundred units in the field, running on hardware (Dell machines) that my company provided and controls. At least several dozen clients are using this feature, and it works perfectly -- except for one instance.
For this one troublemaking machine, it simply doesn't work. I watch the volume sliders when the app is running, and when the volume is supposed to drop, they stay put. When I check the app's log file, it throws no errors, and appears to be executing the code that drops the volume. When I run the executables from the command line, they work perfectly.
I can't vouch for this machine being 100% identical to all the ones that are behaving properly, but we've been buying the same line of Dells for quite some time now; at a bare minimum, it's very, very similar.
So, turning my confusion into a bullet list:
If I'm doing something stupid in the Java code (i.e., not clearing my STDOUT/STDERR buffers), why is it only an issue on this machine?
If there's something broken in the VB6 executables, why do they work on every other machine and on this machine from the command line?
If there's some sort of hardware oddity on this machine, what sort of oddity could cause the volume control executables to fail only when called from within a Java application?
I am very confused. I do not like being confused. Anybody have any suggestions that may lead to my enlightenment?**
-* -- I know, I know, VB6, 1998 called and they want their obsolescent proprietary bug generator back, etc. Wasn't my decision. But the code works. Usually.
-** -- Insert Buddhism joke here.
Update Edit: Customer service may have stumbled onto something; it may be something to do with client configuration settings in the database. New evidence suggests that either something's misconfigured for that client or my software is doing something stupid in response to a specific configuration. And the problem may be more widespread than we thought, due to this particular feature not being as commonly used as I thought.
Responding to the comments:
Debugger: Theoretically possible, but looks like a massive headache given our setup.
High Verbosity Logging, Java: Good idea this, particularly given than the problem may be more widespread than I originally believed. Time to start revisiting some assumptions. And possibly clubbing them. Like baby seals.
High Verbosity Logging, VB6: A possibility; will need to be rolled-into the high-verbosity Java logging to trap the output, since my VB6-fu is so pitiably weak I don't know how to output text to a file. But, yeah, knowing whether or not the script is even getting called would be valuable.
Window Event Viewer: Not familiar with this tool. May have to correct that.
PATH problem: Doesn't feel likely; the Java code constructs a relative path to the executable that doesn't look like it's relying on any environment variables.
My thanks for the suggestions people have provided; at the very least, you've gotten my brain moving in directions that feel promising.
Solution Edit: And the winner is ... That's Not A Bug, That's A Feature! A feature gone horribly, horribly wrong. A feature that will now be neutered so as to stop bothering us.
A batch of invalid assumptions kept me from seeing it sooner, not the least of which was "I don't need to tool the code with more debug statements -- the statements already in there are telling me all I need to know!" DaDaDom, if you'd like to turn your comment into an answer, there's a shiny checkmark in it for you.
Thanks to everybody who chimed in with a suggestion. Now if you'll excuse me, my head is late for a meeting with my desk.

Here goes an answer:
Can you create a version of the software with verbose logging or could you even debug the code? At least then you can tell if it's in the java or the VB part.

Hmmmm. I've been told that executing programs from Java is either easy or hard. The easy part is starting them up. The hard part is dealing with the I/O streams (see my earlier question on using Runtime.exec()). Maybe the VB program is doing or expecting something weird on these particular machines that the Java code isn't working with properly.
edit: I also found a link to Jakarta Commons Exec:
Rationale
Executing external processes from Java is a well-known problem area. It is inheriently platform dependent and requires the developer to know and test for platform specific behaviors, for example using cmd.exe on Windows or limited buffer sizes causing deadlocks. The JRE support for this is very limited, albeit better with the new Java SE 1.5 ProcessBuilder class.
Reliably executing external processes can also require knowledge of the environment variables before or after the command is executed. In J2SE 1.1-1.4 there is not support for this, since the method, System.getenv(), for retriving environment variables is deprecated.
There are currently several different libraries that for their own purposes have implemented frameworks around Runtime.exec() to handle the various issues outlined above. The proposed project should aim at coordinating and learning from these initatives to create and maintain a simple, reusable and well-tested package. Since some of the more problematic platforms are not readily available, it is my hope that the broad Apache community can be a great help.

Have you considered the possibility that the authenticated user may not have permission to edit volume settings on the workstation? Does the program run correctly if you run as an 'Administrator'?

Develop app to run natively or go cross platform? [closed]

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 8 years ago.
Improve this question
What's your opinion on whether one should write an application for a specific platform or use a cross platform approach and reach more potential clients?
It would be a GUI based application and I'm thinking of using Java.
Most of the applications that I've used built on Java don't run as smooth as the native applications on the respective platforms.
The two platforms I'm thinking of are windows and macs.
If I was creating the app just for my own use, and I had to choose one system, I would choose to focus on the mac.
I would like to hear your thoughts.

I would use Qt and yes, definitely target Cross Platform...
The major reason isn't in fact what you think it is (being cross platform by itself) but actually that by targeting multiple platforms your code by some freaking weird magical reasons tends to end up with far better code quality. I've seen this happen countless times in my own projects. Every time I add a new platform the quality of the code increases and the code becomes more clean...
Also every serious app should have as few "dependencies" as possible, being cross platform means you have less dependencies... ;)
Then as a "bonus" you get to your app to run on multiple platforms...

Requirements, requirements, requirements.
In all seriousness, "it depends" is the right answer.
Truly cross platform is hard work; Working where you/your users are familiar is worth something. Solving the problem in an effective manner is really the highest priority.

Cross platform development, in general, is a bit overrated as an artform. Java is the leading technology here, but even in this case, most Java programmers don't really go cross platform. There are a few spectacular examples of tools like Vuze and LimeWire and JRipper which work pretty well just about anywhere, but these are exceptions, statistically speaking. Most Java apps, especially of the corporate variety, are coded with one platform in mind, and they never really move around.
If you want to go Mac and Windows, consider spending time in the Limewire and Vuze codebase. Both of these apps work extremely well on both platforms.
You will definetly need two builds. One build probably won't do.

I suggest to develop it first for the platform you feel comfortable with, and where you can make use of all platform gimmicks; in this case, this would be OS X.
Later, if your app is successful for the Mac, look at porting options. It's IMO not worth to put effort into porting until it is certain that there would be significant interest in the app in the first place.

In this day and age, is there really a good reason to write native code?
Yes. The languages and libraries available do not allow excellent programming to be done well. At best they allow one to write code that works ok across platforms, but never excel.
Pick one and focus on it. Focus on that audience (you'll find the audiences are different in their tastes and desires anyway).
Once you've got an app people are clamoring for on the other side, and just before someone makes a competitor, evaluate the cost/benefit to porting your finely tuned and well designed product over.
If you try to 'serve two masters' you'll make design decisions based on what's easiest for both platforms, and that's not a good design process.
-Adam

If your app uses an MVC design, you can write portable model classes using C++, and native controller and view classes for each platform you want to support. That gives you the best of both worlds - portability where that's practical, and a native interface for which your users will thank you.

I agree with your observation about Java applications versus native applications, although I'm sure that an experienced Java programmer could probably make it work.
The bottom line is that the programming APIs for both Mac and Windows are the best tools to use for building interfaces on their respective systems. If you want your app to run smoothly on a particular system, you should use that system's API.
If it is absolutely essential to have a cross-platform implementation, consider writing all of the core functionality (non user-interface portion) for your program in a library that can be compiled for both systems (c++ is an obvious choice), and then build a nice user interface for each target system that can makes calls to the common library.

IMHO, this discussion should be answer by the customer needs.
Most of the time IT provide solution, the way the solution is build is only a detail for the customer.
However making the code reusable could be useful in case your first choice of development environment was wrong.
many other criteria may come into the thinking.
for instance if your software is for health care you may want to support for 10 years, then you have to select an OS supported for more than 10 years (forget windows and mac). etc.

Depends on how much time you wish to spend on the application. Fastest way is Java, otherwise you can build your model with C++ and do separate GUI code using MFC and Cocoa.

Why don't you consider Web Application.
You can build rich UI Web site running in browser which runs everywhere and all platforms,
If you are familiar with Java, you can try GWT for the 'Weblication'
Check out the demo page of GWT

Make it a web app ?
Otherwise Java i guess. It depends of many things, type of your app, target etc.

I have had good luck with cross platform Java using SWT. This will give you a nice native-look on any OS, and there aren't a whole lot of problems out there that require any JNI code. With any luck, you should be able to distribute the exact same codebase to both targets, and it should just work.
Having said that, you should evaluate whether or not you really need the cross platform functionality. At the very least, it will require you to test the GUI layer of your app on each OS (testing layouts, presentation, etc). With a large app, this becomes cumbersome very quickly.
In either case, choosing a cross-platform language from the start will give you flexibility in the future. If you were to write native code from the start, it would be non-trivial to port the code to another platform. It would likely be accompanied by several bugs, and would also require a port of all the test code to the new platform. You would run into synchronization issues with any new features, bug fixes, etc. With Java, you can write JUnit tests which will run in both OS's, and any bugs or new features will be propogated to both versions automatically.
It really does depend on your specific application. If you are anticipating a user base on both OS's, then that should dictate your language choice.

It is possible to get a nice looking Java app to run on Windows, Linux and Java - look at SBCommander for example - and note that you can run it and look at the UI even if you don't have the hardware that it's supposed to control.
On the other hand, one thing I've found very hard to do is to write a cross-platform app that looks and behaves like a native app on each platform; there are just too many different assumptions about how an application should behave.

It really depends on who your users will be. Don't go cross-platform just because you can. There needs to be a real need regardless of the tool. And testing is going to eat up quite a bit of time. You'll still need to thoroughly test on both platforms.
I use REALbasic to create a wide variety of cross-platform desktop applications from a single code base and it has worked well for me and my clients.

Quite often I find PC developers attempt to capitalize on the Mac market (some do successfully). In turn, they development the application in the described above "cross-platform" architecture (Java, or some Qt framework, etc...) The result is usually, a hideous looking application with poor OS integration support and the community backlash commences in the reviews.
My advice, port it. Do a good job, understand your market before dumping your cross-platform product in your carpet bomb marketing approach.