tazzix.com

Being a mobile developer I run into issues with testing of software applications on a regular basis. Hence, it was always a dream to have a perfect testing solution which does not render the cell phone / mobile device useless for other purposes. I spent some time with Mobile Complete and their solution covers the first part of the problem but you still can not do QoS testing from the perspective of an average consumer and the phones are modified big time.

I started exploring on this front as well and have come up with some features and ideas that should be present in such a system.

• Easy to program scripts running on the device in a non-distructive manner
• Functions executed in linear / iterative fashion, including:
  • KeyPress – keycode
  • KeyDown – keycode
  • Delay – milliseconds
  • KeyUp – keycode
  • AllKeysUp – void
  • PointerDown – x, y
  • PointerUp – x, y
  • NOOP – void (no-operation) to force a step in the report
  • Grouping of above commands to form functions
  • Extended library to directly perform tasks available from the underlying platform:
    • OpenURL – url
    • TakePicture – void
    • etc.
• HTML based reports, viewable on the phone, via an embedded HTTP server, or sent to a computer:
  • Step function, parameters, screenshot before executing, and comments for documentation
  • Cell ID can be included for rough location estimates (once cell-id to GPS coordinates are established)
  • For phone with built-in GPS, show coordinates and link to Google Maps, or Yahoo! Maps, etc.
• Applications:
  • Mobile Software testing
  • QoS testing of a service provider, mimicking an average consumer (the script runs through commute and all)
  • Mobile Web site testing, screen shots are enough to show what is going wrong
• Platforms:
  • Python – to run on S60 v2, S60 v3
  • Symbian – to run on various versions of S60 and UIQ
  • .NET to run on PocketPC and Smarphone based devices

When I started exploring J2ME in 2004, I started by creating some APIs which made my life very easy, however, somebody new to J2ME will need a steep learning curve in the restricted environment and on top of that to learn to use third party APIs. Hence, I envisioned that there should be a RAD environment that would allow using built-in J2ME classes, JSRs conditionally, and my APIs without the person need to know anything about any of these things.

This project is precisely here to convert the vision into a practical software. And this post is to keep me working on it.

Planned features:

• An abstract data type to encapsulate a “Screen”:
  • A wait (splash) screen shown while other objects are created including any data gathering from connectivity options
  • Connectivity provided for:
    • SOAP WebServices (via JSR, kSOAP, and wSOAP)
    • Servlet providing data separated rows by “|?” and columns by “||”
    • Bluetooth, IR, USB via JSRs
    • Custom class implementing connectivity interface
    • RMS via RMS to Object mapping, may also be used to cache data that is cacheable
  • UI provided by LCD UI, thinlet (XUL), charts, or table API.
  • Action handlers to perform UI tasks, navigation of screens (may use Hecl mobile scripting for advanced features)
• Rules for screen navigation
• Internationalization

During my shot at a master’s degree in Software Engineering, I was to select an unconventional language to write and present a report on. I came up with Lua and modula but they were taken before my turn, so I searched and found FORTH. This discovery proved very fruitful because I came to know of a language which could extend itself, never really imaginable to me earlier. But obviously if a turing machine could read its program from a tape then why not…?

Anyways, I learned a lot during the research report and wanted to use this language more often. At the time I had a Nokia 3650 phone which could use a Palm (ThinkOutside) Infra-red keyboard using a special driver. Which was an ideal setup to just start forthing away anywhere at all, hence, I started looking for a Forth interpreter which could run on this phone, but could not find any. I had written some J2ME APIs (specially floating point emulation on MIDP1.0) so my next target was to find a Java based Forth interpreter implemented as a standalone class so that I can wrap it up into a J2ME Midlet of my own.

I stumbled across SFI Forth and achieved the goal, the official page also hosts a download link for my version. And for Spanish? readers. It has no file or RMS persistence support but I have not been using it on better phones now, even though I have plans to enhance it a little whenever I have some time.

In the picture below you can see the setup in action, click to see a larger version.

Overview:

Some time ago the thinlet project dropped support for J2ME, but during my search for a XUL API for J2ME, I could not find a more suitable one. Therefore, I first customized the old version for some of my requirements, later on some new features of the thinlet API for J2SE were back ported to this J2ME version. And now its in a state where I think CLDC can compete with CDC using thinlet and maybe more than that

Features:

• Developed on j2me-wtk and Nokia Series 60, testing on Nokia 3650
• MIDP 1.0, CLDC-1.0 Compliant, i.e. can be used on any kind of J2ME device
• All features supported by thinlet API for J2SE
• Full screen text editing for text boxes, with dictionary (T9) support
• Jump mode support (left arrow to activate controls by mnemonic number)
• Touch screen support

Status:

• In production, and being used in my other projects
• Also used by other developers, there used to be Yahoo! group

Screenshots:

Initial version, modified color scheme, and an IM application:

Can you recognize that this is the same board as the previous post? Well now it has all the components anybody would ever need to learn every aspect of coding on this platform, really! It is a very simple and yet uses almost every pin/feature of the 8051. It is very cheap to build and covers the whole development life cycle of the controller just like for a production circuit, because you need to take out the chip and burn the new firmware then put it in again.

Features:

• 40-pin DIP controller 8052 or similar – ATmel being used here
• 12 MHz crystal
• Reset
• Buzzer
• LEDs on one port
• DIP switches on one port controlling the LEDs
• 5V regulator (can be powered by a 9V standard battery)
• 2 digit 7-segment display
• 2 push buttons, one to increment and one to decrement the number displayed
• RS-232 serial port can update numeric display and buzzer frequency, also send data of dip and push buttons to PC
• A simple PC application can show status of all connected peripherals

So I am back with my urge to do something on the hardware side, while being the regular expert in software, micro-controllers are the way to go. So I have some coding involved and less wires and components to debug in a different way this board just works, and the LED shows that it really does :p A lot more to come in this category though.

My Car is Intel Inside it is equiped with a customized computer for a car.

Main Features:

• Controllable by any consumer remote control, using DSP Line-in lirc IR receiver
• Full navigation system with maps
• Mandrake Linux 9.0 power operating system
• 40 GB storage for unlimited MP3s / Videos
• Optimized audio player irmp3
• Internet access – GPRS
• High fidelity 2.1 sound

I have returned to the workbench after a long time in 2004. Apart from a game-port custom
controller my last work was in the labs for logic design, microprocessor interfacing,
and microprocessor architecture.
My major is computers so the masters degree is going pretty uneventfull, specially when
I have a specialization “Software Engineering”.
Anyways I dived in starting with the famous 8051 microcontroller with a couple of variants
and after the initial testing phase, I am now ready to go to unchanted waters.

TODOs and Ideas:

* A microkernel operating system for 8051 family to ease my application development

* Phone logger, to keep track of complete land line log like mobile phones
and apply provider rules to calculate monthly bills

* Car tracking and utility system (variation of car pc for extremely low power requirements)

* Serial to LAN hardware which can be used to connect a serial modem to a router (wireless)

* Home automation system with support for infra-red remote (with possibility of bluetooth)

Overview:

This API provides Object Oriented Mappings over J2ME’s standard RMS
Features:

• Developed on j2me-wtk and Nokia Series 60, testing on Nokia 3650
• MIDP 1.0, CLDC-1.0 Compliant, i.e. can be used on any kind of J2ME device

• Support for all J2ME primitive data types and their class representations
• Support for Vector which contains any of the supported types / classes
• Support for pseudo-floating point (MIDP1.0 has no float)
• Support for any class implementing the persistence interface
• Filters, Searchers, and sorters can be applied at retrieval time

Status:

• In production and being used in my other projects
• May not give full performance on phones with slow processors
• May not be an optimal solution on phones having limit on RMS size or low memory

TODOs:

• Write a benchmark program and publish results

Overview:

Currently un-named, its goal is to provide a chart drawing package based on MIDP 1.0 specifications. Another goal is to make this package open-source, see help required below.
Status:

• Line charts are complete
• Pie charts are complete
• Bar and Bar with Line charts are working but require some minor changes
• Data can be given in categories and multiple lines and bars are drawn
• An area of the screen can be given for charting while application uses the rest of the screen
• With a sample application the obfuscated jar is 16 KBytes and takes 52 KBytes heap memory on the Nokia Series 60 emulator
• Axes drawing is partially working (lables and markers are missing)

TODOs:

• Customizations in drawing charts (Point circles, Axes stepping, lines in BarCharts, etc.).
• Chart titles, Axes titles, Data titles, Legend Charts for better explanation of charts.
• Finding a way to release the API in a way that source is hidden (till opensource efforts succeed).

Screen Shots:

Here you see a simple midlet on a Nokia 3650, with the charts occupying the whole j2me canvas area.