Recently I found myself wanting to inspect what was in the application database outside of the mobile application I was working on, which as usual lead me to search for a solution on DuckDuckGo.
I found a great link here, which basically says:
- Download and install SQLite command line tools if necessary (OSX comes with one).
- Find the SQLite file you want to inspect
- Run the command to open the database and inspect it:
sqlite3 /Users/<username>/Library/Developer/CoreSimulator/Devices/<Simulator device ID>/data/Containers/Data/Application/<App id>/Library/Private\ Documents/_alloy_.sql sqlite> .tables user order item sqlite> .schema user CREATE TABLE user (id INETGER PRIMARY KEY, uname TEXT, fname TEXT, lname TEXT); sqlite>select * from user; 1|jsmith|John|Smith
- 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
keytool -printcert -file ANDROID_.RSAYou will get certificate fingerprints like this:
MD5: B3:4F:BE:07:AA:78:24:DC:CA:92:36:FF:AE:8C:17:DB SHA1: 16:59:E7:E3:0C:AA:7A:0D:F2:0D:05:20:12:A8:85:0B:32:C5:4F:68 Signature algorithm name: SHA1withRSAThen use the keytool again to print out all the aliases of your signing keystore:
keytool -list -keystore my-signing-key.keystoreYou will get a list of aliases and their certificate fingerprint:
android_key, Jan 23, 2010, PrivateKeyEntry, Certificate fingerprint (MD5): B3:4F:BE:07:AA:78:24:DC:CA:92:36:FF:AE:8C:17:DBVoila! we can now determined the apk has been signed with this keystore, and with the alias ‘android_key’. Keytool is part of Java, so make sure your PATH has Java installation dir in it. read more
- Unzip the downloaded module.
- Copy it to the following folder on OSX Lion /Library/Application Support/Titanium/modules. Be sure to drop it in the right location according to the unzipped folder structure of the module.
- Edit your project’s tiapp.xml file and add the following:
- Start Titanium Studio and follow the module’s instructions to integrate it into your project.
<modules> <module platform="iphone" version="0.5">com.0x82.key.chain</module> <module platform="iphone" version="0.7">com.0x82.testflight</module> </modules>
- Make sure Xcode is closed.
- Install the latest version of PhoneGap
- Go to Xcode prefrences -> Source Trees -> Add a new entry PHONEGAPLIB = /Users/<your username>/Documents/PhoneGapLib
- Either get create_script.sh, or use PhoneGap’s build system to get you started.
create_script.shThis is harder of the two routes, and it may have just been my experience due to point #1, but all you have to do is provide two parameters: a) the project name b) The path where it needs to be installed.
PhoneGap BuildThis is easy as cake. Just put in your project name and in 30 seconds or so you get a project zip file you can download and get started. Happy coding! read more
I have recently shifted to Android since I had to do some development for it and I had to see for myslef if the phone was really as bad as the simulator on the Mac.
The short story is that it is impressive in its own way, but it is not an easy switch from the iPhone.
As I get more time I will be posting my experience with it, along with what I liked and disliked.read more
- 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.