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.
Related
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.
I'm quite new to android programming and I was wondering if there is a Save As button in Eclipse for the entire project instead of saving only 1 XML or Java at a time.
For example, when I work on Excel, sometimes I like to save different versions of Excel workbooks so that I can roll back if there is a problem. I want to do the same thing for Eclipse project files like Listv1, List v2, Listv3 etc.
I know you can use local history, but that is more for different versions of the XML and Java files.
I want to save different versions of project files onto my hard drive so that I can compare two different versions of my project.
Click on your open project in either the Project Explorer or Package Explorer windows. Then File/Copy (or Ctrl-C), then immediately File/Paste (or Ctrl-V). Your'll get a wizard to save the project under a new name.
You need a lot more than manual saves: Any software project of any significant size should be using a version-control system. The one that's become the main standard these days is git.
Providing this sort of multiple versioning is the baseline that a VCS does, and most also handle situations like branching, where you can be working on the new version of your program but still go back and fix a bug in the old one, then push out a fix to the existing users while you keep working on the new version.
Eclipse has very good integration via the eGit plugin, and you might also be interested in the git-flow branching system.
I don't think that eclipse has that feature, why not having a a version control system to track your changes? like Git or Svn, they are free and very powerful
For example, when I work on excel, sometimes I like to save different versions of excel workbooks so that I can roll back if there is a problem.
Learn to use a good source control (version control) system. That's a much cleaner solution than just keeping lots of different copies around. You should still be able to compare different versions easily - and you can experiment on different branches, etc. It'll also make it much easier to share your code with others, should you wish to.
Additionally, it's not clear whether you're currently just a hobbyist or not, but if you're intending to code professionally you'll definitely need to get used to source control systems. (Every software company worth their salt uses source control.)
You might want to look at:
Git (you might want to start at GitHub)
Mercurial
Subversion
(All of these are free, and have Eclipse plug-ins available.)
Hi so I know how to use Kyronet and libgdx but what I want to know is when installing the Kyronet library do I only have to copy it into the Main project folder or do I have to put it in the Android and Desktop folders as well or do I have to do that attach source with?
I'm only asking here cause I can't find any documentation on installing Kryonet and want to cover all of my bases
Never used kryonet, but if it's no android native components dependent, it's ok if you just import it in your main project.
Regarding including source code, there's no need unless you're planning to make frequent changes to it.
In my previous projects, I've had to add it to the build paths of both the Main project and the Android project.
We have huge stack of xml files (around 5000+ files) possibly about 80 MB when not compressed) all of them are device configurations used for read & write data & build user interfaces without any language dependencies. These XML files can be ported to any technologies like Android and Apple world. Not all the 5000+ are loaded at one shot to memory, we might load 200 files into memory based on 1 device connected. We have a .NET/WPF based application which is using those XML files to build the UI and access the device information through protocols like Modbus & Hart (Don't bother protocols now). Anywhere we need custom logic, we have written them in DLL's (in .NET) and we use the reflection & IoC to load those DLLs, create object and access them through interfaces at runtime to complete the XML configuration. On desktop, then we build UI and load configuration
Now We need to develop Android app which runs on Phone and tablet as well. I have 1 year experience working lightly in Java. We could write a core modules which can be used for both phone and tablet and UI layer which is just to render our XML as a UI elements. We know to use Java's Class Loader to create instance so that instead of DLL's we could build .jar file in Android world and load them (if possible?) and access via interfaces. When we load our XML, it will consume nearly 80 to 100 MB of RAM (in WPF & .NET).
When looking into Android world, I could not decide whether to go with Scala or Java. We do not have any Java expert to advise us. Having worked on Python, I feel like Scala is modern & good choice. Also I read that Android apps compiled using Scala is fat(big), take long time to boot up.
But coming from Visual Studio background, we are much sophisticated development team expect everything to run through IDE. Also team has to learn Java/Scala whatever our choice from start.
If we choose to work on Scala on Android, do we except the memory efficiency is near to Java? Also do we have sufficient IDE support (Eclipse or NetBeans or IdeaJ) for Scala?
I am specifically looking for Memory footprint (internals) and IDE support for building Android application. No discussion on performance or productivity..
My Scala IDE is Maven in one terminal window and Vim in another. The browser serves up help documentation. If you can base your build process on Maven, then any IDE should do fine. And since you are working a lot with XML files, I suggest that you do base your build process on Maven rather than SBT.
Of course, there is Eclipse support for Scala, Intellij supports it, there is a Netbeans plugin for Scala, even a Komodo language extension for Scala. Lots of IDE choices to try out. Only the developer knows what works for them.
Make half a dozen identical VMs. Install one IDE on each one of them. Get the developers (end users of the IDE) to test them and choose the one that they want. Do all of the build and continuous integration with SVN and Maven. Make that the boundary between the developers'personal toolset (the IDE or Emacs or Vim) and the supported development tools.
If you're coming from C#, I'd advice choosing Scala. That way you could actually preserve some of your business logic, because good C# code might probably look a bit like things are done in Scala, too. E. g. LINQ in C# and Scala's collection classes (v.s Java collections).
The syntax is a bit different compared to Java/C#, but syntax is hardly a real problem these days.
Java's IDE support is pretty good, but if you're coming from Visual Studio, Intellij (or Eclipse) + Scala plugin might be good enough for you.
If you program the same code in Java and Scala, memory consumption should be pretty the same.
You should keep in mind that you should use ProGuard to keep the size of the Android application manageable.
While i'm developing in C/C++ and Java, i simply make a compile.bat script that does everything, that's fine for me. Why should i use make and why should i use ant?
Suppose you have 1000 source files and change just one of them. With your .bat script you will have to recompile the lot, with make you recompile just the one that changed. This can save quite a bit (read hours on a big project) of time.
Even better, if you change one of your header files, make will re-compile only the source files that use that header.
These are the two main features that have meant make and its offspring are used for all serious software development with compiled languages.
With a build file, you can automate more than just compiling your code; you can run unit tests, gather metrics, package build artifacts for deployment, and more.
An advantage, of sorts, of Ant is that it inspired tools for other platforms - NAnt for .NET, Phing for PHP. They do the same things, and work in the same way.
As long as you develop for yourself under Windows: suit yourself.
But if you start to develop with others Ant and Make are a standard to describe how your App is built.
There may be several reasons:
- because you are not the only one in the project
- because somebody will have to care about the build script when you left
- because a compile.bat script is not platform independent
- because the policy of the project defines the build technology, e.g. for the entire enterprise
I recently read a funny article about build tools. For you only the first part may be of any interest (before the maven bashing starts)
For one thing, make and ant both keep track of which files have already been compiled, so it does not redo work if it isn't needed.
You gain some platform-neutrality (how can I run your batch-script on my linux-box). But more important: build-tools have support for dependency-resolution. Scripts lack this and have to build it on their own.
Say you have targets A, B and C. B and C both depend on A. In an script they call the subroutine A. If you now create a new target D, that depends on B and C, than you will execute A twice. Build-tools recognize this and execute A only once.
Because this situation is typical for task involving compiling, building a distribution, testing, building documentation etc. build-tools are useful for software-development.
It would be possible to use a .bat file -- or bash or another flavor of shell script -- to do everything Ant can do, I believe. But it's far easier to do many things in Ant...
create/move/delete files and directories
apply filter tokens
run unit tests
package a jar, zip, or war properly
Many projects need to do these things, in addition to compiling, when they build.
Also Ant is platform-independent, so you can collaborate with those who use other operating systems.
But why stop at Ant? Apache Maven offers even more compelling features.
Make and Ant really come into their own when used with automated build systems or continuous integration.
The requirements for production builds, test builds and development builds are often different, and on a multi-person team, different developers set up their development environments in different ways.
Having a definitive build process solves the "Works on My Machine" (WOMM) problems that arise whenever the application needs to be built on a different machine from the one that it was developed on. It is the ultimate arbiter when one developer checks in code that doesn't work on another developer's machine. If the build process doesn't produce working software, then the first developer's check-in was broken. If it does produce working software then the second developer's development environment is broken - unless proven otherwise.