This doesn't sound so bad. After reading the paragraph that ended with "Confused? Yeah I was too..." I wasn't confused at all, actually your explanation was good and basically makes sense to me. Maybe not ideal, but that being said, the fact that you were able to come up with what looks like a pretty decent work around is really a credit to the process. The command line Ant tools enable all kinds of customized stuff as well as supporting using tools other than Eclipse. (at my last job we heavily customized it to support building "branded" apps that were released to the market with different package names and images) I'm pretty glad that they based the build system on it, even though Ant itself is terrifying.
I guess after working on BlackBerry apps, I'm spoiled by Android's tools. (to build a BB app of even moderate complexity and deploy it to a device, you have to contact a RIM server. Every. single. time. That and the Eclipse plugin was straight up broken for a long time)
Agree it's not so bad. Just took 2 days to figure out how to do it. 2 days I'd rather have spent making the app more awesome. If on average other developers - I like to think I'm at least average :) - spent this long then that's like a million hours that they've spent on their build config instead of making their apps more awesome.
I wasn't, at all, confused by the solution derived in the article. Ant is fairly common to Java builds I've worked with. But why not have VCS hooks to fix per-dev, testing, staging, and release configurations? I know of dozens exotic build processes, and this seems rather tame.
1. You can select a custom debug key in eclipse and have multiple devs sign with the same debug key.
2. You should be able to instantiate the MapView in the code at runtime (don't have a dev set up to try this on right now but check out MapView(android.content.Context context, java.lang.String apiKey)). Just provide the API key based off a debug/release flag set in your code.
Thanks Zambo. I couldn't find a way to set a custom debug key in Eclipse - I'm using IntelliJ but this frustrated me so much I was considering migrating to Eclipse.
I was also using a debug/release flag previously but kept forgetting to change it when I sent the release build out for testing.
Great post, I'm working on my build tonight and this'll come in handy. I usually end up just changing the Maps API key locally and never committing it which kinda sucks.
For Eclipse you can set the debug key here: Window > Preferences > Android > Build > Custom debug keystore. That's for the normal Eclipse/android build process.
Comes in handy when developing on multiple machines as you can't update an app that was signed with a different debug key (must uninstall first).
Resource overlays might have solved the problem a bit More gracefully. They allow you to specify additional resource directories that take precedence over the default one. I don't have a link at the moment, but google should be able to tell you something. You'd still have to hack around with the build file a bit, but if you're a java/android programmer you should know about ant anyway.
As long as you're learning about java build tools, take a look at the android maven plugin. It can be useful once you outgrow the confines of the default android build process.
"Ant? Why do I know Ant now? I didn’t know Ant 2 days ago. Is it really necessary to have to learn a build tool to perform such a common task?"
Ant is the backstop to the build the IDE makes automatically, in cases, like this one, where there isn't a parameter you can set in the build options dialog.
You might not like ant, or having to learn it. But it's not an unusual choice for Java builds. There are many cases in more-complex Android project builds where ant is necessary.
It is even more frustrating if you are new to the iOS development - need to deal with the code sign, provisioning profiles, certificates, device ID, XCodeConfig, upgrading XCode 3 project to XCode 4 etc..
But I agree the Eclipse / Android SDK should have a better way to support the debug/release build.
I created a brand new iOS project, didn't have to deal with code signing, didn't have to deal with provisioning profiles, certificates, device ID, XcodeConfig, or upgrading from Xcode 3 to Xcode 4.
Then again, I have yet to submit my app to the App Store, or run it on a physical device. Getting started with iOS is a LOT less trouble compared to starting with Android development. I can't even begin to compare the two when started out anew.
I agree it is less trouble to make you first iOS app running in the simulator than Android app.
But after that, for Android app, what you all need is to export the APK file from Eclipse (sign with a keystore) for upload or copy the device; for iOS app, you have much things to do ..
It might just be newer people to Java development with Ant and Maven hell. Frameworks like Play are ridding the bulkiness of setups like that. But still they are a large part of the infrastructure of Java.
Am I the only person in the world who likes Maven? I am a hipster Ruby on Rails dev by day (the type who should loathe Maven), but in a past job I had to use Maven, and I really like how various details about the project (name, version, dependencies) are well defined. Writing plugins isn't easy to get started, but once over the initial hurdle, it's nice to have those things specified.
Comparing to Rake, I'm currently trying to create a rake task to create a custom package (non-gem). I don't even get a project name for free. I've got to ask the user to pass in the name (or a Gemspec object perhaps).
Is the objection to the mass of XML? Or to Maven itself? I can understand the former, but I really think Maven is a well engineered system...
It's more of a love hate thing, it is pretty powerful but it becomes a problem with very long build processes in my experience on big teams. I actually like Maven personally and more so like stuff like SCons: http://www.scons.org/. It seems more common platform rather than so tuned to Java like Maven.
Just in my experience every software project I have been on with Java that used maven had an immense build process. I am not kidding one system I worked on the tests alone within it took about 45 minutes per day just to get started. Maybe it is too powerful, and yes part of that is the xml/enterprise feel of Java and guilty by association.
Someone hasn't tried to do Azure development with Visual Studio if they think this Release/Debug type management is a nightmare. Oh let me name the number of inconsistent ways of transforming config files depending on environments.
Not sure why this keeps getting downvoted. It's a well known "dirty secret". Just try searching for XML Config Transforms as that's theoretically the clean way of solving this problem. It's only natively supported for certain projects, can be hacked into more via manually editting MSBUILD and CSPROJ files and worst of all, breaks miserably during the Azure deploy as VS simply skips some of MSBUILD files and simply decides to package things from your original source tree as it sees fit. Meaning it completely and utterly fails at the one good thing it can do as it only works in fairly contrived situations.
This means I have to manually edit connection strings, debug settings and more that vary between our local ASP.NET servers, our intranet dev server, our local emulator environment and then debug/prod Azure instances.
If I'm mistaken I would be ecstatic to be corrected. Hell, I'd have paid money out of pocket for a macro/conditional solution for this problem when I was working on this project. Also, if it's just too off-topic, please accept my sincere apologies. I just found it kinda nitpicky to pick on Android for this, although I can sympathize with the author if they're accustomed to more "open" languages and frameworks that are more tool-friendly.
Granted, given all the complex permutations and needs the iOS development team and XCode and Apple App Store has to support, there's probably a lot of method to the madness, a lot of "necessary" complexity. The problem is that if you zoom out a bit, much of the complexity one originally thinks is necessary, is not actually necessary, if you change one or more of your premises.
Oh I love the way Xcode handles this. Just setup multiple targets and use a preprocessor macro to switch between configurations. A nice drop down to select from when you're building. It's bliss! Learning the iOS way took me way less time than figuring it out for Android and it was a nicer solution.
I think people view this as too techy of a solution and I think people rely on their IDEs for this sort of thing too much, but after trying to automate my Azure deployments (local web, dev emulator, prod), I finally gave up and just resorted to having to manually comment/uncomment things in files and flex dropdown boxes across Visual Studio everytime I wanted to change environments. And I paid the 45-minute deploy time tax every time I forgot to change one of them when I deployed.
I'd have killed for a simple macro syntax to use within my config files. Hell, at one point I was actually (stupidly, one of the more futile tasks I've ever tried) editting the MSBUILD files by hand.
I guess after working on BlackBerry apps, I'm spoiled by Android's tools. (to build a BB app of even moderate complexity and deploy it to a device, you have to contact a RIM server. Every. single. time. That and the Eclipse plugin was straight up broken for a long time)