I've been using TableLayoutManager as defined in the BlackBerry KnowledgeBase article Create a rich UI layout with TableLayoutManager
I'm considering using GridFieldManager instead.
Is GridFieldManager used for the same purpose? Are there advantages that GridFieldManager has over TableLayoutManager and vice versa?
This is not a complete answer, however here is what I have:
Are there advantages that GridFieldManager has over TableLayoutManager and vice versa?
At a glance - GridFieldManager is a comparatively new component (since API 5.0.0), while you can use TableLayoutManager on much older APIs (since 4.2). So if you're writting an app to be run on those pre-5.0 devices, then I think you should prefer TableLayoutManager.
Related
Are there any existing tools/combination-of-tools I can use so that my wireframes built using pencil or balsamiq can be directly used by my application (grails) for rendering the UI? Or maybe a way to generate GSP's out of my wireframes (assuming there is a set style guide etc.)? I am essentially looking to do away with having to code the HTML/GSP for each and every page.
Napkee is a commercial solution. I don't know any completely free one, though
I am new on Corona and worked with android sdk on Eclipse but i don't know how to pass from one activity to another in this one? What do you we use for this on Corona?
You do not have control over activities of your app when using Corona SDK.
What you need is the StoryBoard API which helps you to manage difference scenes.
Here are a few links regarding storyboard.
http://www.coronalabs.com/blog/2011/11/14/introducing-the-storyboard-api/
http://www.coronalabs.com/blog/2012/03/27/storyboard-scene-events-explained/
http://developer.anscamobile.com/content/storyboard
http://www.coronalabs.com/blog/2011/11/16/common-storyboard-api-questions/
Another unofficial but really efficient and useful method is the Director class
http://maniacdev.com/2011/05/using-the-director-class-for-easy-switching-in-the-corona-sdk/
http://developer.anscamobile.com/code/director-class-10
The PROS and CONS?
Director class is very simple and lightweight. And it has no known bugs. Used to be the only way until Storyboard was introduced a few months ago.
Story board is very flexible, and is officially supported. But it is relatively new and has some minor bugs.
There are about four implementations I can think of that are capable of loading SVG graphics into a Delphi application.
One of those, by Mattias Andersson, who is the author of FMX.Canvas.VPR
, works with FireMonkey, but he's not yet prepared to release the code.
A second one, by Martin Walter, works with the VCL, but developer has quit Delphi and has no plans to convert to FireMonkey.
A third one, part of the AGGPAS framework, works with the VCL, but no FireMonkey.
A fourth one is in development by Jason Southwell, but no date has been fixed yet.
So my question: what road to take if I want an SVG component today, without trying to reinvent the wheel a fifth (and probably more) time?
I'm Mattias Andersson -- the author of FMX.Canvas.VPR; I can say that I'm still actively working on the SVG solution. I guess once I have properly added support for gradients and text rendering then I can release a first beta version. I'm relying on TXMLDocument and that is a bit restrictive in what you are permitted to do (IMO), so I've had to invent some workarounds (maybe a better option would have been to implement my own XML class from scratch.) Also, I've had to do some run-time patching of the FireMonkey classes in order to make everything work correctly. The good part is that I'm actually implementing things according to the SVG interface specifications.
The SVG component I've been working on has been released as part of our Apesuite for Firemonkey.
http://arcana.sivv.com/apesuite
Getting involved with Mattias Andersson in the development is the best option:
FMX.Canvas.VPR by Mattias Andersson looks promising and VPR is proven to be an excellent project
No spoon-fed SVG FireMonkey component working out-of-the-box is available as of the time of posting (extensive web search made in general).
You could also consider using Chromiumembedded. Just load the svg in the embedded browser. You can then mix Delphi code with javascript, mix in html and css, etc.
This way, you can just leave it up to Chrome how to draw stuff fast (for example whether to employ gpu acceleration or not).
You'll get proper svg support, it's easy to integrate into your application, it's flexible, and there is lots of documentation and example code available online.
I am wondering if there is a way to reuse listbox items cells so you don't have to recreate the cell for every item individually?
this technique is used in iOS and as i've seen so far(by simple observasion, no tests were concluded), the performance in lists is much better in iOS then WP7 (on some-what equivalent hardware). Is this improvement due to the OS itself or is the UITableViewController(iOS) better handeled than the listbox(wp7) ?
Yes it is possible but you will have to look more into Silverlight(Xaml) Design.
You can define all rows in the list box to be completely identical with a little code,
Xaml will be the code behind for the design.
ListBox and Silverlight,
I would recommend reading the above page and maybe it will give you a better feel, i develop on both IOS and WP7 and i definitively prefer what the WP7 has to offer.
It just takes a bit of knowledge on both Xaml and The language of choice for the code behind.
As with my previous "vs" question at BlackBerry: Overriding paint() vs subpaint() I am wondering if this has to do mostly with convention, style, or if there are some real hard n fast rules.
The way I've seen it so far is that MainScreen.setBanner(Field) and MainScreen.setTitle(Field) have almost exactly the same functionality. I have used the case of being able to call setTitle(String) in a simple UI. However I am working across iOS, droid, BB, and try to make the UIs similar - my title/banner is a 'pretty' custom manager.
The only difference I can see is the little style element that is inserted automatically under a title.
Is this the only reason I would have to choose between using each of these methods?
Perhaps there are stylistic or convention reasons to use one over the other? Perhaps RIM has some intentions with these methods that I cannot yet see as a new BB developer? Am I making a mistake by treating these methods as direct substitutes?
If you use both, the banner is laid out above the title. My understanding is that if you are using only one, then they are pretty much interchangeable -- the reason to have both is that you can get some stacking behavior if you want to add more information to the top of the screen.
There is an article: "MainScreen explained" that goes into detail on this and other features of MainScreen.