Reading time: 4 – 6 minutes
Image by The GameWay
So I believe by my last posts here you may have guessed I’ve been doing lots of mobile development in the last few months.
It’s got nothing too do with work, as I do all of my mobile development on my spare time at home.
So what brought me to it?
I always felt like I was missing a big “piece of the cake” (which isn’t a lie btw) when seeing some of the people I relate to on a daily basis, talking about how cool mobile application development was.
Some things you can avoid, others you can only delay, and I know the latter was true in this case, but I was fighting really hard to let the laziness win.
Then came the Playbook, and RIM was offering to give one for each developer who successfully built and published an application for it before the launch of the device.
There was no way out this time. I love free stuff more than anything else, I’m one of those people who change their route when they know that if they pass through a certain place at a certain hour, there will be freebies being given. I queue for free bits of cheese at the supermarket *blush*.
So there I was, sitting in front of my computer with a trial copy of flash builder, and trying to make something I thought people would enjoy.
Then came the idea of building a Magic 8 Ball type thing (which later would have to be renamed and rebranded due to patent implications I wasn’t even aware of. But I’ll talk about this one on my next post).
In about 5 days and having no previous flex knowledge at all, but just some ActionScript, I had an application running on my simulator.
It was the coolest thing ever, it felt like the olden days of hacking through other people’s source code to steal get JavaScript ideas.
I then went to the pretty complicated challenging process of getting my app signed and approved.
Rim, the company behind the Playbook (and blackberry) was completely overflowed with approval requests, and it took them good 20+ days to actually get my application approved. I made the cut first time though, which made me quite proud, since it was my first appearance on the “mobile scene”.
Because it got me so excited about the whole thing, I had my second app (Time Traveller) approved even before the deadline before the launch was over. I built this very app several years ago in C, and used it a lot when I was travelling to help me get through the differences in timezones on the several countries in Europe I was going to. Except that this time, I built this one entirely using Rim’s Playbook Tablet SDK, which is optimized for the Playbook.
I then received my Playbook about 15 days after the US release, which meant I had it before it had been mentioned here in the UK. What a chick magnet that was 
Getting the Playbook only gave me more stamina to build my third app, so I started with Bonjour, which is a French learning application that teaches you by pronouncing the words, and encouraging you to repeat then. Pretty cool stuff IMO.
It might be just me, but you can’t build an app that teaches people French, without also building one that teaches people Italian. It’s just wrong! So I couldn’t help but building Ciao, which had exactly the same premise as Bonjour, but for the Italian language.
I put several hours in making sure the applications were useful and functional, and would attend the needs of all. For that reason, I made them available in 6 languages, so even if you can’t speak English, it’s very likely you will be able to speak either Spanish, Dutch, German, Portuguese, French or Italian.
You guessed right, I was very enthusiastic about the whole thing, and surely my mobile saga wouldn’t simply end here.
BUT I feel like I’ve already dragged this blog post for too long, so will continue my story on the next post, where I’ll be telling you what happened next, what patent problems I had with my Magic 8 Ball app, and what new apps I have released.
I will also talk about other markets, and what new applications I’m working on right now.
So stay tuned.
Reading time: 2 – 3 minutes
Here’s is something that got me scratching my head for a little while today while working on my new mobile application.
In my new application, I’ll be reading XML off various different providers, so I have an interface that gets implemented in various classes to make sure they all obey a certain contract, and I don’t need worry about what type they are (more on that later…)
With that in mind, I ended up implementing different logic on different classes since the XML returned will vary from provider to provider. I am using E4X to get the various information I need from the XML returned, and one of them would not work at all when selected.
I will put two XML examples here, and let you spot the difference:
var basket:XML = <foods> <fruit> <name>Apples</name> <name>Bananas</name> </fruit> </foods>; trace(basket..fruit.name[0])
And that should return “Apples”.
Nothing new here, now for the second example:
var basket:XML = <foods xmlns="http://www.w3.org/TR/html4/"> <fruit> <name>Apples</name> <name>Bananas</name> </fruit> </foods>; trace(basket..fruit.name[0])
At a first glance, I have to admit I was expecting apples as well, but to my surprise, I got… nothing…
It took me a while to to go look on the XML again, and then it hit me. This provider would give me XML with a namespace, and in order to read that with E4X, I would need to declare that namespace. There is absolutely nothing wrong with the code above, but it simply won’t find anything since you’re not declaring what the namespace is, and the compiler gets completely lost.
What you need to do is declare the namespace on the top of my code like so:
namespace items = "http://ns.imageshack.us/imginfo/7/"; use namespace items; trace(basket..fruit)
How you name it doesn’t matter, but it’s important that it’s unique, so in case you’re reading from multiple XML files on the same class, you should be using different names, otherwise you will get compiling errors.
Reading time: 1 – 2 minutes
This is just a quick example of how to add a background colour to a label control in AS3.
Most people don’t know, but the label component has a TextField inside of it. What that means is that you can basically use all of the available methods within the TextField in a label. Here’s an example of how to add a background colour to a label.
import fl.controls.Label; // If you were doing Playbook development // import qnx.ui.text.Label; var lblName:Label = new Label(); lblName.textField.background = true; lblName.textField.backgroundColor = 0xFFFFFF; addChild(lblName);
And that’s it. You now have a label with a white background. Seems pretty simple, but what is cool here, is the fact that your label can have pretty much the same behaviour as a text field, and you can modify it as you would in a text field.
Tags: actionscript 3, as3, playbook
Reading time: 2 – 4 minutes
As some of you might have noticed, I have been building some mobile applications lately on my spare time specifically for the Blackberry Playbook. They are mainly built in Adobe Air using Actionscript 3 and Blackberry’s Tablet SDK.
On my latest application, I have found the need for a database, as it needs to store lots of user input data. The first option that comes to mind is SQLite, as it’s very simple to integrate, and has native support.
I will show here an integration example, and focus on a caveat I found while trying to use it on a real device.
For starters, here are the classes you need to import on your main class:
import flash.data.SQLConnection; import flash.data.SQLStatement; import flash.filesystem.File;
I then create a method to initialize my database connection:
private var dbConnection:SQLConnection = new SQLConnection;
private function initDB():void{
var embededSessionDB:File = File.applicationDirectory.resolvePath("assets/db.sqlite");
var writeSessionDB:File = File.applicationStorageDirectory.resolvePath("assets/db.sqlite");
// If a writable DB doesn't exist, we then copy it into the app folder so it's writteable
if (!writeSessionDB.exists) {
embededSessionDB.copyTo(writeSessionDB);
}
var dbFile:File = writeSessionDB;
dbConnection.open(dbFile);
}
What is important to mention here, is that most people (myself being one of them) will be completely tempted to skip the bit where it copies the local file (coming from the application itself) into the local storage. Funnily enough, if you skip this step, when you test it locally, it will all work wonderfully, but when you deploy it into a real device (or even a simulator) nothing happens at all.
After some research, I found out that you need to be using the database from the local storage, and just like this is that you will have read and write permissions.
After getting that small “detour” out of the way, I can go on and write my first query against that database.
private function getWords(intTabID:int):Array{
var stmt:SQLStatement = new SQLStatement();
stmt.sqlConnection = dbConnection;
stmt.text = "SELECT key, word FROM WORDS WHERE category_id = (:wordID)";
stmt.parameters[':wordID'] = intTabID;
stmt.execute();
var result:Array = stmt.getResult().data;
return result;
}
And this will return a nice array with all my data from the SQLite database.
Reading time: 1 – 2 minutes
I’m building a new Blackberry Playbook app, and when starting to work with internationalization, I got stuck with a bug that wouldn’t go away. I’m pretty sure this won’t just affect just this kind of application, but anything that is built using Flash Builder and requires resource bundle files.
It’s a pretty common standard to name resource bundle files as *.properties, but it turns out Flash Builder ignores *.properties files when packaging, and you end up with an error like:
Error: Error #3003: File or directory does not exist.It actually took me quite a long time to figure that one out, since I was pretty sure the files were in the correct location. Changing the file extension to .prop did the trick, and now Flash Builder will package them successfully.
I believe there must be another way in Flash builder settings to make it not ignore *.properties files, but for the time being, simply renaming its extension will do.
Hope that helps someone in the future searching for this error.
Tags: Mobile Apps
Recent Comments