titanium Archive

Titanium Dev…The Good, The Bad, and the Ugly [The Ugly]

Posted February 8th, 2012
This is the sixth (and final) in a series of posts by DeveloperTown Associate Partner Andrew Robinson.

Start from the beginning with “We can create an app for that!”

We have reached the end of this blogging mini-series…but, don’t cry, because we will finally hear the Ugly truth about native mobile development, specifically with the Titanium platform.

The ugly truth is that delivering is the most important thing for the world that we at DeveloperTown thrive in. We cater to the agile-minded/lean-thinking starter community, which cherishes shipping quality product out of the door and iterating over the solution using real-world data and feedback from the people who matter most…yep, you guessed it…the actual Users. The productivity and speed to market gains you achieve when using Titanium make it a no brainer in most situations. There has been some ugly press about performance issues, or bugginess within the Titanium platform, but the bottom line is that Titanium greatly helps you ship a quality product, and it is getting better everyday.

So, we have taken the long way around, but we have finally landed on the Beautiful Truth that Titanium’s foundation in JavaScript, its clean and improving framework, and the excited community surrounding this platform, makes it a very good tool to use while building your art. Combine this with today’s power that comes with having your product/service available in an app store, and the wonderful dedication that our tribe has with shipping, it solidifies the reasons why you can consider building that new app as a native mobile app.

Regardless of what you choose to build with…please…don’t spend forever researching the pros and cons…see that fork in the road, make a decision, build it, and ship it out of the door!!!

Titanium Dev…The Good, The Bad, and the Ugly [The Bad]

Posted February 6th, 2012
This is the fifth in a series of posts by DeveloperTown Associate Partner Andrew Robinson.

Start from the beginning with “We can create an app for that!”

No need for intros, lets get right to it…the bad parts of Titanium development.

Earlier in this series I hinted at the biggest bad there is for Titanium and any other abstraction platform…dependency. You are dependent on those guys out in Mountain View to stay as current as possible with the hardware platform upgrades. You are dependent on their quality assurance, and if they have bugs, you have to have workarounds. You are dependent on their existence…if they decide to give it up, you may be completely stuck, having to rewrite your app using the native platforms development environments anyway.

Appcelerator as a company has only been around for about 5 years on top of the native-native platforms being young as well; you are left with a fairly immature experience. I have run into inconsistencies, just plain inexplicable weirdness, and something’s that for all intents and purposes simply don’t work at times. There is a decent community that is excited about the platform, but Titanium is iterating so quickly it is hard to tell when the responses are stale. I semi-like the Stack Overflow-ish system they have put in place for the community, but again you get inconsistent results depending on what you are looking for.

Finally, there is debugging and optimizing your application. Debugging for the most part is a very good experience. It is only when you run into an issue that doesn’t seem to be caught by the debugger, when you are even aware of the veil that is covering what you are writing and the actual native platform underneath. When this happens you have to resort to incomprehensible logs from the device, or just trying different solutions until you get it working. It doesn’t happen often, but often enough to know that the platform is still in it’s growing pains period. As for optimization, I am referring mostly to memory optimization, which can seem to be a bit of a mystery. I am confident that the memory issues that you may read about from the early days of Titanium are being resolved and improved upon in every release. However, for very process intensive areas of your application, you may be tempted to dive into the native, especially if you are only targeting one of the stores/marketplaces.

If you are completely turned off by Titanium after reading this post, please re-read “The Good”, and wait on me to post “The Ugly”, where I try to summarize how I feel about the entire experience before you pass judgment.

Titanium Dev…The Good, The Bad, and the Ugly [The Good]

Posted February 3rd, 2012
This is the fourth in a series of posts by DeveloperTown Associate Partner Andrew Robinson.

Start from the beginning with “We can create an app for that!”

So, we now know that one of the best canvases for your genius idea in this latest paradigm is mobile devices. We also have been over the native versus web dilemma. Last time we went over native versus native-native, and began talking about how abstraction platforms like Titanium can be useful in the delivery of quality solutions. Now we will dig into Titanium a bit. First, the good:

For me the most important thing about this particular abstraction is the language. If I were to do a series of posts about the “interactive web”, JavaScript would be King Kong of that discussion. JavaScript has had an interesting life from the perspective of application developers. It used to be an unwanted, glazed over, unfortunate necessity step-child that you threw in at the end of a project to make it appear a bit more interactive. However, now with the proliferation of AJAX-based applications and the general maturation of the web developer, it has risen to one of the most prominent positions in the app dev world. Given that many of the application developers that are at the forefront of the general tech movement are in the interactive web space, it makes JavaScript a sexy language to build your entire application with. JavaScript is not just for the UI anymore. You may have heard of rising star development platforms such as Node.js. Well, Node is not the only player in the server side JavaScript world, and I believe we are just at the beginning of the JavaScript movement.

The Titanium creators must believe, like me, that JavaScript is going to continue to play an increasingly important role in application development. I believe they have done a great job in allowing those JavaScript nuts to use their “hard won” skills as a foundation for productivity when creating native mobile apps.

Some of the Titanium competition (and even Appcelerator themselves in the early days of Titanium), make the claim that you can use all of your web dev skills when creating native apps. This is a decent MVP for creating an abstraction, but it is Not a good solution. Basically, it is putting a native wrapper around a browser. Not cool…not cool at all. Titanium has an entire framework that uses the JavaScript language, but has almost nothing else that translates directly from your current web dev skills. This is a good thing though… It reminds me of desktop app development, but with a new age web-esque event-driven OO twist.

I am also a fan of the eclipse IDE, which is what the Titanium IDE is built on top of. The framework is organized and well thought out. The documentation is pretty decent as well. Some stuff is android-y (like interacting with a hardware keyboard and menu buttons) and some stuff is Apple-y (like having a common top toolbar and swipe to delete gestures), and Titanium allows you to do both. You will lose some portability when you take advantage of platform-specific features, but it is a billion times easier than writing two completely different apps. Once you get the hang of where things are and how they interact with each other, creating quality solutions becomes very fluid and rewarding process. Overall, after you get over a few hiccups (which I’ll cover in the post about the bad) it is a pleasant and fast development experience.

Bottom line:

JavaScript goood…

Not utilizing a web browser wrapper and calling it native (if you want a web app, build a web app), gooood…

A very understandable and flexible framework that allows each platform to reach their potential…goooooooood…

Portability?! Portability?! You kidding me?! Don’t talk to me about mobile application development portability…

Posted February 1st, 2012

This is the third in a series of posts by DeveloperTown Associate Partner Andrew Robinson.

Start from the beginning with “We can create an app for that!”

In the last post I left you with the native, versus native-native cliffhanger…I know, you couldn’t sleep in anticipation! Well, let’s get right to it…

I am a computer technologist/scientist, and I remember writing multiple reports throughout school about the great portability wars going on between Microsoft (with .Net backed by their CLR) and Sun (with Java backed by their JVM). The basis of this war was Microsoft said, “You can write in any of our languages, C#, F#, VB, etc, and they will all be converted into machine code by the CLR and run the same on any of our Windows-based machines”. Sun said, “You can write in Java and it will run on any platform that has a JVM built for it…which essentially converts the Java code into machine code”. In my opinion neither approach achieved true portability.

Portability in its purest sense is the ability to write once, and run anywhere, and this is even more important when talking about the array of platform options you have with mobile devices.

We have been discussing what the options are on our journey to deliver our innovative services to our potential customers. So lets say we want to go native…now we have to decide what platforms to target. The dominant markets include Apple’s AppStore and the Android Marketplace, so when building an app the last thing you want to do is build the same app multiple times on multiple platforms. Who cares though right…in the end we just want portability.

As with most attempts at portability, you usually start with a language/framework that you like, and have it compile down to the underlying platform’s language. In the mobile space there have been a few attempts at this, and the competition to be the “go-to abstraction” is heating up. We at DeveloperTown have done our research, and decided that the best option at the moment is a development environment called Titanium, built by Appcelerator.

Deciding to go with an abstraction like Titanium has its pros and cons. Biggest con is that with any abstraction you are at the mercy of the abstraction. To an extent, I’ll include the previously mentioned Sun -v- Microsoft battle. They basically put easier to use, more productive languages and frameworks on top of a compiler. Titanium does the same thing…it puts JavaScript on top of Java for Android, and Objective-C for iOS. Yes, you give up control, and put yourself at the mercy of the abstraction when you don’t use the native-native language/framework. But, the pros and cons of building on an abstraction in many instances outweigh the cons but, it is not all good…as we will see, there is some good, some bad, and some ugly…

To Mobile Web or to Mobile Native…that is the question…

Posted January 30th, 2012

This is the second in a series of posts by DeveloperTown Associate Partner Andrew Robinson.

Start from the beginning with “We can create an app for that!”

On a journey with many forks, the only way to get to your destination is to make a choice and go.

The first fork is the question of “how do I get my product/service in the hands of the user”.  Should you focus on a website that is mobile-optimized/friendly/adjacent/amicable (there are varying degrees of mobile compatibility, and they go by even more names)? Or a native app…err, a suite of native apps, because of course there is iOS, Android, Windows mobile, Blackberry, or whatever platform your favorite eReader or tablet is built on. The issue is that each platform needs there own app built in their own language with their own framework and their own ‘isms’.

As with most in-depth multi-faceted issues, the answer is based on a specific situation. On top of that, this is a now versus then issue. If I were a betting man, and this was a long-term bet, I’d put it all on ‘native’ web. “Release early and often” is the mantra of many in the new era of business and especially application development, and mobile web is very conducive to this. The benefits of the distribution model when you are dealing with the web are fairly obvious. With the advent of the new power being built into HTML 5, CSS, and possibly a new JavaScript, the shortcomings of building true web applications when compared to native apps are being closed and closed quickly.

But alas, we simply aren’t there yet. Not to fret though, were we are, is an amazing place to be. If you have an app that needs/would benefit from interacting with the devices’ gyroscope, camera, GPS or notification system at the moment your only choice is to go native. Not to mention, the number one feature of any application is or should be…speed, and the bottom line is that currently native beats web every time in that department. Finally (and maybe most important to the apps success), there is the marketing, prestige, and customer trust/comfort that is associated with having an app in your favorite app store. Let’s be honest, if you go to a customer, and say to them, “yes, you can go to our website, but you can also download our app in the app store” you will get raised eyebrows. Having that edge could be the deciding factor in a conversion or another half interested prospect.

So, mobile web or mobile native…only you know the answer that is appropriate for you, but if your specific case does take you down the native mobile app path, there are yet even more forks in the road. I like to think about this next fork as native versus native-native… What’s the difference you ask…well, it all begins with portability, which we will discuss in the next part of this mini-series.

We can create an App for that!

Posted January 24th, 2012

Technology flies by quickly. New paradigms crop up and just as quickly as they rise to domination, they are supplanted by the next great innovation. As application developers, we have gone from punch card apps to command line apps to desktop apps. Today however, there are two dominant platforms that have all but put the others out of their misery.

The first is the great connector…the Internet. With the emergence of incredibly responsive and powerful browsers such as Chrome and their movement to bring our entire computing experience to the web (see Chrome OS), the web is now, and will continue to be fertile ground for seeds of innovation.

The other platform isn’t as much a single platform as it is a powerful collection of platforms. With the average person creating and consuming their media, entertaining themselves, informing themselves, and connecting with others via mobile devices…the world wide mobile, is a force to be reckoned with. For evidence of this, just look down the street and count how many people are about to blindly walk into traffic, because they have their head buried in the little mini-world contained within their Android or i-device.

A few years ago, the bar for a business was to have a website. Then it evolved into having a web site with application-like qualities. Now, if I can’t completely interact with nearly all facets of your offering via my phone or tablet, I am incredibly put out, and will probably move to the next option.

So, we know that the new frontier is in the palm of the users hand, as creators it is our job to figure out how best to get our services, ideas, value add, innovation into the users hand. It is an impressive competition for the future going on, and I personally am excited to be able to see it unfold.

There are too many paths that we can take to handle in one post, so I am going to do a mini-series of posts about the world wide mobile…iOS, Opera, Android, Safari, Tablets, eReaders, Firefox ohh my!

Archives

 

Categories