Explicitly inherited method to (re)construct activity GUI after loading(possible) journal entity in sugar-toolkit

[alsroot]

now, read_file() calling placed in map event handler

if I want to construct activity's gui according to loaded jobject
I have to use connect_after("map") and rely on the fact that read_file() will be called before (of course I could call this construction from overloaded read_file but in that case I should count situation w/o loading jobject)

better way is declaring method in Activity class to handle this interval: after init(), read_file() invoking(possible) and before showing gui

[tomeu]

Why don't you update your UI in read_file()?

[alsroot]

Replying to tomeu:

Why don't you update your UI in read_file()?

sometime there is differences between "just construct" and "reconstruct existed"

[alsroot]

Replying to alsroot:

Replying to tomeu:

Why don't you update your UI in read_file()?

sometime there is differences between "just construct" and "reconstruct existed"

moreover in case of having new method there is only one place to collect logic (otherwise in init() and in read_file())

[tomeu]

Replying to alsroot:

Replying to alsroot:

Replying to tomeu:

Why don't you update your UI in read_file()?

sometime there is differences between "just construct" and "reconstruct existed"

moreover in case of having new method there is only one place to collect logic (otherwise in init() and in read_file())

I'm a bit concerned about making the Activity class more complicated. It's already quite messy and that is confusing activity authors.

Cannot we say that activity authors that find themselves in this situation can construct their UI by calling a single function from init and read_file?

[tomeu]

As any solution to this issue would involve API modifications, I'm moving it to 0.86.

[alsroot]

duplicate of #428

[dnarvaez]

Milestone 0.86 deleted