Archive for the ‘LWUIT’ Category

Converting property files to Android resource Xml with Groovy

Friday, July 9th, 2010

Converting J2me projects to Android. Wanted to convert property files to the android xml so decided to cobble together a bit of Groovy

The property file is something like this:

##general strings
menu=Menu
stop=Stop
back=Back
wait=Wait
search=Search
bb.nextmess=Click spacebar for next Question

Make sure you stick the property file name on the command line ….

import groovy.xml.MarkupBuilder

def writer = new StringWriter()
def xml = new MarkupBuilder(writer)

writer.append(’<?xml version=”1.0″ encoding=”utf-8″?>’)

xml.resources {

new File(args[0]).eachLine{line->

bits = line.tokenize(”=”)
try {
string(name:bits[0].trim(),bits[1].trim())

} catch (Exception e) {
//exceptions pah!
}

}

}

println writer.toString()

This give the output ….

<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name='menu'>Menu</string>
<string name='stop'>Stop</string>
<string name='back'>Back</string>
<string name='wait'>Wait</string>
<string name='search'>Search</string>
<string name='bb.nextmess'>Click spacebar for next Question</string>
</resources>

				

Real Android fragmentation in the wild.

Monday, January 4th, 2010

Lots of people have been banging on about Android fragmentation and that it is all going to end up like J2ME and we are all going to explode big splurge. I am pretty relaxed about this as fragmentation is just a fact of life in mobile – because we are dealing with consumer electronics after all – and to be honest it is just the natural state of things, look at all the browsers hacks people take for granted.

That said in creating the “VIP Call” app for Android I came across a real live fragmentation example and here it is:

VIP Call” depends on being able to access the Contacts on the phone via an intent like so:

Intent intent = new Intent(Intent.ACTION_PICK, People.CONTENT_URI);
startActivityForResult(intent, PICK_CONTACT);

and process the returned contact like so:

Uri contactData = data.getData();
Cursor c = activity.managedQuery(contactData, null, null, null, null);
if (c.moveToFirst()) {
String name = c.getString(c.getColumnIndexOrThrow(People.NAME));
String number = c.getString(c.getColumnIndex(”primary_phone”));
return new Vip(name,number);
} else {
return null;
}

This works fine in 1.5 and 1.6 but fails in > 2.0 – my Droid users were not happy.

Turns out the contacts API has been re-written pretty extensively for 2.x so that there is support for multiple accounts. What’s more it aint backwards compatible.

The solution – suggested by google – is to create a ContactsAccessor class that encapsulates the two different implementations. So the call to the Intent now looks like:

startActivityForResult(mContactAccessor.getPickContactIntent(), PICK_CONTACT_REQUEST);

I wont list the full solution here as Google have provided a full example solution in the android-business-card code.

I must say this bit of code in the solution gave me J2ME Vietnam-like flash backs:


/*
* Check the version of the SDK we are running on. Choose an
* implementation class designed for that version of the SDK.
*
* Unfortunately we have to use strings to represent the class
* names. If we used the conventional ContactAccessorSdk5.class.getName()
* syntax, we would get a ClassNotFoundException at runtime on pre-Eclair SDKs.
* Using the above syntax would force Dalvik to load the class and try to
* resolve references to all other classes it uses. Since the pre-Eclair
* does not have those classes, the loading of ContactAccessorSdk5 would fail.
*/
@SuppressWarnings(”deprecation”)
int sdkVersion = Integer.parseInt(Build.VERSION.SDK); // Cupcake style
if (sdkVersion < Build.VERSION_CODES.ECLAIR) {
className = “com.example.android.businesscard.ContactAccessorSdk3_4″;
} else {
className = “com.example.android.businesscard.ContactAccessorSdk5″;
}

Tis my own opinion that fragmentation in Android is going to be on a par with the fragmentation we find in the browser world rather than the J2ME experience. The major reason for this is that the Android OS is over the air upgradable – my G1 has already had about 3 upgrades – this was not possible in the J2ME giving us the long tail we know and love ;-) .

Layar Augmented Reality and Grails!!!

Friday, December 11th, 2009

Just for laughs I created www.splaterz.com which is a do-it-yourself augmented reality layer for the layar browser.  You can create you own points of interest and associated web links via browser and twitter client.  If I get time I will add Android client support.  

The server side code was created in Grails which was an utter joy from start to finish.   I went thru a number of interations adding twitter support, search and acegi authentication and it took about a day all told.  Big shout out to all the plugin developers, especially my mate Marc, who lives over the hill.  If I get time I will add iphone web client support using the iwebkit plugin I saw at the Groovy/Grails exchange this week.

To have a layer publish you must submit it to the Layar site.  Went through one iteration where they objected to an encoding error, but otherwise, pretty stress free.

For those of you wishing to create you own layer this site did did the job for me.  Cheers.

Finally, many thanks to @bookmeister  for testing and random posts.

Haven’t finished with this by any means but please have a play if you have time.

Picture 17

SwiftCapture makes the lwuit featured apps ..

Sunday, November 29th, 2009

SwiftCapture makes the lwuit featured apps web site from Sun.  

Featured apps

Google Dev Day

Friday, November 20th, 2009

Visited Google to play with some new Android devices.  Hadn’t really thought through the  new HTC Tattoo  which has a smaller  screen than the  G1 – 240×320.

HTC Tattoo

Swift for Blackberry

Friday, September 18th, 2009

We have been working hard on a Blackberry build for Swift. It is a tough development environment and was tricky to get the camera going. Here is a screen grab from the emulator.

blackberry-image

LWUIT DateField and other bits

Tuesday, June 23rd, 2009

We missed having a DateField in LWUIT, the Calendar is a great start but it looked a little strange on some phones and we needed something simpler, not to mention a time field.

To do this we extended the TextArea class to create our own MobrizDateField.  When the user clicks on this the system fires up a standard LCDUI form with a DateField on it (DateForm).  The user can then use the native time/date features of the phone to complete the date/time

To tell LWUIT to intercept the DateField calls  we extended the GameCanvasImplementation to create our own MobrizMidpImplementation.  This overrides the editString method and launches the DateForm if the MobrizDateField is being used. We needed a MobrizImplementationFactory to deliver this too.

To tell LWUIT to use the new MobrizMidpImplementation add the following to your code where you initailise the UI.


..
ImplementationFactory.setInstance(new MobrizImplementationFactory());
Display.init(this.mobrizMidlet);
..

Use the new MobrizDateField just like a TextArea:


..
MobrizDateField timeField = new MobrizDateField(dtLong + "", 10,MobrizDateField.TIME, "");
form.addComponent(timeField) ;
..

Things to note:

  • The MobrizDateField takes a string or a long expressed as a string in the constructor .. this is a bit crap but suited us for our app. you may want to change it match to LCDUI datefield exactly.
  • The MobrizDateField actually extends MobrizTextArea which is a TextArea that responds to any key press.

Would welcome any comments or improvments!!!

As ever this code is provided without warranty – user at you own risk.

Here is the source