It’s been quite a couple weeks since our Titanium beta launch. We received a tremendous number of requests for access to Appcelerator beta and hundreds of mobile and desktop projects have already begun production. It’s a good time to share some initial thoughts on all the great that apps that you’re looking to build.

One thing is clear from reading the initial responses: you, our users, are building very different apps than the ones typically seen in the various app stores. Sure, we’re getting our fair share of games and entertainment apps. But whereas those two categories make up 35% of the Apple store, they only make up 11% of what we’ll call our “app pipeline”. So, the question is, what are you looking to build with Titanium?

We’ll get more scientific over the next few weeks, but here are a couple of anecdotal examples of the types of apps that you all are building: “promotional/affinity” apps for upcoming product launches, auto apps that help users navigate around traffic jams, content management front-end apps, onsite billing/quoting apps, medical recording apps for doctors, “augmented reality” apps, university geo-services/mapping apps and eLearning apps, apps that pull together web-based social tools, and lots of mobile ports of existing SaaS-based enterprise apps. In a sign of the times, we’re seeing apps that help job seekers, apps for saving money while on-the-go, and apps that help realtors promote their residential and commercial property… and many, many more.

In short, you are bringing your deep knowledge of web tools and technologies along with your own connectivity to your customers/users to bear on mobile and desktop apps. You are building what can best be described as “Always On” apps. Whether for consumer or business use, almost every Titanium-created app uses web connectivity, leverages information from your datacenter or user base, and mixes in device-centric contextual functionality like geo-location or mobile filesystem access to create a truly unique app experience.

We would love to showcase your story on this blog and help you promote your Titanium-created app. Please drop me a line at sschwarzhoff [at] appcelerator.com if you have a story that you’d like to share. In the meantime, our best wishes on telling your app story with Titanium!

ShareThis

For the past two weeks, we’ve been on a quest to search high and low for the developer who could produce the most downloaded Titanium app AND the developer with the highest rated Titanium app, based on community voting. Many of you worked days, nights and weekends pouring your talent into your apps and your good humor into the IRC. We wanted to see what could be done in a short period of time, and we must say, we are pretty excited by the results. We challenged you to give us your best shot in a quick timeframe and you delivered.

So, who won? Drum roll please…

- Andreas Ritter’s “NuShell” application received the highest rating, 4 stars out of 46 votes.

- Abishek Tiwari’s “Raviex Videos” application has been downloaded 482 times (over 700 total since the first submission).

Congrats to Andreas and Abishek who are each taking home some extra stimulus money – $500 (USD)! And, of course, the first ten developers who submitted an app will be receiving some cool limited edition Appcelerator t-shirts. Check your mailboxes soon.

We appreciate everyone’s involvement and thank you for coding away! Titanium is a great platform because you help make it that way. Please keep the comments and feedback coming! Keep following @appcelerator on Twitter to get the latest updates and be sure to stay tuned for the next Titanium release… it’s just around the corner – sooner than you think.

And remember, submissions of your Titanium applications don’t end here. Feel free to continue developing and adding new apps in Titanium Developer and promoting them through your networks. We’ll continue to expand the app marketplace and offer more opportunities for you to distribute and promote your application in the near future. As always, your feedback and ideas are welcome. Please send them over to us!

Code Strong!

@jhaynie

ShareThis

Problem definition

A few weeks ago i started a thread on the Appcelerator development network about remote routes. The thread got a bit of attention and ultimately meant different things to different people.

web 1.0 transformations

When I get in front of customers today that have an existing web solution in place, they tend to ask some simple questions:

• What do I have to do to implement a service in <backend framework>?
• I’ve already got a bunch of web services, can I use them as is?
• My website has a traditional web 1.0 implementation, will i have to throw away and start over?

Primary focus: cost to implement seems to be the main chasm for them to hurdle.

REST zealots

A bunch of the developers out there are jazzed about building RESTfull services to remotely expose an endpoint for integration. Re-using these endpoints is a natural fit for them and paramount to their needs.

Primary focus: A clean single place to define their services.

back end framework architects

Then there are the framework guys that are out there that have the need to add Appcelerator to extend their portfolio. Recently I helped out with implementing an Appcelerator service for grails. To facilitate the framework integration I write a similar service broker in grails much akin to what we have done for the other platforms. The controller would discover the Appcelerator services written in grails and then invoke them directly. The downside is that:

• grails developers like to integrate at the controller level and not the service level
grails itself makes responding to and rendering JSON very easy
• grails already has routing and discovery built into the framework

Primary focus: not duplicating existing framework functionality in a way that is consistent with their architecture

Previous approaches

In the past I’ve prescribed a 4-tiered strategy for those that are out there that are interested in integrating their existing application using Appcelerator;

• create new Appcelerator-specific remote services that reuse existing code inline if possible
• use an ESB to route to your existing services
• use the app:http written by Mr. Hashemi as mash-up in the client
• do not use remote services, but allow Appcelerator to add richness to your application locally in the browser

Solution

Instead of writing remote services that are Appcelerator specific and restrictive, an implicit contract is adhered to. This means that back end services can be written in any language or platform so long as they are able to consume and render in an approved format (for example ‘application/json’).

Traditional

Here is a simple example for a traditional service.

class MyService < Appcelerator::Service
  Service 'order.create.request', :create_order, 'order.create.response'
 
  def create_order
    order = Order.new(params["amount"])
	order.save
    {'success'=>true, 'id'=>order.id}
  end
end

Using remote routes

And now we make use of controllers as well as remote routes. Here is the controller

class OrderController < ApplicationController
  def create
    order = Order.new(params["amount"])
    order.save
    respond_to do |format|
       format.json { render :json => {:success => true, :id => order.id} }
    end
  end
end

And now in the client we include the following in our javascript (there are a ton of ways to implement this, but here is an example for now)

	$MQR('r:create.order.request','/order/create','post',
	'r:create.order.response');

trade offs

Wrap up

Understanding the trade-offs for the different service routing opportunities should be considered when you architect your solution. At the core of it, Appcelerator provides you with options and leaves that decision up to you, empowering you to make that choice for yourself.

this article cross posted at http://blog.zuerchtech.com/2008/10/05/appcelerator-remote-routes-for-service-integration/

ShareThis

As the Appcelerator Developer Network continues to expand, we thought it would be nice to start highlighting the efforts of some of our most active community members to help facilitate further interaction and collaboration. For our first Developer Spotlight, we’ve selected Kevin Whinnery, a Systems Engineer with ERP powerhouse Lawson Software.

What’s a “day in the life” of Kevin Whinnery like?
At Lawson, I’m currently involved in developing an application to monitor behavior and performance of our SaaS offering for human resources. I have designed and developed a solution built with an Adobe Flex front-end and backed by a Java-based query engine.

Outside of work, I’m actively involved in other development projects with my business LightRail Systems, LLC, where you can follow my efforts through my blog. One example is a student information system developed with Ruby on Rails. We’ll be looking at ways to possibly leverage Appcelerator in this and other applications we’re developing.

How did you hear about Appcelerator?
I originally read about Appcelerator when I was trolling blogs. I made a mental note to check it out, but then got sidetracked with my other projects. A few weeks later, somebody commented on my blog that I should check out Appcelerator, so I set aside some time and took it for a test drive. I downloaded the SDK and took a crack at building something with it. I got hooked immediately and have been using Appcelerator for six months now.

What was your first impression of Appcelerator?
I’ve been developing with Flex for a couple of years now. Event handing isn’t overly complicated, but it does require a lot of code. What caught my eye with Appcelerator was the Web Expression Language – specifically, how elegant message and event handling are with Appcelerator. Compared to what I was used to with Flex, I was very impressed by Appcelerator’s capabilities right out of the gate. It’s a young framework with a few rough edges, but Appcelerator features some unique innovations that make it destined to command a large share of the growing RIA development space.

The messaging system and hand-in-glove integration with backend services are truly unique among RIA frameworks, and they represent Appcelerator’s greatest differentiators. The amount of code required to do basic things, like fire an event containing user input, is immense in an RIA framework like GWT or Flex. With the Web Expression Language and other innovations (like fieldsets – you’re going to love fieldsets), Appcelerator makes these things, which should be simple, exceedingly so.

While Appcelerator’s widget library is useful, I see that more as a future strength of the framework. There needs to be more documentation around integrating third-party widgets, but the fact that you can extend and customize Appcelerator to support any other framework, library or widget is a forward thinking strategy. While you would have to do a lot by hand today, as community support increases, there will be few more efficient ways to build RIAs than with Appcelerator.

Are you using Appcelerator for any applications you’re working on right now?
I was originally planning to use Appcelerator for the student information system we were building, but I didn’t get up to speed with the product soon enough. Given our need to launch this summer, we opted to stick with straight Ruby on Rails. We are working on a new product which will be using Appcelerator, which I could tell you about – but then I’d have to kill you. But we’re excited about showcasing some great Appcelerator features.

I’m also using Google’s App Engine for a muscular dystrophy web site I’ve created. I think Appcelerator currently is the best web framework for Python out there, and will see wide adoption as App Engine grows in popularity.

What would you like to see improved on the Appcelerator Platform?
The widget framework is still young. It’s not as developed as other tools. Flex is more customizable, with a class library that you can customize and extend as needed. While Appcelerator has set the foundation for extensibility here, there is still some work to do.

The SOA integration points are great, but I’d like to see them become a little more general purpose. While all SOA integration points serve the Appcelerator UI, I’d like to see well-known ways to invoke Appcelerator services for other clients. Eventually, I would like to see Appcelerator services behave like true RESTful web services, so they could easily serve other clients.

So you’re a big Flex supporter… what would you tell other Flex users about why they should consider Appcelerator as a complement?
First and foremost, Appcelerator’s Web Expression Language and event handling is a breakthrough in RIA technology. The messages are lightweight and easy to publish and subscribe to. The amount of event handling code you write in an Appcelerator app will go down significantly from a Flex app – especially written with Cairngorm. I can tell you this from personal experience.

Second, there’s no need to use a browser plug-in with Appcelerator. When you create an app with Appcelerator, it will be more accessible and will not need as large an initial download.

Finally, Appcelerator provides you with hand-in-glove integration with a variety of server-side technologies, with no glue code that needs to be written.

While I still like Flex, it really only makes sense to use it in situations where you are going to need to have a graphically intensive or data intensive application. For most applications, you would be swatting a mosquito with a bazooka if you chose Flex. Appcelerator is a much better choice for rich web applications that don’t need to function like fat clients.

So you’re literally writing the book on Appcelerator. What’s that about?
I am genuinely impressed with what you guys are doing. Somebody finally got how to do event driven RIA in an elegant way. This is the first breakthrough innovation we’ve seen in the next wave of Web-based application development. I fell in love with Appcelerator and wanted to get more involved with the technology. I decided to submit a proposal to Manning Publications (publishers of the “In Action” series of books, among others), and they were similarly convinced of Appcelerator’s potential.

Early access to the book should begin sometime this week, with development scheduled to continue into the fall, with a release scheduled for early 2009. I’m hoping lots of folks will join the early access program and offer some feedback during the process.

Any final thoughts you’d like to share with others that might be considering Appcelerator?
Yes. Get involved with the community. I’ve seen Appcelerator continue to innovate on a weekly basis, and thanks to the responsiveness of the development team, community members can have a say in the direction of that innovation.

About Kevin Whinnery
Kevin is a Systems Engineer at Lawson Software, and is also the President and CEO of LightRail Systems, LLC, publisher of the Recess Student Information System. He lives in the Twin Cities of Minneapolis and Saint Paul in the great state of Minnesota with his wife Kendra and two gifted and adorable children, Emmett (3) and Grace (1). When not cranking out code, Kevin enjoys some combination of coaching, playing, or watching baseball, football, and wrestling. If you’d like to get to know Kevin, reach out to him in the community – you can view his profile here.

ShareThis