PyCon 2009 Argentina

Menu:

Recently...

Google Groups
Suscribe to The Prosciutto Project
Email address:
Check it out

    follow me on Twitter

    About

    Mario Zorz

    Mario has more than 8 years of experience in mobile technologies, design, development and implementation of products and mobile solutions for different industries.

    Categories

    General [35]
    History [3]

    Links

    General
    - Mailing list
    - Mario Zorz
    - The Prosciutto Project homepage
    - Follow me on Twitter
    Dev resources
    - SVN
    - Trac

    Menu

    RSS 0.90
    RSS 1.0
    RSS 2.0
    Atom 0.3

    Released under GPLv3

    A little bit of history, part 3

    proshadmin | 17 January, 2009 21:35

    (continued from A little bit of history, part 2)

    I just needed to do something about it: we didn't have that much time, we were spending long hours debugging and testing our applications and trying out lots of handsets, as many as we could get, and all that for testing just one application. Even minor changes demanded that the application be run on the handset testbed all over again to ensure some quality deliverables. If we were going to do this all over again with each new application we developed, we were in trouble.

    So I decided to go ahead and make an abstraction of what every application would need to do. I envisioned a mobile application engine that would be tested only once on every handset, and would be configurable enough as to run any kind of application on it. Separate the business logic from the actual java code, model the business logic outside of it, make a very simple configuration language and have business process analysts/modelers - not coders actually build the application. It was a no brainer, it would give us an unbeatable time to market, we could charge good prices and we would not spend so many nights fighting bugs. And it would be called ZAMAE (ZA Mobile Application Engine). My friend Fernando was not very keen to that idea (I have to say, he's far more pragmatic than I am) but I'm the stuborn type, so I kept on going.

    Back at those days, I used to commute to work by train

    Contrary to what anyone could think, the train was the place were most of ZAMAE architecture design ideas happened. I really had little time to think about it during working hours so I used to think and design on small notepads with the help of a pen when going to or back from work, write notes on it, and code that out by night when I got home.

    The first sketch that I got for ZAMAE architecture was sometime around the first half of November, 2006 (a little bit more than 2 years ago).

    So I guess you'll understand the iterative process we had to implement in order to get some stable ZAMAE version every now and then ;) (yes, like a lot of train trips)


    The underlaying mechanism of how data is stored in the UIApi is really the way that it is still managed today in ZAMAE. The idea is that an application is nothing but a set of forms that are linked together somehow, and each form has screen objects that belong to each form. So you could represent it as an array of Form objects (not exactly the class javax.microedition.lcdui.Form, but rather a custom, ZA-related kind of Form object), in the n level (rows) and each of those forms would have linked a an array of screen objects (m level, columns) that would be displayed accordingly whenever a specific form has the focus. The idea is very simple actually, and for performance purposes I thought that, whenever a form is to be drawn onto the handset screen, we would simply arrange that specific form array in a way that each object would be drawn from the farthest element (the form itself, such as a canvas) and then draw each of the following objects on the screen as found when traversing the array.

    To be continued


    Bookmark and Share

    Posted in History . Comment: (90). Trackbacks:(0). Permalink

    A little bit of history, part 2

    proshadmin | 05 December, 2008 20:56

    (continued from A little bit of history, part 1)

    In march 2004, I was hired by Telefonica Moviles (Movistar now, Unifon back at that moment) as VAS engineer. I met truly interesting people there (you know who you are).

    A funny fact: when at Movilogic, the entire world seemed to be using Palm devices everywhere to me. As soon as I got into Movistar, the entire world seemed to be using mobile phones instead. While it is true that my career orientation happened to go smoothly with the world's changes (Palm started to decay, shares went down, etc. while the handsets made by Nokia and Motorola became as shiny as ever), I often think it was just a coincidence. Unless you believe in destiny, of course.


    So, in my entrepeneur-ish side efforts, mobile phones seemed the way to go. I was in charge of the WAP services, including the wap deck and the content delivery platform, and the wap gateway to some extent until Telefonica bought Movicom Bellsouth to build Movistar, the largest spanish-speaking telecom group in the world.

    Then I discovered some mid and high end phones (at that time at least the Nokia 3100 was a mid-range phone in LATAM) could actually run Java code.

    So we started learning java, J2ME, the differences between MIDP and CLDC versions, the midlet application lifecycle, etc. We were amazed about everything you could do on such tiny machines.

    Soon we came to the surprise-surprise! Meet device fragmentation (follow that link and read this great article to understand what it is).

    As many of you fellow mobile developers most probably know by now, this is the most frustrating monster when you're supposed to develop an application that is targetting a wide target. It's simply desperating to find that your application, which used to run perfectly on your emulator or even on a couple of test phones, behaves erratically when you download and install it on a different model - not to mention if the handset is from a different vendor altogether.

    Since then, device fragmentation is one of the main (if not the only one) problems that I've decided to tackle in one way or another. In my search for purity, I found different efforts such as WURFL (which was never intended to tackle J2ME specific problems but rather WAP ones, anyway it surely is worth mentioning I believe Luca Passani is the pioneer in this kind of efforts) and later on J2ME Polish. J2ME Polish is the single most widely used mobile application framework nowadays, if you're intending to make some good looking app that will run on as many devices as possible. The thing is, J2ME Polish was not as popular until recently, and I just had to act and do something at the moment.

    To be continued


    Bookmark and Share

    Posted in History . Comment: (125). Trackbacks:(0). Permalink

    A little bit of history, part 1

    proshadmin | 14 November, 2008 19:27

    So you want to know how we came about making ZAMAE? and how I ended up open sourcing it under the name The Prosciutto Project?

    Ok then, read on.

    Back in early 2003 I felt I had enough courage to start something on my own in my free time. Apart from meeting my beloved wife Guillermina -who is the ultimate source of motivation for everything I do, as you will see soon- at that time I was working at Movilogic -which is still one of my favorite mobile dev companies- developing end-to-end applications on PalmOS and MSFT PocketPC platforms. With that expertise, I started looking for specific projects that I could handle in my spare time. I actually took almost anything, from coding a small python bridge between a legacy invoice system and the new fiscal printers the government set out to use, to even small assembly chunks -again for legacy systems. Yes, I really wanted to start something, but had no focus.

    Until Adox came into picture. They make critical care equipment such as respirators and infusion pumps. I came to know of their existence through an ad, they were looking for a "Palm programmer". They wanted some fancy graphic generators for Palm devices over serial links and bluetooth to be connected with their state of the art health care equipment. Amazing project! That's when I invited my friend Fernando to join in.

    As we both were working at least from 9am to 6pm in weekdays, we were forced to ask people to have meetings on saturdays or at late hours such as 7pm or 8pm, and do pair work either at his or my home til late night hours. We did several projects with Adox, but they quickly decided it was better to acquire the knowledge and continue the work themselves in their R&D department rather than having to lose every saturday afternoon ;). So they bought the source code along with some code tour / Palm programming classes that I happily gave. Was good for me, good for them, good for Fernando.

    To be continued


    Bookmark and Share

    Posted in History . Comment: (96). Trackbacks:(0). Permalink