Simulating iOS Background Location Changes from the Comfort of Your Desk

Xcode offers a handy feature for developers that are working with location services. Simulating a Location at Runtime allows the developer to specify a location that the device will report to apps as they run. You can even use prerecorded GPX files to simulate walking, running, biking or driving along a route to see how the location changes are handled by your app.

However, simulating location changes in apps that have been terminated is a bit trickier, as the debug area option to simulate location is only available when you're debugging a process. To work around this, you can follow these steps:

1. Run the app in which you want to simulate a background location change.
2. Stop the app.
3. Create a dummy project - I just use the single view application template.
4. Run the dummy project on the same device.
5. In the debug bar for the dummy project, choose a location, or add a GPX file containing the location changes you want to simulate to your project and choose it.

Even though the app that you're wanting to simulate a background location change was stopped at step 2, you should see it get a location services update via application:didFinishLaunchingWithOptions:, with the UIApplicationLaunchOptionsLocationKey set in the options dictionary. And, you can do this from the comfort of your desk without needing to take your iPhone to the location you're wanting to test in.

Configuring OSX Mavericks and Jenkins to Support Interactive Jobs

While developing iOS applications we leverage Jenkins on OSX Mavericks for our Xcode / iOS and Android builds. We perform application level automated testing (i.e. in the Simulator or Emulator) and as such need a Windowed environment can't simply run in a Daemon mode. In addition, OSX Server on Mavericks integrates a "GUI" Apache Server that we want to integrate.

An initial installation of Jenkins on a Mac using the Jenkins supplied installer is ok, but it only supports a headless execution. There are many times that our jobs need a head or window manager to execute (Xcode Automation Tests). To support this on Mac we need to reorganize this. Basically, we want to change the jenkins process from running as a LaunchDaemon and to run as LaunchAgent defined the jenkins user itself. Here is a cookbook for doing this with a fresh Mac install.

1. If you don't have Java installed, install it by attempting to run the following and follow the instructions. java -version (I’d recommend to install the Java 7 version directly from Oracle).
2. Download & Install the Jenkins Mac Installer.
3. This will create a user named jenkins. In the user manager it will have an empty name, go ahead and name it Jenkins User in System Preferences -> User & Groups. You will also want to set a password at this time. It's not necessary, nor recommend to make this user an Administrator
4. Now, we need to disable the Jenkins LaunchDaemon. You can unload and force it not to load again by executing "sudo launchctl unload -w /Library/LaunchDaemons/org.jenkins-ci.plist"
5. We now need to create a LaunchAgents script, and this can be done by copying "cp /Library/LaunchDaemons/org.jenkins-ci.plist to ~/Library/LaunchAgents/org.jenkins-ci.plist"
6. For Jenkins to start on a fresh system boot, you would configure System Preferences -> User & Groups -> Login Options to automatically login to the Jenkins User account.
7. We should now be good to go and can start jenkins by logging in to the jenkins account (and out if already logged in).

One thing to keep in mind, is by default Jenkins can not update itself. To fix this you can do the following.

1. Change the owner on the jenkins.war and directory. "sudo chown /Applications/Jenkins jenkins; sudo chown /Applications/Jenkins/jenkins.war jenkins"

Next we would also like Jenkins to play nicely with OSX Server (You might need to install it if it's not already installed from the App Store). Ideally, we want http://{SERVER_NAME}/jenkins to forward proxy to http://localhost:8080/jenkins.

1. If Websites aren’t enabled, go ahead and turn that on in OSX Server. Make sure to “Allow overrides using .htaccess files” is enabled in the Advanced settings of the "Server Website" and "Server Website (SSL)” sites
2. We need to configure Jenkins to respond to /jenkins as well, and this can be done by adding a prefix to the preferences. "sudo defaults write /Library/Preferences/org.jenkins-ci.plist prefix /jenkins"
3. We need to configure OSX Server to redirect any non-SSL traffic to https for /jenkins. We did this in the OSX Server App by click on Websites -> Server Website -> Redirects -> Edit and adding a Permanent redirect for anything /jenkins to go to https://{SERVER_NAME}/jenkins.
4. We need to configure OSX Server to forward proxy any /jenkins requests to the local jenkins server. Do this by adding an .htaccess file to /Library/Server/Web/Data/Sites/Default/jenkins/.htaccess with the following content.

RewriteEngine on

RewriteCond %{HTTPS} =on

RewriteRule ^(.*)$ http://localhost:8080%{REQUEST_URI} [P]

After that we should now be able to access jenkins from http://{SERVER_NAME}/jenkins and it should redirect the user to https://{SERVER_NAME}/jenkins and allow you to login and continue the Jenkins configuration and create jobs that start windows (i.e. iOS Simulator and the Android Emulator).

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).

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.

Building iPhone and Android Apps at the Same Time

Recently we had the pleasure of working with Oversee.net 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.

Business Rockstars

Lolay had the pleasure of joining Business Rockstars (KFWB - 980 AM) on the air last Wednesday, November 21st. The show was created by Ken Rutkowski and Steve Lehman as a platform for entrepreneurs to share their successes and adventures. 

Check out the details:  http://businessrockstars.com/br/2012/11/business-rockstars-ep113-wed-1121