Re: Unhappy TTNCF6 customer - is TTNCFFinal better???????

ManniAT — Tue, 28 Jul 2009 11:38:26 GMT

Hi ayo,

you a right - a wrapper should hide underlying issues - if possible.

Those issues came up with newer versions of the SDK.
Or in other words - SDK 3.x had no such problems.

With SDK 5.x "startup problems" took place. It had something to do with the fact that TomTom totally changed the programming model and "introduced" some nice problems.

We fixed this in our wrapper with the introduction of "KeepAlive".
Unfortunaltely some SDK versions later a new kind of these problems occured.
We implemented StartTTN to fix these problems.

And finally (in some specific situations) even this didn't help.
The "only" (one possible) solution was the use of a timer which we showed here in the forums.

Last not least most of the "hang ups" could be solved. The reason for them had been:

Programming mistakes
Not using Control.Invoke when needed
Locking problems in multithreaded aps
Version issues
TomTom never took care about compatibility - so each navigator version needs it's matching SDK version
We could solve all of them (most of the problems came from this point)
Real problems (everything done correct - still hangs occured)
Sometimes we could figure out that a "not supported device / OS" was used.
--A lot of customers use such devices without any problems
Sometimes we could provide a workaround (doing some thing which solved the problem although nobody knows why :))

By the way - some of the forum posts are from "native SDK users" (TomTom's support response time isn't the fastest).

Anyhow - you are right: a wrapper should hide such problems.

BUT - the problems occure in SDK calls - and we have to call the SDK.
With one of our bigger customers we tried to implement a multithreaded solution to overcome thos problems. Finally we decided not to implement this solution (our customer does also not use it) in the wrapper. The reasons for this:

The need for the user to take care about "hidden multithreading"
The same could be achived with asynchronious functions

Let me bring this to a conclusion:

A lot of things have been addressed in our wrapper
Of course there are no "forum posts" about it - no one had to deal with it
The potential problems are cought by our wrapper without any notice to the user
We do / did our best to solve problems
There are some problems where the developer has to take care
That's where we "missed" what you expect - to hide those things within the wrapper
To judge from the number of forum posts to the number of affected customers you should have to know the number of customers using our product.
I can't tell you an exact number - but in 2004 we celebrated our 1.000st customer :)

Anyhow - to answer the "question" about TTNCFFinal.
NO - this version doesn't specially address hangups.
Or in other words - if you already use TTN 6.31 and SDK 6.031 (with hangups) you will win nothing with TTNCFFinal.

And if so - you should not buy it; it would not solve your problems.

Regards

Manfred

Unhappy TTNCF6 customer - is TTNCFFinal better???????

ajanaman — Tue, 28 Jul 2009 06:32:32 GMT

I must confess my experience with using your product has not been pleasant. I have a feeling this applies to many other customers judging from the numerous postings of freezes and hang-ups. I am unwilling to invest again on this TTNCFFinal if all that I get is application hang-ups - only for TTN to be blamed for not returning from calls. The fact is a good Wrapper should take care of all issues relating to the communication between the wrapper and the application being wrapped. Any assurances on the TTNFinal, especially regarding application hangups????

ayo

Ask questions

Re: Unhappy TTNCF6 customer - is TTNCFFinal better???????

Unhappy TTNCF6 customer - is TTNCFFinal better???????