What Features Would You Like To See In 1.1

We are already gearing to close 1.0 and are looking at the features we would like to get into 1.1 currently slated for May 2013. In that spirit we would love if you would take a few minutes to answer this quick survey.

Test It

One of the common questions we get for Codename One is regarding testability. Cross platform frameworks are notoriously hard to auto-test and so fail when you try to build more complex applications.
We see this as one of the most important areas in which we can innovate and leapfrog native OS environments by offering testing that is just as cross platform as Codename One is. We aren't just announcing our own unit testing API, we are announcing a fully integrated test recorder to auto-generate GUI tests for your applications and run them on the simulator.

We will also integrate this exact same testing framework into our build server to seamlessly test device support for you in the future.

In the video above you can see me going through the process of recording a test for the kitchen sink and then running it in the simulator.

I'm sure I'm going to get this question so I'll hit it right now before it comes up. No the tests are not JUnit compatible and we haven't used another well known testing framework. The main logic behind this is that tools such as JUnit rely on reflection to work since they use annotations or method invocation without an interface. This doesn't mesh well with Codename One's device targets so we chose to implement something of our own.
You would have to write most of the test cases for Codename One anyway since the API/functionality would be pretty different.

Codename One Benchmarked With Amazing Results

Steve Hannah who ported Codename One to Avian has just completed a set of benchmarks on Codename One's iOS performance putting Codename One's at 33% slower performance than native C and faster performance than Objective-C!
I won't spoil his research results so please read his full post here.

A small disclaimer is that the Objective-C benchmark is a bit heavy on the method/message calls which biases the benchmark in our favor. Method invocations in Codename One are naturally much faster than the equivalent Objective-C code due to the semantics of that language.

Fonts Revisited

Fonts are were a painful subject in Codename One, historically devices supported a very limited set of fonts and we were bound by said limitations. However, devices moved forward and finally we too can move forward to more reasonable font support.

The new font API is limited to Android & iOS, we were considering RIM support too but it seems that the font support on RIM is too limited for our needs (feel free to correct me if I'm wrong here), on the other platforms a standard system font will be used where fonts aren't supported.

In order to use a font just add the ttf file into the src directory, notice that the file must have the ".ttf" extension otherwise the build server won't be able to recognize the file as a font and set it up accordingly (devices need fonts to be defined in very specific ways). Once you do that you can use the font from code or from the theme.

In the theme section of the Codename One designer you now have the option to define the font like this:

The system font will be used where True Type fonts aren't supported, the size of the font can be one of 5 options.
Small, medium & large correspond to the 3 system font sizes and occupy the exact same sizes of the system fonts.
Millimeters & pixels will size the fonts appropriately using the numeric field.

To use fonts from code just use:
        if(Font.isTrueTypeFileSupported()) {
            Font myFont = Font.createTrueTypeFont(fontName, fontFileName);
            myFont = myFont.derive(sizeInPixels, Font.STYLE_PLAIN);
            // do something with the font
        }
Notice that in code only pixel sizes are supported so its up to you to decide how to convert that. You also need to derive the font with the proper size unless you want a 0 sized font which probably isn't very useful.
The font name is the difficult bit, iOS requires the name of the font which doesn't always correlate to the file name in order to load the font, its sometimes viewable within a font viewer but isn't always intuitive so be sure to test that on the device to make sure you got it right.

Cloud Storage, Cloud Bind(tm), iPhone 5 simulator, barcodes and much more

We just made a major update including a pile of fixes and features. One of the biggest things we are launching right now is an early preview of our new Cloud Storage and Cloud Bind (tm) solutions.

Cloud Storage allows you to effectively use our cloud as a big object database, similar to other big data solutions as a sort of key/value pair lookup engine that allows you to share/sync between devices.
The Cloud Bind (tm) solution allows you to seamlessly bind components such as lists, text components etc. to the cloud where changes automatically persist to the Cloud Storage and data is automatically fetched from there.

These are currently limited only to pro users mostly because we haven't yet figured out the free quotas we want to allocate for free/basic users. We will publish more tutorials and information when we have this fleshed out.

We also added an iPhone 5 simulator skin allowing you to generate iPhone 5 resolution screenshots.

And we finally added a bar code/qr code reader API. However, this wasn't as easy as one would suspect. The problem is that ZXing our API of choice for the QR code in the demo, doesn't do barcodes on iOS... So we had to use a different implementation on iOS which might not be as good as ZXing with QR codes. So the old native approach will still work if you want it too, but you don't have to because we have a much simpler API.


There is allot more coming in the next couple of months... Stay tuned.

Detect EDT Violations

One of the hardest ideas for developers to grasp in Codename One (or GUI programming in general) is the idea of a single event dispatch thread (EDT). The rules of using it and releasing it are sometimes complex and mistakes are very easy to make e.g.:

• Writing complex/slow code that blocks the EDT thus slowing the entire application
• Accessing Codename One widgets from a thread that isn't the EDT.

The problem is that both of these issues are notoriously hard to catch on  the simulator but often crop up on the device where race conditions can happen more easily and slow EDT performance is more noticeable.

To ease the process of detecting these violations we added a flag to the simulator allowing you to receive information about such cases.  When using light debugging you will see printouts to the console when accessing the EDT from a separate thread or taking too long to perform the task on the EDT. When setting it to full you will also see the stack trace where the violation was detected.

These tools aren't perfect and they sometimes printout warnings that are unwarranted while entirely missing a real violation. However they can be a valuable tool in improving your application's portability and responsiveness on multiple devices when used consciously.

Screen Capture of Our Java One Session

For those of you unable to attend JavaOne this year, you can check out the full video of our session here. You don't actually see me but you can hear me talk and see the slides/demos since the feed from the projector was recorded.
Apple wiped my iPad the day before with a stupid iOS 6 beta bug and my version of the demo had some bugs in it, but other than that I'm pretty happy with the presentation.
Check it out.

Installing On A Windows Phone Device

We recently added Windows Phone support to Codename One, this allows you to build your applications as a Windows XAP application for installation on a Windows Phone device. Unfortunately of all the platforms we support (including J2ME and iOS) MS is the only company that chose not to allow standard OTA distribution so you will literally need a PC in order to install the application with a cable.

MS has a sort of beta distribution option which might alleviate the problem but we didn't get a chance to try it out.

Sending a build for Windows Phone is similar to sending it to any other platform, with the latest distribution just right click and send a build for Windows Phone, its just that simple.
Unlike most other platforms MS didn't burden us with the silly need to sign the distribution (they can sign it themselves when we upload to the store, makes MUCH more sense!).

Installing said build requires that you enable your device for development for which you need to pay Microsoft. The instructions for doing all of this are all here.

[Survey] Developer Economics 2013: Best practices for app development & marketing

This is a guest post from Andreas Pappas from Vision Mobile, I'm posting this at their request since I think our community can both help them in their research and benefit a great deal from reading the results!
Shai.

As we launch the Developer Economics 2013 online survey, Senior Analyst Andreas Pappas introduces Developer Economics 2013, the fourth in our series of developer research reports. This time we're benchmarking the building blocks of the app economy, from analytics tools to voice APIs. Join us in Developer Economics 2013, take our online survey and win great prizes.

Back in June 2012 we launched Developer Economics 2012, the third in our series of reports that focused on app ecosystems, developer segmentation, platform economics and global app trade routes.

Today we are embarking on the evolution of our developer research: Developer Economics 2013 focuses on the best practices for the tools, services and APIs that developers use to build, market and monetise their apps. Take the survey, have your say on your favourite tools and win prizes, including an iPhone 5 and a Samsung Galaxy SIII. The survey will soon be available in Chinese, Russian, German, French, Spanish, Korean. Developer Economics 2013 is sponsored by AT&T, Mozilla, Nokia, BrightCove, BlackBerry and Telefonica.

A service economy develops around app ecosystems

The mobile development landscape has undergone a massive transformation since the early days of the iOS and Android platforms. In the early stages developers faced a limited supply of tools and services to assist them with crossing platforms, beautifying the UI, bridging fragmentation, integrating with ad networks or analysing user behaviour. They had to create most of the building blocks from scratch using their own means.

As mobile application development continues its growth from 100,000s to millions of apps, the rush for gold has sparked a rush for spades. Across the developer journey, there is now a tool for (almost) every developer need, from app testing to ratings management. The app economy is evolving towards a service economy where developers can pick from a range of tools and services to assist them along the plan - develop - market journey. But best practices are yet far from clear.

Third-party developer services, ranging from user analytics, location APIs, bug-tracking tools, app-store optimisation services, and cross-promotion networks are, today, vying for mindshare among developers. Developer Economics 2013 aims to identify the most popular developer services among these and measure their Developer Mindshare. Furthermore we aim to understand the reasons developers choose the services they do and how they rate them across range of key performance indicators (KPIs), such as reliability, availability across platforms and ease of integration within an app.

The right tools for building an app business

Developer Economics 2013 is benchmarking best practices in a variety of developer tools sectors:

Ad Networks	AdColony AdMarvel AdMob AdWhirl Airpush	Apple (iAd) Burstly Fiksu Flurry InMobi	Inneractive JumpTap Lead Bolt MillenialMedia mOcean Mobile	MobClix Nexage mopub Smaato warp.ly
Back-End as a Service	ACS Applicasa Apstrata Buddy CloudMine	CloudyRec Deployd FeedHenry iKnode Kinvey	kumulos mobDB Parse ScottyApp sencha.io	StackMob Usergrid (Apigee) Trestle (Flurry) QuickBlox
Bug Tracking	Airbreak Apphance	BugSense Crashlytics	Crittercism Hockey App	TestFlight Usermetrix
Cross-Platform Tools	Adobe AIR Appcelerator AppMobi Brightcove	Corona Marmalade Mono	MoSync PhoneGap Qt	RunRev Sencha Unity
Cross-Promo Networks	adDash AdDuplex AppCircle (Flurry) Applifier AppFlood (Papaya)	Chartboost clashmedia Fiksu G6Pay	GreatPlay Network Jampp maudau RevMob	SponsorPay Tapjoy W3i Wavex (6waves)
User Analytics	Apsalar Bango Distimo	Flurry Google Localytics	MobClix mopapp	Testflight Live (Burstly) UserMetrix
Voice Services	AT&T Deutsche Telecom FonYou GetVocal HarQen	Hoiio Ifbyphone IOVOX Jaduka Microsoft	OneAPI Sendflow Skype Telefonica Teleku	TringMe Tropo Twilio Verizon Vivox

Which tool should you use and which one should you trust?

These sectors are becoming increasingly crowded with new entrants while merger & acquisition activity is changing the landscape almost on a monthly basis. The tools and services benchmarked in this survey are becoming the building blocks of modern apps and Developer Economics 2013 aims to establish best practices for the key developer tools sectors across the developer journey.

Developers are often at a loss when it comes to selecting the right tool or partner among the hundreds of services available to them. Cost is just one variable in the selection process but quite often, it is not the most crucial. The reliability of a service, the regional reach, key metrics (such as eCPM or fill rates), as well as the flexibility to adapt to the developer’s needs are sometimes more important than cost, particularly when developers invest time, money and resources to integrate a third-party service with their apps.

Developer Economics 2013 aims to assist developers with the selection process by benchmarking a number of third-party tools and services across a range of KPIs.

We are also helping third-party tool and service providers receive valuable information on how developer rate their services and their key decision criteria when selecting a service. If you're a tools vendor being benchmarked, now is the time to spread the word to your developers.

If you are a developer your input into this research is very valuable to us and we’d like to invite you to take the survey.

Feedback welcome, as always
- Andreas

Apply Code Changes (Edit & Continue)

One of the cool things in HTML development is the ability to just instantly reload and see your changes, its countered by lack of static typing and a proper compiler but the time saving is still pretty great.

Java has had something similar for years, in Netbeans its called Apply Code Changes and Eclipse has a similar feature which is even more seamless... Just change the code and apply the change. It just works and you don't need to rebuild and restart from scratch.
This is remarkably helpful during long debugging sessions where you step over a break point and think: "what if this line was X"... Now you can just  try that instantly.

Many J2ME/EE developers aren't familiar with this feature due to the emulator environment or complex EE deployment scenarios, but to me personally this is a remarkably helpful feature especially when tracking issues in the Codename One Designer but also within our Codename One applications.

I would like to apologize for the delay between posts, I will try to get back into the posting groove within the next few weeks as we recover from Java One.

Windowzing It

We've been going around saying we have a version for Windows Phone for quite some time now. We had code contribution from Telmap showing that this can be done (and was accomplished commercially) so we relied on that contribution for our Windows Phone support assumptions.
(BTW I would like to thank Telmap again for this great contribution and Eric Coolman who contributed the Lumia skin!)
However, when I stepped up to implement the Windows Phone 7.x support I was shocked at how difficult MS has made the process of building applications for their platform. This took quite allot of effort and some compromises to get working reasonably well, but I'm happy to say that we now have a Windows Phone port of Codename One. We are still defining this as a Technology preview since many things don't work at the moment of this writing, but the "heavy lifting" of creating a Windows Phone application and running most of the kitchen sink demo is working.
The process of using the simulator/sending a build to the server and getting a result is all working.

We will include this full process as part of our next plugin update which we will try to release during or immediately after Java One!

One thing that ANNOYINGLY doesn't work is OTA (over the air) install. MS chose to disable this basic functionality which is even available on iOS (although not well known), they have their own beta solution but its cumbersome even when compared to the iOS approach. So currently the only way to actually install the resulting builds is via download and using the MS supplied tools to unlock your device then sideloading them using the MS tools. Ugh.
There are two alternatives which I didn't get to explore, one is jailbreaking and the other is the beta test mechanism from MS. Both seem to have their issues but whatever works...

The approach we took to our implementation was Silverlight/XNA mixing which is only available with Windows Phone 7.1 (Mango) or newer. It effectively uses the hardware accelerated XNA gaming engine to render all the UI but uses the highly visual silverlight scenegraph to render fonts and native widgets (text input etc.).  This approach is quite ambitious but we think it carries with it a great deal of value in terms of performance and extensibility. However since MS chose to change a great deal of their implementation API when going into WindowsRT we will need to play catchup once their platform is available.


Moving forward we still have a great deal of missing functionality in this port but most of it should be trivial to implement in comparison. We are opening the servers for builds now even though basic stuff still isn't implemented (e.g. Networking, Storage, FS, Video etc.) but we want feedback and contribution as early on as possible in the spirit of Open Source.
One of the main things we need to work on is integrating the new Windows UI (formerly Metro) in our platform so it will feel integrated.

Start Making Money With Codename One

We just integrated support for StartApp which allows you to get paid for every download on Android devices. Its a compelling monetization solution that works well with other solutions such as full screen ads (vserv) and banner ads.
StartApp installs an alternative search module on the Android device which your users don't have to use, you will be paid for the download not for the usage of the search feature.

To learn more about how you can integrate StartApp in your application please go to our monetization guide for StartApp.

We will soon bring out additional monetization services including a very exciting option for Android developers that claims they will allow you to make 10 times more money than any other network using their solution.

Watch It In The Simulator

The Codename One simulator now features new support for native browsing and video when running under JDK 7 update 6 or newer. Oracle FINALLY added native video playback into the JDK and a native browser support which means we can now integrate it into our simulator and bring it to you.
We still support older JDK's for debugging and development but you won't get video playback and you will have to use our legacy HTMLComponent on those platforms.

Announcing The Codename One/vserv.mobi Partnership

We are thrilled to announce a (non-exclusive) partnership we just signed with vserv (see their take on it here).

This partnership allows developers to instantly monetize their apps via highly effective full screen ads without writing a single line of code. These ads work seamlessly for all platforms and provide good fill rates for developers.

For more information you can check out our press release and integration guide.

Here is a short developer FAQ please feel free to ask relevant questions in the comments bellow:

Q: Does this mean I have to use vserv ads?

A: No.


Q: Can I use a competing ad network with Codename One?

A: Yes we make no restriction.


Q: Does payment go through Codename One or does Codename One take a commission from my developer payout?

A: No. You get paid directly by vserv at the same or better rates that you would get using their existing tools.


Q: What would happen to the existing Inneractive integration and what about future ad networks?

A: We still support other networks and intend to add even more choice. Part of our agreement with vserv includes setting vserv as the default and main ad network we work with. However, we believe in giving developers choice. Having said that we feel that vserv currently has a very strong value proposition for many of our developers and we are seeing pretty good results so far.

Find It In Codename One

The newest Codename One demo/theme is the mapper theme showing off our cross platform mapping support as well as a flashy new theme that adapts well to both phone and tablet form factors without too much of a hassle.

This theme joins the list of themes that we are publishing to help you get started with building cool Codename One applications that can compete on look with the top-tier apps on the various markets.

Social Boo Demo

A major crowd favorite: the social boo demo is landing soon. The theme and demo includes seamless adaptations for the tablet form factor and other niceties. Its effectively a partial demo since the source material was missing some UI tabs but its still a pretty great theme.

There are many ideas embedded within the theme and demo which you can quickly pick up and start working with:

1. Resizeable tileable multi-layered splash screen that seamlessly adapts to all resolutions.
2. Tablet landscape/portrait mode where a side element in a master-detail structure is automatically hidden in a menu when in portrait.
3. Rounded corners in images using the image mask API which we now integrated almost seamlessly into the Codename One designer.

Click any of the images to see the full size image.

Chrome - Your top choice is now live

We just finished creating the Chrome demo and are working on updating the demos etc. with the new theme. We also have a brand new "new application wizard" in the NetBeans plugin (coming soon to Eclipse as well) which allows more elaborate starting point for your applications.

The Chrome demo took me less than a day to adapt and it works pretty well for all devices.

You can click the images to enlarge.

The Chrome theme isn't yet integrated into the New Application wizard at the moment but this will be landing with the next update!

Vegan Leather Coming To Codename One

Thanks for voting on your favorite themes, we are already hard at work incorporating the first theme into Codename One. In the meantime we also licensed the Pandora theme through design modo, from which we just completed the first extraction: the Leather theme.

This is a heavily textured theme that is strictly designed for smartphones (2mb in size), its worth it to create a remarkably immersive experience.

This theme will be integrated in our upcoming update coming your way soon. There are many subtleties within the theme from the textured backgrounds to the drop shadows and the tab behavior. Check out the additional screenshots bellow.

Vote for your favorite theme!

We have just licensed some of the wonderful themes from the gorgeous app design vault.

We are working on creating demo applications/templates based on these themes so you guys will be able to leverage them in creating world class user interfaces based around these themes.

In order to accomplish this we need your help...

We need to decide which are the most important themes/apps you would want to see us tackle first.

Currently the main contenders are:

• Sportscast
• Foodly
• Blogplex
• Chrome
• Gridlocked
• Mapper
• Photoly
• SocialBoo

We have some of our own preferences/priorities but I would very much like to hear your opinions or if you think we missed an important theme from there (use the comments for that). If you like them all and don't have a strong opinion don't vote! If you do have a strong opinion about some of the themes then vote for them and we will priorities accordingly.

Use the poll to the right of this blog vote.

Amazing Week And Growth

We are undergoing serious growth this week and just in time with the introduction of Java 5 language features support and the progress we are making. We just got featured by quite allot of publications, check out our new press page. But probably more important is getting on the front page of hacker news... The comments there were pretty awful (as they usually are) but our traffic went through the roof and allot of it is actionable (people signing up and actually trying).

We know not everything is chocolate and roses about Codename One but we are working hard on making it perfect and need your help. Please complain.
When things don't work or don't look like you would expect let us know, we might dismiss it at first but when we get the complaint from multiple sources we realize that we need to improve.

We already know about quite a few things we need to fix and wrote about them in the past, the beauty of Codename One is its open source nature and the fact that you guys can help us get better.

We highly appreciate the effort that goes into formalizing constructive criticism of our current implementation and the suggestions to fix them. We take all such complaints seriously but with our limited resources some take more time to address than others and for that we apologize. We try to be as transparent as possible both with the code and our decision making process, I feel that even as we grow as a company we will try to personally address the issues and pains bothering you.

Thank you.

PS. We were in a Java development conference for the past couple of days so we didn't have much time to make a release. We will try to make a new release early next week.

Java 5 Support And Crash Protection Have Landed

We just released an updated NetBeans plugin (Eclipse coming soon) yesterday, it includes one of the bigger changes yet to our architecture: Support for a subset of Java 5.

This effectively means we will enable you to use a large portion of java.util's collections as well as generics, enums, for-each and many other features of Java 5 as part of building an application that will still work on RIM/J2ME devices (and obviously iPhone, Android etc.).

This support is complicated and isn't without its faults/limitations, I ran into some issues with anonymous inner classes that aren't recognized by the bytecode processor. We are working on resolving these but it isn't trivial.

To use Java 5 features you will need to either create a new Codename One project or copy the CLDC jar from a new project to your current project and update the source level in the project properties. You will also need to copy the build XML from a new project to replace your existing build.xml.

Additionally we now have builtin crash-protection support available for paying users (we limit this to paying users due to cloud server costs). You can use the crash-protection code by using something like this:

Log.setReportingLevel(Log.REPORTING_DEBUG);
DefaultCrashReporter.init(true, 2);

This will effectively check every two minutes if there is a change to your log data and if so send it to the server which will email you a link with the log content. Alternatively you can use Log.REPORTING_PRODUCTION to indicate that you only want the log when explicitly sent or with uncaught exceptions. A log can be sent using the Log.sendLog() method.

In order to write information to the log one needs to use the API Log.p(String) or Log.e(Throwable) etc.

Most mobile platforms don't support great Java features like printStackTrace(OutputStream), even those that do (well done Android) don't work well with obfuscated code.

That is why we allow the "crash_protect=true" build argument (again works only for paying users) this will effectively allow a form of poor mans stack traces that work well on all devices even with obfuscated binaries.

We call them "poor mans stack traces" because they don't provide the accuracy and detail of the "real" java stack traces, however they still allow you to trace a stubborn exception that is only reproduced on the device (which unfortunately is something unavoidable for some cases). The stack traces contain only methods that are a part of Codename One e.g. if we invoke a Java API that is not a part of Codename One it will not appear in the stack. Line numbers etc. aren't included in the stack.

Unfortunately this functionality doesn't come cheaply, performance is noticeably impacted by crash_protect at the moment which means we can't use it for production (using logging is just fine though). For now this is mostly practical for debugging, but we intend to improve the performance of this feature as we move forward and make it viable for production systems as well.

Promo Video And Some Updates

We had a very stressful couple of weeks with quite a bit going on in the business side of things. I hope to land in some major server code next week, in the meantime I would appreciate if you guys can let me know what you *honestly* think about this animation (its not narrated).
We might hire a professional animator and ask him to do something along these lines, does it convey the message on a high level? Thanks.

Major Changes In Codename One

We're launching a few major features into Codename One over the next couple of days that would make a huge difference overall to our product/architecture and your experience: Server arguments & Java language processor.

We will start with the first. Up until now Codename One limited the syntax and functionality of the Java VM to the CLDC level of Java support in order to support RIM and J2ME devices. Starting very soon this will no longer be the case! We have added very extensive Java 5 feature support including generics, enums, annotations etc. newer Codename One applications will start making use of these features as well.

These features are implemented by effectively stripping the syntax sugar from the application, this means you will still need to limit yourself to a small subset of Java 5 features but that subset is growing and will maintain some backwards compatibility. There will be no reflection and some painful omissions such as the lack of the "Number" class are still there, however quite a few things are available.
Keep in mind that NetBeans will still show you a far more extensive set of supported features. We intend to extend the plugin to review the code more closely before sending it to the server for a future release.

The second major change is even bigger, we added the ability to send arguments to the build on the server side and are starting to define the arguments you can send. E.g. when sending an iphone build it was always built as a universal application (both iPhone & iPad support). Starting now, you can add a server argument to indicate that you are interested only in iPhone or iPad versions. The same goes to many similar features.
We now also scan the binary code and fine tune the permissions on the Android platform to match the API's used by the developer. When developing native code on Android you can now insert manifest changes in several locations.

We are really excited about these upcoming changes and how you are too. Here is the current list of arguments, keep up with out developer guide which will include an up to date list of all current arguments:

• android.min_sdk_version - defaults to "7". Used in the manifest to indicate the android:minSdkVersion property.
• android.xapplication - defaults to an empty string. Allows developers of native Android code to add text within the application block to define things such as widgets etc.
• block_server_registration - true/false flag defaults to false. By default Codename One applications register with our server, setting this to true blocks them from sending information to our cloud. We keep this data for statistical purposes and intend to provide additional installation stats in the future.
• ios.project_type - one of ios, ipad, iphone (defaults to ios). Indicates whether the resulting binary is targeted to the iphone only or ipad only.
• ios.statusbar_hidden - true/false defaults to false. Hides the iOS status bar if set to true.
• ios.prerendered_icon - true/false defaults to false. The iOS build process adapts the submitted icon for iOS conventions (adding an overlay) that might not be appropriate on some icons. Setting this to true leaves the icon unchanged (only scaled).
• ios.application_exits - true/false (defaults to true). Indicates whether the application should exit immediately on home button press. The default is to exit, leaving the application running is untested at the moment.
• ios.interface_orientation - UIInterfaceOrientationPortrait by default. Indicates the default initial orientation, one of: UIInterfaceOrientationPortrait, UIInterfaceOrientationPortraitUpsideDown, UIInterfaceOrientationLandscapeLeft, UIInterfaceOrientationLandscapeRight
• rim.askPermissions - true/false defaults to true. Indicates whether the user is prompted for permissions on RIM devices.

Creating a Basic Theme And Using The Image Border Wizard

Codename One themes are effectively a set of UIID's mapped to a Style object, we can create a new theme by adding it in the Designer tool and customizing the UIID values.

We can add a component style to a component such as Button, typically UIID's are named with the same name as the Component class. You can modify the UIID of a component by invoking setUIID(String) on an arbitrary component or changing the UIID property in the GUI builder.

Styles can have one of 4 states:

1. Default (unselected) - the way a component appears when its in none of the other states.
2. Selected - shown when the component has focus or is active (on a touch screen device this only appears when the user interacts with the device with touch or with a physical key).
3. Pressed - shown when the component is pressed. This is only active for Button's.
4. Disabled - shown when the component is disabled.

You can add a style to any one of the states in the Designer to make the component appear as expected in those cases.
  

When editing the style of the component you can customize multiple things such as the background image, the way such a background image is displayed or a gradient/solid color background. You can customize colors, fonts, padding/margin, border etc.

Borders are a remarkably powerful tool for customizing a Component. The most powerful approach is the 9-piece image border which is easiest to use when using the Image Border Wizard.

The image border wizard allows you to take an image and "cut it" into 9 distinct pieces: 4 corners, top, bottom, left, right & center.
The corners are placed as usual in the edges of the component and the other elements are tiled to fill up the available space.

Its important when using a gradient effect within the image border to make sure the center pieces are as narrow as possible to avoid a case of a "broken" gradient.

Push It Real Good

Push notification is one of those things that seems simpler going in...

Please notice that this code and implementation is highly experimental and we are still working out the kinks. It is also only enabled for paid accounts in Codename One due to some of the server side infrastructure we need to maintain to support this feature.

Push notification allows you to send a message to a device, usually a simple text message which is sent to the application or prompted to the user appropriately. When supported by the device it can be received even when the application isn't running and doesn't require polling which can drain device battery life.
The keyword here is "when supported" unfortunately not all devices support push notification e.g. Android device that don't have the Google Play application (formerly Android Market) don't support push and must fall back to polling the server... Not ideal.

Currently we support pushing to Google authorized Android devices: C2DM (Cloud To Device Messaging) and to iOS devices: Push Notification.
For other devices we will fallback to polling the server in a given frequency, not an ideal solution by any means so we give you the option to not fallback.

This is how Apple describes push notification (image source Apple):

The "provider" is the server code that wishes to notify the device. It needs to ask Apple to push to a specific device and a specific client application. There are many complexities not mentioned here such as the need to have a push certificate or how the notification to APNS actually happens but the basic idea is identical in iOS and Android's C2DM.

Codename One hides some but not all of the complexities involved in the push notification process. Instead of working between the differences of APNS/C2DM & falling back to polling, we effectively do everything that's involved.

Push consists of the following stages on the client:

1. Local Registration - an application needs to register to ask for push. This is done by invoking:
   Display.getInstance().registerPush("gmail email account for C2DM", fallback);
   
   The fallback flag indicates whether the system should fallback to polling if push isn't supported.
   On iOS this stage prompts the user indicating to him that the application is interested in receiving push notification messages.
2. Remote registration - once registration in the client works, the device needs to register to the cloud. This is an important step since push requires a specific device registration key (think of it as a "phone number" for the device).  Normally Codename One registers all devices that reach this stage so you can push a notification for everyone, however if you wish to push to a specific device you will need to catch this information! To get push events your main class (important, this must be your main class!) should implement the PushCallback interface. The registeredForPush(String) callback is called with the unique device ID that can be used later on when pushing to this particular device.
3. In case of an error during push registration you will receive the dreaded: pushRegistrationError.
   This is a very problematic area on iOS, where you must have a package name that matches EXACTLY the options in your provisioning profile which is setup to support push. It is also critical that you do not use a provisioning profile containing a * character in it.
   
4. You will receive a push callback if all goes well.

Sending the push requires two different things for Google and  iOS. In C2DM (Google) you send a push via a gmail address (you need to apply to get a larger quota) and once you have that quota you can just start sending push notifications.

To prove that you indeed have the account you need a Google auth key which you can retrieve by calling:

https://codename-one.appspot.com/googleAuth?email=youremail@gmail.com&password=yourpassword

The key occasionally expires so be sure to refresh it. You can optionally send us your Google credentials when pushing a message via the server API and we will retrieve the key automatically.
For privacy concerns we recommend setting up a separate account that will be used for push alone and not using your standard Google account to perform push operations.

For iOS developers must download a push certificate from the iOS provisioning portal for the given application. Notice that by enabling push you will probably need to regenerate the provisioning profile as well and download/replace your existing provisioning profile.
The certificate must be converted to a p12 certificate as I explained in the provisioning profile tutorial.  

Currently we don't have the option to send the iOS certificate as part of the push request so you will have to host it somewhere and provide us with the link.

To send a push message use the following web API:
https://codename-one.appspot.com/sendPushMessage?auth=googleAuthKey&
packageName=packageNameOfApplication&
email=gmailAccount&
device=theDeviceKey&
type=1&
production=true/false&
certPassword=pass&
cert=CertificateURL

Notice the following arguments in particular:

• device - this is an optional argument, to send to all devices just omit this argument. To send to a particular device you need to provide its key which was given in the registeredForPush() callback.
• type - this must currently be set to 1, there will be additional types in the future
• production - iOS has production and development push services each of which requires a different certificate. Its important to pick the right one. Pass true for production and false for development.
• cert - the URL for the iOS push certificate which you are hosting.
• certPassword - the password of the certificate

Again take into consideration that this is an early stage release with multiple bugs.