Slicy Photoshop Export Better Than Cake

For iOS and Android projects we're constantly having to export Photoshop designs to the individual assets. It gets very tedious to use the Slice Tool in Photoshop to manually draw boxes around all the assets you want exported and to hide/show groups to get the right transparency and backgrounds.
Well, if you're still doing it this way I have a recommendation! Slicy which is just plain awesome. It's the best $29 I've ever spent.

Take a look at the "How it works" video on that page, but in a nutshell you name your Groups or Assets in a Photoshop file as Foo@2x.png and Slicy will perfectly slice these from the layers and export both the 2x and 1x image sizes. You still have to make sure that the designs use even pixels, but otherwise it works great. That's it. Done. It can even export automatically every time a change is made to the Photoshop file.

We even use it on Android even though it's originally built for iOS. We will use Foo.png instead of the iOS naming of @2x.png (with the designs made for xxhdpi with a resolution of 1080x1920). We then take the directory we had Slicy to export to and use a our android shell script (droidsize.py) to export these to all the other dpi's.

Android New Build System (Gradle)

At Lolay we've now started and are using the Android "New Build System" on 3 projects with success.  We are using a combination of using Android Studio and Gradle with the Android Gradle Plugin. Overall, it was a good decision and it's been worth the time investment as well as minor bugs with Android Studio.

For a background, prior to this for Android development we would use Eclipse, Maven, Maven Android Plugin and the Eclipse m2e Plugin (And we've also used IntelliJ). We're not huge fans of Eclipse, but it is the most popular IDE for Android development (probably not for long). Using Maven, Android and Eclipse together is not an easy experience, and typically had lots of issues. This would particularly be true where the IDE build worked, but the Maven build did not (or vice versa).

One of the things we did like with the Maven builds was the ability to support building a Development, QA, Beta and Release version of an application all of which would use different server URL's, different Flurry codes, etc. This allowed a sophisticated setup. The only problem is this caused a lot of duplication and Android Manifests to obtain this result (we settled on using Maven profiles to point to alternate Android Manifests). This all worked, but was difficult to maintain.

Enter the "New Build System" with Android Studio. First, Android Studio is an absolute pleasure to use. It's as good as the Google I/O talks present. It's also very stable for a Beta version of the product, although this is most likely a result it's really based on IntelliJ and IntelliJ's Android support under the scenes, which was already pretty robust. The Android Plugin for Gradle is also very stable, and this is most likely a result of being able to learn from the Android Plugin for Maven.

One of the nice things about using Android Studio and Gradle with the Android Plugin is it has direct support for building multiple versions of an application. We are now building Debug, QA, Beta and Release version of the application and use different buildTypes to support each one. It's very natural, and it supports modifying your single Android Manifest so that we no longer need to have multiple manifests. In addition, it has a nice "overlay" feature where code and resources in src/main can be overlayed by content/settings in src/{buildType}. This allows us to have have a src/debug/res/values/strings.xml to add in environment specific URL's or Flurry codes. It also allows us to have an environment specific icon in src/debug/res/drawable/ic_launcher.png.

We've also have the great benefit that both the IDE and command line both use Gradle for the build, so that we no longer get issues where an engineer says "works fine built from Eclipse".

The only issue we've run into with the "New Build System" are that occasionally on an Android Studio upgrade it can break something in the project (I'm speaking to you 0.2.4). We've learned to make sure we have a time machine backup before applying any Android Studio upgrade). But, even when this does occur we could build the project command line and edit with a basic text editor like Text Mate to get the build out.

Android Studio and the Android Plugin for Gradle are mainstream enough and stable enough that we recommend all projects switch over to it.

iOS Custom UISwitch

On an iOS project we had the need to provide a custom UISwitch similar to the following.

With iOSS 5 there is quite a bit of support for interface customization. It's great for customizing almost every control in iOS, except... UISwitch. The only thing customizable with UISwitch is the tint color, which is pretty limited. So, iOS 5 is out for supporting this customization.

Next, we looked at several existing open source projects. There are several out there that support a customized look and feel, but none of these had the "feel" of the built in UISwitch control from Apple. Some would allow dragging, and some just clicking, but none allowed both a click and drag interaction.

There was a strong desire for the switch to behave just like the standard UISwitch that supports both a click and drag interaction. That led us to create our own. We were able to support the look and feel and mimic the behavior of UISwitch by implementing a custom drawRect as well as a custom touch handling. Check the Open Source implementation.

LolayUISwitch.h
LolayUISwitch.m

Next, we hope to extend this to support setting the "on" value with animation, and additionally adding in support for all the autoscale settings of iOS on a UIControl. Also, thoughts of supporting a UIView rather than just a UIImage.

OSX Lion and Xcode 4.1

We've upgraded to OSX Lion and Xcode 4.1 and it has been an interesting process. Here's the steps we took.

1. The first was to make sure we were upgraded to 10.6.8 before we started anything.
2. Purchase and download OSX Lion from the App Store (Note, you before starting the installation you may want to create a bootable drive)
3. Install OSX Lion
4. Java is not installed by default, so after Lion is installed you can install Java by going to a Terminal and typing "java -version" and it'll start a download to install Java.
5. Before installing Xcode 4.1 it's good to remove any previous versions of Xcode
1. Uninstall any previous Xcode by issuing a "sudo /Developer/Library/uninstall-devtools"
2. In ~/Library issue a "find . -name *Xcode*" and remove each file/directory
3. In ~/Library issue a "find . -name *Simulator*" and remove each file/directory
4. Reboot
6. Next find Xcode 4.1 on the App Store and download and install it. This just installs the installer. You then have to install it. The installer can be removed when you're finished.
7. If Xcode launches with errors or has no menu times you'll need to reinstall iTunes. The download has the 64-bit universal builds now.

The only issue we've seen is that Core Location isn't working in the simulator and generates an error. See our post on the developer forums.

Zbar on Android with the NDK

We've had experience writing an automobile VIN (Code 39) scanner on both iPhone and Android. In the case of the iPhone we leverage the ZBar library and the Android the ZXing library. Unfortunately, Android has been a tremendous amount of work. There was a tremendous amount of fracturing with the camera drivers to code around to tune the image capture. But that's another story...

For the image processing the ZXing library on Android with was simply not as fast or accurate as capturing   Code 39 barcodes (no opinion on QR, etc.) as ZBar on the iPhone. This left an interesting customer service dilemma as Android would be subpar. We looked at a few options and settled on an interesting proposition.

Android recently introduced the NDK (Native Development Kit) that allows you to build native code from C/C++. Interesting... We realized that there was a good chance that we could get the ZBar library running on Android with the NDK (at least for the image processing). We did have to rewrite the build/make system as the NDK does not have full make/configure support. But, after investing time in this we were able to build the ZBar library on the NDK and leverage their JNI wrapper to invoke this code on Android.

So far the results have been excellent. The ZBar library on Android is 50% faster in recognition for Code 39 and a lot more accurate.

We'll be donating an example project to the ZBar project once we can remove the client specific portions.

Also, just be aware this only applies for Code 39. We have no idea how the image processing quality compares for the other formats.