i am using Codename.one for mobile apps development, once the build is submitted, they provide the "apk" file. Since there are some limitation in codename one, so i was wondering that is there a way to get the native code for android build. ??
You can get the sources using the include source feature (available for the basic 9 USD subscription) but you would be mistaken to use it for the case described.
You can extend Codename One in any way you want including with native code, there are quite a few cn1lib's most of which are open source which demonstrate rather easily how you can write native code in Codename One.
This is a superior approach since it keeps the portability of Codename One and easy development cycle while allowing you to do almost anything you need.
Notice you can look at the full source code of Codename One itself in its open source project page.
My project has next structure:
Java part for GUI
Native part(C++) for logic
they are connected by socket.
So, in development process I run native part on desktop computer and java part in android device. They connect by WiFi and it is very comfortable to debug every part.
But sometimes I need build full and all-sufficient .apk where native part included in it as .so libs and calling from java code.
For this reason I try to find a handy way to "ON and OFF" native support in project. Now I see only one way - comment/uncomment all in Android.mk(it is important to prevent including .so libs in apk because they are big) and comment/uncomment call of native finction in java.
But I don't like it...
Thank you!
What you describe looks like two different projects that share some (maybe much of) common code. You can easily have such setup in Eclipse, you can use linked folders to make source sharing between the two projects automatic. But it may be safer to use your source control's powers to maintain sync between sources for the two projects.
I'm currently working on a project. I've been running into a few issues with the e-mail functionality, I've made multiple attempts to fix the issue and the latest seems to have fixed the issue.
For each rewrite I've created a new class to hold the new code. This doesn't seem to be the best solution as each time I have to go through the code and track down the references to the class and update them, with each rewrite only the code for the actual sending of the email has changed, function inputs and names have been consistent.
I've looked up versioning but this hasn't been particularly helpful in providing a solution either granted most likely due to my own lack of knowledge on the subject. So here is what I'm looking for: to have one instance of the class with multiple versions preferably without all the old code in it to aid in reading. But I want access to the old versions so that if a function/feature was there previously and wasn't built into the current version I can see how it was implemented.
Versioning is exactly what you need here.
Have a look here, which gives you a brief introduction to subversion, one of the most popular versioning systems. You can either set up / use your own private subversion server, or if you project is open source use a number of free providers (such as Google code) who will provide versioning for you.
Other versioning systems exist other than subversion, such as git, mercurial, etc. - but subversion is arguably the most popular and a good starting point.
Are you using any IDE? Eclipse/Netbeans store the history of your file updates and you can always compare/replace from history.
Note: This is not a replacement of version control in any way and I would highly recommend that you explore open-source version control solutions. This would help you in the long run
Mercurial is the way to go. Seemless merging and integration with java and popular IDE's like Netbeans. You can't go wrong. From the very beginning of my programming experience I learned how to use Mercurial in a day.
Use version management tool likes as SVN or CVS.
Ive been using eclipse and my-eclipse to code android and Java projects. I want to be able to back up my code. I know there is a way to back up code so that i can retrieve not only entire projects but changes and old versions but I cant figure out what the software is called and cant find any that are free and easy to implement. Any help would be great!
EDIT:
I don't have a server, can any of these be set up to save locally?
I think you'll want to use version control software. There are great solutions out there - CVS, SVN, Git, Perforce. Most of them integrate nicely into Eclipse.
Developing software without VCS is unthinkable to me.
Any of the plugins mentioned here will do, but I'm using the Subclipse plugin and a free repository at Assembla right now. I only switched from Mercurial because I started using Subversion at work.
If you don't have a server, you can try a free configuration at Assembla.com (http://www.assembla.com/catalog/tag/Free) for either Subversion or Git, and I've used Bitbucket.org in the past for hosting projects with Mercurial. Even the free configurations should be enough for your needs. I divided mine up between multiple projects.
Subversion (at subversion.tigris.org) is one excellent package; there are many others. There are excellent Subversion plugins for Eclipse (google "Subclipse".)
You may look to use the Subclipse package for Eclipse to use it with SVN. It permits you to keep/track/rollback changes and so.
The second option works fine if you need immediate result is to use Dropbox. It is easy to configure and easy to share the folders among multiple computer.
One more vote for using a VCS: in addition to back up you are getting control and some degree of methodology in your project.
Centralized solutions like CVS, SVN and Perforce mostly require setup and maintenance (some of them can run on flat files but these configurations are less popular). I would also consider one of the "Big Tree" distributed VCS Git, Mercurial and Bazaar.
Mercurial seem to have strong Eclipse plugin
what's the point of using ant, maven, and buildr? won't the using build in eclipse or netbeans work fine? i'm just curious what the purpose and benefit of extended build tools are.
Dependency Management: The build tools follow a component model that provides hints on where to look for dependencies. In Eclipse / Netbeans, you have to depend on a JAR and you don't really know if this JAR has been updated or not. With these build tools, they 'know' updates in dependencies (generally because of a good integration with your source control repository), recalculate transitive dependencies and ensure that everything is always built with the latest versions.
Access Control: Java, apart from class level access control, has no higher abstraction. With these build tools you can specify exactly which projects you want to depend on you and control visibility and access at a higher level of granularity.
Custom Control: The Eclipse / Netbeans build always builds JAR files. With custom build mechanisms, you could build your own custom (company-internal) archive with extra metadata information, if you so wish.
Plugins: There are a variety of plugins that come with build tools which can do various things during build. From something basic like generating Javadocs to something more non-trivial like running tests and getting code coverage, static analysis, generation of reports, etc.
Transport: Some build systems also manage transport of archives - from a development system to a deployment or production system. So, you can configure transport routes, schedules and such.
Take a look at some continuous integration servers like CruiseControl or Hudson. Also, the features page of Maven provides some insight into what you want to know.
On top of all the other answers. The primary reason I keep my projects buildable without being forced to use NetBeans or Eclipse is that it makes it so much easier to setup automated (and continuous) builds.
It would be rather complicated (in comparison) to set up a server that somehow starts eclipse, updates the source from the repository, build it all, sends a mail with the result and copies the output to somewhere on a disk where the last 50 builds are stored.
If you are a single developer or a very small group, it can seem that a build system is just an overhead. As the number of developers increases though it quickly becomes difficult to track all changes and ensure developers are keeping in sync. A build system reduces the rate of increase of those overheads as your team grows. Consider the issues of building all the code in Eclipse once you have 100+ developers working on the project.
One compelling reason to have a separate build system is to ensure that what has been delivered to your customers is compiled from a specific version of the code checked into your SCM. This eliminates a whole class of "works on my box" issues and in my opinion this benefit is worth the effort on its own in reduced support time. Isolated builds (say on a CI server) also highlight issues in development, e.g. where partial or breaking changes have been committed, so you have a chance to catch issues early.
A build in an IDE builds whatever happens to be on the box, whereas a standalone build system will produce a reproducible build directly from the SCM. Of course this could be done within an IDE, but AFAIK only by invoking something like Ant or Maven to handle all the build steps.
Then of course there are also the direct benefits of build systems. A modular build system reduces copy-paste issues and handles dependency resolution and other build related issues. This should allow developers to focus on delivering code. Of course every new tool introduces its own issues and the learning curve involved can make it seem that a build system is a needless overhead (just Google I hate Maven to get some idea).
The problem with building from the IDE, is that there are tons of settings affecting the build. When you use a build tool all the settings a condensed in a more or less readable form into a small set of scripts or configuration files. This allows in the ideal case anybody to execute a build with hardly any manual setup.
Without the build tool it might become next to impossible to even compile your code in let's say a year, because you'll have to reverse engineer all the settings
Different features. For example Maven can scan your dependencies and go download them, and their dependencies so you don't have to. For even a medium sized project there may be a very large number of dependencies. I don't think Eclipse can do that.
#anonymous,
Why do you I assume that me, a member
of your team, is using an IDE all the
time? I might want to build the code
on a headless build server, is that
ok?
Would you also deny me the right of
using a continuous integration
engine?
May I fetch dependencies from a central repository please? How can I do that?
Would you tie me to a specific IDE? I can't run Eclipse easily on my very old laptop, but I'll buy a new one.
Maybe I should also uninstall subversion and use patches or just zip folders on a sftp/ftp/Samba share.
The build tools allow you to do a build automatically, without human invention, which is essential if you have a code base being able to build many applications (like we do).
We want to be certain that each and everyone of our applications can build correctly after any code base changes. The best way to check that is to let a computer do it automatically using a Continouos integration tool. We just check in code, and the CI server picks up there is a change and rebuilds all modules influenced by that change. If anything breaks the responsible person is mailed directly.
It is extremely handy being able to automate things.
To expand on Jens Schauder's answer, a lot of those build options end up in some sort of .project file. One of the evils of Eclipse is that they store absolute path names in all of it's project files, so you can't copy a project file from one machine to another, which might have its workspace in a different directory.
The strongest reason for me, is automated builds.
IDEs just work on a higher abstraction layer.
NetBeans nativly uses Ant as its underlying build tool and recently can directly open maven projects in NetBeans. Hence, your typical NetBeans project can be compiled with ant and your maven project already is a NetBeans project.
As with every GUI vs CLI discussion, IDEs seem easier for beginners but once you get the idea it becomes cumbersome to do complex things.
Changing the configuration with an IDE means clicking somewhere which is easy for basic things but for complex stuff you need to find the right place to click. Furthermore IDEs seem to hide the importent information. Clicking a button to add a library is easy but you may still not know where the library is, etc.
In contrast, using a CLI isn't easy to start with but becomes quickly easy. It allows to do complex things more easily.
Using Ant or Maven means that every one can choose his/her own IDE to work one the code. Telling someone to install IDE X to compile it is much more overhead than telling "run <build command> in your shell". And of course your can't explain the former to an external tool.
To sum up, the IDE uses a build tool itself. In case of NetBeans Ant (or Maven) is used so you can get all the advantages and disadvantages of those. Eclipse uses its own thing (as far as I know) but also can integrate ant scripts.
As for the build tools themselves Maven is significantly different from Ant. It can download specified dependencies up to the point of downloading a web server to run your project.
In all projects, developers will often manually invoke the Build process.but it is not Suitable for large Projects, Where it is very difficult to keep track of what needs to be built, in what sequence and what dependencies there are in the building process.Hence we Use Build Tools for Our Projects.
Build Tools Done varieties of the task in the Application which will do by the Developer in their daily life.
They are
1.Downloading dependencies.
2.Compiling source code into binary code.
3.Packaging that binary code.
4.Running tests.
5.Deployment to production systems.