ACCESS REMOTE WEBSERVICES? PERFORM OPERATIONS ON THE SERVER?

Script The webservice wizard is very similar to the GWT RPC functionality if you are familiar with that. We generate a set of simple static functions on the client side and then generate for you a servlet with some helper classes on the server side in order to implement client/server functionality. Lets start by adding a simple webservice to a hello world application. First lets launch the webservice wizard by right clicking and selecting it. This tool allows us to define methods and their arguments. Arguments can be the basic Java types, arrays and Externalizable classes. For simplicities sake I’ll just add a sayHello method with String argument and return value. When we press generate code is generated into the project, notice you migth get prompted if files will be overwritten. We also need to select the source folder of a web server project. I created a standard Java web project and I just selected it here in the tool. The first thing we need to do is open the WebServiceProxy class, its a generated class so its not very important however we need to fix the destination URL to point at the right address including the server context. Now lets look at the server generated code we have the classes in the io package and the proxy.server package which are fixed utility classes. Then we have the CN1WebServiceServlet which is generated to intercept your calls, the only class you need to concern yourself with is the class ending with the word Server which is the one where you should write your source code. Lets fill up the sayHello method with a simple implementation. In the client side lets just add a couple of buttons to the form and demonstrate the difference between a sync call and an async call. In a sync call we just invoke the method directly as if it was a local method. Notice sync calls will throw an IO exception if there was an issue in the server side. The async methods never throw an exception and will communicate success/failure thru a callback mechanism similar to GWT. Success is invoked when the method returns and passes the appropriate response value if relevant. Lets run this code. Notice that when you create a webservice you can’t change the methods after the fact, so if you want to add additional functionality you will need new method names so as not to break applications in production. You can also generate several servlets in several packages and just point to a separate URL. Thanks for watching I hope you found this tutorial educational and helpful. ...

Codename One

USE CLOUD CONNECT

Transcript In this short video we will discuss the new cloud connect feature. This feature makes it trivial to build GUI applications that run on multiple devices with one design. We’ll start by defining “cloud connect”. Cloud connect synchronizes the GUI builder with devices seamlessly. ...

Codename One

USE HTTP, SOCKETS, WEBSERVICES AND WEBSOCKETS

Transcript In this short video I’ll cover some core concepts of networking and webservices on mobile devices and Codename One First and most importantly for those of you coming from the desktop or server world, this might not be a shock that network on mobile devices is unreliable. However, the extent of this is sometimes surprising to developers who are new to mobile. That’s why many low level networking strategies are discouraged on mobile devices. ...

Codename One

USE PROPERTIES TO SPEED DEVELOPMENT

Transcript In this short video I’d like to discuss properties, we will start with a plain old Java object or POJO for short. You probably wrote a lot of these object classes and understand it at a glance. We use getters and setters for encapsulation. Those are the most basic properties. ...

Codename One

USE STORAGE, FILE SYSTEM AND SQL

Transcript In this short video I’d like to discuss the basic file storage API’s in Codename One. I’ll try to keep it relatively simple and skip over some of the more complex ideas such as parsing, externalization etc. I’ll start by talking about storage & filesystem. Storage is a high level abstraction, it might be implemented on top of file system but if you rely on that you might fail on the device as this isn’t always true. Storage is more portable, it doesn’t support file hierarchy such as directories. By contrast in file system we MUST use full file paths always. Storage is tied directly to the app and is usually private, this isn’t guaranteed for filesystem. Storage access is also cached for performance where filesystem access isn’t. But this brings us to a bigger core concept of mobile development, apps on mobile devices are completely isolated from one another and can’t access each others storage and usually can’t access each others filesystem files. This isn’t always the case, Android allows some restricted shared file system access but this is pretty tricky to pull off in a portable way. ...

Codename One