Cascades Development

[Bluenoser]

Hi,

  I am looking for some feedback on the best practices when you have multiple dataModels. Lets say that you had TabbedPane with 10 tabs. Each tab had its own data model. What is the best way to handle loading and freeing all the data models so that they are only loaded when the correct tab for that model is selected.

  My thoughts is that for each dataModel, you would have a .cpp and .h file that contains loading(read local or remote data) and unloading of the data. You would declare and associate the QML and C++ dataModels in the apps .cpp file. Then when you select a tab or the default tab is displayed, you would load up the data. Then when you select another tab, the current tabs data would be freed and the new tabs data would be loaded.

  Then loading of the data could be read from a remote server and you could save the data local. The local data is then what is displayed in the ListViews until the user presses a refresh button to get new remote data. This could also be dependant on the data so it would read remote data each time the ListView was displayed.

  Am I on the right track and how would you handle the entry load and exit unload of the dataModels for each tab?

  Thanks in advance.

[smacmartin]

That sounds fine to me.  What you do depends on your application and is part of your job as the developer of the application to make the best memory/performance tradeoffs for the users of your app.   You'll probably want to err on the side of lower memory unless there is a performance issue you need to address.

Some questions to ask yourself are:

- how much time does it take to load the data?

- how much memory does it take to keep the data?

- if the user switches to a different tab, how likely is he to need that old data again, and will it need to be refreshed anyway?

My first cut would look very much like yours.

Stuart

[Bluenoser]

Stuart,

  Given a TabbedPane system, how would you know to free one dataModel and load another one.

  I saw your knowledge base article about using your own DataModels. Could you help with getting one with what I am asking for?

  Your comment is right about the developer to make the decision about what is the best use of memory/performance for his apps. Right now, there isn't enough documentation about best practices in developing native apps. I am hoping that RIM will help developers in giving this type of information and examples.

Thanks

[gperry]

Not sure that there are guidelines available to this level of detail at least.

What design and implementation choices have you considered so far? Have you tried any prototyping.

I spoke with Stuart and we both would think that come form of Superclass arrangement that allowed the

sub classes to control their own data but still presenting a common interface. If you come up with an elegant 

solution we would be interested in you sharing it and think it might be worth a Knowledge Base Article as this

is likely to be a common problem.

Regards

Graham 

[greenback]

Cascades has been a tremendous joy to use! The UI part of applications is rock solid. The second part of the equation is the data/logic side of application development. If end-users are to benefit from rich super-apps. 

In terms of the data model question: I am also having difficulty figuring out how to connect all the classes together in a way that works with my applications. At the moment, I am concurrently developing 3 super applications. Once the PIM APIs are released, I plan on integrating them into the platform further.

Who can I email at RIM/bb dev to explain my 3 apps, and maybe get some guidance? I think these apps would be useful to a large set of bb end users.

[Bluenoser]

Graham,

  I have been trying to go though the examples and documentation to try and figure it out. I am starting on a prototype, but I am reaching out to others to help. If it is a common problem and I think you are right. It would be great if RIM could create a knowledge base article from someone who knows a lot more than me.

Thanks

Ron

[gperry]

We will look into creating a KB article to address this.

Thanks for the suggestion.

Graham