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…
You’d be better off than anyone who used parse and its far less likely to happen. Codename One is “what we do”
and have been doing for the past 4 years. More importantly, unlike Parse you could just use the open source project
and your users wouldn’t be the wiser. Since Parse is a service that needs to connect to a hosted server everyone
who used parse (myself included) need to develop a rather complex strategy of moving their hosted data (which is
live) while moving their users some of which might still have the old version that use parse on their devices…

When you are looking at PaaS services you need to always evaluate the case of the PaaS closing down (this
is true for IaaS as well but to a lesser degree), in that sense Parse is quite problematic since its effectively
exposed to user installs. Codename One is far safer since the built app doesn’t really need Codename One anymore…

As I mentioned above before taking a long detour, I have a personal app that relies on Parse so I will need to port
it to a different infrastructure. Most of the code there is already well abstracted but I will need to find a way
to migrate the data and also pick a host for the data. I will try to publish the process in a way that helps other
parse4cn1 users with the migration.

Slowing Down New Feature Development

We have set an ambitious goal of posting less news for the month of February and probably March too.
As developers we always want to build a shiny new thing and satisfying a feature request from a user is often
rewarding and cool. However, this means we don’t spend the time writing documentation, generating tutorials
or working on things such as performance, the new windows phone port, fixing bugs etc.

None of those things are really news worthy, so spending the time just writing a blog post about better
JavaDocs/samples for a particular package is probably not very helpful. But this is crucial, we need stability
and refined docs in order to communicate better even with our top developers. As we work on the docs we
see exactly what people have been complaining about. We have a lot of documentation but it is quite bare
and isn’t at the level it should be.

This is a big task and you can already see a lot of the results in the first two chapters of the developer guide and
within the javadocs.

New Features/Enhancements

In direct contrast to the statement above, some features did get thru despite our best efforts…
We added getActualComponent()
to ActionEvent,
this allows us to handle events better for lead components such
as MultiButton.

Finally we added terse
encloseIn
methods to the
TableLayout
class.