Today I’d like to present two open source Java ME games recently released on Forum Nokia Projects. Both games are tested and so should work on both Series40 and Symbian devices supporting with CLDC 1.1 and MIDP 2.0.

BattleTank

Battle Tank is a classic tank game, and illustrates some of the basic concepts you could find when developing a game in Java ME as the usage of sprites, tiles and sound. The game is just a proof of concept, but you should definitely check it out if you want to learn the basics of game development.

Sudokumaster

A Java ME implementation of the classic Sudoku game. This project shows how to manage a dynamic layout for multiple screen resolutions, and how to use several input methods (key, touch, and key & touch). Check out the full source code here.

Other projects?

Do you have an open source game that you’d like to share with other Nokia developers? Let us know in the comment section below, we’d be glad to hear!

Recently named Forum Nokia Champion, Mario Zorz is an active mobile developer from Argentina, focusing his efforts on multiple technologies including Java ME, Web Runtime, Flash Lite and Qt. In this conversation Mario shares his recent mobile activities, including the open source Java ME framework “Prosciutto“, the WRT apps Crane.tv and Cual Es, and gives some really useful tips for all Nokia developers.

ND: Hi Mario, and welcome to Nokia Devs. Please tell us a bit about yourself.

Hi, thanks for inviting me to Nokia Devs. I like to define myself as a mobile technology enthusiast. I started programming computers at the age of 12 and have tasted almost every programming language or flavor that I came across with: BASIC, assembly language on 80×86 and IBM390, ANSI C, Pascal, C++, Python, Java, etc. I’ve been working with mobile technologies for more than 10 years now, having delivered both native and wap / mobile web applications on a myriad of devices and OSs ranging from the earliest versions of Palm OS and Windows CE, to Symbian, Nokia OS and so on.

In my professional career I’ve had the opportunity to work in almost all roles of the mobile ecosystem, developing and leading teams of developers in mobile startups, software factories, mobile content aggregators and launching WAP and mobile internet services while working at the largest local mobile operator as well. I’ve recently been named Forum Nokia Champion (2010). Nowadays I run my own mobile startup called GravityMakers with an old friend of mine. Our company website www.gravitymakers.com will be publicly available soon.

ND: Which platforms and technologies do you use for mobile development on Nokia devices?

Well the area where I developed my expertise is on J2ME and I mainly use my own open source framework Prosciutto to get the core functionalities all at once (i.e. showing stuff on the screen, images, text, connecting to a server and providing a smooth user experience all in one go) so I can focus on what the the application itself is required to do and build functionality on top of that.

I use any text editor for editing such as Notepad++ though I like SlickEdit the most, and use ant and antenna for streamlining my compiling, linking and building process. This kind of environment allows for editing client and server code all on the same IDE, which is something that happens a lot to me. I might be switching from writing J2ME java code to Prosciutto XML models to PHP or Python server-side scripts all the time, so I need an editor that can handle different languages syntaxes and be extremely configurable.

When working on other development platforms such as Nokia WRT I use Aptana Studio 2.0. And if we have to build prototypes to further refine the product spec with a customer, we use either Flowella (Forum Nokia’s design prototyping tool) or Prosciutto itself to build quick screen mocks.

I’m also doing Qt now for higher end devices, so I use the Qt Creator and Nokia Qt SDK for that.
And for testing, I think the single best resource for mobile development testing is Nokia’s Remote Device Access (RDA) as it provides most of the handsets our customers need to target and is at some point more reliable and quicker than testing on emulators.

ND: Do you remember which was your first app developed for a Nokia device?

Actually I had to think a little bit about this question, but yes, definitely! My first app developed for a Nokia device was a custom chat client – that was back in 2005/2006 and we were targeting devices such as the “all new” Nokia 3100 Series 40 device, which had a color screen on a relatively cheap handset. The chat would also run on other handsets as well, but the porting list was pretty much limited to some MIDP 1.0 devices and a bunch of MIDP 2.0 CLDC 1.0 devices. For the rest of them we’ve also written a WAP version of the chat application. We actually aimed at building a community around it and managed to get the chat as a service to be sold within a specific category in a local operator’s wap deck (a term that sounds old-fashioned, doesn’t it?). It was a very rewarding experience – to be able to write something from scratch on devices that were new to the market at that time, and see people actually catching up and using it.

ND: What is Prosciutto Project?

The Prosciutto Project is an open source framework built on JavaME that I created envisioning a mobile browser architecture that would run on virtually any device, hiding the complexities of device fragmentation which happens to be the single most challenging problem for any mobile application developer. That was the main motivation for building the framework, indeed.

This framework is sort of a widget engine: you write definitions in XML models and the engine will render and behave as indicated. I thought of this development model back in 2006 and started shaping it up until I decided it was mature enough to be released to open source, back in 2008.

Most of the common use cases you’d need in a mobile application can be written in Prosciutto XML models so you don’t even have to deal with Java code at all, but in case you need more complex or specific features, Prosciutto provides a set of callback functions too so you can add your custom code as well such as pre and post paint handlers or pre and post keypressed handlers, etc, thus extending the core functionality to whatever you need to build. I’ve also integrated the engine with Hecl, a scripting language similar to Tcl created by David Welton, so you can also write scripts and deliver them OTA and get them executed by the engine without the need to re-build the jad/jar pairs and redistribute, etc. Meaning, you could virtually add quite complex features on your installed user base by getting Prosciutto connect to your server and download the models and scripts, making it a seamless experience for the end user. This not only means a better user experience, but also lowers the costs of redistributing the application on virtually any major feature update on your app.

Prosciutto Palermo Valley Mobile Sessions – English

I use Prosciutto for my own commercial projects and keep enhancing the framework each time.

ND: Which were the biggest challenges, and the greatest goals achieved during its development?

Well, the biggest goal and challenge was to build an engine that is configurable enough as to build “anything you want” in a very small footprint as our main original target was low and mid-end handsets. Many of these handsets had MIDP 1.0 only (which is now pretty much non-sensical), or had a really low java heap memory limit (less than 300 kb), or even a small jar size limit (less than 64 kb).

Some of these devices also have poor garbage collecting strategies in order to be able to run lightweight JVMs (Java Virtual Machine) so creating and deleting java objects all the time was a showstopper. I decided to work on a strategy that would a) give me control of the heap memory footprint at any given point and b) reduce the final jar size as much as possible.

For a) the quick answer was to reserve buffers up-front upon the engine’s initialization and then re-use these buffers all through the run, to minimize garbage collection and thus reducing memory fragmentation. For b) I had to work on what I call “anti-OO approach” in the sense, reduce the amount of classes to a minimum as part of a set of jar-bloat reducing techniques, while trying to keep the code as elegant as possible within these circumstances. Using an obfuscator such as proguard helps a lot and is a must nowadays, but the fine-grained optimization you have to do it yourself.

I managed to get AES encryption (through the use of 3rd party libraries such as bouncycastle) for high security standards requirements and GZip compression for optimizing communication bandwidth and operator fees to run on these kind of devices by leveraging the concept of the “anti-OO approach” described above.

The very first stable version of Prosciutto had all of this in less than 63 kb final jar size, utilizing less than 200kb of heap memory at any point of a long run (i.e. 30 minute session which is fair enough for a mobile application of its kind).

Now, as hardware and JVMs evolved I was able to start refactoring and setting new levels of scalability in the engine. The simplest configuration of a Prosciutto based app weights around 90 kb nowadays, and can be up to 120 kb if you add encryption and OTA compression, as well as other JSRs such as MMAPI, etc.

ND: Can you show us an example of app developed with this framework?

One of my apps running on Prosciutto is a mobile ticketing app, which won the Americas first Forum Nokia Calling All Innovators contest (late 2008) and hit the 2nd runner place in the global contest held at Mobile World Congress in February, 2009 in Barcelona. The app has been produced jointly with my friends at Orugga and written for Ticketek, the largest sports and show ticket broker in Argentina, with headquarters in Australia and New Zealand. The main purpose of the app consists of the ability to browse categories (i.e. concerts, theatre, sport events, etc.), get information about the shows/events, purchase tickets while on the move using a credit card, and select the delivery method which could be any of the existing models (on printed paper) or even by delivering a barcode image in a special section called “my tickets”.
All of this using high level standards of encryption.

Here you can watch me describing the app in this nice video the guys at Forum Nokia Calling All Innovators shot when we had the opportunity to showcase the app in Barcelona:

A video of the latest version of the app with a nicer UI and touch screen support (which is already available in Prosciutto’s core) can be seen here:

That last video was shot running the app on a Symbian S60 5th edition remote device using Forum Nokia RDA service.

ND: “Crane TV” and “Cual Es?” are two WRT widgets that nicely integrate with video content. As from your experience, which are the biggest challenges when creating multimedia apps with WRT? Any hints for developers?

By the way, the Crane TV app has just been featured in Ovi Daily Apps, you can check the review here to learn what it’s all about.

Believe it or not, CraneTV actually was my first Nokia WRT application. I was a little bit uncertain at the time about choosing the technology as I was not completely sure which things were going to work nor how. I’ve been reading a lot at that time (August – September 2010) and everything indicated the best way to get a multimedia app running on Nokia touchscreen devices (S60 5th edition and Symbian^3 devices such as the N8) would be by using WRT.

I think the biggest concerns I have are always related on a top down approach on whether you’ll be able to accomplish the best UX on a given technology, then if every required feature is doable and which APIs and components you’ll need to build each one of them. In this particular case several factors were in place: I had to use WRT, FlashLite for video playing per se, and the API bridge for geo location (for the “videos near me” functionality) and file upload (as the app lets you send pictures to Crane’s server). Also the Nokia N8 was one of the targeted devices and I didn’t even have one with me at the time of developing. Fortunately the guys at Forum Nokia were very helpful in all aspects and helped out with code snippets and comments, not to mention they quickly added the N8 in RDA service (even before it was launched) so I was able to test stuff on it as well.

As of WRT itself, given it’s based on HTML/CSS/JavaScript, you’ll not only find lots of information in Forum Nokia itself, but also there’s plenty of documentation in the web in general if you’re not very used to writing javascript apps – as I myself was at the beginning of the development phase.

In WRT you have the ability to use different javascript libraries such as jQuery and Guarana, the latter one being specifically targeted at Nokia WRT. Even if you can use the Nokia UIKit for WRT I chose to use Guarana as I liked the UI controls and the way it’s implemented in terms of the ViewManager. A good place to start for any developer is the Guarana podcast example application in Forum Nokia wiki.

Also, Flowella is great for refining the specs further before you actually start throwing code. The tool allows you to work on the screens layout, navigation from screen to screen, so you can just have your graphic design people do some mocks (or even up to the final layout and look and feel) and have the screen navigation flow designed in Flowella, plus it allows you to export the flow as a widget and run it on a real phone, which is as near as you can get to showing something to your customer and agree upon what’s going to be built without having to deal with amounts of disposable demo coding.

Finally, and this is not only applicable to WRT but to any technology, My advice to other developers is test everything on as many devices as possible. Some of the code you write just doesn’t behave the same when moving from one phone to another, or even if the code runs correctly, sometimes the UI layout is differently handled when you use your fingers (i.e. on capacitive screens such as the N8’s) or a stylus (i.e. as in the very popular Nokia 5800 XpressMusic). Some good usability and design guidelines applicable to Nokia WRT widgets can be found here and also here.

Regarding the “Cual Es?” application, technically it’s quite similar (as in challenges in development) to what I experienced with Crane: both are applications that need be prepared to be used by several thousands of users on different handsets on different networks, so you have to take these challenges in mind to minimize network usage and leverage the best user experience possible in different conditions. My take on that was to try and download categories and video listings up-front, when the user is commonly OK with waiting for an initialization process, and be very careful in recommending the right video specs for the guys at the backend to produce videos accordingly. Robert Burdick from Forum Nokia Americas was extremely helpful on that and the Flash Lite part as well.

Here’s the little extra catch for “Cual Es?”: apart from using an ad hoc XML structure for client-server communication (as opposed to JSON as used in Crane), they needed to track video playing for stats on their side using Google Analytics, and really there wasn’t anything like that for WRT at the time we were designing the application.
Thanks to the internet, places like Forum Nokia, and people like jappit (have you heard of him before? :p), shortly after development begun I found the Google Analytics for WRT open source library. I just took that and added the ability to track pageviews to the existing ability to track events – this was a requirement from the guys at “Cual Es?” as they needed to be able to compare regular pageviews on www.cuales.fm with the “pageviews” coming from the mobile app.

ND: You have used API Bridge in your widgets: what’s your impression about it?

Well the API Bridge gives you a lot of functionality right at the tip of your coding fingers by exposing core handset functionalities on JavaScript – so the very first impression is that “this thing is cool”. But there are some drawbacks to it, namely the API bridge is implemented through a native Symbian application that needs to be installed on your user’s phone before you can actually call the APIs.

So your options are: you can package everything in one .sisx file – which is a process in which you need to know a little bit more about Symbian, unless it’s not hard it’s not trivial either. On the other hand you can just check if the API bridge is installed – in runtime, and if it’s not, kindly exit your widget and ask the user to download the API bridge standalone application from somewhere in the internet, most probably a host you own. For the sake of simplicity, and given that in the future most Nokia phones will have the API bridge preinstalled, I recommend doing the latter one. Just please note that it is not the best option from a user experience point of view, but I found it to be quite OK for most cases, and it saves you having to deal with Symbian packaging.

Once you have the API bridge up and running, the shipped plug-ins provide features for: uploading files, capturing video, image and audio, reading files, resizing images, creating image thumbnails, using the logging service, using the location service, using the media management service and sending DTMF tones in an active call.
So as you can imagine, this is like an army knife in terms of the possibilities the API bridge opens to your widget application.

Some good resources I found regarding the API bridge deployment process itself have been written by Alessandro La Rosa on Forum Nokia.

And for API bridge and WRT in general, start here.

ND: What do you think about the Nokia offerings for developers? Anything you’d like to change or improve?

To me, Forum Nokia has been and still is the single best mobile developer community around. The kind of support in terms of documentation, help, and anything else you can imagine, is most probably already there. As a matter of fact I do my research there before starting anywhere else.
I haven’t found any other vendor with the same level of support to its developers.

As to technologies: you can choose among different technologies supported on the same handset which is good to some extent. For example, I could have chosen Java ME over WRT to build Crane or Cual Es. Or I could have gone with Flash Lite entirely. So it’s good to have choices, but there’s risks that you don’t fulfill everyone’s needs by doing that.

Because of that, I think it’s good that Nokia is aligning efforts to have Qt as the platform of choice. Having done just some exercises on Qt, I can say that it’s extremely easy to use and build apps on Qt. And if you come from WRT or even the web in general, well you have Qt Quick and QML which is basically javascript. Amazingly enough, it runs fast, and is far easier to code than C++ for most people.

What I do have to say though, is that developers would feel much more comfortable if we saw a clear roadmap down the line. In the last 3-4 years we had native Symbian support on Symbian devices, and JavaME, then Flash Lite, then WRT, now Qt. It’s difficult to catch up with new stuff and even more once you’ve passed the learning curve and mastered a couple of technologies. You want your time to be valued.

ND: Something else you’d like to tell to Nokia developers?

Be active. Share your knowledge with others. Ask and answer questions in Forum Nokia. Test everything you do on as many phones as you can – if not all. And focus efforts on user experience when thinking of your next app, and I’m sure it’ll be a killer app.

After a long pause, Nokia Devs is back with new conversations, featuring Nokia developers from all around the globe.

Today Matt Harney, a mobile developer from Bangkok, shares with the Nokia Devs’ readers his experience with Java ME and his thoughts about his latest app: Carpe Diem.

ND: Welcome Matt, please tell us a bit about yourself.

Well I’m a self taught developer from a games industry background. I’ve been an animator, game developer and programmer for over 10 years and have worked on most consoles and handsets. I am currently based in Bangkok and working on Unity3D and mobile freelance contracts.

ND: Which platforms and technologies do you use for mobile development on Nokia devices?

I really love Netbeans – I think its the best IDE I’ve ever used. The only let down in the chain is really the Nokia emulators – they work but just don’t compare with the speed and quality of the Apple stuff. But with Netbeans, Java ME, LWUIT, the s60 emulator and a bunch of handsets it still fun to make a mobile app.

ND: As a Java ME developer, which are the main benefits and difficulties you find in using this technology?

Java is a great language to work with as I find it feels soft and pliable. It’s a bit like sculpting an application in clay. Java is really fast to work with and has a great debugger ( if a little slow ).

Also, the way it handles phone hardware, multithreading and the libraries and help available are awesome. But then you are always at the mercy of Nokia and how the JVM is implemented.

ND: How do you see the Java ME offering by Nokia? Which improvements and changes should Nokia bring to its Java ME support?

To be honest I stayed away form the Nokia specific Java stuff – and for my last application I didn’t need anything not supported by the general S60 platform. In terms of general java implementation from Nokia the performance really needs to be improved. For instance reading from the camera, updating a screen because of an orientation rotation or just reading and writing a file are still very slow. Also the security settings and how java treats the data connection is a little shallow – for instance its hard to say ‘Only connect via Wifi’. But apart from this Java is a robust solution for developing a Nokia app.

ND: Let’s talk about your Java ME app: Carpe Diem. Can you describe it, and the main difficulties you had during the development process?

Carpe Diem is a daily ‘todo’ – every day you are given a simple task to complete which makes your life and those around you more wholesome. So every day you complete a task with a photo, video or text to then share this with the community. You can see from your handset or the web what everybody else has uploaded and how they approached the tasks. Once you completed a task you can tweet about it from the app, and upload to the web for posting to Facebook. The 365 tasks included in the app are really fun and were written by a project called ‘The School of Life’ and ‘Wiedens&Kennedy‘. I developed the app under contract from the digital production house ‘Specialmoves’.

The main difficulties I had with the app was in implementing the custom UI – for this I needed pixel perfect screen designs and custom fonts across a range of handsets. To help out here I used the LWUIT framework. Other problems I had is with the camera control – always a nightmare when using the camera for photo, video and playback on a slow handset. Oh and I had many headaches trying to solve all the cases when the app tried to connect to the webservices but the user had either disallowed the security pass, or had simply moved out of wifi or cellular coverage.

ND: Why did you choose Java ME to implement your app?

I needed to get into the Ovi Store, and needed to support multiple handsets with camera, video and file storage. And I needed to get something up and running quickly, so from my experience JavaME just made sense. I thought JavaME would have allow Facebook API integration too, but officially it doesn’t

ND: Have you distributed Carpe Diem through the Ovi Store? What’s your impression about it?

My initial impressions are good – its not as slick as the Appstore but much better than the Android Marketplace. Submission is fairly painless, the only requirement for it was Java Verified gained by paying an external testing house. I used Bable Media and they were very good, helping me through the basic, common errors.

ND: Concluding, how do you see Java ME in the long run, compared to other currently emerging mobile technologies?

Well, there is a long legacy of old handsets across the world out there – and Java is the great way to target them. But at the same time if you want to do something with a custom interface the Flash Lite can support most handsets and most features and can be a much faster way to develop a rich application.

ND: Something else you’d like to tell to Nokia developers?

Be kind to your handsets! I trashed 2 developing this project! A new N97 and a 5800XM just stopped working after being blitzed with Java too much. On a technical note also be careful of how much data goes into and out of your app, for instance I had many kb’s of video’s being uploaded, downloaded and saved to the RMS store and this really kills the user experience.