- If you started your project from Eclipse, you may not have the Ant build file and supporting properties file in your project
- If you want to sign your application with a key, the default build keeps prompting you for the keystore password
Both of these are relatively easy to over come and here is a great article on StackOverflow. My only goal here is capture it all in one place.
Environment SetupThe first thing to do, is to make sure that your android SDK folder is on your path. In order to do that, just update your local .bash_profile in your home folder to include the following paths:
#!/bin/sh export PATH=$PATH:$HOME:$HOME/Documents/Development/android-sdk-macosx/tools:\ $HOME/Documents/Development/android-sdk-macosx/platform-tools export ANDROID_HOME=/Users/Kouroche/Documents/Development/android-sdk-macosx
Note the \ in the first export command. It is there to split the command over two lines, but you don’t need that in there. This will not only add the Android SDK to your path, but also define ANDROID_HOME which is used by the build file (more on that later).At this point, you will either have to logout and login again, or source .bash_profile to make sure the changes took effect. To verify, run the following command from your home folder:
$ android list targets
Build filesIn order to add the build files to your project, you can either create a new project from the command line and copy those build files to your project, or you could update you project from the command line to add in the build files.
Creating a new projectIn order to create a new project from the command line, run the following command:
$ android create project --target
--name MyFirstApp \ --path /MyApp --activity MainActivity \ --package com.acme.myapp
The app name nor the package matter. The only thing you may want to match to your current application is the <target-id>.Once the project is created, copy over the following files to the root of your own project and then delete this app folder.
- ant.properties – This is where you store your project specific properties for Ant
- build.xml – This is the generic build file provided by the Android SDK and will most likely not need changing
- local.properties – This file contains the path to your SDK, but I prefer not to copy it over since it may get checked in by mistake.
- progaurd-project.txt – This file contains ProGaurd rules if you choose to obfuscate your code, and more can be found here about that.
- project.properties – This file contains the target for your project and is most likely already part of your project.
Updating your existing projectThis is probably your best bet since it is less of a hack and should add the same set of files to your project.
$ android update project --name
--target \ --path
Once again, make sure to use the same <target-id>
Customizing the buildNow that you can use Ant to build your project, you may want to customize the build process to meet your needs. For example, I always include a build ID somewhere in the application so users can report which build they are on when reporting issues, or you may want your release build to point to a different backend server than your debug build. In any case, the Android SDK makes this also very easy. Looking at the build file, it optionally imports a custom_rules.xml file that you can create in your project root folder to hook into the build process. The build file even lists out the targets for your to include. Here is a sample one I created:
What this does, is to update the build ID in my constants class, and also update the backend server my app talks to depending on whether it is a release build or not.
Signing the appOne of the issues I mentioned early on, for the need to have build automation, was having to provide a password each time the app needed to be signed. Well, the key to solving this problem is the ant.properties file which includes your project specific properties. Unfortunately, i have not found a way around having to include your password in plaintext in some form or fashion so that it can be used, but if your an individual or have a designated build person or machine, you can lock the file down pretty good. So, to get back to the issue at hand, include the following four lines in your ant.properties file and you are good to go:
key.store.password= key.alias= key.alias.password=
If you have been building with Eclipse for while and don’t recall your keystore alias, an easy way is to go through the export process in Eclipse to release the app and see what the keystore alias is.
The build commandOK, so now that it is all set, the easy part is building the application. You can run either of the following commands to build the app for debug or release respectively.
$ ant debug or $ ant releaseGood luck. read more
Issues prior to 4.x
- Unintuitive application navigation – The best example for this was google’s own Google Voice app. Sometimes you could get into say a text chat, and have no way to go back to your inbox sine the back button just closed the app. There were many other examples.
- Horrible keyboard – Although lots of folks love the swift keyboard and have learnt to type by swiping across the keyboard, I am still old fashioned and like to use my thumbs to type. The old keyboard besides being inaccurate, also had the problem of the touch keys below it (Nexus S specific). Since the back, menu, search and home buttons are all touch sensitive, and they are just below the keyboard, you could easily press one of them by mistake and be out of the app you were typing in. I use the same thumbs on my iPhone and never had this level of inaccuracy.
- Horrible browser – The default Android browser was horrible for HTML5 web apps and was just slow. I tried many others, including Firefox beta and Dolphin browser, but none were as solid as Safari on the iPhone.
- Overall Stability – Apps frequently crashed or would be terribly slow to respond. Besides the fact that I have yet to see an app that looks better on Android than it does on the iPhone, apps on Android occasionally crashed which did not help the user experience.
Issues after 4.x
- Keyboard – The keyboard is still an issue and it is pretty much the only one left. Unless you use a third party keyboard that works well, the default keyboard is still way too inaccurate.
- Browser – While the default browser that ships with Android is still not up to par with Safari, Chrome for Android is a much better choice. As a second alternative, the Dolpin browser has some great features like gestures and voice commands that are fun to play with.
- Add Google’s public DNS servers as static DNS servers for the DHCP server. Note that since my main router is using 192.168.1.x, I put this router on 192.168.11.x to make sure there is no complications.
- Configure the wireless access point on the router so that it does not conflict with your main wirless connection (i.e. give it a different name and use a different channel to be extra safe).
- Enable and configure the PPTP client on the router to connect to your favorite VPN location. You can get a list of the VPN location for Witopia here. For the Server IP or DNS Name I put in the IP address of the vpn server I wanted to connect to (e.g. pptp.chicago.witopia.net).
- Add a startup script to the router to configure it to use the VPN connection properly.
The script below will wait until VPN is connected and then update the router’s routing appropriately. Note that 192.168.1.1 is the internal IP of my main router, not the VPN router which is 192.168.11.1.
echo "echo \"Startup Config started\" >> /tmp/mylog.txt" > /tmp/startupConfig.sh echo PPTPSERVER=$(/usr/sbin/nvram get pptpd_client_srvip) >> /tmp/startupConfig.sh echo PPTPGWY=192.168.1.1 >> /tmp/startupConfig.sh echo "/sbin/route add -host \$PPTPSERVER gw \$PPTPGWY" >> /tmp/startupConfig.sh echo "#/sbin/route del default" >> /tmp/startupConfig.sh echo "/sbin/route add default gw \$PPTPGWY metric 100" >> /tmp/startupConfig.sh echo "/sbin/route add default dev ppp0" >> /tmp/startupConfig.sh echo "/sbin/route del default" >> /tmp/startupConfig.sh echo "/sbin/route del default" >> /tmp/startupConfig.sh echo iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE >> /tmp/startupConfig.sh echo "ifconfig ppp0 > /dev/null" > /tmp/whileLoop.sh echo "RC=\$?" >> /tmp/whileLoop.sh echo "echo \"Checking ppp0: \$RC\" >> /tmp/mylog.txt" >> /tmp/whileLoop.sh echo "while [ \$RC -ne 0 ]; do" >> /tmp/whileLoop.sh echo " sleep 5" >> /tmp/whileLoop.sh echo " ifconfig ppp0 > /dev/null" >> /tmp/whileLoop.sh echo " RC=\$?" >> /tmp/whileLoop.sh echo " echo \"Checking ppp0: \$RC\" >> /tmp/mylog.txt" >> /tmp/whileLoop.sh echo "done" >> /tmp/whileLoop.sh echo "echo \"Running startupConfig.sh\" >> /tmp/mylog.txt" >> /tmp/whileLoop.sh echo "ifconfig ppp0 >> /tmp/mylog.txt" >> /tmp/whileLoop.sh echo "sh /tmp/startupConfig.sh" >> /tmp/whileLoop.sh sh /tmp/whileLoop.sh &
- Make it simple
- Guarantee the experience
- Provide a single app store
- Have a clear product lifecycle
Make it simpleThis is a very important success factor for Apple. Everyone, from my 7 year old daughter to my Dad can use the device without instructions. The finger is a natural utility we all know how to use and the rest is just a click away. Granted the other mobile OS platforms have made a lot of progress here, but Apple started it and it is the simplest one to use.
Guarantee the experienceThis is perhaps THE most important success factor for Apple. By controlling both the software and hardware, they basically guarantee you the experience you are going to have. There is only one iPhone, but there are 10s or 20s of each other device. You can get an Android phone from LG, Samsung, Motorola, HTC, just to name a few and they each provide various versions with different specs and their own experience. The same is true for Windows Mobile, WP7 and even palm and RIM. While it is good to have a variety and everyone likes to be unique, it could change your mind about a operating system, device manufacturer, or both if you end up with a device that does not perform. The best example is Nokia. They are still the biggest phone manufacturer on the planet and for the longest time they have what I thought was the best phone factor (until I saw the iPhone). I am talking about the Nokia Communicator. I bought the Nokia 9500 Communicator as soon as it came out and was very excited about it, until I was let down by Nokia. For a $900+ phone, the browser was lousy, it crashed often, took too long to start (along with every other app) and never got any software updates. The worst was the promise to support the BlackBerry platform which never came except to certain European regions. Worst yet, Nokia abandoned that version of the Symbian platform. Not that the iPhone is without fault, but at least I know it will work fast. This was the one thing that impressed me enough to change my mind about the iPhone and touch screen devices. Before the iPhone, I had had such a bad experience with Windows and SonyEricsson touch screen phones that I would not buy a phone unless it had a physical keypad/keyboard. That is mainly why I skipped the original iPhone and waited for iPhone 3G.
The developer guaranteeThe second aspect of the experience guarantee is what developers got. One platform, one resolution, one set of features, and one place to advertise. We will talk about the latter point later, but these are also very important. Again, with almost any other platform every developer has to worry about what devices to support, what resolutions they may have and what features they may have, which ultimately means that the user experience for end users will not be the same on every phone. And this is not accounting for the programming difficulties to support these variations. I must end this section by saying that Windows Phone 7 has made great strides here, but I still do not see it as the same since the hardware is not controlled which would mean that every manufacturer will do something different to make its phone more attractive to end users.
Provide a single app store – One Store to rule them allNow this is arguable the most controversial aspect of the iOS ecosystem. Originally, I disliked the fact that I was not free to put any software I liked on the phone, but now I see the value of it. Before the App Store, almost everyone was skeptical over buying mobile software for various reasons. Chief among these was the fact that it was relatively expensive, and almost always tied to your particular phone, so you had to repurchase it if you upgraded your handset (even if it was just a newer model of the same phone). The iPhone addresses all of these, plus it provides a single great place to promote and sell your app. The approval process has its faults and there are many, but again it too protects users to some extent so they can shop with some sense of security. As for the other potentials now, their app stores are segmented at best which just damages their potential.
Have a clear product lifecycleAt the risk of sounding like a broken record, this also is critical to Apple’s success. The current product lifecycle for any iPhone so far has been two years, which is a year and half more than any other device. I say this jokingly, but it is almost true. Every other phone maker, has such diversity in their phone offering that they do not care about the hardware. Its all disposable, except the money we put down to get it. The only thing that has changed recently is that Google’s Android has been upgradable on some phones (mainly its own G1 and Nexus One), and even at that, you are at the mercy of the device manufacturer as to when and if they will support newer versions of Android. With the iPhone its a clear message. An iPhone will be upgradable to the latest version of the iOS platform for two years. I have to say that Microsoft again is trying to catchup here, and they announced that WP7 phones will be upgradable over the air, and they specifically mentioned this regarding the cut and paste that will be added to WP7. IF they execute well here, they could have this one nailed down.
What to take awayHaving said all of this, there has been some changes in the iPhone ecosystem with the iPhone 4 having a retina display, but you can be certain that iPhone 5 will not support a new resolution, and there is a compromise to be made between consistency and advancing. The only two manufacturers that I see with a true potential to compete with the iPhone are RIM and now HP. They are the only two that control the software and hardware so they can control every aspect of the user experience. For the others it is much harder. Here are a few pointers for the other manufacturers if they are listening:
- Reduce your hardware offering, and instead concentrate on fewer devices with a longer lifecycle. If users know that they are buying a phone that will be supported for a year or two, they will be more inclined to make that investment
- Related to the first, make sure you do provide software updates for your phones. This buys brand loyalty when combined with a good user experience
- There is a fine balance between performance and battery life. But for a smartphone, the performance has to be snappy, otherwise no one will care that the battery lasts 5 days.
- Provide consistency between your devices. You can provide a touchscreen phone, one with a physical keyboard, and even a clamshell, but make it easy for developers to develop one code for all your devices
- Related to the last point, provide a single portal for users to buy applications. Users should not have to jump from shop to shop depending on what they need. Granted this is difficult with some service providers such as Verizon insisting on its own App Store.
- (Personal Agenda) For goodness sake, provide a GSM version of your phone with global support. The rest of the world runs on GSM and users want to know that they can use their phones everywhere.
- (personal Agenda) Do not lock your phones to a provider. We are already tied to contracts to get the phone with huge ETF fees, and most people don’t like to jump providers just for the heck of it. But we do like to be able to put in a local sim when traveling abroad and not have to spend the kids’ tuition fund on mobile fees.