Does the number of panels impact offline mobile performance?

[PaulAmmoun]

Hi,
I have a slow-running mobile application.
I noticed that when I remove features (panel cards) it runs faster.
Since it is an offline builder with cordova why should It be faster? any logic behind it?
I did a small search on the net and they say that the application size does not impact performance.
The UX size was 11.1 MB the smaller one is 6.5mb
the APK size was : 7.58mb the smaller one is : 7.68mb (I don't know why it is bigger; maybe because of the name of the app of info)

[Ted Giles]

Offline typically has the overhead of refreshing the SQLLITE Db - or similar - on the user device.
That's why off line is such a pita.
If you can keep the offline data to be as small as possible, that may help.

[peteconway]

re 'I did a small search on the net and they say that the application size does not impact performance.
The UX size was 11.1 MB the smaller one is 6.5mbI did a small search on the net and they say that the application size does not impact performance.
The UX size was 11.1 MB the smaller one is 6.5mb'

I have to tell you size does matter in AA, that's a big UX, what's in it, what does it do?

Pete

[PaulAmmoun]

Hi Pete,
in 2 words it is used to record visits to customers.
but there is a lot of functionality in it.
the users can:
1-View the route (customers that needs to be visited today)
2-View all the customer
3-make a direct invoice
4-place an order
5-give sample
6-make receipts
7-view the location of the customer on the map with the direction
8-punch feedback of customers for specific products
9-send receive messages from the office
10-punch the customer that needs to visited in the future
11-see previous visit history
etc..

if I divide it in multiple UX can it still be offline?

I am on the latest official release 8000 (it worked well for me)

Thank you

[christappan]

Hi Paul, couple of question/comments:
- what build are you using? I don't know how many lists you have, but I know that there was an improvement last year on build 7704 for Android. Prior to that all the lists (even on non-visiable panels) were refreshing (client-side, not server-side) when the Android keyboard was activated, and they changed it to just refresh the visible lists.
- I found that the client-side show/hide and enable/disable was firing constantly. I moved that kind of functionality to my own javascript to call them intentinoally, but at the end of the day I probably have just as much Javascript running. Still, if you've got a lot of client-side stuff going on, it could slow things down.
- you can split it into more than one UX and still work offline. You just have to embed the child UX and set it to Precomputed. Selwyn seems to think that performance improves with more smaller UXs than fewer large UXs. I can confirm nor deny. What you can't do is put child lists in a separate UX from the parent list if you're using that functionality. You also can't put detail views in a separate UX than a list unless you want to write the Javascript yourself that handles that.

[peteconway]

So Paul, it looks like it does plenty, what I wanted to know was how many lists, grids, data fields etc. UX control carry quite a high xbasic count in them, especially if you are using s lot of AA javascript Actions, these are all getting processed in the DOM in the browser of the device. (The DOM (Document Object Model) is an interface that represents how your HTML and XML documents are read by the browser. It allows a language (JavaScript) to manipulate, structure, and style your website.)
You need to be working on using as much javascript in the javascript functions area as possible, without xbasic involved in my view..
Pete

[christappan]

All due respect, Pete, I believe just the opposite. On a mobile app, all of the HTML and xbasic that is usually generated on the fly in a web app, is pre-packaged as an HTML file that the mobile app just has to open locally. So the only xbasic that executes is when a list is synced with the server, or a list is refreshed from the server, etc. You obviously need enough JavaScript to accomplish what needs to happen in the UI, but the execution of the JavaScript is the only thing that's happening in real time on a mobile app.

If you have any list events, I would test your assumptions on them. I find that events like onListReady fire even if I'm nowhere near that list or interacting with it. Or they fire three or four times instead of the one time you expect. So you can quickly start running way more JavaScript code than you think you are.

I know Pete is an advocate of the view box, and I haven't used it much but those are far lighter weight on the xbasic and JavaScript side then list controls. So if you don't need editable, persisted data to a particular list, that would improve performance to switch to a view box.

[peteconway]

Yes - I use Viewboxes now exclusively, I don't use AA Javascript Actions where they can be avoided, I have full CRUD control, I only have one callback function, ever. I only have one transient message type function ever , what I don't have is 20 Transient Javascript Actions for 20 messages. I have one panel function ever, I have one print function ever, I have one map function ever, I have one of everything, not one for everything I want to do, times the the numbers of times I want to do it, this is where applications in the DOM (in the device) gets slow as it juggles the volume of controls, which is Paul's issue he said 'I have a slow-running mobile application' - I'm saying this is possibly why. It's the downside on no-code option convenience.
Just saying
Pete

[PaulAmmoun]

Hi Pete,
Sorry I misunderstood.
It is 29 lists, 58-panel cards, and 1 map and 1 javascript chart it also has 9 embedded components (not needed for offline that contains lists also.
I know it is a big UX.
I have heard a lot about view boxes, I never used them. But since the data needs to be offline I believe for the majority of my app it can't be used.

[peteconway]

That's way to heavy Paul, how many of the list controls perform Create, Update, and Delete functions?
re 'But since the data needs to be offline I believe for the majority of my app it can't be used' - how is the data stored in local storage of the device?
Pete

[PaulAmmoun]

Hi Pete,
thank you for your time.
Yes I use local storage and some Client side data cache.
Around 10 lists are needed for data entry.

[Ted Giles]

Paul, question.
Can you use the phone as a Hotspot? You mention Cordova so I presume you are using phones.
Reason for asking.
Tablets can have more processing power than a phone, and piggy backing a phone as a Hotspot can make use of that.
It means thinking a bit differently, but your app is, as Pete suggests, a bit large for a mobile.
Also depends on 3/4/5G coverage where you are.

In the UK, off line is rare nowadays as nearly everywhere has 4G as a minimum.

[christappan]

Paul, first, I'm jealous, because I have a UX that's 12MB, but it only has 6 lists and I have no idea how you got that many lists into an 11MB UX.

I don't know the particular needs, but I would look for ways to combine the lists and the data caches being used for lookups, etc. For example, I've got a single list that holds all the values for my dropdown options. The query is a SQL view with a bunch of UNION joins and one of the columns is the name of the option list. So I could click on a gender field with an onClick event to flter the list by list == 'gender' and then only the options from the gender table are displayed. Or filter by list == 'fee' and see just the fee options. Data caches don't have the baggage of a list, but if lots of data caches are combined into a list you may see increased performance?

Again, I don't know much about list boxes, but they appear to be much lighter; lists just have a whole lot of boilerplate included even at the javascript level. So anywhere you have static data in a list I would definitely look toward a view box.

[PaulAmmoun]

Thank you for the responses.
On fast devices the application is performance is acceptable. (the newer devices have 4gb and more ram with a good processing speed).
The issue is on older or budget devices.
From my testing the client sidr data cache do not impact performance. But lists does.
I didn't test if a list without details (read only lists) does impact performance.
The main issue is to explain that to the client :)
It is a replacement of another app(native).
When developing I did the testing on my mobile which is fast (it is a new huawei phone 6gb ram).
When i started implementing on the customers devices he has old devices (2gb ram) on it the application is not responsive at all.
So i need to explain why the new app does not perform as the older one :(
I can try to change some lists into viewboxes but this will take time and not sure about the outcome.
Ps: i have multiple lists but the lists do not have vr many fields.
Thank again for the replies

[RustyB]

Wow very informative posts. Thanks all for sharing. I have a 14 MB ux with about 50 lists running on Android tablet with only 2 GB of RAM. Needless to say it is slow, but does perform a little better of faster tablets. Many decisions we made with this app were when we were first starting with Alpha and didn’t know any better. I now know that View boxes are lighter alternatives to lists, just haven’t had time to convert them.

I did suspect the client-side show/hide and enable/disable firing constantly might be a resource hog, and now that I have heard someone else mention it I will try to move away from using these. Also, I was aware of the “every list gets refreshed” change by Alpha. Luckily, Selwyn had gave me a work around, but good to know it has been fixed.

We also would do things like put code behind a button and then programmatically press the button instead of using JavaScript Actions (hey we were beginners). I am a little confused as to why to try to avoid them Pete. I know Dion recommended them at DevCon as an way to keep all your code in one place as opposed to putting them behind controls that you have to find in your app. They seem like they would be pretty lightweight.