Skip to main content

[Javagroups-j2me] Request for guidence on new concept

2 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
signal3

As many economists will tell you, "there's no such thing as a free lunch"
so, I wouldn't expect to find a "silver-bullet" to your problem ;-) Anyway,
more (Java-ME related) comments are interspersed below...

On Wed, Feb 25, 2009 at 4:47 PM, harshit jain wrote:

> Dear Sir,
>
> I want to make a mobile application through which text file of any size can
> be send from one mobile to another over GSM. Concept is to convert text in
> sound and save it. Instead of transfering sound captured from microphone,
> transfer the saved sound file over GSM network. This sound would be stored
> by reciever and again converted into text. Text - sound convertor are
> already available.
>
> With the help of this software we would be able to send any length of data
> without any constraint of size limit. In present senerio, size limit is
> imposed by connection giving companies over SMS.This software would be able
> to break this boundation. Today if we use GPRS to send any long file we
> would have to upload somewhere on internet, but many times this process
> takes time and reciever has to wait. This software could over come this
> problem.
>

Depending on the device and the network provider's service capabilities you
will encounter varying levels of difficulty doing this. As you've already
noticed, data will need to be sent in discrete chunks if transferred by
SMS. This is an inherent limitation of SMS.

In addition, the same may hold true if you use GPRS/EDGE/ETC, but the limits
will be affected by the network provider rather than the underlying protocol
(i.e. GPRS connection should be able to transfer arbitrary sized files so
long as the network provider allows it).

>
> My problem is that i am unable to find any suitable API for transfering
> saved sound file during active phonecall over GSM. Please help me by
> suggesting APIs and library for it.
>

Again, this is a limitation of the device as well as the network. AFAIK,
many/most 3.5G devices should allow a voice call and data transfer
concurrently. Pre-3G devices will put the data connection "on hold" during
a voice call. I may have the "GSM versions" wrong, but I think the general
idea is correct.

Off the top of my head, I would suggest you implement an architecture which
relies on "fallback" mechanisms. That is, your application might try the
most sophisticated mechanism first, then (if it fails) try a less
sophisticated mechanism, and so on.

For example, you can access the file you want to send using
javax.microedition.io.file (JSR-75) and try using
javax.microedition.io.Connector to open a "socket://" (ala JGroups-ME) to
send it... if the transfer fails after some retries, then try to post via
"http://", and finally try "sms://". When a method succeeds, your
application can note which method to use on subsequent attempts. This
could happen during a "setup" phase of your application, or could be user
specified... or both.

Unfortunately, "standard Java-ME" does not offer any type of inter-process
communication outside of the application sandbox so, I think it will be
impossible to "stream" a live voice call to a data sink residing on the
internet. Perhaps MIDP3.0 addresses this, idk.

It's important to note that sending data /during/ a voice call is something
that the underlying hardware may or may not support, I don't think you can
do much in that regard (except by a deferring the transfer).

Finally, I think you might have slightly unrealistic expectations of what
can be done w/ the current state of affairs... even if you were to develop
this application using a native API (e.g. Symbian/iPhone) you would most
likely still experience the hurdles imposed by each network carrier
(although I think it might be at least possible to accomplish what you
describe). That said, I'm no expert on Symbian or iPhone sdk's or anything
really... so I can't offer you too much more information in that regard :-(
Again, "there's no such thing as a free lunch".

Hopefully this helps you a bit. And, if anyone has additional
details/ideas/corrections... I'm sure the world would love to hear them ;-)

Best wishes

> Hoping any response from your side.
>
> Thanking You
>
> Harshit Jain,
> B.Tech Part II,
> Computer Science and Engineering,
> IT-BHU, Varanasi.
> Mob: +91 9305250184
> Work Email: harshit.jain.cse07@itbhu.ac.in
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Javagroups-j2me mailing list
> Javagroups-j2me@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/javagroups-j2me
>
>
[att1.html]

signal3

I'm sorry, I forgot to consider... if this is a research project or you are
willing to impose device/carrier restrictions on the application... I would
say that any of the popular native APIs (Android, iPhone, Symbian) should be
able to fulfill your needs; but don't hold me to anything ;-)

On Wed, Feb 25, 2009 at 8:12 PM, signal3 wrote:

> As many economists will tell you, "there's no such thing as a free lunch"
> so, I wouldn't expect to find a "silver-bullet" to your problem ;-) Anyway,
> more (Java-ME related) comments are interspersed below...
>
> On Wed, Feb 25, 2009 at 4:47 PM, harshit jain wrote:
>
>> Dear Sir,
>>
>> I want to make a mobile application through which text file of any size
>> can be send from one mobile to another over GSM. Concept is to convert text
>> in sound and save it. Instead of transfering sound captured from microphone,
>> transfer the saved sound file over GSM network. This sound would be stored
>> by reciever and again converted into text. Text - sound convertor are
>> already available.
>>
>> With the help of this software we would be able to send any length of data
>> without any constraint of size limit. In present senerio, size limit is
>> imposed by connection giving companies over SMS.This software would be able
>> to break this boundation. Today if we use GPRS to send any long file we
>> would have to upload somewhere on internet, but many times this process
>> takes time and reciever has to wait. This software could over come this
>> problem.
>>
>
> Depending on the device and the network provider's service capabilities you
> will encounter varying levels of difficulty doing this. As you've already
> noticed, data will need to be sent in discrete chunks if transferred by
> SMS. This is an inherent limitation of SMS.
>
> In addition, the same may hold true if you use GPRS/EDGE/ETC, but the
> limits will be affected by the network provider rather than the underlying
> protocol (i.e. GPRS connection should be able to transfer arbitrary sized
> files so long as the network provider allows it).
>
>
>>
>> My problem is that i am unable to find any suitable API for transfering
>> saved sound file during active phonecall over GSM. Please help me by
>> suggesting APIs and library for it.
>>
>
> Again, this is a limitation of the device as well as the network. AFAIK,
> many/most 3.5G devices should allow a voice call and data transfer
> concurrently. Pre-3G devices will put the data connection "on hold" during
> a voice call. I may have the "GSM versions" wrong, but I think the general
> idea is correct.
>
> Off the top of my head, I would suggest you implement an architecture which
> relies on "fallback" mechanisms. That is, your application might try the
> most sophisticated mechanism first, then (if it fails) try a less
> sophisticated mechanism, and so on.
>
> For example, you can access the file you want to send using
> javax.microedition.io.file (JSR-75) and try using
> javax.microedition.io.Connector to open a "socket://" (ala JGroups-ME) to
> send it... if the transfer fails after some retries, then try to post via
> "http://", and finally try "sms://". When a method succeeds, your
> application can note which method to use on subsequent attempts. This
> could happen during a "setup" phase of your application, or could be user
> specified... or both.
>
> Unfortunately, "standard Java-ME" does not offer any type of inter-process
> communication outside of the application sandbox so, I think it will be
> impossible to "stream" a live voice call to a data sink residing on the
> internet. Perhaps MIDP3.0 addresses this, idk.
>
> It's important to note that sending data /during/ a voice call is something
> that the underlying hardware may or may not support, I don't think you can
> do much in that regard (except by a deferring the transfer).
>
> Finally, I think you might have slightly unrealistic expectations of what
> can be done w/ the current state of affairs... even if you were to develop
> this application using a native API (e.g. Symbian/iPhone) you would most
> likely still experience the hurdles imposed by each network carrier
> (although I think it might be at least possible to accomplish what you
> describe). That said, I'm no expert on Symbian or iPhone sdk's or anything
> really... so I can't offer you too much more information in that regard :-(
> Again, "there's no such thing as a free lunch".
>
> Hopefully this helps you a bit. And, if anyone has additional
> details/ideas/corrections... I'm sure the world would love to hear them ;-)
>
> Best wishes
>
>
>> Hoping any response from your side.
>>
>> Thanking You
>>
>> Harshit Jain,
>> B.Tech Part II,
>> Computer Science and Engineering,
>> IT-BHU, Varanasi.
>> Mob: +91 9305250184
>> Work Email: harshit.jain.cse07@itbhu.ac.in
>>
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
>> CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>> Enterprise
>> -Strategies to boost innovation and cut costs with open source
>> participation
>> -Receive a $600 discount off the registration fee with the source code:
>> SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Javagroups-j2me mailing list
>> Javagroups-j2me@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/javagroups-j2me
>>
>>
>
[att1.html]