Appcelerator Developer Blog

Be the first to publish in Appcelerator’s Marketplace – Join the beta program!


We’re always looking for new ways for developers to build their businesses on Titanium. One of the exciting opportunities that we will be launching in a few weeks is the Titanium Marketplace, where our 1.5 million developers can buy and sell all the cool pieces of software that make Titanium applications great … things like native UI/design elements, templates, modules, frameworks, and extensions to Titanium. We’re well down the road on the storefront; now we’re looking to stock those shelves!

Prior to officially launching we are opening a beta publisher program for developers who would like to get in on the ground floor. Much like our other beta programs, we’ll give a first peek at the Marketplace to those who register early.

Have you created a cool design element, template, or module/extension to Titanium that can be used in a Titanium app? Then sell your work on Appcelerator’s Marketplace … Here’s the skinny:

• Making money is easy: Earn 70% on every sale. You can offer free trials too.
• Sell 24/7: Make money around the clock
• Quick setup: Already a Titanium developer? Then you’re already registered to sell!

Join the beta and be the first to hear about the Marketplace launch!

General

Titanium Desktop – Node.js Prototype

A few weeks ago we received a series of questions from the community about using Node.js with Titanium Desktop. Using a remote Node.js server with the Titanium mobile and/or desktop applications is not much different that working with any remote service. Working with a local Node.js server however is somewhat problematic in that most desktop machines do not have a local Node instance. That being said, while Titanium Desktop (as it stands today) does not bundle Node.js that doesn’t mean you can’t. Or at least that was my theory before kicking off a prototype a few days ago.

screenshot

To make Node.js useful from a local desktop development perspective we need to assure our app always has access to a Node.js instance. To accomplish this I started by compiling Node for OSX and Linux and dropping the resulting binaries into my projects default Resources directory. Items within the Resources directory are bundled with our project when we package for distribution so that solves the first problem. OK so we can distribute Node with the app now, but that is not of much use to us unless we have the ability within our application to pass it a script, create a server, etc.

One of the great things about Titanium Desktop is the ability to use and/or combine the usage of JavaScript, PHP, Python, and Ruby. For this project I settled on utilizing Python & JavaScript. I wrote a basic Python script that is included when the application loads. This script detects the running platform, tracks down the right Node binary, spins up a Node child process for us and passes it a script to get things started. When the instance is ready a callback is made to JavaScript land and the real fun can begin. In this prototype the custom script I have Node execute creates a server and starts listening for incoming connections. Interacting with that instance can be done via standard Ajax using whatever JavaScript library you’re most comfortable with.

To demonstrate usage of this I’ve built a simple little Github application. With Node support comes access to the wonderful world of Node Modules. Use can use npm to install modules within a project’s Resources directory just as you would any other Node project. This prototype uses the node-github module to handle interation with the Github API within Node.

We’ve open sourced the project so head on over to Github and grab the source. If you just want to run the packaged versions you can grab those builds here. Fork, experiment and enjoy!

Desktop

Save $200 on CODESTRONG if you register by June 30th!

CODESTRONGOur Early Bird Registration ends this Thursday – so buy your CODESTRONG ticket now and save $200 off of the normal $899 price!

Great news – now you can save $200 on the mobile development event of the year, but only if you register by June 30th.

Visit the website today to get the details on:

  • 25+ breakout sessions
  • Networking opportunities with 500+ peers
  • Hackathon and executive keynotes
  • Check out the session topics

Then get your pass for just $699, but hurry – special pricing ends June 30th. Register now


Developing the iPhone App Streets with Titanium

Editor’s note: The following guest post was written by Ivan Markovic, who is a member of the Appcelerator Titan’s program. After getting a degree in Drama and Computing Ivan spent 8+ years at Adobe working in the Advanced Technology Division where he helped introduce PDF to the world. Over the past 10 years he’s been acting as an Independent Consultant focusing on PDF based Java technologies as well as front end and UI expertise. These days he split’s his time between developing Apps for the UKs largest independent Estate Agent and designing and developing Apps for magicians and musicians. He also finds time for designing and developing lighting sculptures.

I recently developed a magic iPhone Application using Titanium, called ‘Streets’. In the end I have to say that it turned out to be considerably more arduous, stressful and fraught than I thought it would be!

So some background… I’m a magician, a member of the Magic Circle here in the UK and recently Penn & Teller recorded a pilot for a new show called ‘Fool Us’ where they invited magicians to see if they could fool them with a magic trick. A magician called John Archer was able to do just that and so with him being a hot property I approached him to develop an iPhone App.

He had an idea based on a trick he released a number of years ago that involved the use of a map, where the spectator leafed through an A-Z Street map of London and stopped on any page and chose any street. The magician was then able to tell the spectator which street they had chosen! A very powerful effect and not cheap.


  

So here was an opportunity to develop a very different and original iPhone App and to use John Archer’s increased visibility to help with marketing. Marketing is essential these days as unless your App goes viral it just won’t sell. So you need to have an outlet, a marketing budget or a route to high profile Twitter personalities otherwise it will just die on the vine.

I have to be very careful as to what I say about the App as I can’t reveal the secret but the main facet of this App was to create an environment that replicated the existing iPhone UI but I was concerned that I might have some trademark issues so I decided to rush together a very basic version of the App with minimal instructions and to see how it fared in the review process. The idea being that I didn’t want to spend weeks developing an App that Apple then ended up rejecting for reasons that I couldn’t code around. So this was me just testing the water.

Well as it turned out Apple did reject the App but not for the reasons I suspected they would! Fortunately with regard to their objections I was able to demonstrate that there was precedence and that they couldn’t legitimately reject my App having accepted the others. This argument ended up being persuasive and they changed their decision.

This allowed me to continue developing the App knowing that in essence Apple didn’t have any problems with the process, structure or use of trademarks. Depending on the nature of your App it might be a good idea to go for an initial ‘test’ release, especially if you have concerns that approval process might be treacherous.

The next problem I had was testing, I test on the 3GS but John Archer has a 4G phone. I’ve developed a number of Apps before and never had any platform issues but suddenly the App was crashing on the 4G phone but not on the 3GS phone! It was a nightmare, like a typical non-technical user I was getting reports that “It’s not working” or “It crashes when I open a map”! Educating them to provide you with a proper test environment, a route to the crash and something I could replicate was painful especially that when I did get hold of the details I couldn’t replicated it on the 3GS!

It was then that I realized the Retina display was the problem. With 2x resolution the memory footprint quadruples and I was simply exceeding the limits imposed on the App. But the strange thing was that with a small adjustment to the images I was able to get it all running; but then suddenly it started crashing again! I found that if I ran the App it all worked fine, but if I switched to another couple of Apps and then switched back it crashed! It seems that iOS was somehow paging out the memory and then loading it back in when the App was reactivated and this is what was causing the crash.

After much fannying around I realised the only reliable route to a solution was to make the App exit when suspended, so that it loaded from scratch every time it was started. Yes this does delay the start of the trick but it’s the only reliable way to run the App. In order to do this I created a modified info.plist and added the key/value pair:

I then finished testing and released the App to the Store, where it was approved within days (the initial rejection took about 10 days, seems to be average). All seemed well at first and the reviews started to come in but then we started to see complaints from iPod Touch users. It was crashing on launch and as I didn’t have an iPod Touch I’d never tested against it. What I really should have done was to have popped into an Apple Store and installed it on one of their test devices and given it a test drive there (I have an Enterprise account so this makes distributing Apps remotely a lot easier, as it can all be done via a URL without need for a UDID).

I started taking note of all the E-Mails I was receiving and informed everyone that an update was on its way. I was very careful to make sure that a support E-Mail was very visible on iTunes and that it was also visible on the various support pages. That’s absolutely essential; if the user can’t report and issue and doesn’t receive timely and satisfactory feedback they’ll write a negative review and we all live and die by our reviews.

I kept in touch with the iPod Touch users when I released the App to the Store (even including one of them in the testing process) and then again notified them when the App went live. The result was a group of initially unhappy users now very happy and satisfied. The only problem we have is that the effect is so strong that magicians are wanting to keep this to themselves, so I’m working hard with magazine reviewers and with celebrities to get endorsements. This App is never going to be viral but it’s going to be a slow burn. No I’m not going to make a mint, I’m not even going to even cover half of the time I spent on the development however it’s now a well respected and acknowledged App and is doing quite well as a ‘calling card’ for me; as I am move more into the non-business Apps market.

I’m not a C programmer and never really want to be, but I have been programming for 30 years and the Titanium development environment allowed me to create a very powerful App rapidly and I found the Professional support package essential to help me navigate the peccadilloes of the iOS platform.

So if you want to see how all of this time, effort, sweat blood and tears has manifest itself then search for ‘Streets’ in the iTunes Store… Yes I have to say that I still can’t believe that after over a year of App releases no one had developed an App called ‘Streets’ not in the UK or the US; I was very lucky with that name.


Introducing Titanium Desktop SDK 1.2 Release Candidate 2

Titanium Desktop SDK 1.2 Release Candidate 2 is now available, providing developers with the ability to create Titanium-based apps for distribution through Apple’s Mac App Store. A guide for the Mac App Store submission can be found here.

Additional features in the release include:
* JavaScript source code minification and obfuscation through use of Google Closure Tools.
* Support for the latest WebKit software on Mac OS and Linux, providing a consistent user experience across desktop deployment platforms.
* Quality improvements and bug fixes across Linux, Mac OS and Windows.

Read the Release Notes for details on all new features and improvements.

Download and Installation

Download Links for Titanium Desktop SDK 1.2.0 Release Candidate 2:
* Windows
* Mac OS X
* Linux 32-bit
* Linux 64-bit

You may download the related API Documentation here.

To install, you’ll want to download the appropriate distribution above and then extract into your Titanium directory.

For example, on OSX, your Titanium directory will be under either /Library/Application Support/Titanium or~/Library/Appcelerator Support/Titanium..

On Linux ~/.titanium.

On Windows 7 C:\ProgramData\Titanium and on Windows XP C:\Documents and Settings\All Users\Application Data\Titanium

Once you locate your Titanium directory, extract the zip file into this directory. The zip file will expand the contents and create/overlay some new directories for 1.2.0-RC2.

NOTE for OSX users who use Safari to download: Safari by default will auto uncompress your downloads, how handy. However, if you have a directory named desktopsdk, your extracted directory will be renamed.

Now, you’ll need to restart Titanium Developer to pick up the new release. Once restarted, remember to change your application SDK version and then click the ‘Save’ button.

You should now be able to test with the release candidate software.

Additional Documentation

Enabling Web Inspector on Mac OSX in Desktop 1.2.0
Using Titanium Desktop with PHP
Using Titanium Desktop with Python
Using Titanium Desktop with Ruby

Desktop
Page 60 of 90« First...102030...5859606162...708090...Last »