Friday, September 13, 2013

Beamz by Flo Rida

Check out the new Beamz by Flo Rida that just launched on the Mac App Store. Just a great Mac app that integrates with the Beamz by Flo Rida instrument. It's our first Mac app that integrates with a USB device (as well as Bluetooth Low Energy forthcoming). Tremendous team effort to get it launched!

It's a very addictive experience and is a lot of fun to use! It just sucked me in to keep playing and experimenting with it. I was using a prototype, but can't wait for the production versions! Awesome gift for the Holidays coming up!

The app can be used without the device to get a feel for what it would be like without the instrument, and there's also a version for iOS devices that uses Bluetooth Low Energy on the iOS App Store (launched in August).

Monday, September 2, 2013

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 ( to export these to all the other dpi's.

Saturday, August 24, 2013

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.

Thursday, February 21, 2013

Building iPhone and Android Apps at the Same Time

Recently we had the pleasure of working with on an app for both iPhone and Android for DomainSponsor (and prior ShopWiki). It's quite common for us to launch an application on both platforms at the same time, and DomainSponsor was no exception.

There are a few things we take into consideration when launching an application on both platforms.

  1. Try to keep costs to a minimum by using the same design across iPhone and Android.
  2. Build each platform using the best practices of each platform and adjust the design accordingly. Some examples are adjusting an app from iPhone to Android are
    1. Adding in Back and Up navigation
    2. Location of UI elements like tab controllers
    3. Adding Action Bar elements on the application bar
    4. Using dialogues in the design
    5. Using menus (although we still believe in those elements being available without using the menu as there are many users not aware it even exists).
  3. We build each platform natively
    1. The savings to building each platform natively is cost. But, there are tricks to keep this to a minimum like sharing the design elements/flow as well as using the same overall architecture, naming, etc. when building both apps (i.e. if it's called InboxViewController on iOS it's called InboxActivity on Android and the back end is called InboxManager on both platforms). If you really want to save costs and build once then go straight to mobile web.
    2. Platforms like PhoneGap, Titanium, MonoTouch just do not have a responsiveness interface nor feel like a native experience. We've used them all on applications we've taken over and need to support. We're not the only one, companies like Facebook, HowAboutWe, etc. have all come to the same decision.
    3. We can give a great experience that feels natural to users accustomed to native iPhone and Android applications.
  4. Start iPhone 2 weeks in advance of Android, but develop them in parallel to keep a fast development cycle.
    1. Expect a 7-9 day App Store review cycle for iPhone and anticipate the first review cycle might get rejected and need to be resubmitted.
    2. iPhone leads and blazes the trail on API integration, architectural decisions and Android benefits from these learnings
    3. Android can be launched in the Play Store once the approval for the iPhone occurs so that both can be launched concurrently on the same day.
With these practices we've launched apps for multiple companies on both iPhone and Android at the same time and had a very high success rate of them being completed at the exact same time.