An Android application that I am interested in (OpenSudoku) has become unmaintained by the original author, who last updated the application just under a year ago, in addition they have rejects offers of help from others to contribute directly to the hosted SVN repository.
I am interested enough in the project to seriously consider forking it (I am already familar with many arguments for and against forking in general), but I do have a couple of questions related to best practice with forking Android applications, specifically:
I understand that I will have to change the package name/namespace, is there an easy method I can use to do this (without breaking the Eclipse project files and associated references)?
Is there a way to help users that may want to migrate to the new application, recover settings/data from the original application? (My understanding is that the permissions model that Android enforces would make this impossible)?
Are there any other issues that I should be aware of that comes with forking an Android application that I would need to plan for?
AndroidManifest.xml, various build system files, layouts that use your own views, each Java source file, and the directory tree. That's what you have to change. I use vim -p glob glob glob for changes like this, and mv, which is easy enough.
Not unless the old application cooperates, which it likely doesn't. Perhaps your fork could detect an OpenSudoku install and prompt the user to install, off-market, an 'update' for it that just repackages its preferences for your consumption. I don't know if that works, updating a Market app with a non-market APK. Although, you said "settings/data". If 'data' includes e.g. sets of puzzles on the sdcard, yes, you can load that kind of data without any trouble -- FAT32 offers no security.
Related
I'm building an app with android studio with another developer. Is there any way in which I can make it so that both my partner and I can work on the project at the same time on different computers (both Windows computers)? I know there is a similar question, but I am looking for a more detailed explanation on how to do it.
My suggestion: Use Version Control preferably git.
This will help both of you to develop Apps without any problems of copying & pasting and manually making changes in all files one-by-one.
Note: Want to use git but do not want to open source your code (since Github allows creating private repository but with some Payment), then use Bitbucket, you can create private repositories for FREE!
EDIT: Github now provides unlimited private repositories.
Hope it helps!
Take a look at git. I will help you and your partner to work on the same project on a different computer (Windows, Mac, Linux...).
https://www.atlassian.com/git/tutorials/comparing-workflows
As others have indicated, you should use a version control system like git for this. This will give you the following features (among others):
The ability to share code between people
Essentially keeps a backup of your code on an external server
Keeps a history of revisions to files (so you can "back out" changes if you need) as well as differences between your local file and the version on the server
Allows you to merge changes between you and people working with you
How you do this will depend on which version control system you use, but some version control providers will allow you to also set up what's known as "Continuous Integration" - basically, if you or your partner check code in, it'll immediately start a build. If this is available to you, I strongly recommend using it. The advantage of that is that it'll give you quick feedback if you did something that'll prevent it from building for the other person (e.g. if you forgot to check in a file or something). This'll prevent a lot of frustration and wasted time. (This happens a lot more often than you'd think; you don't want the other person to have to spend half an hour trying to get the app to build again when they download your code only to find out that you forgot to check in a file).
I also strongly recommend integrating your stuff with each other as often as possible as well as practicing regular "re-baselines" (i.e. downloading each others' stuff and merging it with what you have locally). The longer you wait to integrate your stuff with each other the more complicated it'll become, and waiting too long greatly increases the risk of introducing bugs when merging or forcing unnecessary rework.
I have a piece software that should delivered to many customers.
Each build should get a customized set of assets (icons , splash screen etc. ) and a bunch of config files, but also a different app id (eg. com.myself.myapp.customer1 ; com.myself.myapp.customer2 etc... )
Also I need builds for different OSes like Android, iOS , PlayBook.
The way I handled this up to now was:
I created a new Application.mxml for each customer, which opened the right locations and passed the files to the MainController.
This leaves it to me to pick the right assets, certificates and iOS-provisioning files to be packaged each time I need to compile, and I had to repeat this steps for each customer, which is very error-prone and , especially in case of iOS, extremely time-consuming.
So I need to get into automated building quickly...
I already downloaded and installed gradle/gradleFX, but I don't find the documentation very friendly to beginners in this subject.
Now the questions:
How do I have to convert the (Flash Builder- ) given project structure to conform the gradle conventions? Are there FB-plugins or tools I could use?
Can I use gradleFX to build for debug sessions as well? FB 4.7 has a lot of issues with that I really like to circumvent.
Can an ipa be "signed" and packaged with assets after it's principle compilation, so I don't have to wait 15 mins for each compile?
Many thanks
How do I have to convert the (Flash Builder- ) given project structure
to conform the gradle conventions? Are there FB-plugins or tools I
could use?
There is nothing to convert. Unless your project structure is extremely exotic, you should be able to configure GradleFx to work with it.
Note that by default GradleFx uses some Maven-style conventions: for instance, the default source folder will be src/main/actionscript. If you want to configure a typical FlashBuilder project you'll have to explicitly declare the source folder:
srcDirs = ['src']
As for FB plugins: there are none. But you can use an "external build tool" instead of FB's built-in configuration. IntelliJ IDEA has Gradle support, but nothing specifically for GradleFx. GradleFx itself has a flashbuilder plugin, but its purpose is to generate an FB-compatible project from a build script - I don't think that's what you're looking for.
Can I use gradleFX to build for debug sessions as well? FB 4.7 has a
lot of issues with that I really like to circumvent.
You can build a debug-enabled version of your application simply by setting the debug flag to true (as described in Adobe's mxmlc docs). GradleFx does not expose all compiler options in its API (there's just too many of them), however you can use the additionalCompilerOptions to define whatever additional compiler flags you require:
additionalCompilerOptions = ['-debug=true']
I don't know how you should tell FlashBuilder to hook up to the compiled swf for its debug session though :( Perhaps through the "external build tool" configuration.
Can an ipa be "signed" and packaged with assets after it's principle
compilation, so I don't have to wait 15 mins for each compile?
I know too little of mobile support to give you a meaningful answer here, but I can tell you that a major upgrade in this area is in the works right now and will be released soon. Perhaps you should ask this question on http://support.gradlefx.org/; #Slevinbe is very helpful and quick to answer.
I don't find the documentation very friendly to beginners in this
subject
If the docs don't work for you, perhaps the example projects might be more helpful. That said, you could help us make the docs better for beginners by telling us how we could improve them. Just start a discussion on support.gradlefx.org
Multiple outputs
One more thing: your main issue seems to be that you need to create multiple outputs from a single code base. This is one thing that GradleFx doesn't provide out-of-the-box (yet). However, there's a fairly unobtrusive workaround that I've described on my blog. If you find the basic concepts difficult to grasp, then I suggest you don't start with this part, but rather concentrate on getting a single project building first.
I'm working on a Android project which six packages (which commanicate between them) with at least 5 classes in each of them.
I'm trying to optimize my project in order to change my Application Structure and to make it as generic and reliable as possible. Thus, I'm trying to reduce the number of package.
Is it recommanded to have a project with few packages? In other word, what are the consequences (especially on the project execution) of having a lot of packages?
Packages are mainly a convenient way of organising a project with a functionnal or technical separation.
There was an interesting article about optimisation a long time ago on android developer blog where it was mentionned that getter and setter were to be avoided. So relying on public field members was the way to go (http://developer.android.com/training/articles/perf-tips.html). To prevent things to become messy, a programmer reflex would be to "protect" the fields (ie protected) from an acces from another package. With current jit compiler optimizations this is not true anymore. So working with the less packages possible is not really making sense. For the sake of clarity, i would suggest to create as much packages as needed.
My app is getting to the point where I will be highly perturbed if I lose the source somehow. This is a personal / single developer project, so something like Subversion might be overkill. I'm thinking more along the lines of the "Backup" agent that is a part of the GExperts add-on in the Delphi world. Is there such a thing (that would backup all the .java, .xml, sqlite, etc. files) specifically for or suitable for the Android platform?
In my opinion using a version controll system is not overkill at all. You can keep hand on changes all the time. Making features that you don't even know whether to include or not into main branch. Not only features but every complicated task also, for example refactoring. With VCS that's no problem to make fast fix to released product during development of a huge task which is incomplete.
I can't imagine working without any VCS. I prefer Git because is fast and easy.
I'm producing an application for multiple clients. Each of these apps only slightly differs (in the ui presentation) from the others and almost all of the other code is identical.
In the best case scenario I would brand something like a boot-strap app for each client so they could have their logo on a separate app in the market. Once a user installed a client's app it would download the core functionality, set some prefs and launch as if it had come from a single download. This way I could get the benefit of updating for bug fixes once rather than for each application (slated for 20-30 by end of year.) I've read that this isn't possible because of security measures though (and additional visits to the market place for the second download or having to allow installation from unknown sources isn't acceptable.)
I'm thinking that worst-case/only-case might be to include this shared code in each application and create some batch build and deploy once updates are ready.
I'm looking for a .dll like approach for economy of effort and safety.
I'd appreciate any input on this.
Thanks!
The java equivalent of a dll is a jar file. You can extract all of your shared functionality into a library project that compiles into a jar and then include that as a library in your other projects.