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 08, 2009 @ 06:45 PM
“They do everything in 3’s”. For reasons I cannot explain, this is a strange line from one of the countless sci-fi novels I read in my youth that sticks with me 30 years later. As I recall, the story had something to do with a space traveler encountering a massive space station which had been evidently built and then deserted by an alien culture. The foundation of all design and function on the ship was the number 3. Three sides to all objects, three legs to tables and chairs, etc. The parting line evidently being some kind of an epiphany for the human visitor, but one that left me feeling I was missing something.
Fast forward 30 years to Intel’s Craig Barrett saying something totally obvious that again showed me I had been missing something. Barrett congealed the cacophony of competing technologies and mobile devices down to this very basic premise – going forward there will be 3 screens in the average human life: the first is a big screen primarily for entertainment. The second is an intermediate screen for the majority of our interactivity. The third screen is the recently added “mobile device” so many of us now spend so much time engaging. Our third screen will always be with us for communication and easy access to information on the go.
So EVERYONE is going to have a 3rd screen. Just look at the adoption rates for iPhones – staggering. We will all use our 3rd screen to communicate and to retrieve all types of on the go information. It was obvious to us this would change the way we all experience the world. Up to date, location filtered information wherever you go – how cool is that?
As our company began writing apps for the bludgeoning iphone industry, however, we still felt like we were missing something. People were building and downloading high performance apps OR they were serving dynamic content via webpages. Few were providing dynamic content via high performance apps. This lead us to as the question “how can we make mobile content management easy and maximize the end user experience – regardless of the mobile device?” It ended up on the whiteboard like this:
Problem Identification:
- People on the move need access to 'fresh' information and content
- Big screens, laptops, even netbooks are not practical as an in-pocket solution
- Relevant content is constantly changing based on countless factors
- Content providers want branded/customized experience for content delivery
Problem Solution: a mobile optimized content management platform
- Best of both worlds: hybrid solution of native application and backend content
- Native application with on-device content allows high performance and off network use
- Synchronizing local content with backend content ensures timely/easy updates
- Horizontal solution with countless vertical applications
- Cost Effective solution to the problem of dynamic content management and delivery
So we built the AVAI Mobile Platform, which being true geeks we felt obligated to christen “AMP”. The AMP content management system leverages the power of a browser based content management system with native applications on mobile devices. We proffer it as the perfect hybrid solution to the identified problem. Easy, straightforward, and we even offer it as a service so first costs are low. Yet 80% of the folks that engage us in discussions on mobile “aren’t ready to invest in mobile yet”. Maybe they think it’s one of those passing phases – like that whole Internet thing. Or is it me? Am I missing something again?
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 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.