Hi Steve,
Thanks for the explanation. I think I've finally found what is the problem.
I'm using the library you've implemented (cn1-data-access-lib) which I've
modified to save/read object recursively ... The problem is the cost in
term of memory when I update/insert an object.
The code which is problematic in the DAO class of your framework is :
/**
* Gets the POJO model object. If it has been GC'd, then this will return
null.
*
* @return
*/
T getObject() {
Object o = obj;
if (o != null && (o = Display.getInstance().extractHardRef(o)) != null) {
return (T) o;
}
Log.p("[WARNING] invoking getObject() return null object ! (" + o + ")");
return null;
}
In my case, if a gc occur in the middle of a hard task (save a big object)
-> the method "getObject()" return null because of the gc.
Does this mean that I need to perform a gc before each saving of an object
?
I understand why you are using WeakReference object in the framework but
how to manage this in my case ...
Notice that my problem occur only on iOS/Android and it's random.
On Tuesday, November 15, 2016 at 7:09:05 PM UTC+1, Steve Hannah wrote:
>
> One thing you should be aware of when using invokeAndBlock a lot is:
>
> Tasks in the "invokeAndBlock" queue are processed in a First-in-Last-Out
> fashion (i.e. like a stack, rather than a queue). So if you call
> invokeAndBlock(task1), and then you call invokeAndBlock(task2) in a
> separate dispatch before the first invokeAndBlock call has returned, then
> the second call will return before the first one.
>
> This isn't a big deal if all of your calls to invokeAndBlock are
> relatively "fast". However if you throw a "long-running" task into
> invokeAndBlock it can cause some undesirable effects. Modal dialogs in
> particular use invokeAndBlock to prevent the show() method from returning
> until the dialog is closed. This will be a very long-running "task". So
> if you have some existing invokeAndBlock calls that haven't yet completed
> when the Dialog.show() method it called, those calls will also "hang" until
> the dialog has been closed.
>
> This is likely why your runnable is executed later.
>
> Steve
>
> On Tue, Nov 15, 2016 at 6:04 AM, Jérémy MARQUER <[email protected]
> <javascript:>> wrote:
>
>> Hi there,
>>
>> I'm currently implementing a complex application wich required
>> multithreading. I do many access to database to save and read data.
>>
>> My problem is to have an application with the better UI experience even
>> if I have some hard task to complete, depending on user interaction.
>>
>> At the beginning, I misundertood why my application was running very
>> jerky on iPad 3 and smoothly on iPad Air 2 : of course the performance of
>> the last one leads us to think there is no problem in code. So I read some
>> informations about EDT and invokeAndBlock method. My idea, as suggested in
>> your post, was to call invokeAndBlock method when I need to do hard task
>> without blocking the UI.
>>
>> The issue is I've many "invokeAndBlock" calls which could interfere (with
>> internal calls, for example : showing a dialog), and some code is invoked
>> with an offset (which sometime lead to exception).
>>
>> What I can't explain is : why sometimes the code inside runnable is
>> executed later ?
>>
>> I'm trying to use scheduleBackgroundTask instead but it's an async
>> methodology....
>>
>> (PS : sorry if it's not clear !!)
>>
>> Thanks !
>>
>> Jérémy.
>>
>>
>
> --
> Steve Hannah
> Software Developer
> Codename One
> http://www.codenameone.com
>
--
You received this message because you are subscribed to the Google Groups
"CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at https://groups.google.com/group/codenameone-discussions.
To view this discussion on the web visit
https://groups.google.com/d/msgid/codenameone-discussions/35d1bd7c-7fec-4f69-ad60-5b88eb092c3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
