Connecting Groups
Back to SiteGroups!

SpringSters - Blogging Bunch

We think therefore we are

J2ME platform Limitations and ways around these limitations

Posted by sagar on September 27, 2007 RSS Feed

I am a J2ME fan but that doesn’t stop me from noticing some of the limitations of J2ME J.This post is about some of the ways/ideas I have found to overcome those limitations.

 

  1. In J2ME as we all know there is no API for sending an email. Such an API would have been of great use when we wanted to send an email through our J2ME application. But if you just have to send an email through a J2ME application you could pass the email subject and body as well as the senders and receivers name to a Java Servlet the Java Servlet will then collect all this information passed to it by the J2ME application and use Java Mail API to send the email to the desired recipient.
  2. There is no way to access the SMS inbox in J2ME this is because the J2ME midlet runs in a sandbox and has limitations on what all operations it can perform.The idea for overcoming this limitation is to have a native program (written in the native O.S.) which reads the SMS inbox and writes to a Local Socket the J2ME application can then read the data from the Local Socket. But this is not perfect solution because we will require different native programs for different devices.
  3. Every mobile device has an SMS port i.e. the port at which the mobile device receives the incoming Messages (SMS) for example Nokia devices receive SMS at port 0. Now for a Midlet to receive the incoming Messages(SMS) it has to listen at a specific port on the device. Now one can send Messages (SMS) to a device using J2ME (i.e. by using Wireless Messaging API) as well as the normal method (without using J2ME).The Messages send using normal method will be received by the receiving device on the SMS port. On the Other hand Message send using J2ME will carry port number and will be send to a specific port of the receiving device. So we require a midlet on the receiving device listening on that specific port to receive a SMS sent through J2ME.This puts forth an interesting question i.e. if we have a midlet listening on the SMS port of the device will it receive both type of message? (i.e. Normal messages as well as message send through J2ME.) I actually tried it out and found that this didn’t happen. I was unable to receive both types of messages on the device when my midlet was listening for messages on the SMS port of the device. So we can say that we can only receive the Messages sent through J2ME when we have a midlet listening for messages on the receiving device. As I said previously there is no way for accessing the SMS inbox in J2ME but what we can do is to have a midlet listening for SMS on a specific device i.e. get the Message before it actually goes to the inbox and we can have our own created inbox (J2ME application created) for storing the Messages received by the Midlet.
  4. We use platform Request method in J2ME for making a voice call. But the problem here is that we really don’t have any way to end a voice call programmatically. The facility such as ending a voice call programmatically would have been useful for situations such as giving a Miscall through J2ME.The problem with platform Request is that it is totally under the native Systems control so once we call the platform Request for making a voice call we have no way to stop this initiation of voice call programmatically. But now the Mobile Telephony API (MTA) (JSR - 253) is released which promises to have more control over voice call initiation and by using this API we can also end a call programmatically. But still no device yet supports or has the implementation for this API.
  5. Many times we would like our applications to provide Text to speech facility but there again because of the limited resources on the mobile device we may not get fast conversion of text to speech. By that I mean that there may be a some time lag between text to speech conversions of each word because of the limited processing power of the mobile device. The only idea I can think over here is to pass the entire text sentence to a servlet and J2SE also has some classes for text to speech conversion and get back the audio from the servlet and simply play the received audio in the midlet.By doing so we are assigning the much heavy operation of text to speech conversion to servlet which will run on some server and will definitely have more powerful resources than that of the mobile.

Watch out for more in the next post J


Memory Management on Mobile Platform

Posted by kiran on September 21, 2007 RSS Feed

 

When I was a school kid, I never actually worried about the resources I was using or occupying. I always finished my pocket money before the month end. I was wasting a lot of resources and the reason for that I think was that I didn’t realize where the importance and also the source of resources! But after finishing my schools I never remained careless about my resources. I would attribute the change to learning C and C++ in my college. “Isn’t it funny?” J … Yes, the memory management in C and C++ encouraged me to handle my resources.

Then came mobile platforms in my life. The best platform to learn doing a lot of things with very less resources. Every chunk of memory you allocate, needs a reason to do so. Gives another dimension to your resources handling skills.

In last few years I have come across a few mobile technologies. Started with Symbian switched to Palm OS for some amount of time and then back to Symbian a little bit of Windows mobile here and there for a change of taste for few days. I came across different memory management techniques, ways to handle exceptions. And of course distinguishing features for every platform. For Palm its “Locking and unlocking of memory chunk”. This I could talk about in one of the later posts. This one is about my first love Symbian and the bunch of features that distinguish Symbian

Two of the Symbian features I like most are:

  1. Two phase construction
  2. Cleanup stack

Two phase construction:

How do you feel when you just start to construct something and it fails? Some things don’t happen as per the expectations, it’s failure on the planning side. Lets take an example: you start building your house and during construction you notice that the carpenter you booked for your furniture didn’t give you proper estimates for resources and your construction fails .. or at least gets delayed for few weeks or months. But in this scenario you can recover by finding another carpenter. But while programming what if the code in your constructor fails? Lets take an example -

class Person

{

char* name;

char* surname;

public:

// constructor and destructor

Person();

~Person();

}

Now let’s say we allocate these two member variables in a constructor as follows:

Person()

{

name = new char[100];

surname = new char[200];

}

Now the allocation for “name” goes well according to plan. And due to unavailability of a free 200 bytes the allocation for “surname” fails. Now what will happen to the “name” which is already allocated? Its orphaned and finally a memory leak in my application. The constructor of any class should not throw any exceptions ( Leave in Symbian ).

According to me, the best way to handle this situation would be a Two phase construction. It’s a method of creating an object in two phases. First phase would be a constructor and other is say “Construct” method. Let’s take above example class and add a two phase constructor to it.

Class Person

{

Person();

bool Construct()

public:

static Person* Create();

~Person()

}

Person* Person::Create()

{

Person* me = new Person();

if(Person == NULL)

{

return NULL;

}

if( me->Construct() == false)

{

delete me;

return NULL;

}

return me;

}

bool Person::Construct()

{

name = new char[100];

// check for allocation

if(name == NULL )

{

// allocation failed

return FALSE;

}

surname = new char[200];

if(surname == NULL )

{

// allocation failed

// delete previously allocated memory

delete name;

name = NULL;

return FALSE;

}

// everything is successful it means my object is properly allocated

return TRUE;

}

 

This technique of allocation of memory is very impressive for mobile platform because it handles the failure of object construction. I would love to see non wireless platform adopting similar techniques to ensure cleaner object construction.

Be back with the next post on “Cleanup Stack” soon, remember thats other feature I like the most in Symbian.

- Kiran

Of This n That

Posted by anjali on September 11, 2007 RSS Feed

There’s nothing that gets the adrenaline soaring like the closing in of a deadline. We are as impatient to throw off the stealth mode as you are curious about finding out what we are all about. Within a few weeks from now 13friends would be ready to take it’s first few set of visitor’s by invitation. Last few months have been exhilarating to say the least. We have spent umpteen no of hours trying to figure out in our minds what is it that you would need. It’s almost like being parents of a toddler about to step on to the center stage for the first time!!

Last few months we have really seen the activity around social networking products picking up. There are quite a few cool products out there. However have you ever had feelings like wow! that’s cool , but don’t think it’s for me? I think we have a kind of understanding about the lacunae that exists between the need and the type of products hitting the market at regular intervals. Maybe that’s got something to do with the complexity involved. And we are going to do it one step at time …..relentlessly ! What I am reminded at this point is of a quote I read somewhere…

Be THE , not “A”

“A” is random. “A” is generic. “A” is one of many. “A” is adequate.

 

“THE” is singular. “THE” is specific. “THE” is the only. “THE” is expert.

Anyways, if you happen to be in and around Pune do drop us a line and let us know if you would be interested to be a part of the lunch 2.0 movement (true Silicon Valley Style ) that we have started in Pune.

And oh ! did you notice the new Services tab that we have added to the site? As mentioned, community and communication is our forte. If you would like to learn more, don’t be shy about dropping us an email at sevices@mangospring.com. We do answer all legitimate (non-spam) emails we get :)

-Anjali

©2007 - 2008 MangoSpring. All Rights Reserved.