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
LoginCallback classes that use oAuth by default to perform the login.
Up until now when building with include sources for iOS we also included a btres directory which was necessary for the old VM but no longer necessary in the new VM. This increased the distribution size considerably and we are now removing it to speed up the builds and reduce server costs. When we were in the process of reviewing the sizes of apps we noticed quite a few apps with resources weighing well over 5mb which would probably cause performance issues for your application, we suggest reviewing such apps and optimizing them.Read More
Let’s face it, your app is probably a commodity. As noted by Wikipedia, “a commodity has full or partial fungibility; that is, the market treats its instances as equivalent or nearly so with no regard to who produced them.” In basic English it means that your product can be easily replaced in part or completely by another to satisfy the needs of the market. For 99% of apps out there this means that if a user doesn’t find your app, they’ll pick another one that they think fills the need they’re looking to satisfy. This the same whether your app is a game, a productivity app or any other category.Read More
We've been spending a lot of times looking at performance for one of our enterprise customers. As part of the investigation he came up with an interesting and very important find... He found that
hashMap.get("String") was much slower under the new VM than under the old VM. Its these sort of "simple" finds that help narrow down bigger issues in performance that might impact a lot of things in Codename One, since HashMap is so ubiquitous the implications of improving it can be huge.
We are in the process of migrating the storage implementation from App Engine to Amazons S3 storage as part of our bigger migration away from App Engine. If you experience issues related to build results please let us know so we can iron out potential regressions.
We are deploying this change in a way that makes it very easy to toggle this on/off and in case S3 builds prove to be an issue we will be able to revert them quickly.
Notice that the synchronous build feature is an enterprise only feature since its overuse can have a very heavy toll on our servers.
Google has just announced that it is deprecating cloud storage and effectively a major part of App Engine that we are relying on. To make matters worse the window of time to its removal is quite short so we don't have enough time to rewrite and adapt all the various API's and tools that rely on this API.
We have already started the process of migrating off App Engine completely both due to rising costs and Googles horrible service/support. This will also allow us to finally support many long standing user requests such as more powerful push API's etc. since we will no longer be held back by App Engines limitations.
Our build servers are really fast, even if your laptop is relatively slow our iOS build servers are powerful machines equipped with fast SSD's and they generate a full clean build of a typical app (with screenshots etc.) in a couple of minutes!
So the real source of delay when building an app is size, it both slows the build but most of all it slows your upload process (upload is typically much slower than download). Reducing the size of your app will make it faster in runtime as well, e.g. if you have too many redundant resources you might be running into too many GC cycles slowing down execution. In this post we provide some tips to shrink your app size.