Create Android project programmatically in eclipse - android

In short: Is there a supported way to create an Android project for eclipse (as you would get via the new Android project wizard) programmatically? Or if not supported, then is there any way at all? (this is being done within an eclipse plugin)
I've been trying to do this for a while, and it is turning out to be much more difficult than expected. I took a look at the source for both the New and the Import wizards for Android projects, and found that they both use the NewProjectCreator class. There seem to be two ways to use this class; one is via the static "create" method, and the other is to construct an instance of NewProjectCreator and call "createAndroidProjects". However, I'm having trouble getting ahold of all the necessary parameters for either of these. The static method requires both an IAndroidTarget and a ProjectPopulator, neither of which I can find implementations of (There is an anonymous implementation of ProjectPopulator in the NewProjectWizard class, but pasting this into my code is disastrous in the number of classes and fields it can't find). The instance method on the other hand requires an IWizardContainer, but I would like to be able to do this without bringing up a wizard.
At the other end of the spectrum, I've tried simply adding and Android nature to the project, but this causes all sorts of build errors, since it doesn't actually change the setup of the project to reflect whatever the Android standards are. I guess another option is to take this route and try to set up the whole project manually, but I don't know if there are any guidelines for this, or whether the project standards are likely to change.
Does anyone know how to do this? Thanks in advance!

Related

Create Android app using API that reference JAXBContext

I am a Computer Science undergraduate student and I am creating an Android app that using an API to interact with an execution server.
The server takes a xml file and do various stuff with it(get data, process data etc.)and then gives back data as output. Both input and output are exchanged via this API.
The problem is that the API references code from javax.xml.bind, for example, JAXBContext while android doesn't have javax.xml.bind package in its core. (a well known issue)
Feasible solutions on the internet seems to be repackaging the code I need, but I don't know exactly what suppose to be.
Since the API reference classes in javax.xml.bind and javax.net, I guess I have to extract code from these 2 packages and make them part of the API (I have access to API source) and then repackage the API. However, I guess classes inside javax.xml.bind might have dependencies on other classes that not supported by Android, so does javax.net. (Please forgive me if this is stupid thought...)
So anyone know : whether there are classes, which codes in javax.xml.bind and javax.net depends on, not supported by android ?
Bit of tricky question really..
I will be really appreciated if you can provide a work around that enable a Android app to call an API that reference codes inside javax.xml.bind.
Try JiBX (http://jibx.sourceforge.net/), it's a small and fast footprint, Android compatible, XML binding framework.
I ended up with repacking those package which exists in standard Java library but not in Android. Basically, just get source code of all those missing packages and then put them into the API source and rename them into a name that is different from the original one and then change corresponding code in API that reference these methods as well (you have to use a different name, otherwise code reference methods in these package will still looking for methods in the core Library (i.e Android API)
Anyway, hope it helps. If you have the same problem.
If you have any better suggestion. Please share it!

Manage code/build for Android app stores (Google/Amazon/etc)?

I have an Android app that's downloaded primarily from Android Market (now, Google Play). We made a few tweaks to the source and also submitted to the Amazon App Store to see what sort of traction it gets. I'm now looking for a sustainable way to develop from a common code base and yet build so that I can submit to either/both.
Amazon's store has some restrictions about available APIs, and hence I'd like to conditionally remove/modify features from that version. Since Java doesn't support traditional conditional compilation, and conditionally including files in Eclipse doesn't seem trivial (is it even possible?), I wanted to ask what others are doing to solve this.
Admittedly, I'm no Eclipse/Java expert so feel free to school me.
What I'm looking for in a solution:
Building/debugging using Eclipse.
Static code files, with environment/settings toggles to control what to build.
No duplicate code or conditional logic in code to pick code flow at runtime
Is this something you've solved for Android apps specifically, or for other Java/Eclipse based projects? Suggestions for where to begin?
It's quite easy to do in the newest versions of ADT (version 17), though I do find it makes compilation a bit longer:
Create a new Android project (proj-A)
Go to Project->Properties, select Android, and check "Is Library"
Move all your common code to proj-A, import all the necessary libraries
Create a new Android project for Google Play (proj-B)
Go to Project->Properties, select Android, and add Proj-A to the Library
Repeat #4&5 for the Amazon version
If you have some variables that should be set differently for each sub project (i.e. boolean GOOGLE_PLAY_VERSION to enable Google Play specific functions), you have to create another project to contain these values since you can't have projects that reference one-another in a circular fashion. You can solve this by adding the following steps:
Pull all of your sub-project specific variables into one or more Classes that just serves as container(s) for these variables
Create a "dummy" Java project (dummy)
Config proj-A to add a new Source link to the bin directory of dummy
Add the config Classes in each sub-project with project-specific changes
Profits!
Note that the variables in dummy should not be set as final, otherwise it will override sub-project's setting.
This may seem like quite a bit of up-front work, but has worked quite well for me as far as version control goes.
Edit:
Now with Google's move to Android Studio & Gradle, it may be better to move to that if you are starting a new project if you want to support multiple APKs, see Android dev site's Building Your Project with Gradle#Work with build variants. It definitely doesn't hurt to evaluate that option before deciding.
Unfortunately, it's sort of a convention in Android to change flow at runtime based on what would be in C/C++-land conditional compilation.
Our app has to maintain different behavior for different API levels, so we've created some application-level constants that are initialized statically based on API-level information available to us, and used throughout the code. This is the way that Google does things in their examples (for example, see the ActionBarCompat compatibility library, and in particular the factory method used here).
You could create an interface CustomBuild, and implement it in AmazonBuild and GooglePlayBuild, then use a static getBuild() method to switch functionality as necessary:
if(getBuild().shouldEnableFeatureX()){
doStuff();
} else {
doDifferentStuff();
}
Then all you've got to worry about switching between builds is a line or two of code in the factory along with maintaining which things you want enabled in which versions. Or you could include a different version of a static class CustomBuild for each build.
I'm going to second the suggestion of others above re: switching to something like Maven for building; it should make your life much easier once you have it set up.
I'm also going to say you should make the core of the app a library as suggested above, and have two different modules (one for amazon, one for play store) that depend on the library but each only contain the one custom factory file (or just a static class for each type of build that contains the same "should I do this thing?" methods... once you have the infrastructure it's just a matter of preference).
I haven't actually tried this yet, but it's something I've thought about.
How about using Eclipse's ability to link to files from a directory outside your workspace?
Start with one Eclipse project: for the sake of argument, say it's the Google Play version.
Now build a second project, beginning with asking Eclipse to link (not copy) the source files from your first project.
To develop the second project, add classes that subclass ones from the original project to realize your modifications. For resources, you can use some combination of includes, attribute overrides, and selectors.
Where it's not possible to subclass or extend, then obviously you'll have to just copy the original source file and hack on it. If you're really OCD about it, you can probably just maintain a patch set rather than a whole redundant set of files.
What do you think, will it work?
You may create manually two projects in Eclipse pointing to the same source folders but with different inclusion/exclusion filters and different target directories.
Then two Ant targets using properties to switch excluded files from javac fileset are enough to generate corresponding jar files.
The aim is to get a clean application for each target, without any code from the other one.
With features listed as pluggable behaviors in a property file or XML configuration, your runtime will adapt itself with the addition of menu entries.

Refactoring in Android Programming

Please, if someone could write the meaning of refactoring in android, how it is done and what is its use in android programming. I am using Eclipse.
Thanks
Refactoring means making small changes to improve the structure of a program without affecting its operation. So, for example, renaming a method or moving a method from a subclass to a superclass would be examples of small refactorings. Eclipse has a "Refactoring" context menu which automates these and a number of other simple refactorings.
This really has nothing to do with Android, though; it's just a general programming term. There's nothing about refactoring in Android programming that differs from any other system.
I just used the refactoring option in Eclipse to rename my package and automatically rename folders and package references, and found it quite useful! I didn't really know what refactoring meant in this case, until I decided to try it out while playing around with different menu options.
I have had many troubles in the past when I manually tried to change a package name or copy one package to a new one but with a different name, so the refactoring option comes in handy if you want to do it all in one fell swoop.

Are there Android compatible alternatives to Property Utils?

Is there a handy-dandy equivalent to org.apache.commons.beanutils.PropertyUtils on Android?
I can't seem to use bean utils in my android app due to some dependencies on PropertyDescriptor,and IndexedPropertyDescriptor. So I'm wondering if there are any alternatives?
Basically all I want to do is use a method name as a string "someMethod" and feed that into setMethod(anObject, "someMethod", value), much like PropertyUtils does; but without having to resort to the nasties of reflection...
Or are my hands tied and I need to use Reflection?
There is bridge library which works on Android: android-java-air-bridge.jar. Just include into project path and use all apache beanutils features in your Android project as you could use in ordinary java application. Moreover, there are lot of other classes which moved to this Android supporting library. Look at the list.
There is a possibilty to use libraries or write own code depending on the PropertyUtils. But it sure isn't dandy. You can get the general idea about what has to be done in this thread.
There are apparently some projects who have successfully solved the issue, so you can study thier solution. Take a look at Drawingpad-base and libgdx. You can find PropertyUtils in the package com.madrobot.beans in the first project and com.badlogic.gdx.beans in the second.

Invoking a class from one project in another project?

I am very new to eclipse and android developing in general and need help with the following. I have built two android projects in Eclipse with the android SDK:
"ORF401 Project" - targets Android 2.2 platform
"Map Project" - targets Google APIs 2.2 platform
I have followed the steps as specified by the standard Hello World Google Maps for android tutorial and have gotten the Google map to display on the emulator when I run the second project.
I have a menu set up in the 1st project for which one of the options is to load the map. However, I'm not sure how to load the map within this project since only one build target can be specified for each project, and so I cannot specify the Google Maps API as a (additional) build target. Is there a way to call the main .java class from the second project within the first project? I see where a reference can be made to the 2nd project under the project properties, but I'm not sure how to make use of this. One possible solution I found on the web was to add the following code under the switch case in the first project:
Intent intent = new Intent(this, {googleMap}.class);
startActivity(intent);
I presume this would require an additional googleMap.java class in the first project and also another activity, but I can't get it to work. Can anyone make a suggestion as to how I can accomplish this?
If the code for either or both projects would help, I'll be happy to post it. Thanks
The main idea with projects is to have one project per application that does some thing.
I assume your application needs to do something with maps, as well as something else. There is no need to split those ideas. Keep them in one project, because they make up one single application that you develop.
First thing I would suggest - read carefully about activities and intents. Head to http://developer.android.com - everything's clearly explained.
With that all cleared up you will see the point in making some button, which, being tapped, opens a new screen with the map feature that you've developed. And then let's you go back or do something else, like open a new screen, a browser, etc.
And give up trying to call the other project from a different one :) It's not the way I think you want to do stuff.
Just to make sure I'm not misunderstood - of course you might want to have two projects. But those will most probably result in two separate applications. Luckily, applications may also interact by intents, or content providers, or a couple more. Just see how Contacts app takes you to GMail app if you want to send a mail. If that's what you want to achieve - still need to read about intents.
edit:
Here's the link I mentioned about in the comments:
http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-it-too.html
It explains how to achieve the 'additional target' that you would like to have.
There are ways to call a class from one project in another project, but there are bigger problems here. The first project can run on any Android device. The second, however, requires Google Maps APIs. You won't be able to invoke it anyway, because it can't be installed unless you're in an environment that supports Google APIs. There really is no benefit to doing this, unless you have additional functionality in project 1 such that it can exist without project 2.
I would suggest using the Intent method rather than trying to hack something together that allows you to access another class. Regardless, though coupling these two together like this seems overly complicated and error prone. I would suggest simply embedding the mapping functionality in project 1 and requiring Google APIs. Most mainstream device support them anyway.
If you're married to the idea of having two separate projects with different build targets, I would suggest looking into using BroadcastReceivers with a custom intent that you broadcast from application 1. I don't believe startActivity will work across application boundaries because of class loader issues, but I could be wrong about that.

Categories

Resources