Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Adobe AIR Development

Reply
New Developer
Posts: 100
Registered: ‎10-31-2010
My Device: Dev Alpha C and PlayBook

Re: Closing event timeout?

Thank you. Using the CameraRoll is indeed much faster then using PNGEncoder, but the picture quality is much worser than using PNGEncode. It will be less noticeable with pictures, but you clearly see it on a drawing with less colors in it.

 

And you a right that I must not auto save the data afterwards when the user closes the application, but I think my app will be very slow when I save the data immediately when it changes. My app is a drawing application and when the user draws a line, the data changed in fact. So I constantly need to save the data and I'm afraid that will affect the performance of my app.


My PlayBook app:
DrawBook
Developer
Posts: 6,541
Registered: ‎10-27-2010
My Device: HTC One, PlayBook, LE Z10, DE Q10
My Carrier: Verizon

Re: Closing event timeout?

You could monitor "idle" periods of user in-action and save it during those periods. You can give the user a "passive" feedback that information is being stored. You might be even make it a preference to how often you want information saved. Lastly, you could have a "save" button to the user can save on their actions vs. auto.
New Developer
Posts: 100
Registered: ‎10-31-2010
My Device: Dev Alpha C and PlayBook

Re: Closing event timeout?

@jtegen - My app already has an save button and also a close button. When the user presses the close button it pops up a dialog to give the user the option to save the file. But you can also swipe up to the Tablet menu and then close the app. This is is the way I usually close apps and most people close it this way too. The problem is that I can't pop up a dialog at that moment to give the user the option to save. So I want to auto save it so the user is not disappointed that his drawing is gone, because many people expect their drawing is still available when they open the app again.

 

But I booked huge progress now. I now write the raw data directly to a file instead of encoding it first to a PNG. Now my app saves the data within a second even with drawings with a high pixel diversity. I'm still investigating the possibility to save data immediately when it changes.


My PlayBook app:
DrawBook
Highlighted
New Developer
Posts: 100
Registered: ‎10-31-2010
My Device: Dev Alpha C and PlayBook

Re: Closing event timeout?

I found another thing. When you have a lot of apps running and the OS decided to terminate you app to free up memory the CLOSING/EXITING event is almost useless. The OS gives you far less then 1 second during the event.


My PlayBook app:
DrawBook
Developer
Posts: 6,541
Registered: ‎10-27-2010
My Device: HTC One, PlayBook, LE Z10, DE Q10
My Carrier: Verizon

Re: Closing event timeout?

It would be nice if the OS gave an event like "about to quit", and the app has time (say 10 seconds) to do clean up before it actually quits. It would be even better that RIM lets us know the replacement to the deactivate events since they still say that is the way to do things. Either replace it for fix it.
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Closing event timeout?

@Tjitte, thanks for noticing that. I ran my ExitingTest app and forced it to exit from low memory conditions, and in fact it does not even appear that it received the EXITING event or, if it did, it had only a couple of milliseconds maximum to respond, which is useless.

I'll try expanding its capabilities a bit to look at some other aspects of this, but definitely it seems apps should not rely on getting EXITING under low memory conditions.

Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Developer
Posts: 39
Registered: ‎01-13-2011
My Device: Not Specified

Re: Closing event timeout?


Tjitte wrote:

 

But I booked huge progress now. I now write the raw data directly to a file instead of encoding it first to a PNG. Now my app saves the data within a second even with drawings with a high pixel diversity. I'm still investigating the possibility to save data immediately when it changes.



This is the way to do it. Save your state (the user's drawing) as it changes, optimizing this process as much as you need to. Only export an image file upon request by the user. 

New Developer
Posts: 100
Registered: ‎10-31-2010
My Device: Dev Alpha C and PlayBook

Re: Closing event timeout?

We need an event that is triggered when the user swipes up or when the app goes into thumbnail mode in the new SDK.


My PlayBook app:
DrawBook
Developer
Posts: 6,541
Registered: ‎10-27-2010
My Device: HTC One, PlayBook, LE Z10, DE Q10
My Carrier: Verizon

Re: Closing event timeout?

The deactive event should do this, but it is not reliable. The app can go inactive by side swipes as well (moving from one app to another).
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Closing event timeout?

Some of us have been discussing this in #playbook-dev (IRC) for quite some time.  Based on those discussions I'll add a couple more comments here.

 

For one thing, DEACTIVATE is not "unreliable", it's merely defined differently than some of us hoped or expected based on what we'd seen in the simulator.  DEACTIVATE is actually quite reliably sent whenever our app is no longer "active"... the issue is the definition of "active".  The PlayBook has (currently) three "application behaviour" modes: showcase, default, and paused.  In both showcase and default modes, an app that is minimized is still "active".  In default mode, it becomes inactive only when you make a different app active.  In showcase mode, all running apps are "active".

 

The real problem is that we need to consider this from the point of view of user interaction.  What we're missing is any way to detect when an app, previously running fullscreen and capable of realtime user interaction, is no longer in that state.  When an app is minimized, the user cannot directly interact with it in most ways, other than by maximizing it back to fullscreen again.  (Note that, given the complexity of the PlayBook, there are ways to interact with even a minimized app... for example, a game that uses the accelerometer as the primary input channel can continue to work just fine when minimized, if it's an "active" app still.  I'd call this a corner case and ignore it for now.)

 

The simplest way to look at it is that if the only way an app receives touch input is to be fullscreen, then we need an event to tell us when an app becomes "not fullscreen".  This could be getting minimized, swiped-away-from, or maybe even some other action such as top-right-swiping and tapping on the Settings icon, which almost completely masks the running app's window with the settings pages.  Under any of these conditions, it would probably be very helpful to learn of it and let certain apps pause (e.g. for games) or possibly save state (to avoid us having to save too often, hurting usability because of user responsiveness issues, etc), or even just switch to a less power-hungry mode of operation.


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!