For years we have been explaining to people over and over again: “Just use TextArea and invoke setUIID(“Label”)”.

This has three major

issues:

1. 
   People keep asking (always a bad sign, means the API isn’t intuitive enough).
   
2. 
   They also need to do other stuff – setFocusable(false), setEditable(false) so this is starting to get pretty verbose.
   
3. 
   This isn’t localizable!
   

When we

localize

an app the labels/buttons etc. (buttons derive from labels) are localized seamlessly. However, TextArea’s are not localized since we assume they will contain data which you normally don’t localize (user data is already in the right language). The problem is that in this case we do want to localize the label since this is really “a label”.

So I broke down, climbed down from the tree and added a SpanLabel class which is

solving RFE 919

.

Simple yet very helpful.

A similar situation exists in the location API code, we get a question once a week: why doesn’t getCurrentLocation() work?



So we start explaining that you need to bind a listener etc. bla, bla, bla…. Not very helpful…



If there is boilerplate you need to write maybe we should write it for you. This is what we did in the past when people had issues with the complex async version of capture. We added a synchronous version that was much simpler and the questions practically disappeared from the mailing list! So we are doing the same for the location API, we now have a new method:

getCurrentLocationSync();



which will return your location or null if there is an error.



Simple!

You should show a progress dialog while it is running since it might take some time.



Its not an ideal way to track location, this is only for relatively simple use cases.





On a different note I was reviewing code for one of our enterprise customers and on a call with said customer he pointed out that they re-did some of our GoogleAnalitics work. Turns out that when we weren’t looking Google published a REST API for the tool that allows tracking applications more effectively!


Back when they launched their new analytics for applications support, they didn’t have a REST API so we had to use the WEB API which sucks!

The customer in question agreed to contribute the code which I assimilated into our Analytics API. Its off by default but if you will invoke AnaliticsService.

setAppsMode(true) app tracking should start using the new Google API which might have quite a few advantages for you. We didn’t get a chance to test it much but it should be pretty cool.