In this guest blog, John Anderson will introduce Ti-Browser; a new way for rapid prototyping apps that uses Titanium but doesn’t require the developer to have it installed, let alone Xcode and other dependencies.
Ti-Browser started in my head over a year ago. I wanted to have something that would be as easy to use as HTML5, but provide a 100% Native UI experience, using all the cool stuff on modern phones. It needed to be as easy as a web browser, install an app, put in something like a URL and see something cool happen.
In the Beginning
Ti-Browser started as a UI design tool. As a Titanium developer, I was always inclined to write up some quick UI code to present ideas and the feedback was awesome. After a while, I found myself prefacing any presentations with “Now this isn’t really the finished app…” because everyone thought that it was. It was cool to be able to present a ”mock up” that showed what the final app was going to look like because it WAS an app. Not THE finished app, but AN app that used 100% native components, transitions, etc.
Opening it up
Download and Go
Another hurdle Ti-Browser is trying to help mitigate is the decent amount of up-front work you need to do to get a Titanium Studio project up and running. You need to download Titanium Studio, XCode, Android SDK’s, etc. Installing all these components is not a piece of cake either. Using Ti-Browser makes all this work go away. All you need to do is install the Ti-Browser app from the App Store, put in a Gallery Code and you’re looking at UI Demos in minutes instead of hours or even days.
Cloud based XML editor
To make using Ti-Browser even easier, there is a Cloud based XML editor that includes some time-saving features:
- “Intellisense” feature that auto completes XML node names, attribute names and values.
- Cloud based work space to store many files for robust UI demos.
- Samples that you can use as the base of your UI demos to get it done even faster.
When you setup a FREE account on Ti-Browser.com, you will choose a username for the account. This username is also your “gallery code” that you enter in the mobile preview app to view your creations on a device.
Ti-Browser helps you render UI’s defined by simple XML. A classic “Hello World” would be something like:
<Alloy> <Window> <Button text="Hello World" width="125" height="45" borderColor="blue" title="Hello World" /> </Window> </Alloy>
This lets you quickly create a UI. In the above example, you would see something like this on your device running the preview app:
To make all this more interesting, we’d have to add some interactivity to it. Ti-Browser has the ability to react to events by requesting another URL from the server. Much like a web form doing a POST to a url. You can link events to doing a POST or a GET to a URL. We’ll modify our Hello World example to have the Button do a GET to a URL in response to a click event.
<Alloy> <Window> <Button text="Hello World" width="125" height="45" borderColor="blue" title="Hello World" pbUrl="btn_event.xml" pbMethod="GET" handleEvents="click" /> </Window> </Alloy>
Here we see three new attributes:
pbUrlThe URL that is to receive the POST or GET
pbMethodIndicates to use a POST or a GET. POST is required if field values are to be sent.
handleEventscomma delimited list of events to respond to.
When the button is clicked, the app does a GET to
../demo/btn_event.xml which gives the following XML:
<Alloy> <AlertDialog ok="Confirm" message="Hello World…" action="show" title="Sample Alert" /> </Alloy>
When this XML is received, it is parsed which causes a popup to be displayed, which looks like:
This shows that Ti-Browser is capable of showing a wide range of native UI elements, such as Alert Dialogs, Popovers, Sliders, etc.
Have some style
Ti-Browser also supports using “tss-like” files. By including the attribute “cssFile” on a root object (something directly under the Alloy node) Ti-Browser will load the file indicated by the value of the cssFile attribute.
This allows you to maintain a “style sheet” where you can define classes and apply those classes to UI objects. You can then place any attribute you would normally put on the UI object in the class definition and apply this class to the UI object using the class attribute. This gives you many of the benefits of a traditional css file, and keeps the XML file defining your UI layout much cleaner.
Dynamic Server Side XML
We’ve seen some very static responses. The interesting part starts emerging when you think about what kind of response (static vs. dynamic) is sent from the server. Also keep in mind that there’s nothing saying it has to be an .XML file. You could set the URL to be btn_event.xml, btn_event.php, btn_event.aspx. You can use the server side language of your choice that can send down dynamic XML that can open up some very interesting possibilities.
The server side process can analyze what fields were sent in with the GET/POST request and use that as it sees fit. As you can see, without even changing the mobile run-time client, by adding some intelligence on the server side, we are moving from a simple UI design tool to something more like a “real” app.
A good example is a login screen. You could have some XML that would define a Window that has two fields, a username and password and a submit button, such as below.
<Alloy> <Window cssFile="style.css" class="mainWin" openInNav="navgroup1" > <Label class="loginCaption" text="Username" /> <TextField id="uname" pb="true" class="loginField" /> <Label class="loginCaption" text="Password" /> <TextField id="pword" pb="true" class="loginField" /> <Button title="Login" pbUrl="login.php" pbMethod="POST" handleEvents="click" class="loginButton" /> </Window> </Alloy>
which would render out to:
In this example we see one attribute that we haven’t seen before, the
pb which means that the value of this UI element should be sent with the URL request. When this is set to true, the value of the field (text value, slider value, switch value, etc.) will be sent with the request. This allows the server side process to see what is going on in the UI and act accordingly.
In our example, we will be posting back the value of the username and password fields. This will allow the
login.php file to see the values entered in these fields. It could then do a database lookup to see if the values entered were valid or not. Armed with this information,
login.php could then send down one set of XML if the values were valid, and another set of XML if it’s not valid.
UI Demo or App?
This is where you can start to see the power of a dynamic XML response. Instead of having a static response for each action, you can have a server side process running. To see the potential of this in action, download Ti-Browser from the App Store and enter “scan” for the Gallery Code. This will bring up a simple barcode scanning application. You can also enter “irefurb” and it will bring up an app to browse refurbished products on Apple’s website.
As the saying goes, everything is good or bad by comparison, so let’s compare Ti-Browser to some of the similar tools that are out there. I don’t have extensive experience with these alternatives, so my comments are based on what I’m seeing on the websites.
Appcelerator has a tool called LiveView that allows you to immediately see changes in your code on the device as you make them. This is a good tool which allows you to make your programming sessions a bit more interactive. This does require a subscription to the Titanium Platform which is a bit pricey, and can make this tool out of reach for the indie developer or someone just getting started.
It also requires all the setup of Titanium Studio, and setting up SDK’s for all the platforms that you want to run on. This means that you’ll need to purchase a Mac, if you want to code and compile for iOS and all the headaches of getting the software components installed and configured.
Ti-Browser is easier in that it allows you to “download and go” without a ton of setup.
Ti-Shadow is similar to LiveView with the exception that it is open source, which means that you don’t have to have a subscription to the Appcelerator Platform. This makes it accessible to anyone who wants to download it and install it. Since it uses the Node Package Manager, this setup is a bit more streamlined.
There is a decent amount of command line commands that although they make the setup and use fairly easy, it does require someone who is comfortable with using the command line. Ti-Browser is completely cloud based, which means absolutely zero setup and you can maintain your files from any computer that has a web browser, even a netbook such as a Chromebook would work fine.
RapidDev seems to be fairly similar to Ti-Shadow.
Out of the box, Ti-Browser’s best use case is for developing interactive, hyper-realistic UI demos. You can download the app, log onto the Portal site view the samples and start creating your own UI demos. No installs, no command line setup, just quick productivity. Ti-Browser is also compiled with some modules (barcode reader at the present) that gives you access to advanced functionality with not extra work.
If you decide to venture out beyond the Portal and redirect Ti-Browser to your own servers, then you can explore the world or dynamic XML responses and see what we mean by blurring the line between a dynamic UI demo and an actual app.
Feel free to try it out and give it a whirl. If you have any questions/comments feel free to drop me a line at firstname.lastname@example.org.
Enjoy and Code Strong!