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 <jrmy...@gmail.com
> <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 codenameone-discussions+unsubscr...@googlegroups.com.
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.
