our journey with cordova-cli

Hey folks !

So we are back with a new post.This time would rather prefer to tell you a kinda story of how we fought we with cordova-cli and finally captured it in our captivity :P :P
Yeah .. Its time to celebrate .. But the success is at very initial stage right now.Getting stucked up with cli was disheartening, but conquering it was heartwarming :D

So to start, we aimed to make the various cordova cli commands work for sugar.All we knew was that we had to push some changes in the cordova-cli package.So quickly searched up where the cordova-cli code lied and downloaded it.Well, to our surprize, the cli code was nothing but a pointer to cordova-lib which was actually the backbone.So downloaded lib too ! But where do the both meet ? How to make them work together ? Though we had some documentation in the readme of cordova-lib.. but ahh .. it didn't work as expected.Spent days to figure what was wrong.Finally after hours of research, found a way to work around.

so let me get you know how we fixed up the things to let our changes in our local directory reflect in the cli on the terminal. The first was the discovery of ~/.cordova directory from where the library code for all the platforms is fetched once downloaded from their respective urls.This is the directory which enables us to copy the templates when we issue the cordova platform add command.Next, the correct linking between cordova-cli and cordova-lib,for this we had to go into cordova-cli directory and issue the npm link from there for cordova-lib.Once cordova-lib is there in the cordova-cli/node_modules then the changes done in directory cordova-cli/node_modules/cordova-lib  get it reflected on terminal.But we have to be cautious to remove the cordova executable file from usr/lib/bin directory which may be residing there from earlier installation of cordova-cli.Lastly to get a feel of our changes we move to cordova-cli/bin and run the cordova executable file present there.

Now let me take you through the digging we have done in the cordova-cli code. Firstly the executable that we run inside the bin folder of cordova-cli, simply calls cli.js of cordova-cli with process.args ( the arguments we provide) , the cli then calls for cordova-lib.js of cordova-lib in node_modules.Obviously apart from the cordova-lib, we do need a few other node dependencies as well.

Cordova-lib.js defines various files to be used with different commands - see here. So for the cordova commands, we are directed to the cordova.js inside cordova-lib/cordova.There different modules which eventually cater to our various category of commands like create, platform add etc are added.

For cordova create command, create.js in cordova-lib simply makes a new project with the specified directory name,id and app name but with no specific platform. To add a platform we issue ' cordova platform add <platform name >'. This calls for the platform.js.It looks in platforms.js [note a difference of 's' in platforms ;-) ] to see if there is an entry for the specified platform.If not it issues an error, else it downloads the platform's library from the url specified in platforms.js.Its only when the command is issued first time for the specified platform that cli downloads it else ~/.cordova/lib/<platform>/<version> is referred for the platform project template.The 'create' file in ~/.cordova/lib/<platform>/<version> /lib folder contains the platform specific script to add the files from the platform's library to the cordova project.

Once the platform has been added to the project, we then need to build project after coding up our logic in the app.For this the build command is broken into two parts, prepare and compile.The prepare part copies all the updated parts from the global www folder - projectDirectory/www to the native platform's www folder - projectDirectory/platform/<platform name>/www, it also updates the app name, package name,icons etc and installs and uninstalls the plugins through plugman.Once the relevant web stuff has been added to the native platform compile part then runs a script using superspawn.js which converts the web stuff to the native platform package.

So as far as today we are building upon the build command and hope to finish it soon :-)

A visual representation of all explained above can be found below ..

A quick update

This week's post is gonna be a bit short.I'll discuss what all we have explored and what we plan to do next.

So the previous week, as per the irc meeting, we  had decided to document up the things done and analyze what more we want to do. We had been focussing more on the code front till then but we decided to shift our focus to "thinking" for a week.So basically it was to analyze the different possible paths and define our goals in a better way and be sure of them.

I documented in details the code we have written, why we wrote that, mapping between what cordova wiki mentions and what we have done and what we need to do next. You can access it here.

So yesterday we discussed on irc the path we must now follow.For this week, we shall be focussing on cordova-cli and try to come up with the accelerometer plugin. As I dont have an xo currently with me, I would be simulating using a linux file.

Once the cordova-cli is done with we shall be able to convert a simple html page to a full blown .xo file which can be installed on the sugar. We hope to do this asap but currently we are facing a lot of issues to be resolved. Hope to get some results soon !

How to create activities with sugar web and help them communicate with python

In the middle of my posts related to the sugar cordova project, I would also like to share a simple and straight process to develop activities on sugar web and help them communicate with native python.

This post is to help all the developers out there who might as well want to develop some cool activities for sugar using sugar web and might need to communicate with the native python back end using the javascript-python bridge.

So here go the steps which you must follow :

1. Setup up the sugar development environment : http://developer.sugarlabs.org/dev-environment.md.html

2. Create a sample activity through command line - follow the steps mentioned here : http://developer.sugarlabs.org/activity.md.html

3.Once you are done with the initial set up of your activity then you can jump into more details, here are a few pointers on how to set up a link between native side and the javascript side using sugar web - 

• Compare this file with the file given here
• A sample call : look here in the first file goes to this line in the apisocket.py file
• So basically if we want to implement something on native front and call it in javascript, so code up your class in python in sugar and import it in apisocket.py and then code up a function in activity class of apisocket.py which wraps up the calls to your class or simply you can put your logic in the function itself if its not huge ( for getting started dont go for building a seperate class and importing, code up your logic in a function there itself to test whether it works).
• The function responsible for calling to the native side isbus.sendmessage.It has the following parameters :
•  the class and function to which call is made : like activity.show_object_chooser
• the parameters which you want to pass are defined in [] like [parameter1,parameter2,....]
• the callback function which has two parameters for the success and failure - when there is success the error object would be null else it shall contain the error
• The call back from native to javascript is made by the send_resultor send_error functions of the API Client class of apisocket.py file - you can see a sample usage of these functions in activity class functions of apisocket.py
• So as per your code logic you either call send_error or send_result function - incase of error call send_error or else return the object through send_result
• On the javascript side you check through the callback(3rd parameter of bus.sendmessage) that whether the error is null and invoke errorhandler or successhandler as per the result
• Inside the apisocket.py function , you can access the parameters passed by : request['params'][0] , request['params'][1] and so on ...

I hope the interested developers are benefitted from the post.

A special thanks to Manusheel for motivating me to write this on blog ;-)

An update of the week's progress

So its been a week to the previous post, and I wish to share what all we have experimented with and done during this time.

As discussed in the previous post, we were facing issues with the way cordova modules have been written and the way sugar web defines the js modules.So we need to convert the sugar web styled modules to that of cordova.For this we take the help of nodejs scripts which can do the interconversion between the two.At first we designed a script which was specific to env.js but we had to make it general so that other sugar web js files which have dependencies can also be converted to the cordova format.So we generalized the script.

Apart from this task, we ventured into the waters of cordova cli and found out how we can make the command like cordova platform add sugar and cordova build sugar work.So we have the cordova-cli repository here which takes care of the command line interface.But now the most of the code of cordova cli has been shifted to this repository named cordova-lib which has all the code for cordova api's.Here we have the parsers for the individual platform which perform the tasks when we give the cordova command.So to make our sugar platform work with the cordova cli we need to make something similar to that.

Now when we are almost through with the basic setup of cordova, so we decided to move ahead to look in for the features of cordova that can be replicated for sugar as well.We are currently studying the various plugins of cordova and trying to understand the complexity of each to implement on sugar.Soon we must be rolling over to the cordova plugin development for sugar ;)