Great Resource For iOS Guidelines

Embarrassingly enough, I have troubles finding all of the guidelines and things I should keep in mind while designing and developing a Mobile App. Thankfully, I came across this resource which I can turn to when I’m not sure about something.

Check it out, it’s well put-together and worth a bookmark :)

The iOS Design Guidelines

Hybrid vs Native Apps

I think this debate is probably up there with vi vs emacs at this point, but here’s my take on it.

I’ll start with my experiences with developing both Hybrid apps and Native Apps in my day jobs. For companies, the idea of “write once, deploy on any device” is pretty sexy especially if they are mostly web but are trying to bring in mobile development business. There is lower labour costs and lower training and staffing costs since you don’t have to hire Objective C or Java developers nor do you have to bring current staff up to speed on those languages. The lower labour costs come from the fact that you’re writing the app once and not two or three times depending on the platforms you are supporting.

There are a few tools that make Hybrid apps possible but the one with the most clout is PhoneGap. It supports a vast number of platforms and is free to use. There is even a build tool which manages your build processes in the cloud for a fee.

The way PhoneGap works is that it creates a native application that contains a WebView. It’s in this WebView that your HTML, CSS and JavaScript is executed. It’s as simple as that!

I hope you didn’t think that the story ends here…because it doesn’t and it’s not one with a happy ending. Yes, in my experience you can certainly develop great Mobile apps using the Hybrid approach. I am in no way trashing this method. When going Hybrid you need to keep some key points in mind.

One of the things I would be worried about when going with the Hybrid approach is third-party libraries. Although PhoneGap offers a lot of functionality out of the box, you will need to supply libraries for things like displaying ads and analytics. PhoneGap does have a community of plugins which interface with third-party libraries, but if you are using a library no one has written a plugin for then you will have to write your own.

When you write a plugin for PhoneGap, you are really writing code in at least two languages. The answer to why lies in the fact that PhoneGap provides a JavaScript layer which makes calls into the native functions of the device. Therefore, writing a plugin will mean that you have to write in at least two languages: JavaScript and Objective C or Java or both depending on what you want to support. At the risk of sounding cynical, this is the whole reason you wanted to go with a Hybrid approach to begin with! You wanted to avoid writing code in multiple native languages.

To further add to some of the pains of Hybrid Mobile App Development, there is the issue of architecture. Technically, I guess you can have a straightforward “website” structure where you have multiple HTML pages and you just link to them through anchor tags but I have never been on a project where things could have been implemented in such a simple manner. In fact, the preferred method in PhoneGap is to use a Single Page Application architecture. This isn’t terrible, but it will require your JavaScript developer to be proficient with an SPA-type setup and a strong understanding of JavaScript is a must with this approach.

Speaking from my personal experience, I have gone with just using PhoneGap’s starter “framework” when you start the app which worked out pretty well. I have also used Sencha Touch which is based on the Ext framework but adds a lot of cool stuff for the mobile environment. At the risk of sounding like one of their salesmen, it’s a great framework and should consider it if you have a more complicated UI and are really looking for a near-native experience.

The team who built Sencha Touch went through a lot of work to add a great level of polish. For example, the scrolling lists that are part of nearly every Mobile app have a lot going on under the hood that controls the smoothness and even the momentum of scrolling through the list. This gives you a feel that is pretty damn close to native. It’s also an MV* framework so it conforms to a lot of what you already know about structure if you’re coming from a Web Dev background and have used Rails.

Another cool thing that Sencha Touch has going for it is that it comes with CSS “themes” that you can include in your project that make it look like it’s a native app. It has themes for iOS, Android, BlackBerry and Windows Phone.

It’s negatives are that it can be clunky feeling on some of the Android devices. Even newer ones like the Galaxy S4 had some issues regarding performance. This is due to a couple of factors. One of which is another strike against Sencha. The DOM structure of some of its elements can be quite complex and this bogs down performance. The other is that the browser on the Android devices just isn’t very good. You can use Chromium which is the Open Source version of Chrome. I have had experience including a build of Chromium and using that to power the WebView that is created in a PhoneGap project. This helped performance, but some rendering issues still remained.

Overall, if you have to go with a Hybrid solution I would opt to use Sencha Touch. Especially if you’re trying to create a native experience but don’t have the know-how to build a native app. I don’t have experience using something like Backbone or something like that to build a Mobile Application. Please contact me if you have, I would be curious as to what your experience was.

In the other corner of this flame war is a full-fledged Native Application. I have developed quite a few Native applications some of which I will share at a later time on this blog. For now, I will just share what it was like to code in the native environments.

Personally, I started out doing Native Applications. I coded in Java when I ran my Mobile Games business for J2ME. From there I moved on to developing BlackBerry Applications which also used Java. Then I started writing Android Applications and then finally sticking with developing iOS apps.

One of the points I made earlier is that a Hybrid approach means that if you’re a Web Developer, then you don’t have to learn new languages. From my perspective, learning Java and Objective C wasn’t that difficult. At the time of writing this, Swift has already been released for quite some time now and it’s much more elegant and friendly to newcomers than Objective C. There is even less of an excuse while looking at Java since it’s taught in most Computer Science curriculums. The thing that comes with the learning curve is just learning what all of the libraries that come with iOS or Android can do and what they can’t do. Usually this is fixed with reading a lot of documentation.

In my opinion, nothing in the Hybrid world compares to using a Native app and nothing compares to actually coding one. With the Hybrid app development path, I always felt like I was hacking something together to make it work. I can’t quite put it into words, but if someone asked me if a feature was possible I never felt totally comfortable giving a timeframe since there was usually an obscure issue that would come with adding the new feature.

From the projects I worked on using the Hybrid approach, I never really experienced a savings in time. These projects took just as long to build and maintain as a Native project. In fact, I would say they took longer since we had to account for things that wouldn’t be issues developing in the native environments. One issue was just managing and maintaining all of the plugins for third-party libraries which required that we write native code anyways.

Another advantage that Native Environments have that Hybrid doesn’t is that both iOS and Android have WYSIWYG editors for the UI. In iOS you have the IDE XCode which has Storyboard which lets you layout screens, navigation and transitions in a visual way. Android has the Android Studio which is similar to Storyboard. I don’t know of anything similar for doing a Web UI which you could use in a PhoneGap project.

Closing Thoughts

If you have a choice in your project as to what method to choose, go with Native. It doesn’t take long to learn the ropes of Objective-C, Swift and Java and sites like Team Treehouse, Code School and Pluralsight have a lot of great courses that will get you coding Native Apps quickly.

If you have to develop a Hybrid app and there’s no way around it. I would use Titanium from Appcelerator which isn’t a Hybrid app. It lets you code in JavaScript and the tool will convert your JavaScript to Native Code. If you can’t use Titanium and MUST go with a true hybrid app, then you should look at using Sencha Touch and PhoneGap for your project.

How To Add Directory To Path On Ubuntu 14.04

For the past several years, I have been running a Mac as my primary development machine. Recently, I’ve been doing some development on a Ubuntu virtual machine. As per usual with my bouncing back and forth between things, I forgot how to add a directory to my PATH in a Linux Distro. On my Mac, I’m used to having a .bash_login, but I didn’t have that option in this case.

Here’s what I did to add a directory to my PATH in Ubuntu 14.04

sudo vi /etc/environment

Just add your directory to the end of the PATH value, restart your machine and you’re good to go!

How to tell if your Intel-based Mac has a 32-bit or 64-bit processor

I found this information was surprisingly tricky to nail down but finally found a link. I needed to download an SDK where it was important that I downloaded the correct architecture, whether or not my Macbook was 32-bit or 64-bit. After googling around for a bit I finally found a forum post which linked to a site which linked to the page I’m going to share here. It’s a table of all of the different processors Apple puts into their machines and their architecture.

I hope everyone finds this helpful:

dyld: Symbol not found: _mysql_get_client_info

I came across this issue when I generated a new rails app specifying MySQL as the database to use. I am running Mac OS X Yosemite, Ruby 2.1 and Rails 4.

Here’s what I did, I uninstalled the mysql2 gem, then used Brew to install MySQL, then reinstalled the mysql2 gem. Here’s the commands for easy copy and paste:

gem uninstall mysql2
brew install mysql
gem install mysql2

After running those commands, I was able to use MySQL in my Rails projects with no issue.

THREAD WARNING: exec() call blocked the main thread. Plugin should use CordovaInterface.getThreadPool(). – Cordova Plugin Warning

Hey all,

So I came across this today. My plugin needed to add and manipulate views within the Cordova app. The problem is that you can’t do this since in Cordova, the WebView is on the WebCore thread and it can manipulate the UIThread directly. Hence you get this nice error/warning:

THREAD WARNING: exec() call to [pluginname].[method] blocked the main thread for XXms. Plugin should use CordovaInterface.getThreadPool().

The way to fix this is to use the runOnUiThread method from your plugin’s source file. To do this you need to get the main activity of the app. Here’s how you would do that:

  1. this.cordova.getActivity();

From here you would then invoke the runOnUiThread method and pass in a new Runnable object with its own run method. Within the run method is where you would put your code that changes your views. Here’s a snippet to tie it all together:

  1. public boolean execute(String action, final JSONArray inputs, final CallbackContext callbackContext) throws JSONException {
  2.         PluginResult result = null;
  3.         if (action.equals("myPluginMethod")) {
  4.             this.cordova.getActivity().runOnUiThread(new Runnable() {
  5.                 public void run() {
  6.                     callbackContext.sendPluginResult(myMethod(inputs));
  7.                 }
  8.             });
  10.             result = new PluginResult(Status.OK);
  12.         }
  13. }

Hope this helps! Feel free to share your experiences in the comments.

What are symbols in Ruby?

One of the conceptual sticking points I had when learning Ruby was what symbols actually were.

If you’re new to Ruby and/or Rails, you might have come across something like the following:

  1. params[:user_id]

Within a few minutes, you learn or you are told that it’s a symbol. When I was learning Ruby that didn’t mean a lot to me. It took me a bit to really grok them.

A symbol is just a unique way to represent something in code. Think of it like a constant except the value is simply the name of the constant. An example that really helped was the use of Cardinal directions. North, South, East and West don’t really have “values” in the traditional sense. They represent a direction.

For example, if you were coding a game where you control the movement of a player, you might have the following:

  1. def move_player(direction)
  2.   if direction == :north
  3.     player.y -= 1
  4.   elsif direction == :south
  5.     player.y += 1
  6.   elsif direction == :east
  7.     player.x += 1
  8.   else #west
  9.     player.x -= 1
  10.   end
  11. end

In the above code, we don’t care about what the value of North would be. We just care that the player is moving North. That highlights the main purpose of a symbol.

The most common usage of symbols are as keys in a hash. Like the example above, you just need a unique way of being able to identify something.

Here’s another example:

  1. user = {
  2.     :first_name => "Don"
  3.     :last_name  => "Marges"
  4.     :age        => 29
  5.   }

If you contrast this concept with objects in JavaScript, you see that symbols actually make a lot of sense. In JavaScript, the key could be a string which won’t necessarily be unique. Symbols in Ruby are guaranteed to be unique.

Now, you should be warned that you won’t really see an example like the one above in the wild. It is a common practice to use the shorthand of symbols as keys in Ruby. So the above example would look like the following:

  1. user = {
  2.     first_name:  "Don"
  3.     last_name:   "Marges"
  4.     age:         29
  5.   }

I hope this little tutorial has helped you understand symbols a bit more clearly. I didn’t catch on to them as quickly as a should have when learning Ruby because I came from languages like PHP and JavaScript where there isn’t a concept of a Symbol, so I didn’t really have a frame of reference.

Cordova Plugin Creator Ruby Gem

Hey everyone!

I just wanted to announce the release of a Ruby Gem I created!

It was born out of some work I’ve been doing recently with PhoneGap. Essentially, I was creating some plugins that extended the functionality of PhoneGap. For those of you who don’t know, PhoneGap is a tool which Adobe owns that allows you to create Native Mobile Applications using Web Technologies. It’s basically like you’re coding for the browser, except you can release your app in the App Stores. It does this by creating a WebView and running your code within that context.

PhoneGap gives you the ability to write plugins which are native code that you write JavaScript interfaces for. So in your Web code, you can call the JavaScript functions which call into the native code for your plugin.

The drawback is that there is a very specific structure that your plugins must have in terms of configurations and directory structure and it was a pain to have to set it up manually as I would miss a setting and it would prevent my plugin from working.

Using my trusty knowledge of Ruby and creating gems, I created a gem which handled all of the setup for a plugin for you so you can just get to work coding the plugin itself.

Since I’m terrible at naming things, it’s named Cordova Plugin Creator and you can find it on Rubygems here.

Here is the repo for it as well.

Any feedback is appreciated and welcome.

How to fix – TypeError: Uh oh! Arguments to path.join must be strings in Cordova Plugin Remove

I came across a problem while doing some Cordova/PhoneGap Plugin Development that I thought I would share my solution to.

The problem was when using the Cordova Command Line Tool to remove a plugin which was for the iOS and Android platforms I got this error:

TypeError: Uh oh!
Arguments to path.join must be strings

The problem for me was an incorrect setting in my plugin.xml file specific to the Android portion of the plugin. When you create a plugin, a plugin.xml file is necessary to make it work. For each platform you want it to work on, you must add an entry to that file. For example, the Android entry would look like this:

  1. <platform name="android">
  2.         <config-file target="res/xml/config.xml" parent="/*">
  3.           <feature name="MyPlugin">
  4.             <param name="android-package" value="com.mycompany.MyPlugin" />
  5.           </feature>
  6.         </config-file>
  7.         <source-file src="src/android/" target-dir="src/com/mycompany/" />
  8.       </platform>

The issue for me was caused by an incorrect source-file tag, I had the following:

  1. <source-file src="src/android/" />

You MUST have a target-dir attribute specified as well:

  1. <source-file src="src/android/" target-dir="src/com/mycompany/" />

I hope this helps. Feel free to share your solutions or whether this worked for you in the comments.

Primum non nocere – Or one way to be an awesome developer

I bet you’re asking what the phrase Primum non nocere means and what does it have to do with Software Development! Well read on 😉

Primum non nocere is a Latin phrase which is actually taught to med students. It means “First, do no harm”. It’s taught as a means of helping students to realize that sometimes the best course of action is none at all or the least invasive action.

To put the aforementioned phrase into context, let’s say that you suffer from a headache on a particular day of the month for every month of your life. The headache is manageable and just requires you to take it easy for that day. You decide to have your Doctor check it out. Your Doctor tells you to take some Aspirin and lay down until the headache goes away for that day. The Doctor my send you for a test, but if you’re a young person and in good shape, then the last statement will be the most likely outcome.

Now let’s look at this from a Developer’s perspective. When we see a problem with the code we are working on, what is our course of action? Well we would pull down the latest code, create a branch, run the test suite, do some more debugging and finally see what the issue is if we are lucky. Then what do we do? Well, if you’re a student of TDD, you’ll write some tests, make them pass to fix the bug. Then you would see if all of the other tests are passing. If everything looks good you’ll push it up to your repo and submit a pull request.

What typically happens is that your fix introduced some other subtle bug which you may not have expected. So you go through the process again. Then probably again, stacking change upon change. This is in violation of Primum non nocere. In the example visit to your Doctor, did he whip out his bonesaw and start poking around inside your brain? When you have a muscle cramp, does the Doctor cut open your skin to see what’s happening?

The initial problem could have been left alone and you wouldn’t be stuck in this cycle of breaking/fixing. For example, let’s say you populate a list from an external API. From time to time, the request will timeout leaving you with a blank list. So your idea was to check for a timeout and if the request does in fact timeout, then make the request again. You realize that sometimes it could timeout multiple times, so you put it in a loop to keep rechecking. Then you create a way to break out of the loop when the request is successful. After that work you realize that your app is killing the user’s battery by constantly hammering http requests, on an on ad infinitum.

If we were to apply Primum non nocere, one option in the above example would be to simply add some indication to the user that the data was unable to be fetched and to try again and adding a button to refresh but that’s as far as you would go. This would not require any edits to existing code and would be a matter of a Label field and possibly a Button to call the function you have to make the request.

Is it potentially a pain for the user to hit the refresh button? Possibly, but I think we all vastly overestimate how much users actually care about stuff like this. I know that the statement I just made would probably make our inner Steve Jobs blow a gasket, or our bosses or stakeholders put in a recommendation of who should be in the first round of layoffs but hear me out.

When one of the iPhones was having issues of dropped calls because people were holding it a certain way, Steve Jobs famously taught everyone how to fix the problem by holding the phone in the other hand. That’s brilliant! Instead of recalling the phones or issuing a complicated fix, he simply showed people a quick and easy way to fix it that didn’t involve even more issues. Did that affect sales of the iPhone in the least? Absolutely not!

Even though Primum non nocere was meant for Medical Practitioners, I feel that Developers would benefit from its use as well.