As I am new to Android development, I did find the section for custom components. What I am interested in is to create custom components and make them available to other developers. Is there an article or information that covers the creation & deployment of third party components for Android?
Example:
Company "A" wants to use a custom component that I wrote. How do I go about getting it to them and that they can easily use it in there application development?
Thanks in advance!
Craig
Android applications are not that much different from java programs. In order to create your own library you can just create a jar out of it distribute this jar. To use it, one would have to include this jar in its code.
Using Eclipse, you can use the export function to create the jar. It's even possible to create jars out of Android projects, but in this case you would have to be careful not to include conflicting files (like AndroidManifest.xml) when creating the jar, or else your library would be useless for the end user.
Related
I have a project that I have been working on which is a standard android application that does not include any other external libraries at this time. I am now looking at making a game at the end of the app(its a quiz so after the questions I want to make a mini game).
So what I am trying to find out is can I just import the libraries that it uses and connect them to my project rather than creating a LibGDX project and importing that?
What it comes down to is your personal preference. In answer to your question, yes you could just add in the jar files and such into your current project, however you are going to have to edit your manifest and some add in some other stuff besides jars using this Setup. In my personal opinion it would be easier to create a libgdx project using the tutorial found here, but in the end as I said before it all depends on what exactly you want to do.
Before deciding, ask yourself.
Do I want to have everything in one project, or can it be in more than one?
What would be better in the long run for managing my app.
Do I want ease now or later?
Cheers!
So here is the deal. Let's say I'm developing an app depending on the Facebook SDK and Chris Banes PullToRefreshListView. I import the SDK's to my workspace(which I don't really like since it fills upp the workspace!) and reference it in my app as libraries. I'm making some changes to the PullToRefreshListView, let's say I'm adding a custom font or changing the color of one of the labels.
Now, I'm using Git to version control my project. I would like to be able to put up my project to our Git server and make my colleagues able to pull the project and get to work without having to struggle with getting the same SDK's (of the same versions as I used) setup and referenced in the project. Since I've made some changes to one of the libraries, the project could never be fully restored by another person if I don't provide the code.
How should I act in this situation?
Is it possible to put an uncompiled library in the libs folder or something like that?
If not, what is the right way of accomplishing this?
All I can find when Googling or searching Stack Overflow is how-to's on using compiled .jar files in the libs folder, which is good but not what I'm looking for.
Essentially, I'm looking for a good way of structuring projects using 3rd party libraries.
It sounds like these are android library projects (they contain assets). If that's the case, you can't turn them into JAR files.
The easiest way that comes to mind is to have your root project folder contain your app and all said libraries:
Root
-\Your app
-\src
-\res
-\3rd party lib 1
-\3rd party lib 2
-\3rd party lib 3
This structure would make it pretty simple to push to git and manage in eclipse.
I am currently starting a project which I would like to develop both a Android and desktop app for using mono for android. I would like to encapsulate the common logic into a shared library but at the moment I am unsure of how to accomidate both frameworks.
Thanks!
You must create projects using the "Android Class Library" project template because the mscorlib supported by monodroid(v2.0.5.0) is lower then the MSFX2.0 (v2.0.50727)
You'll want to create separate class library projects for each platform, and then share the source files across them. This question has a lot of links and details about how to go about doing that.
It's quite often that we see two versions of an android app: a paid version and a free version. I'm also developing an app that would like to release two versions. What is the best way to do this? Creating two projects and copying files in between does not seem to be the best way in my mind.
Use Library Project, as the official dev guide suggested:
If you have source code and resources that are common to multiple Android projects, you can move them to a library project so that it is easier to maintain across applications and versions. Here are some common scenarios in which you could make use of library projects:
If you are developing multiple related applications that use some of the same components, you move the redundant components out of their respective application projects and create a single, reuseable set of the same components in a library project.
If you are creating an application that exists in both free and paid versions. You move the part of the application that is common to both versions into a library project. The two dependent projects, with their different package names, will reference the library project and provide only the difference between the two application versions.
Update: This method is really only good for compiling with Eclipse, since Android Studio supports build flavors which can achieve exactly this.
While #yorkw's and #Nate's answers are both good, this is the method I use due to its simplicity. From the article:
com.example.myapp – Android Project Library - This is where my ENTIRE app lives. All the functionality for the FULL and LITE versions.
com.example.myapp.full - Android Application Project - This is a shell that contains graphics and resources needed for the full version only. Basically it’s a super lightweight shell.
com.example.myapp.lite - Android Application Project – This is another shell that contains nothing but graphics and resources needed for the lite version. Again, its a super lightweight shell.
I also keep a static variable IS_PRO in a library class which is set when the app launches. This should be used only for notifications, alerts, and so on (such as asking the user to upgrade to pro).
However, this method has one drawback: you must clean and rebuild any time the library or its resources are modified. Also be sure to read this post on sharing resources between a project and a library.
I would call this a FORK in development. Start a new App development, but have your common code coming from a common file location. Make your free based edits to the forked code, and try your best to keep that code completely separate.
I actually did this on an iPhone based app, I have a free version and 2 different payed versions (a single player only and a multi-player). I would do it the same way on Android.
U can use git for example.
Create branch "app_with_ads", and master will be your "paid" version.
Develop in master and merge periodically to another.
before publish u probably will have to change app package, or something else in Android\ Manifest.xml
Here's a little blog tutorial about doing this.
Basically a howto for building a Full and Lite version of the same app, using a library project to accomplish code reuse between the two versions.
Since it's popular to have both a free and a paid version in the android market of the same app, I had decided to do the same. Initially I just duplicated the complete codebase and adapted some code here and there (added ads, built in some limitations etc) since there was no option to do library projects at that time, but that left me with two projects that are horrific to manage fixes to bugs as I need to do those twice.
Since r14 we can use library projects with resources, so that would be a great solution to this particular problem as far as I can tell. Therefore I've read up on library projects and conciderations, and I'm curious to know what the minimum amount of files needed in the projects of the different versions are. My questions therefore are;
Could I have all of the code in the shared project, and have bare bone project with basically just a manifest?
If so, should I? is this the optimal way conceptually? (so apart from the fact that it depends on my code base)
How should I deal with library package naming, are there specific rules?
Are there tools about that can compare code from two different projects and perhaps merge them auto-magically or auto-manually, and which one is preferred?
If I understand your problem correctly, you want to create multiple Android apps that are similar to one another (i.e., have a lot of the same source code), but which are different in particular (minor) ways, and you want each of these apps to have a distinct package, so that it can be separately uploaded and distributed on an app store such as Google Play. A Project Library is an excellent facility for accomplishing those goals.
I'm assuming that the differences between your various versions are minor, involving things like resources and the app name and package, and a switch that turns on certain features for a paid version while leaving them off for a free version.
Even if that is not the case, by using polymorphism in the ways described below, your various apps could differ in significant ways and still share a common Project Library.
A Project Library can be defined in Eclipse in the same way as any Android project can be defined, but it is marked as a Project Library (by checking the "Is Library" box near the bottom of the Android page of the library's Project Properties dialog) and cannot be compiled and run on its own. Instead, it is intended to be included by reference in one or more other projects which are actual apps (by adding a reference to it on the Android page of each such app's Project Properties dialog). These apps will use the Project Library, and thus will share its code and capabilities.
Each such referencing app will have its own manifest file (where their respective, different packages can be declared), and they can also define their own classes (including classes derived from the Activity and/or Application classes of the Project Library), so that these classes can be specialized polymorphically for each app that uses the Project Library (e.g., by overriding methods or by providing definitions for methods that are defined as abstract within the Project Library's Activity- or Application-derived classes), although you can also use those Library classes without modification (provided that they are not abstract) by simply referencing them within the manifest file (e.g., in an activity or application tag) of each app that uses the Library, just as you would reference Activity or Application-derived classes defined within the app itself.
If you decided to use this approach, then you would put your main source files in a Project Library, and would create a separate project for each app you want to produce, each of which would reference the Project Library. The manifest file of the Project Library would be overridden by the manifest of whatever project is being created using that Library (actually, I think that the Project Library's own manifest is completely ignored, not just overridden, but nonetheless it is useful to create a manifest for the Library, so that you can manually template - copy and edit - the manifest of each project that uses it from the Library's own manifest).
I have used this approach to create multiple android apps that share some of the same capabilities, and it has worked very well for me.
Regarding package naming, any old package name will work for a library project, but of course it makes sense to use the same prefix for the Library Project's package as you use for your various individual (e.g., free vs. paid) apps that use it, with something like ".library" as the last part of the name, while the various apps could have endings like ".myappfree" and ".myapppaid". Naturally, you would want to use your reverse domain name convention for the library's package prefix to prevent conflicts, just as you would for a package name of a released app.
In Windows, a nice, open-source tool for comparing code bases is WinMerge:
http://winmerge.org/
If I were in your position, however, I would only use this tool to manually identify differences, and would not attempt to use it to automate the refactoring of your code into a Library Project. That would be best done under your own (manual) control.
Finally, as an alternative, you might consider using a single app that is free and that has your free app's capabilities by default, with an option to upgrade to your full app's capabilities (delivered within the same APK) via an in-app payment, rather than having separate free and paid apps. In-app payments have improved a great deal in the past several months (with the release of version 3 of IAB), and although there are still some glitches, they have become a more practical alternative to the free/full dichotomy than they were at first.
Yes, you can have a project that is basically just a manifest specifying app name, name space, icon etc, with all the actual code and 99% of the resources in the library project.
Yes, I think you should use this approach. It's very common to use library projects to deal with the Free/Paid app problem.
I've not had any problems with naming, though you should be careful with any resources in separate projects to avoid using the same names.
I'm not aware of any tools, and if it were me I'd want to do it manually to be sure I'm merging what needs merging and keeping separate what needs to be separate. you've one significant refactor to do, but once all the duplication is removed I'm sure it'll be much easier.