Archive for June, 2011

Titanium Desktop – Node.js Prototype

Thursday, June 30th, 2011

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!

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

Tuesday, June 28th, 2011

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

Monday, June 27th, 2011

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

Friday, June 24th, 2011

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

New Defaults for Android Layouts in 1.7

Friday, June 24th, 2011

One thing that’s come up a few times after 1.7 has dropped is a new default configuration in Titanium that has “broken” layouts for Android applications. If you’re upgrading from previous versions of Titanium to 1.7, your layouts may seem “squished” and your fonts smaller than you expect. For the impatient or the experienced, I will share the “fix” first so you can revert Titanium back to its old behavior. For those wishing to understand how Titanium and Android handle layouts and different screen densities, I will provide some context and guidance for Android layouts second.

The Fix

In previous Titanium versions, we overrode a default setting in AndroidManifest.xml which has to do with scaling UI for various screen densities. In 1.7, we stopped doing that and followed the Android defaults, empowering the developer to decide what behavior they might prefer. To change this back to the old, auto-scaling behavior, you will need to edit a setting in tiapp.xml:

Adding this to your tiapp.xml should solve any problems with layout scaling that were introduced as a result of upgrading to 1.7. You may or may not need to clean your project (force Titanium to freshly re-generate the native project files) to ensure your new configuration settings are picked up:

Supporting Multiple Screen Densities

And now a bit of context on what the above code snippet is doing.

Android devices, as you are no doubt aware, come in many shapes and sizes. For developers, that means supporting screens with different resolutions and densities – the official Android docs on supporting multiple screens is essential reading on this topic. Screen density is the number of pixels on a physical space on the screen, usually measured in dpi (dots per inch). Screen resolution is the actual number of pixels on the screen, usually given in a width by height notation like “1440×960″.

For example, I have a Motorola Droid 2 I use for development. The resolution of its display is 480×854 – it is also considered a “high density” screen (240dpi) because all of those pixels are packed into a reasonably small area. If I wanted to test this device screen size on my desktop in the emulator, I would use the “WVGA854″ skin, which is available in the Run Configurations menu in Titanium Studio:

Android will ship on devices with many different screen densities, so coding our application with different pixel sizes for fonts and layouts would get old pretty fast. To help combat this, Android allows developers to specify layout values (and font sizes, though the term is slightly different) in density independent pixels, also called dips. When your UI components are sized in dips, the Android OS will scale your UI up or down as if the screen your application is running on were what it calls a “medium density” (or 160dpi) screen. Most of the time, this is the behavior we would want and expect.

To make dips the default unit for UI components in an Android application, it requires an entry in AndroidManifest.xml (android:anyDensity=”false”), which is what we specified in our tiapp.xml above.

Code Examples

In Titanium Mobile, typically we specify fontSize or height/width/top/bottom/left/right values as integer values. On iPhone, these values correspond to the 320×480 point system used to lay out UI components (even though the densities of iPhone handsets can be different). On Android in 1.7, raw integer values (unless the tiapp.xml configuration is changed) correspond to real pixels on the screen. Consider the following simple app.js:

On Android, on a medium density display (like the HVGA screen size in the emulator), the box and text show up at a pretty large size. On a high resolution, high density display like my Droid 2, the text and box are pretty small:

In terms of proportions, I’d prefer to have the box and text show up at about the same size on the high density screen as well. I can fix my code by specifying my heights/widths/font sizes as a ‘dp’ or ‘dip’ string rather than an integer value:

On the iOS side, that platform doesn’t care about the units – they will take any ‘dp’ values and use them as points. That code produces something which is a little closer to what I’d expect:

Conclusion

So when it comes to handling multiple screen densities on Android in Titanium, you have a couple of choices. In code, you can specify your height/font size values in either dips or raw pixels, as befits the situation. Or, if you’d rather have your UIs scaled up and down in all cases (as was the default setting in previous versions of Titanium), you can add the tiapp.xml configuration setting we led off this article with. Let us know if you have any questions, and hopefully this helps clear up any confusion around layout on Android.