Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Multiple devices - Single codebase

 
Pablo Bertetti
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys, we're starting a J2ME project that will produce a software to be run initially in two different devices.
What's the best way to deal with native vendor capabilities in terms of source code and build management, giving that

- We need to maintain a single codebase
- We might need to add support for more devices in the future
- We would want to use Eclipse for development and, if possible Eclipse incremental's build

Initially, we're thinking in having this directory structure:



That way, we would have a single codebase in /common while native implementations would remain under the /native subdir.

Another way would be to keep a single codeline while preprocessing directives specific for each device, however it tends to be unmanageable when the devices number grows.

Do you have any advice/experience on developing for multiple device using a single codebase?
Regarding Eclipse, would it be possible to configure Eclipse's incremental compiler to deal with that directory structure ? Having 2 projects ? Through user-defined variables ? Or do we need to use exclusively ANT for producing the builds ?

Thanks a lot !
[ November 18, 2004: Message edited by: Pablo Bertetti ]
 
Michael Yuan
author
Ranch Hand
Posts: 1427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I use ANT to manage multiple build targets. I only use the IDE as a code editor and browser.
 
Pablo Bertetti
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michael Yuan:
I use ANT to manage multiple build targets. I only use the IDE as a code editor and browser.


Thanks for the tip!.

Regarding the approach to follow when dealing with two different device-proprietary implementations (Bluetooth stack for example), would you recommend to handle it through preprocessing using a single class file or by having a cloned native class structure for each device in separate subdirectories and then building pointing to the needed one ?

Thanks!
 
William Joseph
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pablo,

We went with platform specific bases classes to implement phone specific behavior. During the build process, Ant determines the correct platform directory to include in the classpath for each build. Each of the platform classes implements the same behavior to the best of that platform/device's ability. For example, we have

../platform/nokia
PlatformCanvas.java
Extends Nokia FullCanvas
Defines default colors that look good on Nokia phones

../platform/sanyo
PlatformCanvas.java
Extends regular Canvas
Defines default colors that look good on Sanyo phones

etc.

Then we have

GenericCanvas.java
Extends PlatformCanvas - get the correct platform based on Ant build settings

All of our classes extend GenericCanvas. We never have to worry about any device specific behavior. We do the same for sound, GPS, etc.

Although this adds some overhead due to the class hierarchy, from a code reuse point of view it's worth it. In addition, it's much easier to migrate the device specific stuff to future projects to reduce development time.

- William
 
Pablo Bertetti
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by William Joseph:
Then we have

GenericCanvas.java
Extends PlatformCanvas - get the correct platform based on Ant build settings

All of our classes extend GenericCanvas. We never have to worry about any device specific behavior. We do the same for sound, GPS, etc.
- William


Thanks for the feedback!, however, I do not completely understand why are you using a GenericCanvas as a base class for the other subclasses, and not using directly PlatformCanvas as the base class. Is it just a matter of reusing generic code put in GenericCanvas or a level of indirection established for another particular reason ?

Thanks!
 
William Joseph
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
GenericCanvas just contains a bunch of reusable code that we abstracted out of the higher level classes. We could have pushed everything down into each PlatformCanvas, but we decided it was better from a reliability and testing standpoint to leave it in GenericCanvas. Plus we're old Smalltalk coders so we love abstraction.

The only problem with this strategy is when you recognize you need to add new functionality at the Platform level. You end up having to remember to add the new functionality to each individual platform. We've reduced the problem by only adding the functionalty to one platform initially. After we've tested that platform, we move on to the next. Kind of lock-step, but I'll trade development time now for bug fixes later.

-- William
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic