NewFeature Tagged Posts

Sometimes I get a question on stack overflow that triggers a "yes this should be easy" reflex. I got such a question a couple of weeks ago when I implemented the animated gif support cn1lib and I had another one last week which asked about sorting tables.

So you know how you write a blog post just before you go on vacation, press publish and never check that it actually got published... Funny thing, that's exactly what I did and the blog post mentioning that I was on "vacation" for a couple of weeks never got published. Anyway, other people have been busy while I was "away" but I got a couple of things done too including animated gif support.

We've been very busy the past few weeks despite the summer time but August is always problematic, I will personally take some time off from the blog next week and near the end of August. To allow that I want to clear my table from a lot of the features that went into Codename One over the past couple of weeks and didn't get sufficient or any documentation...

When discussing the features Chen slipped in just in the last minute of 3.7 I mentioned there were two such features but only discussed the desktop skin. The second one is a more terse/logical API for calling REST web services using the builder pattern.

During the final stages of the 3.7 release cycle we had a lot of material to go thru and Chen slipped a couple of features that we just didn't have the time to discuss. One of those features is the new desktop skin which is a special case skin to debug desktop and JavaScript apps.

With version 3.7, we have revamped the GUI builder with a designer that allows you to position your elements precisely where you want them. The experience should be closer to what you find in graphical design applications like Photoshop rather than the more rigid "drop in the slot" approach in previous versions of the GUI builder. There are caveats to be aware of with this approach, but overall, it should empower you to build beautiful UIs with greater ease than before.

A common request over the past couple of years has been to add a text field that supports a clear button in the end, we used to have a common answer on how this can be implemented but we didn't have an actual implementation builtin despite this being a relatively common request.

SVG (Scalable Vector Graphics) is an XML based image format that represents an image as vectors instead of pixels (raster). An SVG file is represented by the set of lines & shapes that make it and can thus be rendered at any resolution without quality degradation due to scaling. It has some other neat tricks up its sleeve but I'm only going to discuss that specific feature today.

A developer recently asked me why Display is called Display when it has such a broad purpose?The reason is historic with roots in Codename One's origin back in 2007, when we formed the company Chen advocated for a rename of that class and I disagreed. In retrospect I was wrong, the name doesn't work.

Until this weeks release push notification was registered using Display.registerPush(Hashtable, boolean) the thing is that both of these arguments to that method are no longer used or not the best way to implement registration. So we deprecated that method and introduced a new version of the method Display.registerPush().

This feature is still undergoing development but I wanted to share the progress here so we can start getting bug reports and suggestions. One of the frequent requests for the side menu UI is to provide a way for it to render on top of the UI instead of shift the UI. The old side menu was written when the facebook app was the chief application that used that UI paradigm so it was built to match that approach.

One of the main reasons for the thread API I discussed yesterday is a new threadsafe Database API. This new API allows you to wrap your `Database` instance with a thread that will hide all access to the database and implicitly make it threadsafe by serializing all requests to a single database thread.

Working with threads is usually ranked as one of the least intuitive and painful tasks in programming. This is such an error prone task that some platforms/languages took the route of avoiding threads entirely. I needed to convert some code to work on a separate thread but I still wanted the ability to communicate and transfer data from that thread.

Fingerprint scanners are pretty common in modern hardware both from Apple and some Android vendors. The problem is that the iOS and Android API's for accessing them are a world apart. However, it's possible to find some low level common ground which is exactly what our cn1lib for fingerprint scanning accomplished.

As part of the bootcamp we wrote a couple of cn1libs and the first one is the Braintree cn1lib which allows us to do credit card payments within an app. If you aren't familiar with Braintree it's a PayPal company that provides payment integration for mobile devices.

One of the biggest pain points in Codename One is theming, there are several things we did to alleviate the problem but it's an inherently complex problem. One difficulty people have is in the disconnect between what we see in the UI and the styling in the designer. This creates a disconnect that is often hard to bridge.

Since I haven't blogged in a while a lot of stuff has piled up on my desk and I'll get it out in batches in this post I'll go over a few of the bigger changes we did while I was away on the bootcamp and also give you a bit of an update on what we've been doing within the bootcamp itself.

The ComponentSelector class is a new class that brings the power of jQuery to Codename One. While it is not actually jQuery, it is heavily influenced by it. If you're not familiar with jQuery, here is the 10 second intro.

One of the primary use-cases that benefits from our recent improvements for native peer integration, is "map apps". That is, apps that use native maps in some shape or form. This is an extremely common uses case for mobile apps these days. Codename One has supported native maps for quite some time, but (up until recently), they were limited by a couple of factors...

I didn't post much about new features in a while because we've been so busy with the bootcamp that we didn't have as much time to write the posts or the actual functionality. But a few features/changes did slide in over the past couple of weeks as is pretty much inevitable.

Just last week I mentioned that we wanted to get push working on Windows & we're pretty thrilled to announce that it's available already... This means that we now support push on pretty much any major device with the exception of the Safari web browser.

Up until now push notification in Codename One only worked for Android & iOS devices. This is about to change this weekend when the JavaScript port should (almost) seamlessly start working with push!This is pretty cool as push to the web is a pain with every browser taking a somewhat different route but with Codename One this will "mostly" work.

I wrote on the Friday post about a few cool pull requests from Diamond but I didn't provide a usage example for that API. Probably the best usage example is gmail style undo. If you are not a gmail user then the gmail app essentially never prompts for confirmation!

One of the first things a hacker will do when compromising an app is look at it. E.g. if I want to exploit a bank's login UI I would look at the label next to the login and then search for it in the decompiled code. So if the UI has the String "enter user name and password" I can search for that.

One of the common requests we received over the years is a way to let text "fit" into the allocated space so the font will match almost exactly the width available. In some designs this is very important but it's also very tricky. Measuring the width of a String is a surprisingly expensive operation on some OS's. Unfortunately, there is no other way other than trial & error to find the "best size".

Just last week I mentioned the effort we were taking to bring the z-ordered peer components into other platforms and I'm pretty happy to report that tomorrows update should include support for iOS & the JavaScript ports for z-ordering.

Display.canExecute(url) provides us with a generic tool to test the availability of a feature before executing a command. This is very useful for inter-app communications and allows us to achieve various things such as launching Google Map instead of Apple Maps on iOS.

iOS & Android are walled gardens which is both a blessing and a curse. Looking at the bright side the walled garden aspect of locked down devices means the devices are more secure by nature. E.g. on a PC that was compromised I can detect the banking details of a user logging into a bank. But on a phone it would be much harder due to the deep process isolation.

One of the problems with native maps is that they work very differently between the device and the simulator. This is because we use MapComponent on the simulator and as a fallback on the devices where Google Maps isn't available. We just committed a new mode for maps that allows you to use the Google HTML maps as the fallback instead of the MapComponent.

We try to make Codename One "seamless", this expresses itself in many small details such as the automatic detection of permissions on Android etc. The build servers go a long way in setting up the environment as intuitive. But it's not enough, build hints are often confusing and obscure. It's just hard to abstract the mess that is native mobile OS's and the odd policies from Apple/Google...

Certificate pinning is a security measure designed to thwart potentially dangerous and complex attacks. Since those sort of attacks are pretty hard to execute it's a security measure that is probably unnecessary for most developers. However, if you are building an application for a very sensitive industry (e.g. Government, Banking etc.) you might be required to include this defensive measure.

Just a couple of weeks ago I was offering tips on how to search the website in lieu of a search engine. Having gone thru the process repeatedly and trying many different approaches and off the shelf solutions we decided to build something simple of our own and we did.

One of the fallouts from the new encrypted storage API we added last week is the fact that it encrypts things like preferences making them unusable if you expected them to work before/after encryption was applied. To workaround this we added a new API to the `Preferences` class:

Caching server data locally is a huge part of the advantage a native app has over a web app. Normally this is non-trivial as it requires a delicate balance especially if you want to test the server resource for changes.

We've had quite a few interesting features land last week and didn't get a chance to cover them. First we have access to the OS's caches directory where you can store files that you don't really need as cache. Both iOS & Android have such a directory and files stored there might be purged without notice if the OS runs out of space.

We had support for bouncy castle encryption for quite a while but it is not as intuitive as we'd like it to be. This makes securing/encrypting your app painful and so we procrastinate and eventually skip that "feature" altogether. Frankly, I hate working on encryption it's painful... That's why we procrastinated on this feature until today!

The validation framework makes it easy to verify input quickly and effectively. Up until now you had to define an emblem in order to create an error icon and if you didn't you had to define an "Invalid" UIID for every entry. This exists by default for text fields and other types but is still a big hassle just to check that we have a valid email...

Subclassing isn't bad but it becomes tedious especially if it's just there to implement something trivial. One of the pain points we had with the ConnectionRequest API's is the submission body wasn't as convenient as it should be.

One of the frustrating parts in Codename One is builds failing in the cloud, the expectation is that a build that passes locally would pass in the cloud and that is something we strive to have at all times. One of the more commonfailures for new developers is due to refactoring of the main class or changing the signatures of the methods e.g. adding a throws clause to `start()`.

We usually just add a new feature and then tell you about it in these posts but properties is a special case and this post is intended not just as a tutorial but as a solicitation of feedback... We committed properties as a deprecated API because we aren't sure yet. This could be a very important API moving forward and we want as much peer review as possible over this.

We are launching a partners page in the website that will refer to consultants that we recommend/approve. If you are a software development company that works with Codename One we'd like to feature you in our website and provide the following benefits...

Last week a question came up in stackoverflow that came out quite a few times before but this time I had a better answer thanks to the round border. After giving that answer I recalled that I already wrote some code to implement badging in the FloatingActionButton but never exposed it because of some bugs...

The Phoenix theme had a FloatingActionButton with a gradient on top. This goes against the mostly flat material design spec but after looking at the design with a solid color I came to the conclusion that the designer was totally right to use a gradient in this case. Unfortunately we didn't build that support into the FloatingActionButton.

I explained why we don't support the full Java API (and the difficulties involved) not so long ago. The logic behind this is solid. However, the utility of porting existing Java code to Codename One is also with a lot of merit.

We introduced the new RoundBorder API a couple of weeks ago and it's already picking some usage. But to really take off it needs to be within the themes, starting with the next plugin update the border section of the designer tool will include the options for round border.

The material design floating action button is a powerful tool for promoting an action within your application. Quite a few Codename One developers implemented with own interpretation of this UI element and with the coming update we will have an official implementation.

Circles and completely round border sides are problematic for multi-resolutions. You need to draw them dynamically and can't use image borders which can't be tiled/cut to fit round designs. Up until now we recommended using background images or changing the design entirely but now we have a new option: RoundBorder.

Starting with the next Friday release we will migrate to the new peer support. This migration will allow us to focus on a single code base and remove the branch where we are maintaining the old peer support.

We finished the final major piece of the offline build offering that we announced in July! This Sunday we will update the plugins to include this ability as an option. Once installed you can use the instructions below to install the offline build service.

One of our enterprise customers needed help with file upload from the desktop. E.g. in his Codename One app running in the browser or desktop he wanted the ability to drag a file. Somewhat like we can drag a file into gmails compose window.

This is a feature Steve added way back in June but I didn't get around to documenting it. Build hints can sometimes get "unwieldy" e.g. in the case of ios.plistInject or we sometimes have pretty verbose values.

When we initially designed the cn1lib file format we looked at jar files as a starting point. We wanted a way to distribute binary libraries that support the native code access, restrictions and ideally code completion.

I wanted to write about the new kitchen sink demo which I'm trying to finish... But I haven't finished it yet as it's such a major undertaking. As part of that work I wanted to show some code that downloads themes and didn't want to use the venerable infinite progress indicator which I generally dislike...

It's tough to pick up a new toolchain like Codename One. There's so much to learn... A lot of our developers come from the Android world and even though Codename One is much simpler than Android porting the first app to Codename One is still painful.

One of the big decisions we made a while back was to build the new GUI builder on top of Codename One itself, we extended that decision three months ago with the decision to build the Codename One settings in Codename One and then deciding to make it the default preferences UI for all IDE's...

We had a couple of posts in the past about the new GUI builder but we didn't have a "how to" guide yet. In this post we'll try to go step by step over the process of using the GUI builder and understanding its inner workings. We'll also try to clarify conclusively the role the new GUI builder plays in the toolchain and the migrations process from the old GUI builder.

As we mentioned recently we have a new idea on how peering can be improved and we just deployed a this into our build servers in the weekend update. This is highly experimental and might crash instantly which is why we hope you give it a test drive and see how it feels before we switch it on by default.

A common issue we get from developers relates to minor differences between devices which are often very hard to quantify. They are also very hard to explain to the developers in some occasions. One of the biggest points of difficulty is density which is a very hard concept to grasp and it's often hard to know which image will be used from the set of multi images or how many pixels will be used for 1 millimeter.

The ToastBar was one of those API's I didn't know I needed and yet I became addicted to it... Ever since Steve came out with the ToastBar I constantly catch myself typing Display.show only to delete that to use the ToastBar. It's both really easy to use and more consistent with modern mobile UI design.

InfiniteContainer and InfiniteScrollAdapter revolutionized the way we think about Codename One. Up until their introduction we advocated lists for large sets of components and this is no longer the case.

However, InfiniteContainer has a controversial feature even within out team. It violates the EDT on purpose...

We covered the new Accordion component last week and just started using it in a demo for which it was very suitable. As we were working with it we discovered that it was missing some core methods to remove an Accordion entry or change it's title. But worse, was the fact that a delete button in the title wouldn't work! The crux of the issue is in the fact that lead component doesn't support excluding a specific component within the hierarchy from it's behavior so we set about to fix that...

Background fetch allows an app to periodically "fetch" information from the network while the app is in the background. This is scheduled by the native platform, where apps that support background fetch will be started up (in the background), and their performBackgroundFetch method will be invoked.

The Accordion ui pattern is a vertically stacked list of items. Each item can be opened/closed to reveal more content similarly to a Tree however unlike the Tree the Accordion is designed to include containers or arbitrary components rather than model based data.

After many months of work and effort put in by all of us but especially by Steve Hannah and Fabrício Carvalho Cabeça we are finally live with the Windows Universal Platform (AKA UWP) native build target! As far as I know Codename One is the only native option for Java developers to build native Windows UWP apps.

Managing your project dependencies and 3rd party extensions among the hard to navigate list of cn1libs has always been challenging. We are now tackling this problem in the new settings UI which is scheduled to launch for all IDE's this Friday.

With the upcoming library update this weekend we will remove the venerable (old) skins that are baked into the simulator. This means that they will no longer be immediately accessible but you can still download all of them thru the Skins -> More menu option.

Bluetooth is one of those specs that makes me take a step back... It's nuanced, complex and multi-layered. That isn't necessarily bad, it solves a remarkably hard problem. Unfortunately when people say the words "bluetooth support" it's rare to find two people who actually mean the same thing!

CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects. It has over eighteen thousand libraries and can help you scale your projects elegantly. Cocoapods can be used in your Codename One project to include native iOS libraries without having to go through the hassle of bundling the actual library into your project. Rather than bundling .h and .a files in your ios/native directory, you can specify which "pods" your app uses via the ios.pods build hint. (There are other build hints also if you need more advanced features).

Starting with the new version of the NetBeans plugin we will have the new settings/preferences UI which we introduced in the IntelliJ/IDEA plugin. Currently this will be in addition to the main preferences but as we move forward we will only add features to the new settings UI.

One of our support emails drew my attention to a glaring ommission in our icon font support... When we create an icon for a `Button` it's color matches the unselected color of the button which might not look as attractive when the `Buton` is selected or pressed!

One of the often requested features in Codename One is zip support, we had some issues with it until a couple of years back we added tar and later gzip support. But people still asked for standard zip file support which was missing.

I'm working on a tool that I hope to share next week that needs zip to work, initially I wanted to do this natively as zip works on most native OS's but one of the true benefits of the tool is if we can get it to work in the JavaScript port live on the web...

When we initially launched Codename One it was pretty hard to imagine todays apps. Menus and back navigation were miles apart when comparing Android 2.x and iOS 4.x... So we created a very elaborate set of abstractions (command behavior) that served as a set of patch framework we could live with for a while.

We talked about the new Android 6 (Marshmallow) permissions in Codename One last week and so far we've been pretty happy with the result. We had some build regressions on the older Ant based build path but those were fixed shortly after and it's been smooth sailing since then. As part of the transition to the new permissions system we added two features to the simulator and the AndroidNativeUtil class.

As part of our continuing effort to squash bugs for the 3.4 release date we hit two major issues, the first of which is a long time RFE to fix PDF viewing on iOS and Android to work consistently. This also applies to any file opening in iOS/Android which should now be trivial with the Display.execute method. Just use that method on any file within your home directory in FileSystemStorage and it should launch the native app to view that file.

As part of the bug fixes for the 3.4 release we fixed issue 1725 which was surprisingly difficult to fix... As part of that fix we also added a new method to TextArea by the name of setActAsLabel which we now implicitly call in the SpanLabel & SpanButton classes.

One of the hard things to debug in Codename One is UIID/Padding/Margin placement which is often tricky to get "just right". I use the Component Inspector quite a lot to review a layout that misbehaves and gain further insight into what's happening in runtime.

In our original Java 8 support announcement post we specifically mentioned the lack of streams but completely missed the fact that default/static native interfaces didn't work. This is now fixed thanks to an alert community member who pointed that out.

Our current IntelliJ/IDEA plugin is seriously behind the times. In our recent survey it was very easy to spot IDEA developers who were significantly less satisfied with Codename One than the rest of the developer community.The IDEA plugin doesn't include basic capabilities such as...

Clipping is one of the core tenants of graphics programming, you define the boundaries for drawing and when you exceed said boundaries things aren't drawn. Shaped clipping allows us to clip based on any arbitrary shape and not just a rectangle, this allows some unique effects generated in runtime.

Starting with the next update of Codename One (later this week) we will switch Toolbar on as the default for all newly created projects. This doesn't mean much for most of us as existing projects won't be affected, however if you are creating a new project this means you won't need to create a Toolbar for every Form and that we won't have to deal with as many issues related to the native Android title.

I was working on documenting the SQLite support in Codename One, you can see some of that work both in the db package and in the developer guide. As a demo for SQL I decided to just create a tool that allows you to type arbitrary SQL to execute it on the device and see the results in a Table...

Beside being a cool example this can be a hugely powerful debugging tool to one of the more painful API's to debug on the device. You can integrate this as a hidden feature into your application and use it to debug odd "on device" issues by querying the DB!

We've had a busy week working with several customers on various tasks/issues as well as the documentation which is practically unrecognizable by now (more than 600 pages by now). As a result a lot of small fixes and enhancements were made to the code as well as one new niche component.

A very common UI pattern is the 5 star ranking system. Up until recently we always had the same answer when developers asked us how to implement it: "Use toggle buttons (CheckBox)". This is still not a bad answer but we think there is a "better" simpler way to do this thru the Slider which was effectively designed with this usage in mind.

Just last week I wrote that we are making an effort not to add new features and we got foiled by a couple of new features. The main reason for this is paying customers who need to have a feature now. This makes it hard for us to focus completely, but it does keep the lights on here so we can't really complain.To be fair, during this time we were able to almost double the page count of the developer guide from the 3.2 era to 576 pages at this moment and we still have a lot of work ahead of us in that department.

As you know we've been working a lot on the docs both the developer guide and the JavaDoc's, we nearly doubled the amount pages in the developer guide and we did it without "cheating" (e.g. cramming more stuff, increasing font size). You can see all that work in the developer guide section but what I want to discuss today is the new Component Gallery and Layout Gallery.

I've been remarkably busy working on issues and documentation so I neglected an important announcement I had to make. Over the weekend we flipped the default build from gradle back to ant. So effectively if you don't set any build hint the behavior will be android.gradle false which should work fine for most of you. This is temporary but we felt it was necessary as a stopgap measure.

Facebook recently announced the closing of parse.com which is disappointing but not totally surprising. Everyone knows a project from a large tech company can just shutdown in a blink of an eye leaving millions of users/developers in limbo. In that sense one of the questions that gets under my skin is what happens if Codename One calls it quits...

JavaDoc source code embeds suck!I love JavaDoc but it didn't age well. When you work with other tools (e.g. in the Microsoft world) suddenly the embedded samples look amazing and "search" functionality is just built in!Why can't we have that?JDK 9 is introducing new support for search but source embeds can be so much better and are a crucial learning tool...

Following with the feedback on the recent survey we spent a lot of time debating how we can improve the general process of documentation and ideally have the community more involved. So one of the first things we did is place our entire developer guide directly into the Codename One Wiki!This allows any one of you without any special permissions (just a standard github account) to edit the wiki directly. No pull request or anything like that required. The syntax is based on asciidoc which is reasonably intuitive so if you see something wrong/missing etc. just edit it directly, we review all changes after the fact so if you get something wrong we will fix it!

Steve has implemented one of our long time RFE's: Async editing in Android. This effectively means that the Android keyboard will behave as it does in iOS and won't fold/open as you move between text fields. It will also remain open as you scroll the screen and won't resize the UI as it opens!As you can imagine this is a huge change so it is currently off by default but we will flip the change sometime next week to be the default.

We committed a major somewhat revolutionary change to how layout animations and the basic component tree work in Codename One. This is important to understand since it changes the very nature of how we expect components to behave in Codename One. This also allows us to create some pretty spectacular effects such as the ones in the title above.

After a discussion with some members of the community we decided to shift the weight of our support efforts to StackOverflow from our existing google group discussion forum. Notice that we will still answer questions in the discussion forum but we strongly prefer using StackOverflow (don't forget to use the codenameone tag). There are issues with StackOverflow which is why we are keeping the existing group and will still answer questions/issues there but the benefits far outweigh the issues:

Sizing images for multiple DPIs and device sizes is challenging. There are image quality and bandwidth considerations, especially when loading images over the network. The new Cloudinary cn1lib simplifies this process by preprocessing images on the server side, so that they can be delivered to the mobile app in the exact correct side and quality.

We became infatuated with icon fonts a while back and used them quite a bit, recently we added the FontImage class that made them really easy to use.However, up until now you had to download a font. Look up the value and enter it in. This was OK but not ideal in terms of syntax/availability especially for simpler apps.

I've spent a lot of time working with and reviewing other cross platform tools this past month, mostly with Cordova due to our recent announcement that we support Cordova. I hope it doesn't come off as too arrogant but our "onboarding" experience is pretty amazing in comparison to pretty much everything else. Just install IDE, type in Codename One and follow wizard for new app. The only tools that are simpler than that are the rather limited web based solutions.But we do fall short in one major way, our "hello world" apps look bad by default when compared to pretty much any tool out there. There are a lot of reasons for this but none of them are good reasons and this gives a horrible first impression to any developer picking up Codename One for the first time.

We just released the first version of the open source CN1Cordova project on github. This means you can take a common Cordova/PhoneGap app, import it into NetBeans and build a native app using our cloud build servers without any changes! Before we delve into the exact process of converting an app lets start by reviewing the exact benefits PhoneGap/Cordova developers can gain from Codename One. You can also check out the video tutorial and slides below.

A common trick for animating Components in Codename One is to set their preferred size to 0 and then invoke animateLayout() thus triggering an animation to hide said component. There are several issues with this trick but one of the biggest ones is the fact that setPreferredSize has been deprecated for quite a while.

We've been working on some pretty exciting things recently trying to get them out of the door. As part of that work we added some API's specifically one that probably should have been a part of Codename One 1.0 Properties file support...

In this last minute before 3.2 finally comes out we have a batch of new features & updates. Some of the last minute features that went into Codename One include: shorter more terse syntax for creating forms, migration wizard for the new GUI builder & dialog adaptive sizing.

The new Codename One CSS library enables you to create entire themes using only CSS, but in this post, I’m going to focus on its ability to automatically generate image backgrounds and borders for your apps.

Since we announced the new GUI builder work we got quite a few questions in the discussion forum and offline so I prepared a quick video showing how the new GUI builder will look when released (more or less). Notice that a lot of things will change with the GUI builder but some things are pretty much fixed such as the basic architecture with the XML to Java process. This is unlikely to change much.

This is the third and final instalment in a series on integrating 3rd party native SDKs in your Codename One application. If you missed the first two chapters, I recommend you begin with part one before reading this tutorial, as it provides much needed context for the procedures described here.

This blog post is part two in a three-part series on integrating 3rd party native SDKs into Codename One application. I recommend you start with part one in this series as it will give you much-needed context to understand the procedures described in part two and three.

We are happy to announce support for local notifications on iOS and Android. Local notifications are similar to push notifications, except that they are initiated locally by the app, rather than remotely. They are useful for communicating information to the user while the app is running in the background, since they manifest themselves as pop-up notifications on supported devices.

This past Thursday, we held our fourth webinar, and the topic was how to incorporate 3rd party native libraries into a Codename One app. I used the recently released FreshDesk cn1lib as a case study for this webinar. As the topic is a little involved, I decided to break it up into two webinars. In part one, we focused on the public API and architecture involved in developing a wrapper for a native SDK, and walked through the native implementation for Android.

Codename One provides extensive support for designing beautiful user interfaces, but it isn't necessarily obvious to new developers how to achieve their desired results. A common workflow for app design includes a PSD file with mock-ups of the UI, created by a professional designer.

We've been so busy recently that changes and features keep piling up with no end...

Permanent Sidemenu

It was always possible to create a permanent side menu but up until now it wasn't trivial. For Tablets/Desktops the side menu UI is perfect, but the folding aspect of it isn't as great. We have more space so we'd like to keep it open all the time.

We are starting the complete overhaul of our push implementation that will allow us to deliver improved push related fixes/features and provide more reliability to the push service. When we designed our push offering initially it was focused around the limitations of Google App Engine which we are finally phasing out. The new servers are no longer constrained by this can scale far more easily and efficiently for all requirements.

On Thursday morning we rolled the cameras for chapter 2 of our exciting new webinar series. This time around there were far fewer (though not zero) technical issues, and we were able to share a productive hour of mobile app development in the company of our fellow coders.

We decided to discontinue support for building without a certificate, this support was added initially because generating an iOS certificate was so difficult and we wanted developers to see that "it works" before committing to the expense. However, this process is wrought with bugs that are often hard to trace back and error prone. Added to that is the fact that we now have the new certificate wizard which makes the process simpler thus removing the final blocker (no need for a Mac).We will block this functionality in the build servers by next week and thru the plugin after that.

Tuesday morning I held a webinar on Java mobile development using Codename One. First of all, I'd like to thank all who signed up and attended. Unfortunately there were some technical difficulties with the Webinar software that caused some major glitches. Double thanks to those who endured and stayed to the end. We've learned from this experience and we will do better in future webinars.

We've released a burst of small new features that piled up during the code freeze and release cycle. The first one is the Facebook "invite friends" feature. Historically with the Facebook API you could just use the Graph API to query Facebook for the list of friends. This will return an empty list now and will only expose friends who are already using the app. You can use the standard share button or Facebook share both of which are great options to promote your app. However, Facebook also has a special native API allowing the user to invite his friends into the app...

Its been a busy month and getting busier by the moment, we are preparing for App Engines suspension of its blobstore service which will be coming around soon. This effectively means older crash report email functionality will be stopped for older apps (just rebuild the app for the emails to work again). We are also getting ready for Codename One 3.1 which we have tentatively scheduled for July 27th. This release will include a weeks worth of code freeze and will be the first of our new policy for faster release schedules.

So you have finished your app and tested it on the simulator. Everything looks good. You're now ready to proceed with testing on your iPhone. You select the "Send iOS Debug Build" menu item and wait for the build server to work its magic, but then you're faced with a notice that iOS builds require a valid certificate and provisioning profile. What a hassle!

When we introduced Codename One initially we limited the API to CLDC level which is roughly a subset of Java 1.3, we then added support for a subset of Java 5 and we are now adding Java 8 language features!Thanks to some work from Steve and the great work done by the guys from the Retro Lambda project we were able to add compatibility to the major Java 8 features, most notably lambda expressions. This is highly experimental and some features might not work but so far it seems things are functioning rather smoothly.

While multi-image's go a long way in making your app scalable to various devices, scalable images can be even more convenient. The SVG standard never took off though, its too complex to support in an efficient way on the devices and so its relegated to web applications and even those don't make heavy use of it due to its complexity.However, icon fonts have gained a lot of popularity in recent years and we used them in the past in Codename One e.g. in the photo demo.

Chen recently published a major refactoring of our connection framework which up until now only supported Facebook login. With this recent refactoring the code to connect to various authentication services becomes far simpler and various services should become more pluggable. The default implementation centers around the Login and LoginCallback classes that use oAuth by default to perform the login.

The JavaScript port is nearing beta stage which will start next week its already added support for most API's including SQL support and many other features. Once the JavaScript port is in beta it will become an enterprise only feature so if you haven't tried it yet you have one week to try your app.

With the release of 3.0 we were overwhelmed with a lot of last minute features and improvements. It seems that we neglected to mention a lot of features that made it into the final 3.0 product. One of the nicest new features is a set of new flat themes with various colors in the designer and the project wizard. We found that a lot of developers prefer themes with more control over the look, themes that look more similar across platform yet have a more modern "flat" feel.

We are very excited to announce the alpha release of the Codename One Javascript port. This brings us one step closer to the coveted _write once run anywhere_ ideal. Starting with Codename One version 3.0, you will be able to deploy your projects as Javascript applications that run directly in the browser.

Devices have sensors such as accelerometer, GPS and up until now our support for them was relatively basic.Chen recently introduced a cn1lib that includes support for various types of sensors on the device. Check it out if you need support for such API's.

When Codename One packages applications into native apps we hide a lot of details to make the process simpler. One of the things we had an issue with is getResource/getResourceAsStream both of which are problematic since they support hierarchies and a concept of package relativity. That's a concept that is problematic in iOS, generally everything about file access within the bundle in iOS is a bit problematic to accomplish in a cross platform way because Apple tries so hard to "simplify" and ends up creating fragmentation for us.

Up until recently we had to handcode validation logic into every form, this becomes tedious as we work thru larger applications. Some developers built their own generic logic, which leads to obvious duplication of effort. In the interest of keeping everything together we decided to release a standardized validation framework that allows us to define constraints on a set of components, mark invalid entries and disable submission buttons.

As part of tracking a bug in iOS media playback Steve hit upon some code that recreated the OpenGL framebuffer pretty much all the time. This was there to allow device rotation to work, but was implemented incorrectly... After this fix animations and UI is much smoother on iOS, if you notice any potential issues let us know.

Now that the new website is live we are down to standard business again beyond just the typical bug fixes. Chen just updated the gallery support to include the ability to pick a video file and not just an image file...

One of the pains in Codename One is the access to the demos, yes we have the downloadable demo bundle and the SVN but for a compete novice to Codename One this isn't front and center. Chen decided to address that by embedding the latest versions of the demos both into the Eclipse and the NetBeans plugins, now when you create a new Codename One project you can also create a demo project and "just run it". This allows you to quickly learn/debug our sample code which should help with the Codename One learning curve.