[
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
|
The issue comes about in the set up of the developer's environment. If
you have to search a manufacturer's web site for ten or twenty different
SDKs to get all the devices you are targeting it can be difficult to
ensure that you have all the SDKs you need, that you have the most up to
date version of the SDKs, and that you are familiar with the
idiosyncrasies of each SDK.
You would be very surprised just how many phones Motorola actually makes
- we are not Apple with just three phone models.
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 Craig Setera
Sent: Tuesday, February 03, 2009 3:55
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] Extension point for defining devices - Back
onTrack
I can't comment on the carrier differentiation of different devices.
Ken, you might have some thoughts there since I know that RIM provides
device simulators that are specific to carriers in some cases.
I guess I'm not clear on how different SDK's affects the usability.
Can you explain?
Thanks,
Craig
On Jan 30, 2009, at 10:27 AM, Hildum Eric-XFQ473 wrote:
> 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
> _______________________________________________
> dsdp-mtj-dev mailing list
> dsdp-mtj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
