[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-mtj-dev] Extension point for defining devices - Back onTrack
|
I'll jump in here. Previously Motorola had supplied multiple SDKs, each
one targeted at a few devices. This was essentially the codeline model
you describe. The end result was massive confusion as developers tried
to figure out what SDK applied to which device, or worse, which edition
of which SDK contained the device they were interested in. In the
redesign initiated several years ago, and implemented by the current
MOTODEV Studio, we changed to a single SDK supporting all devices. (Or
at least all GSM, 3G, and CDMA devices - iDEN is still a separate
world.) This has been much easier for developers to understand and
configure.
Regarding your question, I think it is more accurate to say that the SDK
sets the device APIs at the device level. MTJ exposes the SDK and
devices which are then set at the project level. The SDK uses this
information to set the APIs available to the build system. This
operation can be examined in MOTODEV Studio by changing the device type,
then looking at the associated libraries in the project properties. Very
fine control of the APIs and system properties is possible with this
approach.
Bottom line, in our experience, an SDK per device or per few devices is
a really, really bad idea.
I will add one more item to this discussion - what are we going to do
about regional/carrier variations of devices? Do we need to add support
for this level of phone variation?
Eric Hildum
Senior Product Manager, Mobile Developer Tools & SDK
Software Platforms and Delivery
Ecosystem and Market Development
Motorola
Direct: +1-408-541-6809
Mobile: +1-510-305-0801
809 11th Avenue
Sunnyvale, CA 94089
USA
-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Ken Wallis
Sent: Friday, January 30, 2009 7:02
To: Mobile Tools for The Java Platform mailing list
Subject: RE: [dsdp-mtj-dev] Extension point for defining devices - Back
onTrack
This direction would be closer to how we manage our SDK's.
In terms of project association, could it not be at the level of SDK
only? What would the difference be between devices provided by a single
SDK? Obviously the devices may have different capabilities... I guess
my question is, in the current MTJ approach, are the available API's set
at the device level?
For us, we would probably have an "SDK" for each BlackBerry handheld
codeline, this is in effect what we have today. And the SDK therefore
would have a consistent API. Of course, I could see this not being
flexible enough for a generic framework...
I guess I am thinking on the fly here... So perhaps project association
is still at the Device level, but a device is uniquely defined in
combination with the SDK.
One thing that is important, is for the ISDK (or if necessary at a more
granular level, the IDevice) to be able to provide the compile time
libraries. We provide our own implementation of the JavaME API's, and
obviously our BlackBerry extensions. We would need a mechanism to
inject this as the compile target.
Ken Wallis
Team Lead - Eclipse Tools
Research In Motion
905-629-4746 x14369
-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: Thursday, January 29, 2009 8:14 PM
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] Extension point for defining devices - Back
onTrack
The basic idea that I have in my head goes something like this:
* Introduce a new ISDK interface into the MTJ models.
** ISDK has a name
** ISDK manages a list of IDevice instances
** There are likely other things to go here and I believe that Diego is
already proposing this interface
* The current device importer implementations is altered to implicitly
create a new ISDK with the created devices
* All of the UI is updated to use the SDK's within the IDE (the device
selector primarily)
* A new extension point is added to register an ISDK instance.
** This extension point would specify the "name" of the SDK
** The extension point would specify the implementing class for the ISDK
instance
There is likely more to it, but this seems like the basics. The
implication here is that an ISDK is entirely responsible for the devices
being managed. How and where those devices come from is not part of the
system. The instances can be generated "on the fly" as necessary by the
SDK, or stored away some where. The core MTJ functionality would not
attempt to persist or resurrect device that are owned by an SDK. This
also implies that the current implementations for UEI and such would
need to be altered to do the device persistence themselves.
This is the basic idea I've been pondering for this. In the end, it
isn't well formed enough to be considered for Galileo in my mind.... We
need to continue the discussion to figure out if this works at all and
what would need to be done to make it work. I haven't looked seriously
at the JRE extension points to see how close or far this proposal is
from the JRE definition.
Thanks,
Craig
Christian Kurzke wrote:
> Hildum Eric-XFQ473 wrote:
>> This would probably impact projects, which associate one or more
>> devices with the projects. How would we reestablish these
associations?
>>
>
> This raises an interesting question:
>
> Should a project be associated with an "SDK" or with a "Device".
> e.g. If a project is associated with a Device, and there is more than
> one SDK providing (posible updated) support for the same Device, how
> would this be handled.
> Or, when an updated SDK is providing support for the same devices,
> should the project be automatically using the newer SDK?
>
> This may lead to problems where a developer wants to temporarily try
> out multiple SDKs for the same device.
>
> My recommendation is that the project association is with a
> combination of "SDK ID and Device ID", and no behind the scenes
> changes to surprise the developer.
> I think something like the JDT VmInstall ID. see:
>
http://help.eclipse.org/stable/topic/org.eclipse.jdt.doc.isv/reference/e
xtension-points/org_eclipse_jdt_launching_vmInstalls.html
>
>
> Btw, Danail, thanks for the idea with the JDT VM registration analogy,
> i think this is a very good reference for how we can solve this.
>
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
