Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Reply
Developer
BBSJdev
Posts: 6,116
Registered: ‎07-05-2012
My Device: Playbook, Dev Alpha C, Z10 LE, Z30

Re: Divider

[ Edited ]

Okay I don't want to get in to a 'mines bigger then yours' argument or in this case smaller.

All I will say is that as someone who worked on the first ARM compilers, assemblers and linker I would probably take that bet.

 

[Edit] Oh I see you are comparing QML and C++ not our coding. :smileywink:

 

But as a case in point why in C++ add a function when you have already subclassed Container which has those functions in already?

Surely you can see it's unnecessarily adding code and therefore increasing memory use?

 

Also your class won't work in QML you're effectively saying you must use C++ at all times.

 

 


If you've been helped click on Like Button, if you've been saved buy the app. :smileyhappy:

Developer of stokLocker, Sympatico and Super Sentences.
Please use plain text.
Developer
Developer
p8
Posts: 132
Registered: ‎01-24-2013
My Device: blackberry z10

Re: Divider

[ Edited ]

Im comparing both.

 

Your suggestion is a good "quick and easy" solution for someone happy to use qml.

Even better would be to create a reusable component in qml, since something like a divider is likely to be needed again ad again.

 

Mine is  good c++ solution. Its cleaner more robust, and reusable, but obviously only feasible if one wants to write in c++.
It certainly uses more (source) code than yours, but thats just one consideration when writing a project.

That certainly has nothing (simple) to do with memory usage. Im surprised that you think so. It can very easily happen that more (source) code uses less memory when compiled and executed. Qml is always comes with extra baggage that slows down and increases memory usage of an app. It one of  the prices one pays for being able to do simple things "quickly and easily".

 

 

 

Please use plain text.
Developer
Developer
p8
Posts: 132
Registered: ‎01-24-2013
My Device: blackberry z10

Re: Divider

> But as a case in point why in C++ add a function when you have already subclassed Container which has those functions in already?

 

You mean "setColor" ?

 

Thats abstracting client code from the fact that Container is subclassed.

I could change my implementation to not subclassing Container, or eg containing a Container, and client code would not need to be changed

Please use plain text.
Developer
BBSJdev
Posts: 6,116
Registered: ‎07-05-2012
My Device: Playbook, Dev Alpha C, Z10 LE, Z30

Re: Divider

Sorry I don't want to drag this out but I disagree, what does your class have over the Container class apart from;

 

  - Can't be used in QML

  - Unnecessarily duplicates functions already present in the Container class

  - Increases memory size from unnecessarily substituting Container class

 

Sorry IMHO even in a C++ only environment this class makes no sense.

 

Any way this is going way off topic so I'll leave it at that.

No doubt your C++ experience is far superior to mine so I'm probably missing something obvious.


If you've been helped click on Like Button, if you've been saved buy the app. :smileyhappy:

Developer of stokLocker, Sympatico and Super Sentences.
Please use plain text.
Developer
Developer
p8
Posts: 132
Registered: ‎01-24-2013
My Device: blackberry z10

Re: Divider

[ Edited ]

Yes I think its just best to summarise with saying that your suggestion should be preferred if using Qml (ideally modified by puttng the code into a custom component :

 

https://developer.blackberry.com/native/documentation/cascades/ui/custom_components/

 

And mine is good suggestion if writing in C++.

There are good arguments for/against C++/Qml that would be more appropriate in a separate thread.

Memory consumption and execution speed speak clearly for c++ however.

 

> - Can't be used in QML

 

Agreed (well actually it can...C++ classes can be made available to Qml, but I wont go into that now. For this example it would be better to create a custom component in Qml as you suggested..unless one wanted it to be available to client code in both C++ and qml .. then this would be the way to go)

 

> Unnecessarily duplicates functions already present in the Container class

 

If you mean setColor, I think I explained this clearly. It protectes client code from changes in the implementation.

 

>  - Increases memory size from unnecessarily substituting Container class

 

It doesnt increase memory (any more than using c++ inceases memory consumption over using c)

 

> Sorry IMHO even in a C++ only environment this class makes no sense.

 

It certainly does.
 It makes client code simple and robust:

 

new tRpSep(Cont); // simple as that, anywhere client code needs a separator in any project

 

 

>> I bet the memory footprint is a lot smaller than yours ;-)

 

Id like to take this back. Ive no idea what your code in general looks like or how it behaves and I should have expressed myself more carefully. Sorry.

 

 

 

Please use plain text.
Developer
Zmey
Posts: 1,512
Registered: ‎12-18-2012
My Device: PlayBook, Z10, DAC

Re: Divider

Just wanted to add a little bit to the discussion:

I remember that in the docs there was a mention that the only class that should be subclassed is CustomControl. It was explicitly mentioned that other classes shouldn't be subclassed. I don't know why, maybe this can break binary compatibility in the future.

I've rewritten my code to subclass CustomControl and create Container as a root node, even though it was working when inheriting from Container directly.

Andrey Fidrya, @zmeyc on twitter
Please use plain text.
Developer
BBSJdev
Posts: 6,116
Registered: ‎07-05-2012
My Device: Playbook, Dev Alpha C, Z10 LE, Z30

Re: Divider

@zmey This is what I have done as well, but for the OP's question this is overkill.


If you've been helped click on Like Button, if you've been saved buy the app. :smileyhappy:

Developer of stokLocker, Sympatico and Super Sentences.
Please use plain text.
Developer
Developer
p8
Posts: 132
Registered: ‎01-24-2013
My Device: blackberry z10

Re: Divider

[ Edited ]

Hi Zmey.

 

Good point and thanks for mentioning it.

 

I had read this too and its better to play it safe as you do by not subclasing Container.

 

but

 

(1) I find the documentation unclear here. It could be saying "you shouldnt subclass Control directly (but its ok to subclass its descendents (eg Container)"

 

(2) I think its very unlikely that Blackberry will change anything that will cause code that has subclassed something like Container to then break (but still work when you contain/use it in eg a CustomControl). The only thing that springs to mind that would do this would be if they changed (signatures of) protected/private members. They would mess up their own code by doing so, so its much more likely theyd create new and/or overload functions instead. Even then theyd have to be careful not to break binary compatibility (which could happen even if you were only subclassing CustomControl). Most classes like Container dont define any private/protected members anywas so this is a non-isssue in this case.

 

I personaly feel its overly restrictive to ask (if thats waht this piece of documentation is actually saying..and if it is it should be unambiguous!) developers not to subclass most of the controls. Sure it leaves the library designers more room to change things later..but at a price.. there are some things that cant be done, or done as well at least, without subclassing, and can be quite a bit more effort..all members in the control you want to access from outside need to be proxied through the interface of the CustomControl.

 

Gererally however I just subclass Page (which is not a Control) and Container (which doesnt have new private/protected members), so like I said it doesnt matter. But in general I suppose your right to be safe and try to just subclass CustomControl. Maybe I should too.

 

P.S

: Thats exactly the kind of thing functions like setColor() in my class protect the client from..If I decided I did in fact want to subclass CustomControl instead, which then contained a Container * instead of being one, then the fact that clients had been written to access tRpSep::setColor (rather than Container:setBackground), would mean theyd be unaffected. Only my implementation of setColor would need to be modified

 

Please use plain text.
Developer
BBSJdev
Posts: 6,116
Registered: ‎07-05-2012
My Device: Playbook, Dev Alpha C, Z10 LE, Z30

Re: Divider

@p8 Sorry but I just see a number of problems with your implementation and a few statements you've made on C++ and memory footprint are just plain wrong.  However if you are happy with it then let's just leave it at that as this is getting way off-topic.

 


If you've been helped click on Like Button, if you've been saved buy the app. :smileyhappy:

Developer of stokLocker, Sympatico and Super Sentences.
Please use plain text.
Developer
ekke
Posts: 1,538
Registered: ‎04-08-2010
My Device: Z10 (red Limited Edition), Q10, Z30
My Carrier: Telekom.de, O2, Vodafone

Re: Divider

curious to read this thread ;-)

 

from my POV:

using a Container, fill it with color, use height and padding, add some properties

 

and you have a perfect Divider you can re-use in all your apps

 

doesn't matter if you're doing this from C++ or QML

 

my 2 cts

-------------------------------------------------------------------------------
ekke (independent software architect, rosenheim, germany)

BlackBerry Elite Developer
BlackBerry Platinum Enterprise Partner
International Development Mobile Apps BlackBerry 10 Cascades
Cascades - Workshops / Trainings / Bootcamps

blog: http://ekkes-corner.org videos: http://www.youtube.com/user/ekkescorner http://vimeo.com/ekkescorner/videos
bb10-development: http://appbus.org Twitter: @ekkescorner
Please use plain text.