Before we get into the subject of today's post a small public service announcement: we recently added the ability to create annual pro subscriptions. This provides a 10% discount over our standard pro subscription rates.
I'm writing this while preparing for my JavaZone flight. What you see in the picture on the right is the typical content of my backpack which I carry with me everywhere in case there is a problem I need to debug, this is somewhat of a visual tutorial of "what it takes" to be a mobile developer today. I took this picture for the JavaZone presentation I'm making and I think it illustrates well why Codename One exists (BTW it is missing some of my testing devices such as the iPad 2, the Android tablets and a few J2ME phones). From left to right top to bottom:
- Windows 8 Machine (for building Windows Phone apps)
- iPad 3 (retina - iOS 7 beta)
- Mac (for building iOS apps)
- Blackberry Z10 (BB OS 10)
- Nokia Asha (S40)
- iPod Touch (iOS 6)
- Nexus One (Gingerbread)
- Galaxy Nexus (Jelly Bean)
- Blackberry Torch (BB OS 6)
- Nokia Lumia 520 (Windows Phone 8)
Who said mobile development isn't back breaking work! And now for something completely different: On iOS the translation tool we use for converting bytecode to xcode applications is tuned for compatibility more than it is tuned for speed. This means that generated code performs a lot of null pointer checks (so it can throw a NullPointerException) and performs array boundary checks. Both of these effectively slow the execution of your application significantly. We now have a new build flag for iOS called:
ios.unsafe If you define that build argument as true:
ios.unsafe=true You will get an application that won't throw ArrayIndexOutOfBounds exceptions or NullPointerExceptions, however it might crash for such cases! This is one of those flags that you will need to test REALLY well before using in production, however once enabled it should drastically improve the performance of Codename One. Notice that some things are never tested by the translated code such as class cast exception etc. (so code that relies on those will just crash). We are now in the process of re-designing our iOS backend which includes some tough decisions regarding backend technology, our goals are:
- Shortening build times.
- Improved crash analysis .
- Faster execution.
- Improved graphics support.
Notice: This post was automatically converted using a script from an older blogging system. Some elements might not have come out as intended.... If that is the case please let us know via the comments section below.