I have an Android project in Eclipse which I've used git for revision control. The project is built around an sqlite database and I've named the project com.lsp.rengine.
I now want to create a second application using a different set of data. I can basically copy the new database over the top of the existing one (in assets/) and things work fine. I will need to change some icons and layouts however, so thought a simple git branch would get me on my merry way.
There are a few show stoppers which are stumping me. For one, I can't install both applications on the same device as they currently share the same com.lsp.rengine name. If I refactor the project name to com.lsp.pengine, my upstream branch thinks all the shared code has disappeared.
How can I manage Eclipse, the two branches in git, and still have shared codebase (update master codebase, changes are reflected in both branches) and somehow have two separate install locations?
I think the best approach would be to refactor your code into two separate Android projects with a third library project containing all the shared code. The TicTacToeMain and TicTacToeLib sample projects should be able to help you get started.
Related
I have been working on a project for both native iOS and Android apps. Now that my parent projects are done, I need to run clones for them. These clones will use more or less the same code but with different languages, resources and possibly XIB files as well. I have been using GIT for code management and I google the best way to handle this and the suggested technique was with Forking which was no good because it started creating issues with different Package IDs in the projects.
Now, you know the problem that I am facing. I am looking for expert opinion to handle this scenario.
Don't know how about Android, but for iOS you can use targets and then set which files should be used by selected target. Each target may have its own Info.plist file, different graphic assets and more.
Start with duplicating an existing target:
You will notice Info-copy.plist file, which is a setting file for the new target.
Then use a proper scheme to run your new target:
If it's not there, go to "Manage schemes" and press "Autocreate schemes now"
Now I have two projects one is like model and another is like view. Now I use it in eclipse and model is used as library for view. But now I need to move this projects on Github. But I don't want every time to checkout both projects. Is there any way how to do it easily?
Easy but wrong
Most Android library projects which contain a Library and a Sample project have done the following:
Put them both in a empty folder (eg. your workspace)
Call git init in that folder, normally this is called within the project itself.
The right way
As indicated by the titles, the method above is not the normal way,
You should take a look at Submodules,
which is the standard procedure for having multiple projects with git
Imagine mobile application that is planned to be implemented for both iOS and Android.
Development was started from the iOS version only and now the time has come to start with Android one.
iOS application's code is stored at its' own Git repository that named after the apps name, e.g. "MYApp".
Now I would like to create one common repository for both iOS and Android applications and name it again after application's name: "MYApp".
It is not a problem at first glance.
Just create repository, create 2 subfolders there and start working.
But.
I would like that Android developer could work only with his folder and iOS developer only with his one too and both of them could see only their own folders related history (log).
I worked with SVN previously.
Usually I created subfolders and you could checkout any of them to work only with this subfolder.
History was also filtered to your scope.
I'm stuck with implementing the same under Git.
Please, help me to find right direction.
I will sum up solutions suggested.
Use branching for different platforms. I don't think that it is good idea, because branches used for another purpose. It seems to me very "jacky".
Use submodules. Just create as many repos as platforms you are targeting to, name them "MYApp-iOS", "MyApp-Android", etc. and finally end up with "master" repo, that could be names as "MYApp" (without any suffixes). Then add all related repos to "master" one with git submodules feature.
Use git slave. Investigating...
Please, feel free to edit this list to brainstorm the problem.
There is a way to keep to kind-of-related separate projects in a same git repository utilising git branching.
But keep in mind that that is not why branching was implemented into git. One of its uses would be development of a radical new functionality to your app that might not see the release any time soon for example.
On the end: it is a matter of opinion. If you are prepared to administrate a more complex repository just to keep both codes on the same place - you can.
I would definetly make two separate repositories though. Couple of opinions on this topic can also be found here on SO: Git branches with completely different content
EDIT:
gitslave seems to tackle your problem. You might want to give it a try.
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 would like to know how Android app versioning is done when creating apps with Eclipse.
Now I've completed my first working application and would like to develop it further. But I dont want to mess with code of a working application until improved application will be in working condition. Now I can open up new project and copy/paste all code+resources, but it will have different package name (because of duplicating variables) and as I know same Market app should be within same package.
How is this done and what tools are needed?
Use version control for this. For your needs I think Git or Subversion would be enough. So take your working app code, check it in the VCS you chose (Git, Subversion etc), tag it for a release and go from there.
There are some other aspects here. You need to learn about version control and how to use it. And you need to learn about Eclipse workspaces. To address your issue here, you can copy the eclipse project into new folder, create a eclipse workspace there, and import/add this new copy of project in it. This way, you will have one workspace for the working app, and another for your improved app.
Hope this helps you understand. If you are new to programming it may take a bit to wrap your head around it. Good luck.
You can keep your code under version control. Google offers free hosting but it can be seen by other people (if they look hard enough for it). The safest bet is to set up a free SVN server on your computer.
After you have the code under source control, you can access it through a free SVN client.
On Eclipse I use Subclipse together with my own Subversion repository. It works great.
Here is the link, Androids website accepts Git as a standard subversion system, with Repo and Gerrit as helper tools based on Git.
http://source.android.com/source/version-control.html