Posted by AVAI Mobile Developer on Tue, Nov 10, 2009 @ 09:08 AM
I recently attempted to write my first Blackberry application. I knew that I would have to learn some new skills but, with my background in mobile development and my roots as a Java developer, I was up to the challenge.
I didn't start with anything too complicated. I found the tutorials section of Blackberry's developers site (http://na.blackberry.com/eng/developers/resources/tutorials.jsp#tab_tab_development) and started working my way through the getting started tutorials.
Now I've used the Eclipse IDE in the past, so I was ecstatic to learn that not only is there a Blackberry plug-in for Eclipse, but it's the recommended approach. I also learned that the plug-in is not compatible with my Mac OS X. Now I wasn't excited about this, but I can adapt, so I hopped over to the Eclipse homepage to download the newest version and installed it in my Windows VM. After, not too much time I have Eclipse up and running and return to Blackberry to download the plug-in. They have an easy to use installer, so I download that, hit install and I'm ready to go. Of course, nothing can ever be that simple. The install doesn't take and I have no message explaining why. I double check the requirements only to realize that the newest version of Eclipse is not supported. I have to head back to Eclipse and download an older version. Great, I haven't even finished the setup, and I've already made a mistake. But a simple mix up over the wrong version isn't huge, and I have been assured that Blackberry development is easy, so I'm not giving up yet.
I must say after I installed the correct version of Eclipse and ran the Blackberry Plug-In installer one more time, the install went off without a hitch. I opened my brand new copy of Eclipse, create a workspace, create a new project, and there in front of me is the option to create a Blackberry project. Score! At this point, I must admit I am excited. I love Eclipse. I really do. And after all the time I've spent fighting XCode, I'm finally back to an IDE that doesn't fight me. From this point on the process seems very simple. I follow RIM's very understandable Writing Your First Blackberry Application tutorial. The code makes sense, the RIM libraries appear easy to use, and within an hour I've written a very basic "Hello World" app. Now granted Blackberry has an unfair advantage over iPhone in this respect. When I wrote my first iPhone application I had never seen Objective C code before and the syntax was completely different than anything I had ever written before. However, I did appreciate that Blackberry development allowed me to use both a language and an IDE I was already familiar with.
Running the application in the simulator also seemed quite easy. Aside from the fact that it didn't automatically launch my application as the iPhone simulator does, the simulator seemed relatively easy to use with enough options to test various states my real Blackberry phone could be in while running an application.
With the great success I had had writing, compiling, and running my app in the Simulator I was ready to see it on a phone. This was the step I had most anticipated, not only because it always feels great to see my application in its final state, but because I had heard that putting an application on the Blackberry is a much easier process than putting an application on the iPhone. I still get a sour taste in my mouth when I think back to the struggles I had with my first several iPhone apps and making sure my code signing settings were just right and all my certificates in place and never being exactly sure what was wrong when XCode gave me one more cryptic error each time it failed to put the app on my phone. But this was not going to be a problem on the Blackberry. I connect my Blackberry and begin looking for the "Build to device" option. I can't find one. I return to my tutorial. Surely the tutorial's writer anticipated that the next logical step any developer would want to take would be to put their application on an actual Blackberry device. I scroll to the bottom, but all I see are suggestions as to other things I can add to my application and instructions on how to exit Eclipse. Thanks RIM.
I scan through Blackberry's list of tutorials and find one entitled "How to Deploy and Distribute Applications." Surely this must be it. Again I find another series of useful steps explaining how to deploy my application through the Desktop Manager. Great. I install the Desktop Manager update to the latest version, follow all the appropriate steps and I'm ready to go and I get an error when I attempt to install the app. I double check everything, make a few changes, try again, this time a different error. I try several different configurations, nothing seems to work. After several attempts, I resolve to give up on the Desktop Manager. Reading through the rest of the document I discover the javaloader deployment method. Apparently, the Blackberry JDE comes bundled with this easy to use command prompt tool. A simple call to "javaloader -u load yourfilename.cod", and my program is loaded on the phone! I find my application in the Downloads section (like the Simulator, it doesn't seem to automatically run it) and soon I'm staring at the familiar "Hello World" screen.
All in all, I must say Blackberry development was only a little more complicated than I anticipated. At the time I remember cursing Blackberry and complaining that this was not in any way easier than beginning iPhone development, but looking back, I can see that Blackberry development does have its advantages. From my limited experience with the platform I can already begin to see that it is well thought out and I'm eager to learn more. I won't say my first Blackberry app was easier or harder than my first iPhone app, but it was different. But different is good. While Blackberry and iPhone are both smart phones, they are very different, and they both deserve my share of respect as a developer.
Posted by Eric Mills on Sun, Nov 01, 2009 @ 11:32 PM
In the spirit of Halloween, I want to provide some tips on one of the most horrifying and scary parts of iPhone development: Ad hoc distribution. Generally, ad hoc distribution is used to allow other people to install applications onto their device during development. We typically use it as a way to let clients test out an application before it reaches the app store.
The biggest problem we ran into with this method was actually getting it to work. We would send the client an email with some files and we would constantly hear back from them "It didn't work". Since our job was to make sure that it did work, we became pretty familiar with the errors that would arise and how to fix them. Here are few common errors and reasons why you might see them.
If you are installing via iTunes and the end message is this:
This could mean a few things. The device you are installing the application to doesn't have the provisioning profile on it. Check the phone under "Settings" -> "General" -> "Profile" to see if the provisioning profile is there. If it is not there, you need to make sure you dragged the profile into iTunes.
Another reason the profile could be missing is because the device you are installing to isn't included in the profile. You will need to double check the program portal and verify that you have included the device. If you make these checks you will likely find the problem and can resolve it.
If the end message is this:
This usually means the Entitlemints.plist file is missing. This file is included for ad hoc builds and is necessary for everything to work right. If you are a developer, make sure you have included this file in the project and unchecked the "get-task-allow" option. Also check the project settings and make sure that you have included this file as a "Code Signing Entitlements" entry for the build type you are using.
Another thing we recommend for this process is to take email out of the equation. While we develop applications on a Mac OS, we still use Exchange email, and our clients use various operating systems and email clients. There are a lot of opportunities for file corruption if you use email. We have started putting the files on a public server and linking clients to the files. If you make these checks each time you create an ad hoc build you will have a much better success rate with ad hoc distribution. Or, in Halloween terms, it will turn a trick into a treat.
Posted by Eric Mills on Mon, Oct 19, 2009 @ 08:30 AM
It has been a long time coming, but we can now give you full disclosure on one of our big projects. Last week, Woodland Park Zoo became the first zoo to have it's own iPhone app. This app utilizes AMP (AVAI Mobile Platform) to provide the zoo with a content management system that serves data to both the iPhone App and a mobile optimized website.
Zoo administrators will be able to add content for years to come all from a simple web interface. This provides users with a great utility for navigating the zoo through the GPS. We plot your location at the zoo on the map right on the phone. You can pinch to zoom and scroll very easily just like a Google Map.
In addition users can use the Friend Finder feature to see their friends on the map. The app can also post to facebook and twitter so that people can share their experiences with their friends.
So far, the reviews are very positive and we couldn't be happier with the reactions we've received. Mobile apps are here to stay. They just make life better.
Posted by Eric Mills on Mon, Aug 10, 2009 @ 09:04 PM
Ok, so you know that more people access the internet from mobile devices than from computers. You also know that more and more people are trying to interact with you from their mobile phone. You may also know that it is time to start redirecting some of those marketing dollars away from traditional media and into mobile. Good for you. Where do you start?
Let's see now, what have you done with mobile so far? Nothing, you say? Ok, not good. What could you do? Well, if you had a lot of time and money you could write a version of your software or website optimized for every mobile phone platform. Let's see now there's iPhone, Android, Blackberry, Windows Mobile, Palm Pre, and a ton of Symbian devices out there. All with different operating systems, programming languages, and SDKs. No matter the device, you content would look great. Oh and you need something to deliver content to all these phones. Ugh. Ok, now you have spent all your time and money.
I'm here to help you find the sweet spot between nothing and everything. Here it comes. When trying to reach your mobile audience, the best bang for your buck is a native iPhone app and a mobile optimized website. iPhone currently accounts for over 50% of the mobile traffic in the United States, so that one is a no brainer. Let the rest of the platforms fight for the other 50%, and you can hit them all with a mobile optimized website. You still need a content management system that can serve content to both, but that is much more reasonable that trying to be all things to all phones.
Posted by Eric Mills on Mon, Jul 20, 2009 @ 09:03 PM
Earlier this month, Flurry released market share statistics of mobile apps across "200 applications, 25 million consumers and four platforms: Apple (iPhone and iPod Touch), Blackberry, JavaME and Google Android". I find these numbers fascinating.
Blackberry has a huge number of handsets out there, but it appears that nobody is using the Blackberry apps. I approached a Blackberry user recently and inquired about the "Blackberry app store", Appworld. He didn't know anything about it. That is part of the problem. While Apple is spending millions on the "There's an app for that" campaign, Blackberry is doing nothing. I don't think there are many iPhone users who don't know about the app store.
Here is the other part of the problem: Blackberry apps are a pain compared to iPhone apps. It feels more like installing a PC program than a mobile app. Download, install, set permissions, find, test, reset permissions, test again, find something better to do. Wake up Blackberry.
Android is going a lot right. According to Flurry, they have around 7x the number of developer and consumer mindshare. This is cool. I can't wait to see how the market reacts to the 20 new handsets coming out on Android next year.
How long can this iPhone domination last? I say at least a couple more years.
Posted by Eric Mills on Sun, Jun 28, 2009 @ 12:47 PM
When designing a mobile application, there are many important choices to be made. One of those choices involves deciding between a native, web, or hybrid app. Each has its own set of pros and cons.
Native App
Description - This is an app which is written specifically for the platform (like iPhone or Blackberry). It is installed directly on the phone.
Example: Any iPhone app in the Apple App Store.
Pros: Native apps are like desktop applications in that they are very responsive to user input. They can take advantage of all the hardware on the phone, like GPS, accelerometer, camera, advanced graphics cards, bluetooth, and others. With the iPhone, native apps can take advantage of special software features like in-app purchases, notifications, and the the greatest mobile app distribution platform: the Apple App Store.
Cons: Native apps have the longest development time of all apps. For the iPhone, native apps must be written in Objective-C. You may think that since apple is so cool, their apps would be created using something like the Minority Report hand gestures, but that is far from the truth. Objective-C is based upon the C programming language. Yes, it's the same C that has been around for 30 years. Objective-C is like a sister to C++; it is an object oriented version of C. It is only used to develop on the for the Mac and iPhone platforms. It is a powerful and flexible language, but not a particularly fast language in which to develop.
When to use: You want to create a native iPhone app when you want the benefits of the app store, or when performance is critical.
Web App
Description: A Web App is nothing more than a website that is optimized for the mobile platform. You typically access these apps by opening the web browser on your phone and navigating to the correct url.
Pros: Web Apps are the fastest to build because the tools for creating web pages are quite mature. Good old HTML and CSS are the building blocks of these apps. You can probably save at least 25% of development costs by building a web app instead of a native app. They will also work across many different types of phones.
Cons: Web Apps are not nearly as interactive as native apps. Why haven't all desktop apps moved to web apps? Most have, but not all. For many people, the speed and power of a desktop app just can't be sacrificed. Web Apps run on web servers, so a web host is required. Also, web apps require an internet connection, where native apps do not. No internet connection, no web app. Also note that Flash and Java do not work on the iPhone, so don't even think about it.
When to use: Use a web app when you want to target many different types of phones and you don't need to charge for the app.
Hybrid App
Description: This is a combination of a native app and a web app. The outer shell of the app is a native app and has all the pros and cons of a native app. The inside of the app is a web app, with all the same pros and cons. Said more precisely, a hybrid app is a native app where some of the screens inside are web pages.
Pros: You can still use the app store to distribute your app (and charge for it!). You can use web pages inside to display some of the content that doesn't require any native app functionality. App users will probably not be able to tell that parts of the app are web pages.Cons: There aren't many cons. Web pages will still require an internet connection and they will be slightly slower than the rest of the app depending on the connection speed.
When to use: If you don't mind the cons, you should use web pages for any content inside the app that you can. Note: Be careful when using some of the cross-platform libraries (like Phonegap) for your web pages. Apple has recently began rejecting these apps without much of an explanation. Stick with UIWebView if you want to be squeaky clean on your app store submission.