Monthly Archives: January 2013

Codename One, Java, Javascript, Software Development

4 Ways to Consume JSON Web Services in Codename One

I just released a Javascript bridge for Codename One that allows you to communicate easily back and forth between Java and Javascript. This library may be absorbed by the Codename One core at some point in the future, but for now it is very easy to include it with your own projects.

There are countless ways that this Javascript bridge can be used to add value to Codename One applications. In this post, I will show how it can be used as an alternate way to consume JSON web services.

Codename One already includes a JSONParser class that allows you to, quite easily, consume a web service and parse its output into a tree of Hashtables and Vectors (I will demonstrate this method below). So why use the Javascript bridge to solve an already-solved problem? The answer is: Just to prove that it can be done.

Method 1: Load data using ConnectionRequest, and parse data into Hashtables and Vectors using the JSONParser class

E.g. Loading JSON feed from Youtube for Most Popular Videos

The benefit of this method is that it is a 100% Java solution that should work the same across all platforms. It should also be very fast and efficient.

Note: Codename One offers a Result class that makes it much easier to query the result of the JSON parser. Read more about it in Eric Coolman’s blog post.

The amount of code required to consume and parse the request is not really relevant because it can all be wrapped in a single method with a callback for the result.

Method 2: Load data using WebBrowser and use Javascript’s JSON.parse() function to produce a JSObject

E.g. Loading JSON feed from Youtube for Most Popular Videos

The benefit of this method is that it is easier to obtain nested content stored in a JSObject than in a tree of Hashtables and Vectors. E.g. The same example as above (to obtain the make of a car in the result set) could be carried out on 2 lines:

JSObject response = (JSObject)context.get("JSON.parse(document.body.textContent)");
String make = response.getString("people[0].car.type.make.name");

Method 3: Pass a JSON String into JavascriptContext.get() to obtain a JSObject

E.g. Loading JSON feed from Youtube for Most Popular Videos

This is really just a hybrid of the two approaches, and it is useful if we’ve already loaded the JSON data and have it in a String. E.g. perhaps we used ConnectionRequest to load data from a Web Service, and some of the Data is JSON and some of it is another format. In any case, this method assumes that we have a String of JSON data and we want to turn it into a JSON object so that we can work with it.

Then we can pass the string directly to JavascriptContext.get(), and the WebBrowser component will handle all of the parsing.

JSObject response = (JSObject)context.get(jsonString);
String make = response.getString("people[0].car.type.make.name");

Method 4: Load data with the WebBrowser and parse it using JSONParser

E.g. Loading JSON feed from Youtube for Most Popular Videos

This is really the inverse approach of method 3 above. In this case we load JSON data in the WebBrowser, retrieve it as a string using JavascriptContext.get(), and then parse it using the JSONParser class.

News

AditNetwork : A Pyramid Scheme By Any Other Name …

Pyramid schemes have been around for ages. They are illegal now in Canada and the United States, but that doesn’t stop people from trying to start them up. Pyramid scheme operators have gotten crafty over the years. The “new” pyramid scheme is one that infuses a supposed product or service into the scheme so as to obfuscate its true nature as a pyramid scheme. The thing that I find frustrating is that there never seems to be a shortage of gullible victims for these schemes.

One example that I recently ran across is ADITNetwork. I uncovered this program during an investigation of strange Google Analytics results in one of the websites that I’m involved with. The website was receiving large amounts of traffic for periods of about 90 days long. Then this traffic would all disappear for a period of 90 to 180 days. This cycle occurred 3 times before I finally started to dig into the cause.

I saw that during the periods of heavy traffic I was getting a large amount of traffic (nearly all of it) from aditnetwork.com and other IP addresses that could be traced back to aditnetwork.com. But we weren’t paying them for advertising and, in fact, we weren’t doing any advertising at all so wasn’t sure exactly why they would be giving us all of this traffic.

All of the traffic was to our home page and there was 100% bounce rate.

I had to ask, what was their deal? Why would they be giving us all of this free traffic? And why was there such a high bounce rate? Something certainly wasn’t right.

The AditNetwork website is non-specific when it comes to exactly how it works. It does say:

ADITnetwork.com helps our clients establish a professional global Internet advertising platform, combined with an efficient marketing system. We can help to improve the clients website’s traffic and ranking effectively. We help the small and medium business owners not only get to be more popular and reach more potential markets, but also get more benefits through affiliate marketing. Our customers will have continuing long-term interests. We’ll form a win-win situation for all the partners and the company.

So this makes it look like they offer web-based advertising to web sites to help get them traffic. That sounds like a legitimate operation. But it still didn’t answer why they were sending us traffic, when we have never asked them to.

After a couple of Google Searches for “AditNetwork Scam” etc.., I was very surprised to find two things:

1. Google was full of pages talking about how you can get rich with Adit Network.
2. The only pages that mentioned the word “scam” seemed to be saying that it wasn’t a scam, and that it was a great business opportunity.

After reading a Facebook fan page for them, and watching a couple of Youtube videos (here and here, I now understand what their game is.

Basically they pay people to click on web advertisements. At first I thought that this was just a simple ad-clicking scam where they pay people to click on ads, then split the money earned from the click. However, that isn’t how it works. In fact, people (i.e. suckers born yesterday) *pay* AditNetwork for the privilege to be able to click on advertisements. Then, if they click on enough advertisements, they can earn up to 70% of their original investment back.

That 70% is the crux of the grand bargain. It is the remaining 30% that provides the cash pool upon which the pyramid scheme operates. Of course nobody would invest in business where the maximum they could earn was 70% of their original investment. Participants can only make a profit by signing other people up, for which they get a cut. Essentially they’re just receiving a cut of the 30% (minimum 30%) that AditNetwork will make off of their sign up fee. The following is a screenshot from their Youtube Promotional video:

Notice the break down. They pay 10% commission for people you sign up, 4% for people they sign up, down to 1% for the 9th and 10th level of sign up. And you need to be a VIP member (i.e. pay them $5000 in order to get commissions down to the 10th level). Let’s do a break-down of where the money goes if I sign up for AditNetwork. Let’s assume that commissions are paid all they way up 10 levels to an original VIP member. Then:

10% goes to the guy who signed me up
4% each goes to the next two guys up the ladder
2% each to the next 5 guys up the ladder.
1% each to the next 2 guys up the ladder.

Adding that up we get 10% + (2 x 4%) + (5 x 2%) + (2 x 1%) = 30%.

We have our magic number of 30%. So if I happen to earn back all of the remaining 70% of my investment by clicking on ads, then we see exactly where all of the money is going. Of course, if I fail to make back the full 70% or the ladder doesn’t go up that high in my case, the extra money just goes to AditNetwork. But they make money either way because they are the original VIP investor.

So we can break an AditNetwork investment down into two parts:

1. 30% of the investment goes into a pyramid scheme.
2. 70% of the investment is a deposit that you make and work off by clicking on ads.

Presumably, AditNetwork plans to be making money also by selling actual advertisements (i.e. getting websites like mine to pay them for the traffic that they generate from people clicking on ads), but an advertiser would have to be brain dead to pay for this traffic if they knew where it was coming from.

This is just another example of how easy it is to prey on people’s willingness to believe in “a free lunch”.

AditNetwork is doomed to fail because it is built on a house of cards. I’m not sure if it’s strategy is obfuscated enough to evade the laws against pyramid schemes, but it is clear that it cannot survive in the long term and many, many people will have lost their investment when the scheme dries up (like all pyramid schemes do). Advertisers would be silly to pay for advertisements on AditNetwork because the traffic they receive is false traffic (people just being paid to view their site). And the revenue stream that is being shared is coming 100% from sign-up fees. No useful work is taking place. No useful product is created. No useful service is being carried out. It is just money being funnelled in from the bottom of the pyramid to the top.

It is really sad that there seem to be so many people who allow themselves to be deceived by operations such as this one.

Codename One, Java, Javascript, Mobile Development, Software Development

Develop for Mobile or Die!

If you develop software that is designed to be used by Humans, then you are now required to develop mobile-friendly user interfaces.

In 2011, a mobile user interface was a luxury. In 2012, it was a nice add-on. In 2013, it is a requirement, or your software will be headed for the junk bin. Smart phones are now ubiquitous, and tablets are taking the place of the laptop in many contexts. People are becoming savvy to what can be accomplished with a tablet, and their expectations have been significantly raised for all software that they use.

Of course, the desktop (i.e. computers with mouse or trackpad and keyboard) is not going anywhere. It is just being reserved for those heavy-duty tasks that cannot be performed with a touch device like (and this list is shrinking every year) video editing, software development, and word processing. One class of application this can now be handled wholly via a mobile interface is the CRUD application. And if it can be created for mobile, it should be created for mobile – or your users will complain (either silently by seeking out other solutions, or loudly in email).

One trend that I noticed in 2012, was a shift of user gripes originating from users using IE to users on mobile devices. At first, my canned response was: “please use a computer, not your iPad, for using this database”. Of course, the software worked on iPad, but it wasn’t optimized for the platform so it was a little painful to use. And even under the best of conditions, users will find a way to break a UI. At first, there were some valid reasons why the app had to be used on a computer. But at this point, there are no longer any technical barriers in the way of providing a mobile interface to a (mostly) CRUD application.

Transitioning CRUD Applications to Mobile

The easiest way to transition a CRUD application to mobile, is to use an HTML library like jQuery mobile. It provides a slick UI that is very similar to native. The simple act of adding a UI in jQuery mobile that is tailored specifically for mobile users will eliminate most gripes. The larger buttons and fields, combined with a more familiar mobile workflow will make your users much more at home inside your application.

Unfortunately, the similarity to native applications will invariably lead your users to start requesting features that they have seen in other native applications. E.g.:

  • We want to be able to take videos with our phone and upload them into the database. Can we do that?
  • We want to be able to use the database without being online. Can we do that?
  • We want the database to be able to track our movement and velocity and store this in the database. Can we do that?
  • The application is kind of sluggish when loading pages and scrolling, etc…. Can you improve it?

The list of feature requests is not even limited to things people have seen before … the possibilities are endless.

While HTML5 is improving all the time, and it does technically support offline apps, and limited video access, it is still very flaky, and does not approach a native experience yet. Ultimately, when your users start asking for native-like features, you need to start looking for a way to build an application that is treated as a first-class citizen on the mobile platform of choice.

Mobile Platform of Choice??? Do I really need to Choose?

The next step after outgrowing your HTML5 mobile interface (with jQuery Mobile), is to look at your options for developing a native application. I’m using “native” in a very loose sense here. Really what I mean is an application that is installed on a mobile device in the same way as the platform’s native applications. This could be an application that is written directly using the platform’s SDK or using some other toolkit that ultimately builds an application that can be installed on the device.

If you are developing a CRUD application for an organization (like I usually am), you may or may not be able to dictate that your users use a specific device. In my case, I usually can’t… or if I try it is a world of pain dealing with people that use “the other” platform. Therefore, developing separate applications for each platform is not really an option (or good use of resources). I’m still choked at having to venture outside the web-box, much less create multiple versions of the same app.
At the minimum you’ll need to develop versions for Android and iOS (but BB and WinPhone users might get on the gripe-wagon, so watch out!!).

Phone Gap

As a web developer, naturally, the first thing I looked at was Phone Gap. It allows you to develop your application using the same web tools (HTML/Javascript/CSS) and deploy it as a “native” application. The native application is essentially just a thin wrapper around a web view component. It provides some additional libraries for working with the device’s hardware like accelerometer, GPS, video camera, etc.. Because it is just a web view wrapped in an app, you can use all of the same libraries (e.g. jQuery Mobile if you like) for developing the app. If you’re lucky you won’t have to modify the existing web app at all.

Building the applications for Phone Gap can be a little more involved, as different platforms need to be set up differently, and some even differences in the application code to make it work. However, the PhoneGap build service is available to provide building in the cloud for multiple different devices. This should ease the “pain” substantially.

Phone Gap will probably give you enough flexibility to add most features you need in a CRUD application. However, you may run into issues with performance. Javascript/HTML runs much more slowly (and noticeably so on low-powered mobile devices) than native code. Facebook’s shift away from HTML5 apps to native apps last year is a key indicator that, for mobile at least, HTML5’s time has not yet come. This performance will be most noticeable when performing scrolling operations and in some transitions, but it can rear its head anywhere.

To make matters worse, on iOS, the UIWebView component doesn’t use the same Javascript engine that is used in the Safari web browser. It is substantially slower. So, by moving your application from the Web into a PhoneGap app, you will be facing a performance penalty directly from Apple.

If you are running into performance problems, or you require native features that just aren’t offered in Phone Gap, you may need to graduate to the next level: Real Native Apps

“Real” Native Apps

First, let me define what I mean when I say “Real” native apps. I mean applications that are compiled down to native executables on the supported platform. I disqualify Phone Gap from this category (and the many other HTML5 in WebView solutions) because the actual code is running inside a web sandbox.

If you have reached this level, you should at least take the various platforms’ native toolkits for a spin so that you understand how they work. Each platform offers its own unique vision for their mobile worlds. And some concepts don’t transfer easily from one platform to another. Developing for iOS is very similar to developing for Mac OS X. You use Xcode and Interface builder to develop your application logic and user interface. Generally the entire user interface is contained inside a single Nib file, and you can use the many UIController classes to control the user interface. iOS includes many useful frameworks such as CoreData which makes it easier for you to develop CRUD apps on iOS.

Android, on the other hand, is an XML jungle. The UI is defined in XML files, and so is the application configuration. It is a much more open environment than iOS, in that it is set up to encourage applications to share its components with other applications on the system.

Blackberry and Windows Phone provide their own models, but I’m not familiar with either of these platforms.

In the course of auditing the respective SDKs you’re bound to observe the elephant in the room: All of these SDKs use different programming languages. iOS uses Objective-C, Android uses Java, Windows Phone uses C# (or C++ depending on version), and Blackberry uses C++ (at least for BB10… older versions use Java).

This makes it very difficult to share code across multiple platforms. Since I don’t have the resources to maintain separate code bases for each platform, I need to either pick a single platform and run with it, or look for a solution that will allow me to develop for all of the platforms with a single code base (remember I have disqualified Phone Gap and its HTML5 ilk already if I have reached this point).

Luckily there are options:

  1. MonoTouch provides C# bindings for pretty much the entire Cocoa Touch API (iOS). It also provides bindings for Android.

  2. J2ObjC is a tool developed by google to convert Java code to Objective-C so that it can be reused for iPhone development.

  3. Oracle ADF provides a full development toolkit that allows you to build for most mobile platforms. It uses an embedded JVM for business logic, and Phone Gap for the UI…(should we disqualify this out the gate because of Phone Gap?)

  4. Appcelerator Titanium provides a cross-platform solution that provides Javascript wrappers around native components. It is different than Phone Gap in that it doesn’t run inside a web view, it merely uses the native platform’s built-in Javascript interpreter and bindings to access native components.

5. XMLVM is a low level converter that allows you to convert code between many different languages. It provides compatibility libraries for working with Android and iOS. In my opinion, this is the most ingenious software development of the past 10 years.

  1. Codename One. Codename One allows you to write mobile applications in Java and compile them into native executables for most major platforms. It uses XMLVM under the hood for its iOS port. This is, by far, the best option right now for cross-platform native mobile development, and I’ll explain why in the following section.

If you know of other options, please let me know.

These solutions can be grouped into 3 categories:

  1. Tools that assist in porting from one platform to another, but don’t provide a full development solution. These include J2ObjC and XMLVM. While these are very interesting projects, it our aim is to be able to build a cross-platform web app, then these projects won’t get us there directly. If you are developing a tool or SDK that is designed to help you and others build cross-platform apps, then these projects may be of great interest to you.

  2. Tools that allow you to share your business logic between platforms, but ultimately require a rewrite of the user interface for each platform. MonoTouch falls into this category. Really MonoTouch is a solution for C# developers who want to develop for iOS and would prefer to use C# instead of Objective-C. It isn’t really a solution for building cross-platform mobile applications.

  3. Tools that provide a full solution for developing cross-platform mobile applications. Codename One, Oracle ADF, and Appcelerator Titanium fall into this category.

Oracle ADF

I have watched videos and read documentation for Oracle ADF, but have never actually tried to build an application with it. There are a couple of show-stoppers for me on this platform:

  1. It is commercial. I wasn’t clear on the license costs, but it makes it sound like they are hoping to make large license fees off of large enterprises.

  2. They use Phone Gap for the UI. If I’m at this point (looking for a native solution and Phone Gap won’t cut it), then, ADF doesn’t meet the requirements.

Appcelerator Titanium

Appcelerator Titanium is a clever project. I spent some time last year using the desktop version to develop some desktop applications using Javascript and CSS (the desktop version actually works more like Phone Gap than their mobile version does… it embeds a web view in a native window). Ultimately I abandoned all of my desktop Titanium projects as it was apparent that the Appcelerator people were putting all of their development resources into their mobile edition and letting the desktop version languish.

The mobile edition has some promise and apparently it has their full weight behind it. The concept of using Javascript bindings for native components is interesting, although it leaves open some of the same performance problems that plague PhoneGap. From what I have read in various forums and blogs, Appcelerator mobile apps do run into performance and memory problems if they are not developed carefully. Although they seem to be getting better with each release.

Appcelerator provides an API that generalizes commonalities between different platforms, but it enables you to write plugins that are platform specific if you need to use features of a platform that aren’t available in the API. This blog (presumably by someone who knows titanium – “titaniumninja”), argues that Appcelerator isn’t really a “Write Once Run Anywhere” tool:

Titanium isn’t a write-once-run-everywhere platform. As Appcelerator’s guys use to say, its aim is to be a write-once-adapt-everywhere tool, since, while using a common high level language and API, it enables the exploitment of platform specific features when needed. This philosophy is clearly visible in the API, as we have entire sub-namespaces dedicated to either iOS, or Android. This allows adapting our mobile applications to the platforms where they’re executed, thus avoiding a write once, suck everywhere effect. Moreover, the possibility to develop custom native extensions to the framework opens up a wide range of development scenarios, ideally allowing us to create user experiences that are practically undistinguishable from those of applications developed with native SDKs.

This description/warning seems realistic and makes me optimistic about the platform. If you are a Javascript/CSS ninja, then Appcelerator will probably provide an accelerated path to a mobile application, while not inhibiting you with a glass ceiling. I really like to be able to build native plugins for high-level frameworks. Otherwise I feel like I’m one feature request away from having to abandon the platform.

Without having dug too deeply into Appcelerator’s API, there are a couple of negatives (when compared with Codename One or native app development) that appear right off the bat:

  1. Javascript is a bitch to debug compared with managed languages like Java and C#.
  2. Memory management and performance are likely issues, and you may need to dig into the “native plugins” crutch sooner than later to resolve such issues.

If Appcelerator was the only cross-platform solution on the market, you can bet I’d be using it.

But Codename One exists…

Codename One

I have been developing with Codename One for a couple of months now. Based on that, you would probably guess that it was my choice for developing native mobile apps. You would be correct. When you line up all of the other options for development (native SDKs, Appcelerator, ADF, etc..), Codename One wins on almost every front.

What do I like about Codename One?

Codename One is the only true write-once-run anywhere solution out there (for native apps). It uses OpenGL (I believe on all platforms, but any graphics toolkit could be used if something better came along) as the foundation upon which its rich set of components are built. This makes it much easier to port to different platforms than, say Appcelerator, because all of the widgets are light weight (Similar to Swing in the Java Desktop world). The user interface can be styled using themes to look exactly like the native platform, and they provide native themes for all platforms for which they produce apps.

Applications are written in Java and they are compiled into native binaries (on iOS they use XMLVM to produce native C code that is compiled into an ARM binary using LLVM). They provide plugins for Netbeans and Eclipse, as well as a simulator to be able to run and preview your apps right in the IDE. The resource editor application also provides rich GUI development tools for forms and themes.

Basically, they have provided for the entire development cycle. They don’t leave you hanging. They even provide a cloud build server for you to build your applications without having to install the native SDKs. This allows Windows users to build iOS apps, and Mac users to build Windows Phone apps. (Initially I was concerned that I wouldn’t be able to do my own builds offline, but this was unfounded, as I was able to, without too much difficulty, set up my own build environments for iOS and Android… and I have no reason to believe it will be any more difficult for Blackberry).

The performance of CodenameOne apps is near native, and may even be faster than native apps in some case (e.g. Java method calls are 3 to 4 times faster than Objective-C message calls).

All of these features (the GUI builder, simulator, build server, Netbeans plugins, etc..) was enough to make me try it. But I stayed for the API. CodenameOne’s API is a joy to use. Their founders have a real knack for building clean UIs that are easy for developers to figure out. It appears to be heavily influenced by Swing, but with all of its demons exorcised. As an experiment I set out to write an application using the Android SDK, the iOS native SDK, and Codename One separately to get a feel for the differences in the API. By far, the Codename One API provided the most fluent experience.

In places where the API doesn’t support something, Codename One provides native interfaces that allow you to develop your own native libraries that interoperate with Codename One. This means there is no glass ceiling. Anything you can do on a native platform, you can do on Codename One.

If you are a Java developer, you really should be using Codename One to develop your mobile apps. Otherwise you are wasting precious resources and excluding potential users and platforms from enjoying your application.

If you are not a Java developer, and you want to develop mobile apps, I still think that you would be better off learning Java and jumping on the Codename One wagon than spend your time developing for another platform.