Creating an iOS (iPhone) Provisioning Profile/Certificate

One of the hardest parts in developing for iOS is the total mess they made with their overly complex certificate/provisioning process. Relatively for the complexity the guys at Apple did a great job of hiding allot of the crude details but its still difficult to figure out where to start.

Start by logging in to the iOS provisioning portal

 

In the certificates section you can download your development and distribution certificates.

 

In the devices section add device id's for the development devices you want to support. Notice no more than 100 devices are supported!

Create an application id, it should match the package identifier of your application perfectly!

 

Create a provisioning profile for development, make sure to select the right app and make sure to add the devices you want to use during debug.

 

Refresh the screen to see the profile you just created and press the download button to download your development provisioning profile. 

Create a distribution provisioning profile, it will be used when uploading to the app store. There is no need to specify devices here.

 

Download the distribution provisioning profile.

We can now import the cer files into the key chain tool on a Mac by double clicking the file, on Windows the process is slightly more elaborate

We can export the p12 files for the distribution and development profiles through the keychain tool

In the IDE we enter the project settings, configure our provisioning profile, the password we typed when exporting and the p12 certificates. It is now possible to send the build to the server.

Codename One Info Graphic

Any feedback/suggestions about this infographic would be highly appreciated. We need to printout some rollups/fliers and we want to use this as the basis.

CN1 gallery

The gallery is usually an important piece in the puzzle when developers pick a platform, please tell us and the world about your apps.
http://www.codenameone.com/submit.html

Better Documentation For Codename One

A recent discussion in the Codename One discussion group convinced me of a more urgent need to replace the old LWUIT developer guide with something more up to date designed for Codename One from scratch. You can view it in full screen here.
If you wish to participate in authoring this document please make sure that any contribution you make is entirely your own and is not subjected to copyright from Oracle or other corporations. In that case use the contact us form in the website to ask for an invite with a valid email address.

Deep Dive Into The GUI Builder

The Codename One GUI builder has several unique underlying concepts that aren't as common among such tools, in this article I will try to clarify some of these basic ideas.

Basic Concepts

The Codename One Designer isn't a standard code generator, the UI is saved within the resource file and can be designed without the source files available. This has several advantages:

1. No fragile generated code to break.
2. Designers who don't know Java can use the tool.
3. The "Codename One LIVE!" application can show a live preview of your design as you build it.
4. Images and theme settings can be integrated directly with the GUI without concern.
5. The tool is consistent since the file you save is the file you run.
6. GUI's/themes can be downloaded dynamically without replacing the application (this can reduce download size).
7. It allows for control over application flow. It allows preview within the tool without compilation. 

This does present some disadvantages and oddities:

1. Its harder to integrate custom code into the GUI builder/designer tool.
2. The tool is somewhat opaque, there is no "code" you can inspect to see what was accomplished by the tool. 
3. If the resource file grows too large it can significantly impact memory/performance of a running application.
4. Binding between code and GUI isn't as intuitive and is mostly centralized in a single class.

In theory you don't need to generate any code, you can load any resource file that contains a UI element as you would normally load a Resource file:
Resources r = Resources.open("/myFile.res");
Then you can just create a UI using the UIBuilder API:

UIBuilder u = new UIBuilder();
Container c = u.createContainer(r, "uiNameInResource");

(Notice that since Form & Dialog both derive from Container you can just downcast to the appropriate type).

This would work for any resource file and can work completely dynamically! E.g. you can download a resource file on the fly and just show the UI that is within the resource file... That is what Codename One LIVE! is doing internally.

IDE Bindings

While the option of creating a Resource file manually is powerful, its not nearly as convenient as modern GUI builders allow. Developers expect the ability to override events and basic behavior directly from the GUI builder and in mobile applications even the flow for some cases.

To facilitate IDE integration we decided on using a single Statemachine class, similar to the common controller pattern. We considered multiple classes for every form/dialog/container and eventually decided this would make code generation more cumbersome.

The designer effectively generates one class "StatemachineBase" which is a subclass of UIBuilder (you can change the name/package of the class in the Codename One properties file at the root of the project). StatemachineBase is generated every time the resource file is saved assuming that the resource file is within the src directory of a Codename One project. Since the state machine base class is always generated, all changes made into it will be overwritten without prompting the user.

User code is placed within the Statemachine class, which is a subclass of the Statemachine Base class. Hence it is a subclass of UIBuilder!

When the resource file is saved the designer generates 2 major types of methods into  Statemachine base:
1. Finders - findX(Container c). A shortcut method to find a component instance within a hierarchy of containers. Effectively this is a shortcut syntax for UIBuilder.findByName(), its still useful since the method is type safe. Hence if a resource component name is changed the find() method will fail in subsequent compilations.

2. Callback events - these are various callback methods with common names e.g.: onCreateFormX(), beforeFormX() etc. These will be invoked when a particular event/behavior occurs.

Within the GUI builder, the event buttons would be enabled and the GUI builder provides a quick and dirty way to just override these methods. To prevent a future case in which the underlying resource file will be changed (e.g formX could be renamed to formY) a super method is invoked e.g. super.onCreateFormX();

This will probably be replaced with the @Override annotation when Java 5 features are integrated into Codename One.

Working With The Generated Code

The generated code is rather simplistic, e.g. the following code from the tzone demo adds a for the remove button toggle:


As you can see from the code above implementing some basic callbacks within the state machine is rather simple. The method findFriendsRoot(c.getParent()); is used to find the "FriendsRoot" component within the hierarchy, notice that we just pass the parent container to the finder method. If the finder method doesn't find the friend root under the parent it will find the "true" root component and search there.
The friends root is a container that contains the full list of our "friends" and within it we can just work with the components that were instantiated by the GUI builder.

Implementing Custom Components

There are two basic approaches for custom components:

1. Override a specific type - e.g. make all Form's derive a common base class. 
2. Replace a deployed instance.

The first  uses a feature of UIBuilder which allows overriding component types, specifically override createComponentInstance to return an instance of your desired component e.g.:



This code allows me to create a unified global form subclass. That's very useful when I want so global system level functionality that isn't supported by the designer normally.

The second approach allows me to replace an existing component:


Notice that we replace the title with an empty label, in this case we do this so we can later replace it while animating the replace behavior thus creating a slide-in effect within the title. It can be replaced though, for every purpose including the purpose of a completely different custom made component. By using the replace method the existing layout constraints are automatically maintained.

Share It With Your Friends

Chen added one of the cooler features we had in a while: the Share button. Those of you who aren't familiar with the amazing power of this button to propagate the popularity of your application should really take notice! Its a huge deal!

The Codename One share button uses the Android specific Intent when running on the Android family of devices and falls back to reasonable defaults on other platforms. It allows your users to tell their friends about your application or activity within the application with zero effort from your part. Essentially your users become your sales people!

On Android it supports all the native sharing intents SMS, twitter, facebook, email etc. For other platforms we currently support Facebook, SMS & email. We might add twitter but we have some legal concerns due to their use of the "problematic" OAuth 1.x standard rather than 2.x.

The code for the demo above can be activated with just a few lines and is a part of the updated Kitchen Sink demo:
        ShareButton s = new ShareButton();
        s.setText("Share");
        s.setTextToShare("Codename One is so COOL!!!");

Parsing In Codename One: JSON, XML & CSV

Codename One has several builtin parsers for JSON, XML & CSV formats which you can use to parse data from the internet or data that is shipping with your product. E.g. use the CSV data to setup default values for your application.

The parsers are all geared towards simplicity and small size, they don't validate and will fail in odd ways when faced with broken data.

CSV is probably the easiest to use, the "Comma Separated Values" format is just a list of values separated by commas (or some other character) with newlines to indicate another row in the table. These usually map well to an Excel spreadsheet or database table.

To parse a CSV just use the CSVParser class as such:
CSVParser parser = new CSVParser();
String[][] data = parser.read(stream);

The data array will contain a two dimensional array of the CSV data. You can change the delimiter character by using the CSVParser constructor that accepts a character.


The JSON "Java Script Object Notation" format is popular on the web for passing values to/from webservices since it works so well with JavaScript. Parsing JSON is just as easy but has two different variations. You can use the JSONParser class to build a tree of the JSON data as such:

JSONParser parser = new JSONParser();
Hashtable response = parser.parse(reader);

The response is a Hashtable containing a nested hierarchy of Vectors, Strings and numbers to represent the content of the submitted JSON. To extract the data from a specific path just iterate the Hashtable keys and recurs into it. Notice that there is a webservices demo as part of the kitchen sink showing the returned data as a Tree structure.

An alternative approach is to use the static data parse() method of the JSONParser class and implement a callback parser e.g.:

JSONParser.parse(reader, callback);

Notice that a static version of the method is used! The callback object is an instance of the JSONParseCallback interface which includes multiple methods. These will be invoked by the parser to indicate internal parser states in a similar way to a traditional XML SAX event based parser.

Advanced readers might want to dig deeper into the processing language contributed by Eric Coolman which allows for xpath like expressions when parsing JSON & XML. Read about it in Eric's blog.

Last but not least is the XML parser, to use it just create an instance of the XMLParser class and invoke parse:
XMLParser parser = new XMLParser();
Element elem = parser.parse(reader);

The element contains children and attributes and represents a tag element within the XML document or even the document itself. You can iterate over the XML tree to extract the data from within the XML file.

Where am I?

One of the latest and coolest addition to CN1 is maps.
The MapComponent is using OpenStreetMap provider to show the map.
The code was contributed by Roman Kamyk and was originally used for a lwuit app.

Below is the code of the screen above:



The example below shows how to integrate the new MapComponent with Google Location API.
make sure to obtain your secret api key from Google Location data API.
https://developers.google.com/maps/documentation/places/