
Fuck the Android Build Process - mdelbo
http://www.bonobolabs.com/fuck-the-android-build-process/
======
spacemanaki
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)

~~~
mdelbo
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.

~~~
fpgeek
No matter what's happened to date, I'd hope that future developers will find
your rant pretty quickly and end up saving the 2 days.

------
thezilch
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.

------
zambo
Not able to try this out right now but:

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.

~~~
mdelbo
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.

~~~
petedoyle
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).

~~~
mdelbo
Handy to know that setting exists. Thanks dude.

------
scompt
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.

------
Zigurd
"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.

------
pkulak
Why can't you just use a config file?

------
techblock
Do you guys think that the frustrating for building on Android has made more
developers switch over the just developing on iOS?

~~~
tszming
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.

~~~
X-Istence
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.

~~~
tszming
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 ..

------
emehrkay
If only there were a tool to help automate some of the finer details of Java
application development

------
drivebyacct2
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.

~~~
mkramlich
... or tried doing iOS development.

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.

~~~
mdelbo
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.

~~~
drivebyacct2
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.

