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
Highlighted
Developer
Developer
Posts: 266
Registered: ‎04-01-2009
My Device: Not Specified

Difference: Real Device vs. Simulator

Hello,

let's collect the info here where we state what is different (from a developer view) on the Simulator vs the real Device.

 

I'll start with this:

- When using SharedObject to store data, make sure to set permissions for that! It works on the simulator without permissions but doesnt work on the real device without permissions

 

Please feel free to add more!

Developer
Posts: 2,462
Registered: ‎11-04-2010
My Device: Bold 9700

Re: Difference: Real Device vs. Simulator

Also the icon size must NOT exceed 90 x 90 pixels. If it is larger, it will show up on the simulator but not on the actual device.

J. Rab (Blog) (Twitter)
--
1. If you liked my post or found it useful please click on the thumbs up and provide a Like!
2. If my post solved your problem please click on the Accept as Solution button. Much appreciated!

Approved Apps: OnTrack | ssShots | Hangman
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Difference: Real Device vs. Simulator

@bba, are you saying that you can positively confirm, after comparing identical code on a real device and in the simulator, that mere use of SharedObject, even though the data gets stored in the "application storage directory" and not under the shared/ folders, definitely requires the access_shared permission to work?

 

This would invalidate my theory about access_shared, which would really start to depress me.  (See also Elena's post immediately following mine.)

 


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
Developer
Posts: 266
Registered: ‎04-01-2009
My Device: Not Specified

Re: Difference: Real Device vs. Simulator

Peter, 2 weeks ago I have submitted an App to AppWorld in which I have NOT set the permission for shared_access (because I did not know about it). It worked fine on the simulator not having this permission set. 

 

But then I got a negative review in AppWorld saying that the data is not saved after the app is exited. This lead me to that fact that the shared_access is needed to be set when using SharedObject. But on the simulator it is not needed.

Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Difference: Real Device vs. Simulator

@bba, okay, so you're speculating then... just trying to deduce the reason from a problem report.

 

I think if we're going to have a thread that reports on differences, we should be really clear about what's confirmed as fact, and what's still supposition.

 

To be fair, as I haven't tested my app myself on real hardware, I don't really know that SWIPE_START works differently there... also just speculating.

 

Maybe anyone posting such things can at least be clear on whether they've personally tested things and confirmed the problem, or to what extent they're speculating.  Better than us all running off half-cocked and changing things that maybe are just our own bugs.


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: 526
Registered: ‎05-17-2009
My Device: 9900
My Carrier: ATT

Re: Difference: Real Device vs. Simulator

I can confirm this. I know one of my apps was tested on device with and without the shared object permission. At least at that time and whatever os version they were on, the permission made the difference in the shared object code working.

Like all of my posts
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Difference: Real Device vs. Simulator

 


kylefowler wrote:

I can confirm this. I know one of my apps was tested on device with and without the shared object permission. At least at that time and whatever os version they were on, the permission made the difference in the shared object code working.


 

I can now confirm that access_shared is NOT required for a generic use of SharedObject.

 

I was able to get someone to test my own app on a real tablet, with 1.0.whatever.  It uses SharedObject in the following manner, roughly:

 

var so:SharedObject = SharedObject.getLocal("prefs");
so.data.prefs = prefs;
so.flush();

I do not have access_shared listed in my blackberry-tablet.xml file, and when the above code is executed, the data does get saved under the app's own data/#SharedObjects folder as expected.  (Confirmed by verifying that, upon reinvoking the app, the saved state is restored, and confirmed by direct inspection of that folder.)

 

 

It was also confirmed that access_shared in fact is actually required, as I had earlier surmised, for access to the shared/ folder tree, and not for anything inside File.applicationStorageDirectory.

 

If your app changes anything in shared/ (or, possibly, even reads from it... that's still unclear), then you should definitely specify the access_shared permission and submit a new release.  If you merely use SharedObject in the app's own storage area, however, you do not need it.

 


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: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Difference: Real Device vs. Simulator

Not related to my above post on SharedObject, I do have another difference to report.

 

The real device will apparently support three modes for multitasking, as we've seen in recent videos.  These are now labelled "Showcase" (the former "all signing all dancing" mode), "Default" (which appears to be how the simulator functions), and "Paused" (which appears to mean basically frozen).

 

I believe the notes on qnx.system.QNXSystemPowerMode are actually referring to these settings and, if true, it appears we could read through the undocumented qnx.system.QNXSystem class what the current setting is.

 

The main difference I've heard of so far is that if the device is in Showcase mode, your app may not receive any ACTIVATE/DEACTIVATE events.  If your app relies on DEACTIVATE to persist its data, it will not work properly in Showcase mode even though it works fine in the simulator.

 

To resolve this, you can add a handler for event.EXITING on the NativeApplication object to listen for when the app exits, and that will ensure you get a chance to persist your state even in Showcase mode.

 

Everyone who deals with the activate/deactivate states may also want to consider the different affect on their apps that these three modes will have... it looks like in the Paused mode, an app gets few events and no CPU most of the time, so if you rely on the sort of ongoing operation that the simulator has given you (i.e. Default mode) then you may see issues in Paused mode.


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: 124
Registered: ‎01-22-2011
My Device: Blackberry Q10
My Carrier: Sprint

Re: Difference: Real Device vs. Simulator

Very interesting.  This explains a very mysterious behavior I was seeing between my app used on my simulator and in the test house.  Nice find!

Developer
Posts: 526
Registered: ‎05-17-2009
My Device: 9900
My Carrier: ATT

Re: Difference: Real Device vs. Simulator

Ill have to go back to my guy who tested for me and confirm. Id bet you are right though. Could have been old software or another issue.


peter9477 wrote:

 


kylefowler wrote:

I can confirm this. I know one of my apps was tested on device with and without the shared object permission. At least at that time and whatever os version they were on, the permission made the difference in the shared object code working.


 

I can now confirm that access_shared is NOT required for a generic use of SharedObject.

 

I was able to get someone to test my own app on a real tablet, with 1.0.whatever.  It uses SharedObject in the following manner, roughly:

 

var so:SharedObject = SharedObject.getLocal("prefs");
so.data.prefs = prefs;
so.flush();

I do not have access_shared listed in my blackberry-tablet.xml file, and when the above code is executed, the data does get saved under the app's own data/#SharedObjects folder as expected.  (Confirmed by verifying that, upon reinvoking the app, the saved state is restored, and confirmed by direct inspection of that folder.)

 

 

It was also confirmed that access_shared in fact is actually required, as I had earlier surmised, for access to the shared/ folder tree, and not for anything inside File.applicationStorageDirectory.

 

If your app changes anything in shared/ (or, possibly, even reads from it... that's still unclear), then you should definitely specify the access_shared permission and submit a new release.  If you merely use SharedObject in the app's own storage area, however, you do not need it.

 


 

Like all of my posts