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:

1. Download and install SQLite command line tools if necessary (OSX comes with one).
2. Find the SQLite file you want to inspect
3. 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

read more

In order to have a fully regression tested application, it is necessary to have an automated build process to ensure all checkins are validated nightly ( or whatever your schedule is). This is a simple task for most Java projects, however you may run into some issues with Android that I point out here.

• 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 Setup

The 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 files

In 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 project

In 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 project

This 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 build

Now 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 app

One 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=
 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 command

OK, 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 release

Good luck. read more

I found this on stack overflow, so I am just recapturing here since i found it so useful. First, unzip the APK and extract the file /META-INF/ANDROID_.RSA (this file may also be CERT.RSA, but there should only be one .RSA file). Then issue this command:

     keytool -printcert -file ANDROID_.RSA

You 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: SHA1withRSA

Then use the keytool again to print out all the aliases of your signing keystore:

     keytool -list -keystore my-signing-key.keystore

You 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:DB

Voila! 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

Apple announced their iOS6, along with OSX Mountain Lion, and bunch of new hardware on Monday. Amongst the new features announced were features that already exist on over platforms but now they do on Apple’s platform as well. Take do not disturb for example! This feature is nothing new, and platforms like BlackBerry have had it for years, so what makes it awesome on iOS? The smart thing that Apple has done is that instead of bombarding folks with a ton of new features that will never get learnt (and thus used), they slowly introduce them so that users’ expertise grows with the platform. Its true that Android lets you configure anything and everything, but half the folks that own an Android phone don’t know how to use half of its features. They are just happy either because they know they are not sandboxed or that they do not have an iPhone like everyone else. Apple created the original iPhone with just the bare functionality needed to make it usable. Granted the whole iPhone design was new, awesome, game changing, and infinitely intuitive, but the actual functionality of the phone was nothing new. This let buys get used to the platform and grows with it as new features came out. So while ‘Do Not Disturb’ is a welcomed addition to iOS6, its not an earth shattering feature….and since its one of only a dozen visible changes to the platform, most anyone who needed the feature will know how to use it. read more

Here is a great guide for packaging your Sencha Touch 2 application. In addition to this, also take a look at the getting started guide for Sencha Touch 2 since alot has changed. read more

According to the internets, all of them, HTC is about to concentrate on making fewer, better phones. If so, other phone makers should follow suit to save themselves. Yes, its true that most people do not want to have a phone that everybody else has, and this is the exact reason why some have chosen iPhone alternatives (of which there are none….but I’m not biased at all). Because, lets be honest, as flexible and configurable as Android may be, it is no where as user friendly as the iphone, nor as responsive or usable. In fact, my own Nexus S is just collecting dust since it was an absolute pain to deal with… inaccurate clicks…inconsistent UI, slow, etc, etc. So the only reason anyone would get any other phone than an iPhone would be not to have the phone everyone else has. Case and point, a very close friend admitted to this very fact, but finally reason took over and he got an iPhone. Back to the point here…as I mentioned in an earlier post, one of Apple’s successes with the iPhone, IMHO, is that it concentrates on fewer hardware, and supports said hardware for at least 2 years. The other phone makers, just roll out newer versions of their phones instead with different screen sizes which has been another pitfall for Android….and don’t get me started on BlackBerry. As for Nokia’s refocus……..it is about to release the Lumia 900 Series only a few months after releasing the 810 and 710. In fact, all these phones have been released in less than a year. What do you think will happen with the older phones, when there is new hardware out? They’ll be forgotten and de-prioritized. Lets hope HTC is serious here and gets back to its roots. read more

Appcelerator Titanium is a decent tool once you get used to its quirks. However, it is even more powerful with its marketplace and optional modules you can add to it. Two of my recent purchases have been from 0x82: Testflight, and KeyChain. here is a quick quide on how to add new modules to your titanium project:

1. Unzip the downloaded module.
2. 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.
3. Edit your project’s tiapp.xml file and add the following:

<modules>
    <module platform="iphone" version="0.5">com.0x82.key.chain</module>
    <module platform="iphone" version="0.7">com.0x82.testflight</module>
</modules>

4. Start Titanium Studio and follow the module’s instructions to integrate it into your project.

  Good luck! read more

PhoneGap just released version 0.9.5, but it still does not fix the issue with getting a project started with Xcode 4. Here is what I did to get my project going:

1. Make sure Xcode is closed.
2. Install the latest version of PhoneGap
3. Go to Xcode prefrences -> Source Trees -> Add a new entry PHONEGAPLIB = /Users/<your username>/Documents/PhoneGapLib
4. Either get create_script.sh, or use PhoneGap’s build system to get you started.

create_script.sh

This 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 Build

This 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

And there probably won’t be one anytime in the near future. For anyone that doubts this, let me just say that Apple just surpassed Microsoft this past quarter in revenue and that is no small feat. Well it seems pretty simple enough to answer, right? Apple has a very simple formula:

• Make it simple
• Guarantee the experience
• Provide a single app store
• Have a clear product lifecycle

 

Make it simple

This 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 experience

This 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 guarantee

The 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 all

Now 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 lifecycle

At 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 away

Having 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:

1. 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
2. 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
3. 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.
4. 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
5. 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.
6. (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.
7. (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.

How else can others compete with the iPhone? Get vocal in the comments. read more