We are thrilled to announce the immediate availability of Codename One 3.3!
With version 3.3 was tumultuous, we made a lot of earth shattering changes to performance, animations, fonts and many other things. As a result we have a ground-breaking release that requires a step back.
With 3.4 we want to tone down on the "big ticket changes" and work heavily on product refinement. We are already hard at work updating our docs and refining our general process..
We've been working feverishly to get Codename One 3.3 out of the door next week. Tomorrow morning we will finally have the codefreeze branch for 3.3 and we'll be able to focus on getting the docs/release in order.
The release should be on the 27th of the month and we should ideally get the plugins out of the door within the next couple of days.
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!
I deeply care about what we do at Codename One and writing a negative post even when the words aren't mine is difficult. I think one of the most valuable thing about an open project is honesty and open communications even when that's unpleasant, without open criticism we can't get better.
Chen recently sent out a request to fill out our survey via direct mail and responses came streaming in. Added to the guys who filled it out after our previous blog post we got a lot of additional valuable feedback. We can't satisfy everyone and we shouldn't aim to, however developers who spent time answering our survey probably like the basic concept of Codename One and should be happy. Most of them by a good margin (over 90%) are happy, but its only a good margin not a great margin and in this post I'd like to hash up the problems.
I had a big post ready for today but after a long twitter debate with @BrendanEich I had to write a followup as twitter is a poor medium for that level of debate.
This started with a blog post from Andreas Gal who effectively took the exact opposite stance to mine on Google's move to OpenJDK.
Then Mr. Eich picked it up...
I think we'll remember 2015 as the year we finally "hit our stride" and "got it". Up until now we did a lot of things correctly but were a bit disorganized both in the way we communicated Codename One and in the refinement of the product itself.
We changed and refined almost every piece of Codename One in 2015 and the results were great. But we want to do better so here is my analysis of what we did wrong (both in 2015 and before) and what we did right. Followed by the initial survey results and feedback from we got from you guys and our 2016 direction.
I've been following the news breaking since yesterday as a hacker news post highlighted that an Android commit included OpenJDK files. This is amazing news and a huge step forward for Java, its still unclear if this is just another move or the inkling of a settlement between Google and Oracle but I'm very hopeful that this is indeed a settlement. So far Google wouldn't comment on the court case and whether it was settled since its still ongoing.Read More
We released a new version of the introducing Codename One video almost a month ago but we just neglected to highlight it in the blog. Our old videos are pretty dated by now and we use far better toolchains for video production today, so we are in the process of redoing all our old videos. This is a long and tedious process that we do while producing newer content, fixes and moving forward. So the timeline of such updates is quite volatile. Check out the new video below.Read More
Historically, we didn't use Androids profiling tools often. They were pretty awful and the only tools that we really used extensively were the on-device GPU profiling tools which were reasonably good. In recent years Android's native story improved by leaps and bounds with the introduction of Android Studio and 3rd party tools developing native Android apps has improved a lot. But the CPU profiling tools are still stuck in the stone age and this is in stark contrast to the iOS tooling.Read More