Announcing: Try Titanium (and a lot more)

Last month, Codex Labs launched an exciting new website called TryTitanium. In the spirit of TryRuby (developed, in part by our founder and CEO, Andrew McElroy), jsFiddle, and others, TryTitanium allows developers to write code for Appcelerator’s Titanium mobile development environment right in their web browser and see the results in a web-based iPhone-simulated viewer! At the moment, we’ve got one lesson in there, which walks you through development of a Breakout-style game (code originally developed by Tipsy & Tumbler’s Boydlee Pollentine), which you can walk through at your own pace and learn the basics of how Titanium works. We’ll be adding more lessons, references, and the ability to just start from scratch with your own code, but for now, there’s actually nothing stopping you from switching off “Lesson Mode” and tweaking the code to your heart’s content!

So why is this site important? Well, in the next few weeks and months, Codex Labs is going to be introducing a number of new lines of services and products, among which TryTitanium is only the beginning. All of these new offerings are being built around training and helping the development community to build bigger and better software, not just for mobile platforms, but across platforms and form factors.

Our first and most obvious (because it already exists) offering is called Codex Live. This is the name under which our live, instructor-led classroom and online training classes will continue to be offered. The Codex Live classrooms have always been offered in a hybrid fashion, catering both to in-person students, usually at our office in Nashville, TN, but also onsite at every tiConf location this year and soon to be expanding to Atlanta, GA, and other locations to be announced soon, as well as to online students who can join and participate in the classes live at http://classroom.codexlabs.com. Our Titanium trainers are the best in the business and are knowledgeable beyond the boundaries of the curriculum, able to answer questions “Live”. In addition, every class that we schedule is Guaranteed to Run™, which means that you never have to worry about cancelling or changing your plans at the last minute.

Our first new offering, which will be debuting this week, is Codex Casts. Found at http://CodexCasts.com, this will be a monthly video subscription site covering topics ranging from unit testing to JavaScript best practices to secure mobile commerce to Titanium Native Module development for both Kroll and Hyperloop. New CodexCasts will be released weekly. Stay tuned for an announcement very, very soon on the debut of this new site!

Our second new offering, which is where TryTitanium fits in, is called Codex Go. This will be a suite of online, self-paced training courses, offered at an affordable rate and allowing developers to train on their own timeline, using comprehensive, interactive, hands-on lessons, labs and exercises. TryTitanium will be expanded with new lesson plans and will eventually be folded into Codex Go along with additional training topics including beginning JavaScript, game development with Lanica’s Platino game engine, and even web development with Knockout.js, Angular and Durandal (eventually – these additional lesson plans are a bit farther down the roadmap at this point).

Finally, we will be introducing a number of open source, freeware, Titanium module and Titanium add-on products under the name of Codex Source. While not directly related to training, Codex Source will be our way of “giving back” to the development community in whatever way we can. This is also the area in which, unfortunately, I can’t say a whole lot right now in terms of specific details, because most of the things we’re working on are somewhat secretive at this stage, and all are still under development. Suffice to say, we think the products that we’ll be introducing under Codex Source are going to absolutely blow people away. And some of these will be introduced VERY soon. (Keep an eye on the tiConf in New York in May – that’s all I can say.)

So, I hope I’ve piqued your curiosity a bit and sparked your interest in mobile development! It’s a very exciting time for software developers, and Codex Labs will be on the front lines of the bleeding edge in development and training. Stay tuned – we’ll be posting a LOT more in the next few weeks and months. We’ll be at every tiConf we can possibly make it to and we’ll see you around the world and around the Interwebs!

NY or bust!

–John Gould CFO, Codex Labs

What’s in a name? An explanation behind Codex Labs.

The name Codex Labs, LLC may at first appear to be a strange choice of words for a training company? However, is it?

Let’s begin by defining what a Codex is:

co·dex ˈkōˌdeks/ noun: codex; plural noun: codexes; plural noun: codices 1. an ancient manuscript text in book form. an official list of medicines, chemicals, etc.

It should be noted that Leonardo Di Vinci’s iconic technical/scientific writings were often done in a collection called a Codex. Eg. ( Codex Atlanticus, Codex Madrid, Codex on the Flight of Birds, and many more).

Furthermore, he had this to say about understanding the natural world:

First I shall do some experiments before I proceed farther, because my intention is to cite experience first and then with reasoning show why such experience is bound to operate in such a way. And this is the true rule by which those who speculate about the effects of nature must proceed.

  • source: Ms. E, folio 55r; see ref. 3, pp. 299-301, for a complete list of facsimiles and transcriptions of Leonardo’s Notebooks.

Interesting. Essentially we have the basis for science well before Bacon’s time. Think 100 years ahead of Europe.

More relevant to the company Codex Labs, we have already established what a Codex is, but now we have the basis for why the Labs part. A Lab should be an interactive space whereby you can explore, learn, and discover a particular technique, concept, or idea.

Together, we have Codex (the textual, audio, and video documentation/instruction) and Labs (active learning aka learn by doing and instructor led classes).

We will discuss in future posts what “Active Learning” is. It is often called “learn by doing”. We will also see what it’s strengths are.

To be clear, we will continue to offer the instructor led TCD (Titanium Certified Developer) course, the TCE (Titanium Certified Expert) course, and the combined Titanium Mobile Development Course at both our training center in Brentwood, TN and online through our online classroom.

The Codex Labs “Guarantee to run” a scheduled course

Since June of 2013 Codex Labs, LLC has quietly had an internal standard that if we schedule it, we execute it.

Today, We are going one step further and officially announcing: “If we schedule a course on eventbrite and if even one student signs up for it then we will run that class– Guaranteed!”

In otherwords, “If it’s on the schedule, it will be held”.

For additional assurance, look for this logo:

guarantee-to-run

The reason why we feel the need to roll this out in the first place is due to the fact that travel (should you choose to attend the class in person rather than use our virtual classroom) as well as hotels are annoying to book only to have the class cancel.

At Codex Labs, LLC you’ll never have this nightmare scenario happen to you.

Lastly, feel free to peruse our currently scheduled courses:

http://CodexLabs.Eventbrite.com

or http://training.appcelerator.com/schedule

Cucumber testing with Alloy

[vimeo clip_id=75164235 width=800]

Vimeo only encodes one video into HD per week. It will be in HD next week. Sorry for the wait.
If you want a full HD downloadable version, Here you go. It’s an mp4
You have to actually download the video to see it in HD

The github repo is here: https://github.com/CodexLabs/alloy_fugitive

This currently only works with Alloy and iOS. Android and Titanium classic support is being worked on now. These two shell scripts run.sh and ./ticucumber.sh exist so that I can work out the best way to wrap calabash gem (ruby). I will then make a npm package and attempt to get calabash to run through opal.rb. I am currently using ruby 1.9.3 MRI for the ruby interpreter.

Titanium Alloy App.js not found: what is going on and how to fix it.

I was working on the cucumber blog post and part 2 and 3 of the unit testing blog posts, but kept consistently running into this issue:

appjs-cod

As long as you stick to using titanium studio to clean, build, and distribute your application, then you should never see this bug. This is also true for the node package titanium (The Titanium CLI).

That said, sometimes there is a need to open up the xcodeproj file in build/iphone and run the program from Xcode. Checking for memory leaks is one mainstream use case that comes to mind. This issue almost always comes up when I am demonstrating how to use Instruments.app on a Titanium app in the TCE (Titanium Certified Expert) class. Bottom line, this is a big deal.

I do have to give Appcelerator credit for trying to fix this issue:
https://jira.appcelerator.org/browse/TIMOB-14683

https://jira.appcelerator.org/browse/TIMOB-11599
And several more tickets.

It’s been a persistent issue.

The bottom line, when you build a Titanium (including Alloy) project via Titanium CLI or via Titanium Studio, the compiled project with the requisite assets shows up in a directory similar to: alloy_fugitive/build/iphone/build/Debug-iphonesimulator/alloy_fugitive.app

Keep in mind that .app programs (be they iOS simulator programs or OSX Apps are actually “executable” directories)

However, and here is the key information, when you build via Xcode, it copies the project over to a directory similar to: /Users/andrewmcelroy/Library/Developer/Xcode/DerivedData/alloy_fugitive-avymvmevmwfystazafhrrwfmsvgs/Build/Products/Debug-iphonesimulator/alloy_fugitive.app

The -avym…. is of course randomized. Hopefully, I am not exposing any encryption information/private information by posting that path. I have no idea how that random string is generated. :-/

The reason why this is a problem is because when you run titanium build, one of the steps is to symlink all the assets over from the Resources directory.

** This fails to happen when you press the Xcode build button or use xcodebuild **

Once the assets are copied or symlinked into this DerivedData folder and then built (assuming the app isn’t already on the simulator) then it works as the video shows. However, if the app is on the simulator, then it will need to be deleted before Xcode bothers to shove the new symlinked/copied data over to the Simulator folder.

It turns out that completely unwittingly I accidentally guarded against this entire issue with my b2i script. The xcodebuild line that I use is as follows:

xcodebuild -project “pwd“/build/iphone/*.xcodeproj -configuration Debug -sdk iphoneos CONFIGURATION_BUILD_DIR=”pwd/build/iphone/build/”

This ensures that I always build from the build/iphone/build directory and never DerivedData directory. I did this because I was anoyed with not knowing where my .app file was floating off to.

Specifically, I specified a CONFIGURATION_BUILD_DIR.

However, I believe a better fix would be to modify the shell script that runs ‘post compile’ often called Script-{random-giberish-here}.sh the contents of which include curently:

[gist id=21a10188acab1ecc7a69]

I would include a check that it’s not being built from the DerivedData folder, but rather the build/iphone/build directory.

Here’s a video demonstrating the problem in a reproducable manner:

[vimeo clip_id= 75159222 width=700]

Getting started with unit-testing in Alloy 1 of 3

This is the first of a three part series as we look at what Unit Testing in Titanium/Alloy is like ( we are using using Behave.js in this article).
There will be another series where we talk about Integration ( Cucumber testing). stay tuned.

Intent of blog post:
The intent of this post is to show a cross-platform (Windows, Mac, Linux, etc) way to unit test an Alloy/Titanium App from the vantage point of a beginner. In the blog post we are going to repeat an approach that denvers (on github) created.

We will however unit test the default Alloy one tab app.

Some Background

Unit Testing is a widely used practice across (almost) every development platform, the vast majority of developers who adopted it rarely, if ever, go back to non-unit tested projects.

Among the benefit of Unit Testing we can mention:

  • Ensuring bugs are found fast and automatically via these automated tests.
  • Prevent breaking of already tested functionality when adding code or modifying it.
  • Allows for easy refactoring without worrying of breaking changes.

Up until recently, the Alloy community was seriously lacking in unit testing framework. Luckily a few frameworks started cropping up, and we can now safely start adding this very important layer of quality assurance and maintainability to our projects.

For the purpose of this post we’ll be looking at unit-testing with behave.js

  1. Create a new Alloy Project
  2. Create a new “lib” directory under app (app\lib) and copy the behave.js module (behave.js file here)
  3. Create a new directory “specs” under assets (app\assets\specs)
  4. Create a file that will contain your tests, for example: test-spec-1.js
  5. Add the following code to the alloy.js file located in the root directory of the app
    [gist id=322f291ae48d7252cf86]
  6. Now it’s time to write our unit tests
  7. Open the previously created test-spec-1.js file and type the following:
    [gist id=e7c331559efb20f8fe9f]
  8. Now, all that’s left is to run these tests. You can use the titanium cli or Titanium Studio like this:
    [gist id=5c9eaaf14aab79d3e23e]

If everything is working properly you should be able to see results similar to these

Here’s the complete codebase. Enjoy

Discussion:

This is the very tip of the iceberg on Unit Testing. We did not Test Drive this (since the code already existed). Also, behave.js may or may not be the best choice for unit testing moving forward. We will explore this in the next blog post where we contrast it against Mocha.

The biggest reason why I am hesitant to use Behave for production is because it does not appear to be well maintained, lacks stubbing and mocking functions/ documentation, and has no concept of before and after blocks (setup and tear down routines)– muchless Let or Subject functionality (from Ruby’s Rspec BDD framework).

On the other hand, Behave.js is very simple to understand and is incredibly easy to extend. It would be trivial to overcome the objections I just talked about

What do you think? Is this, as NASA would put it, “the right stuff” or is there a better way? Let us know in the comments.

In the next article we will look at a Mocha ( grunt-mocha-test) + Alloy runtimeTester example (the UI validation function: validateUiComponent. Example spec)

Build an Android launcher app with titanium

Have you ever needed to build a Kiosk app for Android?

If so, one option you may want to consider is to make your app a ‘Launcher’.

It turns out that this is really simple.

If you aren’t already maintaining your own AndroidManifest.xml file under the platform/android directory in your titanium app — go do that right now.

Once you have an AndroidManifest.xml add this:

[gist id=6448649]

Please note that the important line is 3. I added the BOOT_COMPLETED incase I wanted to capture the BOOT_COMPLETED event as well.

OR SEE THE SIDE NOTE.

SIDE NOTE: It is somewhat controversial in the Titanium Developer community to have a custom AndroidManifest.xml.
There is a risk of your AndroidManifest.xml file becoming obsolete as new versions of titanium are shipped.
If that’s a concern and if you aren’t experiencing any inconsistent behavior (orientation change, etc) then consider doing this:

[gist id=6450518]

You want to do one or the other.

If you do both, then the mere presence of the AndroidManifest.xml file will cause titanium to ignore everything in tiapp.xml when it comes to android. For this example app, I am leaving both examples in this codebase.

Again, because I have an AndroidManifest.xml file, the tiapp.xml example isn’t being exercised.

If you want to make use of BOOT_COMPLETED in Titanium, please see this article http://bencoding.com/2013/04/02/using-boot_completed-in-titanium/

photo

Once you open the app, hit the home button, this menu will come up. select hipsterdash and it will remember that choice when you boot.
Happy Coding.

PS: here is a hello world style android launcher example (alloy) https://github.com/CodexLabs/hipsterdash
The only point of this alloy project is to demonstrate that this blog post is accurate.

It’s licensed under the MIT software license.

One last thing, If you want to know more about Intent filters in Android ( they are very powerful) check out the docs: http://developer.android.com/guide/components/intents-filters.html

UITableViewCellEditingStyleInsert is now a pull request for Titanium Mobile

**EDIT 2:*** You can now see the Issue ticket for this feature at https://jira.appcelerator.org/browse/TC-2892

**EDIT:** you can see the pull request here https://github.com/appcelerator/titanium_mobile/pull/4636
A year ago, we were working on a mobile app for a ADD/ADHD practice and needed to do the following with Titanium:

iphone_contact_editing

See that green plus thing in the tableview? Titanium 2.x and even as of 3.1.2 does not support that API natively on iOS. To be clear, UITableViewCellEditingStyleInsert is an API only found on iOS. Regardless.

A year ago we patched our internal copy of titanium as such:

[gist id=6396850]

 

We then posted an announcement to the Titanium Q&A forms.

https://developer.appcelerator.com/question/140226/add-row-row-in-editable-tableview

Let’s just say that maybe I took on the properties of the ADHD practice a bit too much, because a year later we are now finally getting around to doing a proper pull request. This patch is Apache 2 licensed. 

Introducing b2i: Build to iPhone

Have you ever written a Titanium app and needed to run it on an actual iPhone or iPad, but didn’t want to deal with iTunes or Xcode’s GUI? We have an answer for you. It’s called b2i. Originally it was called xcode-build-to-iphone, but that’s way too long to type out every time. I wrote it during tiConf 2013. It is available on github via https://github.com/Sophrinix/xcode-build-to-device

You can also download the program as a zip file. However you will need to follow the install instructions.

I will eventually make this a node package, but for now it is a shell script and requires that you setup an alias in your bash_profile (or equivalent) 

The installation instructions are in the readme.

However I will reproduce them here:

Installation

Clone the repo, call it .b2i and place it in your home directory

git clone git@github.com:Sophrinix/xcode-build-to-device.git ~/.b2i

Add this to your ~/.bash_profile and/or ~/.zshrc (if you use zsh)

alias b2i="~/.b2i/build2phone.sh"

If you plan on using terminal from Titanium Studio, you’ll want to add that line to the bash_profile

Now anytime you are in the root directory (aka same level as where the tiapp.xml file is) you can type:

 b2i

Provided that your certificates are correct, it will build your titanium app to the device directly. No iTunes, no GUIs to mess with. :-)

You will have to make sure that your project has been build as an iPhone target… aka yourproject/build/iphone/files_here_must_exist

If there is nothing in that directory then consider using the titanium CLI and run

titanium build

This b2i program will work on alloy and traditional appcelerator apps.