Adobe Air Captive Runtime. Who needs it more, desktop or mobile platforms?

I was reading the article Installation and deployment options in Adobe Air 3, and then I started thinking about what it does really means. At first, the captive runtime is a great tool to test new Air versions on devices that has an older version installed. When using captive runtime you can basically bundle the Air runtime with your application and don’t bother whether the target device has a different runtime already (or no runtime at all). The article shows the advantages and downsides for the solution, so I won’t repeat it here.

What actually has caught my attention is the fact that Air-based applications for Desktop computers aren’t many so far, and it doesn’t seem to be even considered as development platform for most “non-Flash” developers. One roadblock, in my opinion, was the need to install Air runtime as a separated task when you deploy an Air application. Although this is not a complicated task, it is an extra step that usually developers tend to avoid. I still recall all the complains about the same thing, when Microsoft started using .NET runtime and you have to install it to be able to run .NET made applications.

So, although captive runtime is mandatory for iOS devices, and a nice choice for Android and Playbook, I believe the real beneficiary will be the desktop OSes (aka Windows and MacOSX) developers, since now the developers can “sell” their application as a native one, from an installation standpoint of course.



Taking care of your Playbook source code

Professionally, it is very common work on software development using some sort of source control system to keep our precious work safe, and to help us keep track of the changes we do.

Now, when we do software development at home, as a hobby or as a side project, we tend to neglect this basic procedure, sometimes just relying on backups, Dropbox, or even worse, our lucky to keep our work safe after burning the midnight oil.

The problem with source control at home is that, although it is very easy to set up them on your computer, and keep track of changes, it is not as easy as it seems to rely on that to keep it safer on another computer.

Read the rest of this entry »

Leave a comment

App Game Kit Updates

Some time ago, I’ve posted some information about the App Game Kit, a mobile cross platform development kit that is being developed by The Game Creators. It’s planned to be a 2D engine, allowing developers to create games for iOS, Samsung Bada and Windows on launch time, and more platforms later 2011.

This month on the The Game Creators newsletter, they are providing an extensive Q&A that really helps to clarify the developers questions about it. To make your life easier (and keep you reading my blog), I reproduce here some of the questions from their newsletter:

I assume there will be a built in tile-, layer-, animation- and lightning system, like in the 2D plugin Kit (or something similar)?

  • Our focus primarily is a solid and fast foundation. We are adding features which elevate it from being just another wrapper, but we’re keeping those dark for the moment.

And, I also hope there will still be a significant amount of 3D commands?

  • There will be no 3D commands in the first release. Our aim is a really solid 2D kit to begin with. We may be exposing some nice 3D-esk features like shaders and UV manipulation, but only as far as quads.

I asked if the AGK will use the OpenGL ES system for its rendering?

  • Yes we are using OpenGL ES on devices where OpenGL is not available, but you are protected from this distinction by the language.

Is it just me or does the tier 1 runtime app that loads other apps sound like it’s against Apple’s TOS?

  • It’s a grey area and we have some strategies to overcome this barrier. For those with a Mac, you will always have the option of compiling natively to comply fully with Apple rules.

Bytecode, fine, but why not allow us to distribute ourselves similar to how DBC was done?

  • You can, anyone with a Mac can compile their Tier 1 apps natively for publication on the App
    Store. We plan to offer a service to publish apps for those users who do not have access to an Apple Mac.

Why not offer pre-processing commands where we can have our cake and eat it too?

  • You can. There will be a command in AGK which tells you which device you are running on, just in-case you want to re-arrange your screen, make buttons smaller or present specific themes.

Will it be possible to embed and access external .dll files and AS3 .api files?

  • There are no plans to support third party external plugins or modules in Tier 1. Naturally Tier 2 will allow any number of linkages as it’s plain old C++.

Any TGC splash screens or watermarks?

  • No plans to add anything like that. If you pay for AGK, you should not have to display our logos all over your work.

Why couldn’t I sell games made from Tier 1 without going through TGC?

  • You can, many platforms are not as restrictive as Apple, allowing you to compile your Tier 1 app and distribute it right away. To distribute your own Tier 1 apps on Apple, you will need a Mac to perform the final certificate based compile.

What kinds of support will there be for internationalization and localization? Would we be
building this kind of support ourselves or will there be something built into AGK for multiple languages?

  • Great question. We have been focusing more on speed and universal stability at the moment, with localisation being left to the app author for the moment. There are a number of competing solutions which make localisation a snap, though we have yet to choose one. One simplified solution we have identified is that the app can be exported with the text data separated out, so you can localise without re-compiling the app. We’ll explore this more during the public betas.

I would like to see the ability for us to distribute our works freely. In other words if I want to make some games for free and I don’t want to go through TGC, I should be able to do that?

  • Yes you can do that in Tier 1 and 2. See answers above.

What’s the point of making AGK compile to byte-code in the first place? You could just convert to C++ and compile it yourselves?

  • The choice is about ease versus speed. Tier 1 byte-code is designed to run on every device we ultimately support. If this becomes ten platforms, it means the programmer only has to code and test on one device, knowing they don’t have to buy, build and set-up the nine other platforms to make their app cross-platform. Tier 2 is for those who prefer to compile for each platform personally, ensuring the fastest performance and widest support for device specific features.

Have you guys at TGC done any research into existing languages geared towards games?

  • TGC have been developing and publishing game creation tools for over eleven years, and its employees have been using game making tools ten years before that. We have a natural interest in this field and always keep an eye on the horizon to see what our contemporaries are up to. To date, we’ve not found anything that has convinced us to switch to a third party development tool. As the number of game capable platforms explode, AGK is something we needed in-house, and we’re pleased to be able to share this cool technology with you soon.

Is it possible to use the “easy” tier1 commands in tier2? Or are you restricted to the c++ ish code?

  • Yes you can. In order for you to self-publish a Tier 1 app, you will need a Mac, the iOS SDK and a special build of the Tier 1 interpreter which will allow you to take your Tier 1 app and compile it as a native binary for the App Store. C++ knowledge is not required.

Do you publish all the games we ask you to publish (if they work) or do you publish only the good ones?

  • Good question. We have over two years’ experience specifically in publishing mobile apps to
    various stores, and have learned a thing or two about what makes a good app. Given the cost TGC would incur incubating the app and getting it ready for cross-platform sale, we’d only choose apps that reach a certain standard. Apps that don’t quite make the grade will be given support on how they can be improved. Accepted apps will enjoy cross promotion within our extensive catalogue of apps and constant monitoring to ensure they remain compatible as devices evolve.

I own all of these platforms already, so if you need a beta tester with a multitude of devices and who has been with DB since the very beginning, I’d be happy to oblige?

  • Great to hear we have a small army of brutal testers. As soon as we’re confident, we will
    announce a public beta of AGK in our monthly newsletter. Not quite there yet!

When selling games using Tier 1 will the end user have to first download a player? Does this apply to all supported platforms?

  • Not at all, when you compile your app in Tier 1 the player is included. When you sell your app on the store, the interpreter is part of the final package and no separate Player is required. All devices will operate this way.

Will Tier 1 games be sold through a player app? I assume we can’t sell them through an Appstore directly.

  • Selling through a player is prohibited on most mobile stores, and so we are not using this
    approach. You can sell your app directly through an App Store by building a package that includes the player along with your app code, media and other files.

Since you receive money from every sale of Tier 1 games I assume it will be cheaper to get a Tier 1 license then a Tier 2 license? Will there also be an upgrade price for those who want Tier 2 later?

  • Yes to both questions. Tier 1 is the affordable and easy game making solution, whereas Tier 2 provides additional benefits of device specific support and a C++ environment.

You have support for MP3s, do we need some kind of license to sell games with MP3 music?

  • Not at all, only device and OS manufacturers need to buy such an encode/decode license. As the app uses the native MP3 support of the device, and not an internal decoder, no fee is due.

How hard would it be to make the run-time app (used in tier 1) into a browser plug-in?

  • We are treating browsers as another future platform for us to support. We continue to look at the evolving browser technologies with interest, especially those that promise native performance from the host system.

If I wanted to take advantage of the user’s GPS location, would I need a Tier 2 licence or are these features supported within Tier 1?

  • A. You would need a Tier 2 license, and you would need to learn the platform specific SDK that provides that GPS information.

So, when will we be able to pre-order it and for those of us who do pre-order it will we have to wait until it is officially released to get it or will we be able to get our hands on a beta copy (or pre-release candidate) to start experimenting with?

  • We are not planning to take pre-orders at this time, and warming to the idea of a community
    discount applied to an early adopter version of AGK. As you would be helping us test the product, you would be automatically given a full price license on completion under this scheme. There will also be a public beta to some degree so you can play around with the tool kit and get a feel for the technology.

Is Kindle going to be one of the targeted platforms?

  • No, Kindle will not be supported for some time. Our primary target are popular mobile and
    desktop devices that are capable of playing fast games and apps.

When/If the Android platform is supported – how would I take advantage of the Google maps feature? Would I need a T-2 licence for this?

  • Yes you would need the Tier 2 product, which allows per-device support of specific features not present in the core engine, such as GPS, Maps, Calendar and other features.

The newsletter also shows a simple demo source code, so you can have an idea about the program language used, and the resources available. As you probably know, TGC are the creators of DarkBasic, so it was expected that the AGK would use similar syntax. Using bytecode, or compiling it natively seems to cover all possibilities (like iOS restrictions), but good performance on mobile devices is really something I’d like to see how it is going to be.

There is no beta or actual demo available, but considering their launch schedule, I’d expect something soon.

The TGC website has a community forum, with a specific are to discuss the App Game Kit. If you are interested, I think it is the best place to get information.

Leave a comment

Playbook application development wrap up

Sunday, Feb 27th. Today I finally finished my Playbook application, and submitted it to the AppWorld. Now, it is just a matter of waiting for the application review and approval (or rejection). I’ll let you know what will happen. Until there, I won’t tell you what the application is, you thief!

During the last months, RIM has released four SDKs releases, all in beta stage, and three simulators running as a VM on VMWare. Although it has shown certain evolution, as a small developer, it was really hard to keep up with the changes. It might be something I missed from the release notes, but I ended up having to change my code couple of times as the Air SDK received changes. As a beta, there is no commitment to avoid backward compatibility, so this is expected. The problem is getting the right information on the right place, which was never completely clear. In addition, the SDK reference guide could use more examples, and some topics seemed until “under construction”.

On the bright side, the community support I got from the Blackberry Developer Forum. There were amazing people there, and having more eyes looking for changes and updates was the most valuable asset I could “hire”. If you’re starting looking at Playbook development, you shouldn’t be reading this, you should be there! Kidding, you probably can keeping reading both! Pleeaaase!

Having everything running in a way to get the HelloWorld app running was actually easy, and RIM’s Get Started guide is, in its last version, very good and detailed. Check them here. I did the steps on both Mac and Windows, without problems. I didn’t try Linux, though.

During the SDK upgrades I did a mistake once. I was having a nasty compiler error, the after a while (really long “while”), I realized I forgot to change the SDK path to the proper version. It is not really clear where or when to do that, since the SDK installer asks you for the Flash Builder path, and I assumed those things were updated automatically. So, for your information, you should change the SDK path in Preferences -> Flash Builder -> Target Platforms -> Blackberry Tablet OS.

The use of a VM as simulator was also a little bit challenging. I didn’t see a problem in it being a virtual machine and it worked fine for me. The problem is actually the lack of features that will be present in the device itself, like camera, GPS, gestures recognition, etc… My app has a tiny use of gestures, which I couldn’t test at all before submitting it for review. As backup, I’m also checking for standard mouse events, which I could test. That way, the user will be able to use the feature, even I did a mistake about the gesture implementation. Some other developers had to change plans, since their original project would use the camera, for example. Another constant request was the change of orientation which was added in one of the latest releases.

I look forward that RIM/QNX keep updating and adding features to the simulator, even if I can have an actual device available for development.

After I finished the development and testing, I was scared about the process of sign your application, which is mandatory to get your app in the AppWorld. The BB forum has a thread with more than 200 posts about the subject, with tons of terrified developers with the command line utilities we have to run to get the application properly signed. Well, I was scared with (almost) no reason. Following RIM’s instructions to get my developer certificate was enough for the first step – Configure Application Signing from the command line. For the packaging/sign process itself, I’ve followed JRab’s post, which was complemented with other users comments. It was very helpful indeed.

During this process, the only problem I had, was related to my Mac bash shell and my  password. I was using a punctuation character in my password, and the bash didn’t like it even enclosed using double-quotes. I had to change all commands that were using double-quotes to single-quotes to make it work. The worst about all that is that I didn’t get an error, but the utility prompted me to enter a passcode! That really fouled me, and I had to get help from my fellow developers to solve it.

As you can see, the problem was more my lack of knowledge of that bash behaviour than actually anything related to the command line commands. Without sounding like I’m trying to find a problem where it isn’t one, the problem here is the command-line interface itself. The commands are somehow straightforward, but with a lot of small details and parameters, which makes it easier to make mistakes. Doing that from a graphical utility would be much easier, for sure.

At the end, the Playbook development was a very pleasant activity, even realizing that the whole development process has still several issues to be sorted out. If RIM starts paying more attention to what the community are looking for, we’ll have one of the nicest ecosystem to work with – cool device, nice development tools and amazing community.


1 Comment

Is Android the new Linux?

First of all, it is fact that Android is based upon a modified version of the Linux Kernel, so the question in the headline above seems somehow stupid. Despite the fact that a catchy headline could bring more readers for this blog (I don’t think I’m supposed to say that…), the real idea about this title is to bring a discussion about Android and the App marketplace from a developer perspective.

During the past several years, Linux as Operating System has been growing and growing, with more professional applications and more user friendly interface. I’ve been using Linux on daily basis at my job as desktop, and I’m impressed on how well-polished the applications are nowadays. The only thing, which is good for the company, is that everything needed is there, for free – from the Evolution with MS Exchange interface to the excellent IDEs, like Eclipse and Netbeans.

I’ve seen companies attempts to make money selling off-the-shelf applications, but with few exceptions, they had all failed. Even the distribution makers had to get their revenues from other sources like support, installation and custom development, because selling licenses doesn’t seem to work for this business model.

On the mobile development market, Android has been a juggernaut, with its growth reaching the skies every new statistic your can find on Internet, starting beating Apple, Nokia and RIM in number of devices. Of course, one factor that helps is that Android is actually used for several different manufactures, making its growth easier in certain aspect, but the OS has also its qualities and neat applications that cannot be denied.

Another day I was browsing the Android Market and I was impressed about the kind of application was available. Although there are tons of legitimate applications, I could also find shameless rip-offs of well know applications available on another platforms. I have to admit that unfortunately this is part of the kind of freedom that this ecosystem brings, but at the end, this is very bad for all legitimate developers around there.

But the point that I’m trying to get here is that the Android marketplace is a wild environment for paid applications. It is the one with more free than paid applications (check Jan 2011 Distimo Report), compared with Apple  Nokia and RIM’s app stores. What this means to me it that having more free apps, it is very likely that an app that a potential customer is looking for is already available there for free, jeopardizing any revenue you could get selling your paid one.

So, to a off-the-shelf Android developer would remain the in-app paid system or revenues coming from advertisement. A good example for the second is the best-seller Angry Birds, that release its Android version for free, but with ads. It might be good for them, but mainly because Angry Bird is well known, and it is been expanded for several different platforms, so they can do well selling ads. Probably this is not always true for less known apps.

I’m not saying that the Android platform is a failure, because it’s not. But I don’t believe it is as profitable as others stores for the off-the-shelf developer.

For Android developers, these applications would work more like a portfolio to show off than to make money selling them. I believe the real money is on in-house development and the professional services market. The kind of freedom we find on Android ecosystem is perfect for companies to build its own solutions to be used by themselves or for their customers. And also, with the large variety of device providers and form factors (smartphones, tablets, etc…), it makes easier for those companies to choose the right solution. So, while the off-the-shelf application market is unknown for me, the Android developer professional seems to be a very good choice to invest your time with.

Leave a comment

The Mobile Experiment V 1/2 – SQLite

In my last post, we have a short introduction about the SQLite support on BB OS. This time, I’m gonna start implementing it for the TimeTracker application.

My first step was to create a new class called TimeTrackerDatabase, which is responsible for all database activities, i.e, database and table creation and data insertion. Remember that my application is very simple, so there is no need to edit and/or delete data.

The TimeTrackerDatabase constructor is responsible for verifying whether the SD card is present or not, as well as creating the database file in the proper place. Actually, the SD card test is done by another class private method called hasSD(), which was copied from one of the RIM’s sample code:

private boolean hasSD() {
   // Determine if the SDCard is present
   String root = null;
   Enumeration e = FileSystemRegistry.listRoots();
   while (e.hasMoreElements()) {
       root = (String)e.nextElement();
       if(root.equalsIgnoreCase("sdcard/")) {
           return true;
   return false;

The constructor itself will call the function above, and if the SD card is not present, it will show a message saying that the app requires a SD card to work. The way it is done below, the message is shown using the event thread. The invokeLater method will ensure that the dialog will be displayed in the next available oportunity by the main event thread. There is an excellent article about Blackberry UI Threading here:

Here is the complete constructor:

public TimeTrackerDatabase() throws Exception {
 if(!hasSD()) {
     UiApplication.getUiApplication().invokeLater(new Runnable()
         public void run() {
           Dialog.alert("This application requires an SD card to be present. Exiting application...");
 } else {
    dbLocation = "/SDCard/databases/TimeTracker/";
    // Create URI
    uriTracker = URI.create(dbLocation + DB_NAME);
    // Open or create a plain text database.  This will create the
    // directory and file defined by the URI (if they do not already exist).
    Database dbTracker = DatabaseFactory.openOrCreate(uriTracker);
    // Close the database in case it is blank and we need to write to the file

If the application starts with no SD card installed, the following message will appear and the application will close.

The else portion of the code above is responsible for open or create the database file.

Since the database is created on the first run, we need to create the table as well. The nice about using SQLite is that you can use SQL syntax (what a discovery!), which I know and have used a little bit in the past. The following method creates the table schema, and it will be called only once during the application life-time. At first I thought it would be easier to install the database file with all tables, but at the end, it is really much simpler make the application deal with its own database. It is easy during the first installation, and easier during eventual updates.

 public boolean createDBSchema() throws Exception
    Statement st = dbTracker.createStatement("CREATE TABLE IF NOT EXISTS " +
                                             "'tasks' ( " +
                                             " 'project' TEXT,  " +
                                             " 'notes' TEXT, " +
                                             " 'begin_date' INTEGER, " +
                                             " 'end_date' INTEGER " +
                                             " )" );


   return true;

The openDatabase method above just opens the database file using the dbTracker handler (see below). The Statement object is really simple to work with, and resembles me my old days using Visual Basic or Delphi.

public boolean openDatabase() throws Exception
   try {
      dbTracker =;
   }  catch ( Exception e ) {
      System.out.println( e.getMessage() );
      return false;
   return true;

Last but not least (I always wanted to use this cliché), I need a method that allows me to include data into the database. Everything is done using the INSERT SQL statement, like the following one:

INSERT INTO 'tasks' (project, notes, begin_date, end_date)
values ('Paint the house',  'Boring but necessary', 1295150379061,1295150407736)

The method to perform this task will basically take the parameters and put them together in a way to build a statement like the above:

public boolean saveData(TimeTrackerData data) throws Exception
	String stmt;

	stmt = "INSERT INTO 'tasks' (project, notes, begin_date, end_date VALUES (" +
				data.projectName +"'," +
				data.noteTask +"'," +
			    String.valueOf(data.beginDate) + "," +
			    String.valueOf(data.endDate) + ")";

	Statement st = dbTracker.createStatement(stmt);

	return true;

As you can see, I decided to create another class, just to keep the values that will be saved into the database. I believe this is a nicer approach because we don’t have to keep changing the saveData method signature. The TimerTrackerData is a class but it doesn’t do anything than keeping the table fields as class proprieties.

public class TimeTrackerData {
	String projectName;
	String noteTask;
	long beginDate;
	long endDate;

Finally, back to the main class (our UI), we have to call the proper methods from the database class to perform as expected.

private void saveDatabaseData()
	// save data to the database
	TimeTrackerData trackerData = new TimeTrackerData();
	trackerData.projectName = projectListField.getEditField().toString();
	trackerData.noteTask = notesField.getText();
	trackerData.beginDate = dateField.getDate();
	trackerData.endDate = System.currentTimeMillis();
	try {
	} catch (Exception e) {
		System.out.println( e.getMessage() );


It seems this make this simple application complete. If you want the full source code, follow me on Twitter ( and ask for it! I’ll be glad to send it to you. Or leave a comment here, too!

Leave a comment

The Mobile Experiment V – Storing data with SQLite API

Finally I managed to publish this new post. I’ve been busy this holidays, with very little time to write something useful.

If you look at the previous posts, you’ll see that our application are already able to allow user input. It comes the moment where the task you’re working on is done, and you press the Stop button:

At that time, besides the fact that the GUI has to be ready to start another project, the previous data has to be stored somewhere. You probably remember that we are using the PersistentStore to save our live data, so it is always possible to restore the previous state even after a reboot.

Now, when the project is done, the complete data must be stored somewhere else. Depending on this system is used, you could have dozens of projects records after a week, or month. It also must be easy to retrieve them to send by email (check here our application feature requirements).

Although a straight text file would do the job, I’ve decided using the built-in SQLite support that was added to the Blackberry OS since version 5.0. My decision was driven by the fact that this would be the best way to deal with data, even if the application functionality is expanded (present the saved data on screen, edit or deleted saved data, etc…).

You can find few samples and tutorials over the internet about SQLite and Blackberry. I’ve been using RIM’s SQLite Developer Guide to get almost all information I need. This sample code also gave me some interesting information.

The only caveat about this choice is that, to be compatible with all devices, I have to store the database in the SDCard only. Interestingly, the Bold and Storm series support using the internal memory for storage, but not the Torch. Therefore, you have to check what device your app is running to find the right place, or just use the SD card always, like I did.

If you are using the simulator to test your app, you’ll have to create a directory in any place on your computer disk, and tell the simulator to use that directory as SD card. To do so, open the simulator’s menu Simulate -> Change SD Card, click the Add Directory button, and select the desire place.

Another great advantage of using the simulated SD card, is that you can access the SQLite database using any desktop tool, allowing you to add data, create and modify tables, or even test SQL statements without having to run your application over and over.

Although I said “create and modify tables”, I’d suggest that you add the database schema creating in your application. It makes easy to create the database and tables when the application is run the first time.

After a deep research (aka googling for 10-secs), I found the excellent SQLite Expert, which has a free Personal edition that covered all my needs for basic SQL syntax testing, etc… There are other options as well, so you have plenty of choices.

In the next few days I’ll be posting the final article about SQLite with code samples. You can receive real-time updates following me on Twitter: mobicreator.

Leave a comment