Scaled down, mobile ofbiz framework?

[cjhowe]

I'm brainstorming a couple of options for integration
of ofbiz with mobile terminals (smartphones).  What
could be stripped off of Ofbiz and still provide the
framework' basic database functionality with hsql or
derby as well as the services and minilang.  Also
looking at what could be done to pair down the java
requirement to JRE instead of the JDK.

The most frequent use of this would be through a thin
client.  However, I'm needing to anticipate loss of
connectivity so it needs to store information locally
and then sync.  Would a paired down OFBiz work for
this or would it be better to look at another option
for use on the smartphone and then have it sync
through SOAP when connectivity is available?

[David E Jones-2]

On a phone? I don't think you can even run a J2SE JRE on a phone...  
not even with a "Hello World!" type of application (ie without OFBiz  
in the picture at all). A J2SE JRE is a LOT bigger than a J2ME JRE...

You could certainly do a SOAP or other client, and I know that has  
been done before for very small applications, even running on a phone.

-David


On Aug 25, 2006, at 2:02 PM, Chris Howe wrote:

> I'm brainstorming a couple of options for integration
> of ofbiz with mobile terminals (smartphones).  What
> could be stripped off of Ofbiz and still provide the
> framework' basic database functionality with hsql or
> derby as well as the services and minilang.  Also
> looking at what could be done to pair down the java
> requirement to JRE instead of the JDK.
>
> The most frequent use of this would be through a thin
> client.  However, I'm needing to anticipate loss of
> connectivity so it needs to store information locally
> and then sync.  Would a paired down OFBiz work for
> this or would it be better to look at another option
> for use on the smartphone and then have it sync
> through SOAP when connectivity is available?

... [show rest of quote]

[cjhowe]

Thanks David.  The Sun Java Wireless Toolkit looks to
be able to do this simply enough.

--- David E Jones <[hidden email]>
wrote:

>
> On a phone? I don't think you can even run a J2SE
> JRE on a phone...  
> not even with a "Hello World!" type of application
> (ie without OFBiz  
> in the picture at all). A J2SE JRE is a LOT bigger
> than a J2ME JRE...
>
> You could certainly do a SOAP or other client, and I
> know that has  
> been done before for very small applications, even
> running on a phone.
>
> -David
>
>
> On Aug 25, 2006, at 2:02 PM, Chris Howe wrote:
>
> > I'm brainstorming a couple of options for
> integration
> > of ofbiz with mobile terminals (smartphones).
> What
> > could be stripped off of Ofbiz and still provide
> the
> > framework' basic database functionality with hsql
> or
> > derby as well as the services and minilang.  Also
> > looking at what could be done to pair down the
> java
> > requirement to JRE instead of the JDK.
> >
> > The most frequent use of this would be through a
> thin
> > client.  However, I'm needing to anticipate loss
> of
> > connectivity so it needs to store information
> locally
> > and then sync.  Would a paired down OFBiz work for
> > this or would it be better to look at another
> option
> > for use on the smartphone and then have it sync
> > through SOAP when connectivity is available?
>
>

... [show rest of quote]

[BJ Freeman]

why not have WAP pages.
Then any phone that can browse the web can interact.
http://www.openmobilealliance.org/tech/affiliates/wap/wapindex.html
http://www.bitstream.com/wireless/


Chris Howe sent the following on 8/25/2006 1:59 PM:

> Thanks David.  The Sun Java Wireless Toolkit looks to
> be able to do this simply enough.
>
> --- David E Jones <[hidden email]>
> wrote:
>
>> On a phone? I don't think you can even run a J2SE
>> JRE on a phone...  
>> not even with a "Hello World!" type of application
>> (ie without OFBiz  
>> in the picture at all). A J2SE JRE is a LOT bigger
>> than a J2ME JRE...
>>
>> You could certainly do a SOAP or other client, and I
>> know that has  
>> been done before for very small applications, even
>> running on a phone.
>>
>> -David
>>
>>
>> On Aug 25, 2006, at 2:02 PM, Chris Howe wrote:
>>
>>> I'm brainstorming a couple of options for
>> integration
>>> of ofbiz with mobile terminals (smartphones).
>> What
>>> could be stripped off of Ofbiz and still provide
>> the
>>> framework' basic database functionality with hsql
>> or
>>> derby as well as the services and minilang.  Also
>>> looking at what could be done to pair down the
>> java
>>> requirement to JRE instead of the JDK.
>>>
>>> The most frequent use of this would be through a
>> thin
>>> client.  However, I'm needing to anticipate loss
>> of
>>> connectivity so it needs to store information
>> locally
>>> and then sync.  Would a paired down OFBiz work for
>>> this or would it be better to look at another
>> option
>>> for use on the smartphone and then have it sync
>>> through SOAP when connectivity is available?
>>
>
>

... [show rest of quote]

[cjhowe]

Thanks BJ, but serving WAP pages doesn't cover the
need of when the user has no connectivity.  I think
it's better that the end user do the exact same thing
everytime regardless of connectivity status and let
the software deal with sync.

--- BJ Freeman <[hidden email]> wrote:

> why not have WAP pages.
> Then any phone that can browse the web can interact.
>
http://www.openmobilealliance.org/tech/affiliates/wap/wapindex.html

> http://www.bitstream.com/wireless/
>
>
> Chris Howe sent the following on 8/25/2006 1:59 PM:
> > Thanks David.  The Sun Java Wireless Toolkit looks
> to
> > be able to do this simply enough.
> >
> > --- David E Jones <[hidden email]>
> > wrote:
> >
> >> On a phone? I don't think you can even run a J2SE
> >> JRE on a phone...  
> >> not even with a "Hello World!" type of
> application
> >> (ie without OFBiz  
> >> in the picture at all). A J2SE JRE is a LOT
> bigger
> >> than a J2ME JRE...
> >>
> >> You could certainly do a SOAP or other client,
> and I
> >> know that has  
> >> been done before for very small applications,
> even
> >> running on a phone.
> >>
> >> -David
> >>
> >>
> >> On Aug 25, 2006, at 2:02 PM, Chris Howe wrote:
> >>
> >>> I'm brainstorming a couple of options for
> >> integration
> >>> of ofbiz with mobile terminals (smartphones).
> >> What
> >>> could be stripped off of Ofbiz and still provide
> >> the
> >>> framework' basic database functionality with
> hsql
> >> or
> >>> derby as well as the services and minilang.
> Also
> >>> looking at what could be done to pair down the
> >> java
> >>> requirement to JRE instead of the JDK.
> >>>
> >>> The most frequent use of this would be through a
> >> thin
> >>> client.  However, I'm needing to anticipate loss
> >> of
> >>> connectivity so it needs to store information
> >> locally
> >>> and then sync.  Would a paired down OFBiz work
> for
> >>> this or would it be better to look at another
> >> option
> >>> for use on the smartphone and then have it sync
> >>> through SOAP when connectivity is available?
> >>
> >
> >
>

... [show rest of quote]

[Brett]

I've written several J2ME midlets communicating with various web
applications (e.g. ofbiz and Zope).  Here are a few points from my
experience:

1. The J2ME platform has a very limited set of Java APIs.  You will
not be able to get a framework like ofbiz working on it.

2. The best option is to create a simple client that can communicate
with ofbiz services.  You could use SOAP but from my experience even
XML parsing on the phone is difficult due to memory constraints and
performance.  I found it easier to create simple serialization method
for objects that was shared on the mobile phone and the server.

3. J2ME is getting better but you will still find it difficult to get
the same application to run the same on every phone.  For simple data
displays on the phone, WAP is still the easiest and most pervasive.

4. The best Java platform that I have found is the Blackberry.  Their
emulators are very accurate and they have an extended API set that
lets you create more robust applications.


Brett

On 8/25/06, Chris Howe <[hidden email]> wrote:

> I'm brainstorming a couple of options for integration
> of ofbiz with mobile terminals (smartphones).  What
> could be stripped off of Ofbiz and still provide the
> framework' basic database functionality with hsql or
> derby as well as the services and minilang.  Also
> looking at what could be done to pair down the java
> requirement to JRE instead of the JDK.
>
> The most frequent use of this would be through a thin
> client.  However, I'm needing to anticipate loss of
> connectivity so it needs to store information locally
> and then sync.  Would a paired down OFBiz work for
> this or would it be better to look at another option
> for use on the smartphone and then have it sync
> through SOAP when connectivity is available?
>

... [show rest of quote]

[davidnwelton]

You're definitely not going to run OFBiz on a phone.  Well, not for a
few years at least - who knows what the future holds!

<advertising>
Depending on what you need to do, you could quickly put together a
front end with Hecl (hecl.org) that attempts to comunicate with the
server, and if it fails, saves the data to retry later.
<advertising />

In any case, the above strategy is as good as you're going to get, I think.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/

[cjhowe]

that looks very intuitive.  let me see if i have the
approach down.

complete form,
take fields and inputs, create hash table
add hash table to list
try to send list to server
if success clear list
if not do nothing
complete new form
take fields and inputs, create hash table
add has table to list
try to sent list to server
...
???




--- David Welton <[hidden email]> wrote:

> You're definitely not going to run OFBiz on a phone.
>  Well, not for a
> few years at least - who knows what the future
> holds!
>
> <advertising>
> Depending on what you need to do, you could quickly
> put together a
> front end with Hecl (hecl.org) that attempts to
> comunicate with the
> server, and if it fails, saves the data to retry
> later.
> <advertising />
>
> In any case, the above strategy is as good as you're
> going to get, I think.
>
> --
> David N. Welton
>  - http://www.dedasys.com/davidw/
>
> Linux, Open Source Consulting
>  - http://www.dedasys.com/
>

... [show rest of quote]

[davidnwelton]

On 8/28/06, Chris Howe <[hidden email]> wrote:
> that looks very intuitive.  let me see if i have the
> approach down.

On starting the application, try and send any unsent data.

> complete form,
> take fields and inputs, create hash table
> add hash table to list
> try to send list to server
> if success clear list
> if not do nothing

If not, store in non-volatile phone memory ("RecordStore - even cheap
ones have at least a bit of this) to be sent later.

> complete new form
> take fields and inputs, create hash table
> add has table to list
> try to sent list to server

Yep.  I wrote a simple shopping list app using some of this, that's
available here:

http://dedasys.com/shopping_list/

It does more grabbing of the data from the server rather than the
other way around, but the concepts are mostly all there.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/