×

Discussion Board

Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 35
  1. #16
    Registered User
    Join Date
    Apr 2008
    Posts
    7

    Re: Nokia N97 SDK - beta - released . Feedback welcomed.

    Quote Originally Posted by ltomuta View Post
    To date N97 is the only device that has WRT widget home screen support and a public native API for home screen.
    Yes. But I suppose that there will be other devices with such a home screen in future. I would like to recognize such devices dynamically but not just to hardcode N97 device uid. Is there any way to do it?

  2. #17
    Nokia Developer Moderator
    Join Date
    Sep 2004
    Location
    Tampere, Finland
    Posts
    11,359

    Re: Nokia N97 SDK - beta - released . Feedback welcomed.

    Yes, you can try to load the library dinamically and see if it exists or not.

    However, there is no guarante that:
    a) other devices will ever have this feature (it is not part of S60 5th Edition platform release)
    b) the API will stay the same or that it will exist at all

    So yes, you can detect the feature but I really can't figure out what use you will have for it untill the API will be added to the platform release and it will come with binary compatibility as well.
    -- Lucian

    If you are not yet a DVLUP member it is time to correct that mistake :) Click here to join: http://www.dvlup.com/lucian/Invite

  3. #18
    Registered User
    Join Date
    Nov 2004
    Posts
    14

    Exclamation Re: Nokia N97 SDK - beta - released

    There seems to be a bug in the Homescreen Widget Example in HsWidgetExample.cpp:

    The function ToString()

    HBufC8 *text = HBufC8::NewL( aText.Length() + 4 /*for ending zero*/ );
    [...]
    CnvUtfConverter::ConvertFromUnicodeToUtf8( dest, aText );

    will fail when there are unicode characters in the string to be converted.

    The memory allocated for the UTF8 string should bet at least text.length*4 + 1 long:

    HBufC8 *text = HBufC8::NewL( (aText.Length() * 4) + 1 /*for ending zero*/ )

    as a unicode character can be up to 4 bytes long when it's encoded in UTF8, afaik.

    Cheers
    ole @ mobileways.de

  4. #19
    Nokia Developer Moderator
    Join Date
    Feb 2006
    Location
    Oslo, Norway
    Posts
    28,684

    Re: Nokia N97 SDK - beta - released

    The proper way would be
    Code:
    HBufC8 *text=CnvUtfConverter::ConvertFromUnicodeToUtf8L(aText);;
    CleanupStack::PushL(text);
    text=text->ReAllocL(text->Length()+1);
    CleanupStack::Pop();

  5. #20
    Registered User
    Join Date
    Nov 2004
    Posts
    14

    Wink Re: Nokia N97 SDK - beta - released

    Quote Originally Posted by wizard_hu_ View Post
    The proper way would be
    Code:
    HBufC8 *text=CnvUtfConverter::ConvertFromUnicodeToUtf8L(aText);;
    CleanupStack::PushL(text);
    text=text->ReAllocL(text->Length()+1);
    CleanupStack::Pop();
    Hi Wizard_hu,

    although that code might look nice, I wouldn't implement it that way.

    Why wasting resources on using the cleanup stack and more importantly on a realloc(!) when you can easily get around it?

    Would be nice if the examples demonstrated how to use as little as possible resources ;-)

    Just my 2 cents
    ole @ mobileways.de

  6. #21
    Registered User
    Join Date
    Apr 2008
    Posts
    7

    Re: Nokia N97 SDK - beta - released . Feedback welcomed.

    Quote Originally Posted by ltomuta View Post
    So yes, you can detect the feature but I really can't figure out what use you will have for it untill the API will be added to the platform release and it will come with binary compatibility as well.
    In fact my problem is the position of a floating window over the homescreen. On "standard" standby screens it looks well under the clock pane. However on N97 it is not so fine and it covers the clock of the homescreen (which is lower than standard one). That's why I would like to detect this feature. That allows me to change window position according to standby screen type.

    Quote Originally Posted by ltomuta View Post
    Yes, you can try to load the library dinamically and see if it exists or not.
    I thought that homescreen DLLs are static...
    Thank you for this suggestion. It seems to be a good way to detect homescreen feature :)

  7. #22
    Nokia Developer Moderator
    Join Date
    Feb 2006
    Location
    Oslo, Norway
    Posts
    28,684

    Re: Nokia N97 SDK - beta - released

    Feel free to try understanding how my code works.
    Would be nice if the examples demonstrated how to use as little as possible resources ;-)
    Do not worry, it does.

  8. #23
    Registered User
    Join Date
    Nov 2004
    Posts
    14

    Cool Re: Nokia N97 SDK - beta - released

    Quote Originally Posted by wizard_hu_ View Post
    Do not worry, it does.
    Oh! Really sorry, but could you quickly explain how a { PushL(...); ReallocL(); Pop(); } uses less resources than a { /* NOP */ } !?

    I think I am starting to worry right now! :-P

    Using a ReallocL(len+1) + CleanupStack just for safe-guarding a following PtrZ() seems to be a bit strange!?

    If you want to use ConvertFromUnicodeToUtf8L() you might better replace the PtrZ()-copying construct with some std:string.copy(). That would actually be cool as I haven't used std::string before and would love to see how you'd implement it.

    Quote Originally Posted by wizard_hu_ View Post
    Feel free to try understanding how my code works
    WOW!

    Cheers
    ole @ mobileways.de

  9. #24
    Nokia Developer Moderator
    Join Date
    Feb 2006
    Location
    Oslo, Norway
    Posts
    28,684

    Re: Nokia N97 SDK - beta - released

    You could eliminate Cleanup Stack if that is what really bothers you
    Code:
    HBufC8 *text=CnvUtfConverter::ConvertFromUnicodeToUtf8L(aText);;
    HBufC8 *textz=text->ReAlloc(text->Length()+1);
    if(textz==NULL)
    {
        delete text;
        User::LeaveNoMemory();
    }
    Personally I prefer the one using Cleanup Stack, that is more readable. And generally local pointers should be kept on the Cleanup Stack anyway.

  10. #25
    Registered User
    Join Date
    Nov 2004
    Posts
    14

    Red face Re: Nokia N97 SDK - beta - released

    Quote Originally Posted by wizard_hu_ View Post
    You could eliminate Cleanup Stack if that is what really bothers you
    What's really bothering me is that a completely unnecessary { PushL(); ReallocL(); Pop(); } is presented as a resource-effective example.

    I am specifically bothered by the ReallocL() for increasing the memory buffer by 1 (one) byte just to cope with the PtrZ used later - where you clearly could allocate enough memory right from the start or use some other method of copying the not-"\0"-terminated HBufC8 buffer into a std::string.

    I've got no idea of how the ReallocL is implemented in Symbian OS(es), but if it ever uses a "malloc(); copy(); delete()" mechanism, you'll even introduce an unnecessary leave for a low-memory situation ...

    And generally local pointers should be kept on the Cleanup Stack anyway.
    Why should I push a local pointer to the cleanup stack when there's no leaving function in between the allocation and the delete!? But I might be missing something here :-}

    Cheers
    ole @ mobileways.de

  11. #26
    Nokia Developer Moderator
    Join Date
    Feb 2006
    Location
    Oslo, Norway
    Posts
    28,684

    Re: Nokia N97 SDK - beta - released

    You posted a code apparently converting some 16-bit Unicode text (I suppose) to UTF-8 format, into a 8-bit descriptor. It also suggested that the result has to be zero-terminated. I can not see any references to std::string, non-leaving-only future activities, etc.

    About the memory-management part: there are good chances for that HBufC8::ReAlloc/L actually uses RHeap::ReAlloc/L internally, which results in rare "real" re-allocations.
    And for about low-memory situations: in the average case it still requires less memory, even in the unfortunate case when that "real" re-allocation becomes necessary. Anyway, if Open C/C++ comes into the picture, the code is already doomed when a low memory situation occur.

    Usage of the Cleanup Stack is simply the Symbian way of coding, you use it if it is required, you do not use it if it is not.

  12. #27
    Registered User
    Join Date
    Nov 2004
    Posts
    14

    Re: Nokia N97 SDK - beta - released

    Quote Originally Posted by wizard_hu_ View Post
    You posted a code apparently converting some 16-bit Unicode text (I suppose) ... I can not see any references to ...
    How can you propose "the proper way" to code something if you don't know what it's all about!?

    I'd suggest to read a post before replying to it. From my personal experience I would be very careful to propose a "proper way" to code something - even if I knew what I was talking about.

    Not knowing or understanding the context and still having an answer to a non-question post ( = bug report ) speaks for itself.

    If you read my initial posting again you'll quickly realize that I just wanted to report a bug in the function ToString() in the homescreen widget example HsWidgetExample.cpp.

    As the homescreen widget API is pretty new to S60 I thought ( actually I know ) that other developers might just copy and paste some code from that example to their projects.

    Please have a look at the ToString() function to see that your solution is probably the worst possible - as discussed before.

    I'm hoping that the example is being fixed - and I would love to see a clever implementation without any unnecessary ReallocL()'s that even result in another unnecessary use of the Cleanup Stack.

    Cheers
    ole @ mobileways.de

  13. #28
    Nokia Developer Moderator
    Join Date
    Feb 2006
    Location
    Oslo, Norway
    Posts
    28,684

    Re: Nokia N97 SDK - beta - released

    Quote Originally Posted by jan_ole View Post
    How can you propose "the proper way" to code something if you don't know what it's all about!?
    It is easy: I see the code, then I fix it. As it happened. The supposed context comes from the board: "Symbian C++".
    I'd suggest to read a post before replying to it.
    If you have some time, you can freely read my 13000+ posts, and evaluate if I actually read what people write or not. Of course you might have more experience, since you have joined more than a year before me.
    From my personal experience I would be very careful to propose a "proper way" to code something - even if I knew what I was talking about.
    Yes, you should be careful.
    Not knowing or understanding the context and still having an answer to a non-question post ( = bug report ) speaks for itself.
    It is a habit. When I see crappy code, I tend to fix it.
    If you read my initial posting again you'll quickly realize that I just wanted to report a bug in the function ToString() in the homescreen widget example HsWidgetExample.cpp.

    As the homescreen widget API is pretty new to S60 I thought ( actually I know ) that other developers might just copy and paste some code from that example to their projects.
    That part is fine, feedback is welcome.
    Please have a look at the ToString() function to see that your solution is probably the worst possible - as discussed before.
    I do not have that SDK here and now, but the context would not matter anyway.
    I'm hoping that the example is being fixed - and I would love to see a clever implementation without any unnecessary ReallocL()'s that even result in another unnecessary use of the Cleanup Stack.
    Cleanup Stack is a safety measure. ReAllocL will move content on rare cases (in addition to my previous post, note that the ReAllocL in question happens immediately after the initial allocation, thus there are very good chances for that the next cell is not allocated, even in the case when allocation size has to be extended).

    If you want to continue this discussion, you should estimate overall memory requirements.

  14. #29
    Registered User
    Join Date
    Nov 2004
    Posts
    14

    Re: Nokia N97 SDK - beta - released

    Quote Originally Posted by wizard_hu_ View Post
    It is easy: I see the code, then I fix it. As it happened.
    Sorry to say, but adding unnecessary code that even runs the risk of an unnecessary leave doesn't qualify as a fix. It qualifies as a FAIL maybe ;-)

    Quote Originally Posted by wizard_hu_ View Post
    If you have some time, you can freely read my 13000+ posts, ...
    Trust me, I'd love to, really. I remember using some of your earlier comments to solve problems. However, this time you didn't read the posting and you even admitted it yourself ;-)

    Quote Originally Posted by wizard_hu_ View Post
    It is a habit. When I see crappy code, I tend to fix it.
    Yeah, you know, we've had that before. Replacing a malloc(n+1) with a malloc(n); realloc(n+1) is a real wizardry ;-)

    Quote Originally Posted by wizard_hu_ View Post
    I do not have that SDK here and now, but the context would not matter anyway.
    Okay, I see. That's the problem. Context doesn't matter to you. Nice approach, I will remember that ;-)

    Quote Originally Posted by wizard_hu_ View Post
    ReAllocL will move content on rare cases (in addition to my previous post, note that the ReAllocL in question happens immediately after the initial allocation, thus there are very good chances for that the next cell is not allocated, even in the case when allocation size has to be extended).
    I can confirm that *not* using ReAllocL() doesn't allocate any memory and doesn't move memory either. And I can attest that this is always the case when you're *not* using ReAllocL() :-P

    If you want to continue this discussion, you should estimate overall memory requirements.
    Excuse me, but I don't want to continue this "discussion" and I don't think it's reasonable to estimate overall memory requirements to decide wether the complexity of { /* NOP */ } is less than the complexity of { PushL(); ReallocL(); Pop(); }. But of course, context doesn't matter. By the way, are you a fan of Metallica!?

    Cheers
    ole @ mobileways.de

  15. #30
    Nokia Developer Moderator
    Join Date
    Feb 2006
    Location
    Oslo, Norway
    Posts
    28,684

    Re: Nokia N97 SDK - beta - released

    Here are the expressions for comparison
    - 4*n+1
    - p*n+1, 1<=p<=4
    I still assume that ReAllocL will not do anything in most of the time. For most cases I also expect p<2.
    By the way, if CnvUtfConverter::ConvertFromUnicodeToUtf8L happens to find a "hole" where the worst-case "4*n" string fits, but the "4*n+1" does not, it also means that your proposal could not make use of that "hole", so the 4*n+1 bytes would have to be allocated somewhere else. If that "somewhere else" exist, ReAllocL will also succeed.

    Have you noticed that my reasoning is getting better over time, while you can not show anything except "waaa, ReAllocL sucks"?

Similar Threads

  1. Series 40 Nokia 6212 NFC SDK has been released!
    By arip. in forum Near Field Communication
    Replies: 0
    Last Post: 2008-08-18, 11:23
  2. Nokia 6131 NFC SDK v. 1.1 has been released!
    By Raluca_ in forum Near Field Communication
    Replies: 8
    Last Post: 2008-05-29, 13:54
  3. Nokia 6131 NFC SDK 1.0 has been released
    By Nokia Ron in forum Near Field Communication
    Replies: 0
    Last Post: 2007-03-26, 22:28
  4. Infra-red capability
    By Symbian_Challenge_0412 in forum General Development Questions
    Replies: 1
    Last Post: 2005-08-16, 18:24

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×