2016년 11월 17일 목요일

Is screen too complex for the emulator? Limit to the number and size of blocks?


I am developing a rather large application, which I am testing in emulation until I feel it is ready for pushing it on an Android device.

The app architecture is spread out over several screens which seem to all work, except one. 3 of those screens are quite complex, and two of them do run as expected, but the 3rd one is giving me trouble, with the emulator "stalling" on load, which ends with an emulator crash.

For a while I suspected that perhaps the presence of tables (which seemed to have caused a problem in another screen, since then corrected by replacing the table arrangements with a multi-layered organization of nested horizontal and vertical arrangements) was to blame for it, so I cleaned it up. The duplicate screen with no table arrangements loaded and displayed fine in the emulator, until I imported the computing procedures. Then it crashed.

At that point in time, all those procedures were still unconnected to any event trap, so loading the page would not have activated them. But I presume the system provisionally visits them on page load (even before the ".Initialize" runs) to allocate memory and resources; is that a valid assessment?

It so happens that this is indeed the most complex screen in terms of sheer size and number of blocks, with something like a projected total 160 sel-contained Blocks (definitions, event traps and called procedures), which should represent about 3500 statement-blocks. The other screens that currently load and run fine each have about 2500 statement-blocks total.

That is a lot, but is it really *too much*?

I dread having to split this screen into two less complex screens, since it would affect the harmony and feel of the application; but if there is no other way... I would like to know if there are alternative approaches that could be tried before launching myself in a major reprogramming effort that I do not know would be successful (since splitting the code will end up making two components that are each 60 to 65% of the original combined screen, as some functions would have to be duplicated, and could still be beyond the limit, if there is such a limit in the first place).

Has anyone come across an actual "memory space saturation" of that (suspected) sort, and could share experience and gained wisdom in that area?

Thanks
CBVG

-- 
Testing and developing using a real phone is soooooooooooooo much easier. Install the AI companion on your phone, connect, and off you go.
Allows you to see if your app is too complex on a real screen too.
That said, maybe looking at making your app less complex is a good idea too. Not necessarily by splitting your app into more screens, but by rethinking the layout and rethinking how you can reuse parts of your code elsewhere by making procedures. Without having seen your app, I bet that it can be 30% simpler.
Cheers, Ghica.

-- 
You realize that your "answer" provides absolutely nothing that I did not know already? And that all your "suggestions" already have been addressed as being "not a solution" for the current situation?
I am asking if there is a limit to the size and number of blocks. And the reason I am testing on the emulator is to ensure the application will be compatible with 100% of all devices out there.
Without having seen my app, your "bet" is 100% wrong.
The code is already well over 75% procedures, and less than 25% event traps.

-- 

which should represent about 3500 statement-blocks. The other screens that currently load and run fine each have about 2500 statement-blocks total.

That is a lot, but is it really *too much*?


yes
see the following tips and in your case especially #3 and #4

1. switch screens correctly 

2. follow these recommendations Using Images with App Inventor

3. avoid redundancy
probably it helps to read chapter 19 - 21 in Dave's book http://www.appinventor.org/book2 to get an idea how to do DRY programming with App Inventor https://en.wikipedia.org/wiki/Don%27t_repeat_yourself



6. Backup your project frequently, see also http://twodogapps.com/?page_id=686#BackupWork
Taifun

-- 
Another completely besides the point answer.
1- this is not an issue of screen switching, it is an issue of screen not starting
2- I am not using images
3- the code has virtually no redundancy, it bombs out even before I bring in the event trappers blocks, with only the procedures being added to the screen
4- one of the reason I would resist splitting the screen to two more screens is that it will reduce the reuse ratio
5- the .apk file is 2.3 M, that is pretty far from the 10 M limit
6- how is that even relevant? I have 5 versions of the app at different levels of integration and different configurations of "work around", plus 3 additional archived versions, and 4 retained "check-points" (I recently deleted 11 extra check-points to reduce my footprint on the servers)

I think my question was pretty specific about needing to know by how much this is too much, in order to find out how radical a solution is needed.
I realize you are trying to "help" but saying "you got a problem" (which I was somewhat already aware of) is NOT helping.

--
1- this is not an issue of screen switching, it is an issue of screen not starting

yes, I posted all my general tips, sorry, if this is confusing for you
for you the relevant tips are as mentioned #3 and #4
your issue is to have too much blocks in one (or more) of your screens



3- the code has virtually no redundancy
without providing some screenshots this is what we only can guess and this guess is based on our experience



4- one of the reason I would resist splitting the screen to two more screens is that it will reduce the reuse ratio
most probably there is no need to split the screen


5- the .apk file is 2.3 M, that is pretty far from the 10 M limit

that's not relevant here, your issue is too much blocks in one (or more) of your screens


I think my question was pretty specific about needing to know by how much this is too much, 

there is no fix limit, when you get problems and you got problems, then you have too much 


Taifun

-- 
You built a complicated app with a compiler intended primarily as a teaching tool.  Wonderful, however it does not work as expected.  You possibly would have a better result using a professional compiler like Eclipse or Android Studio 2 (which are free)  or B4A or Delphi with the mobile add on pack etc.  Some professionals use AI2 as a prototyping tool since its performance capabilities in many areas are limited compared to the professional tools.

You seem convinced you have to develop using the emulator.  Why not follow the suggestions to use AI Companion or USB with a real device; get your app working there then try either other devices or a fancier emulator other than the stock Google emulator.  to ensure compatibility with other defices  If you want a better emulator, go to genymotion.com.  The emulator that comes with AI2  is the standard emulator provided with the Google SDK..  It is known to balk with large AI2 programs.  Why?  Because it is an emulator, not real hardware.    It has a limited memory and it's performance is dependent on your computer's cpu.  Be aware, the genymotion emulator has it own issues, is more complex and more difficult to use.

No one on the forum is clairvoyant but you only provide a verbal description of what does not work.  If you want help debugging block images might be useful in many instances.  However your app has over 3500 blocks, you most probably have exceeded the capabilities of either your emulator or your ability to create a workable project.  Are you aware that if loading your blocks over the server takes more than 60 seconds, Googles (not MIT)  Cloud will FAIL and the Project may not render on and emulator or even using WIFI?

You are discovering building complex apps that probably should really be run on a real computer might not work as hoped.  You are aware AI2's screen graphics are particularly SLOW compared to apps built with other platforms?  The price one pays using a relatively easy to use tool compared to learning Java when developing Android apps.



-- 
I tested your app and in this case the issue is that the screen layout is so complex that it is causing the companion to run out of memory. Because the emulator covers devices back to Android version 1.5, it is limiting processes to 16 MB of RAM. Most new Android devices will allow for 32 MB or more of RAM per process. I used the companion on a Samsung Galaxy S4 and was able to load all of your screens without issue because it allows the process 128 MB of RAM. It is possible that there are ways of optimizing the companion code so that these more complicated screens will work in the emulator, but that will take some time and effort on our part. In the meantime, if you can get your hands on an Android phone and test using the companion, that will be your best opportunity to finishing your app.

Evan

-- 
Well, "teaching tools" is a bit of a stretch. It could have started like that, but does not have to still be called only that. For the record, the first programming language I learned -- that was in 1975 -- was Pascal. Back then, it was touted as a teaching language, but don't tell that it is ONLY a teaching environment to all the people building real life application in Lazarus/Free Pascal or Delphi.

My basic point is that there are limitations to the emulator which I do not know are representative of some of the most limited devices out there, as far as the number of blocks is concerned; but those limitations are not explicitly documented, hence the issue. As I built the app, and the list of requirements and features grew, I did consider moving the whole project to a different environment. However, that would mean essentially giving up of about 1000 hours of work and starting from scratch, while pressing forward could be just a few weeks away, as long as the limitations can be addressed through some tweaking.

Still, the problem was not an issue of debugging, but of system interface and resources allocation. I think that I made that clear from the get go, as the code was not running, and could not even be made to run as it lacked the calls to the procedures from the still missing even traps; but was only trying to load, on one of the screens.

I feel that my experience will prove invaluable to whoever comes after and tries similar developments, I am just surprised that I seem to be the first one to ever do this (mind you, I have a tendency to "stretch the envelope". When that Atari Portfolio came out in 1989, it was stated that one would not use it to type the "next great american novel". But I did write a full length novel on this--on-lookers may debate whether it qualifies as a "next great american novel", particularly since it is science fiction, and most of it is set in space, but I digress).

I take good note of this "google time out" issue. This is another thing that perhaps should be posted somewhere prominent, as opposed to being found only in forum response. That said, the application is not intended to be CPU intensive. One would be expected to enter data and get an answer from it in the course of less than one minute, perhaps once or twice a week. The problematic screen is supposed to offer database edition capability, to revisit and potentially correct previously entered data, and is not expected to be run even that infrequently; performance is not as paramount as reliability and data visibility.

Thanks for the insight.


CBVG



-- 
Now that is what I call a *good* answer.
Yes, the application is complex, and from a philosophical point of view, does need to cater to any devices, including the ones most limited in memory (right up to Cupcake, if need be)

You claim that you tested my app? How did you manage to access it? Aren't those supposed to be linked to a google mail account, and thus locked? 

It is reassuring to learn that the emulator is representative of the weakest type of Android device, this indeed would serve as a demonstration that if it does run there, then it will run everywhere. On the flip side, relying on my own Marshmallow Android device, I would quite possibly have been totally oblivious to the limitations others may have, taking liberties that would make it not as portable as it should. Hence my insistance to rely on the emulator (unless someone has a vintage Cupcake device for sale, cheap?)

I did a bit of soul searching, and will likely end up splitting the problematic screen in two. That screen had dual modes, using a button click to toggle between them and relying on "visibility" to change the display appropriately, so might not be too much of a problem to work-out, although my sensitivity to code optimisation would be hurt by the need to duplicate some procedures in both screen (unless I find a clever way of invoking the call to an auxiliary screen that serves no other purpose than running those procedures which does not end up taking even more resources for said page switching).

Thanks for your help and insight.


CBVG

-- 
Hi Vincent,

There are several things here that we should address. First, you have a complex app and need to help. Evan's answer is right on the money you should try this and see if that helps finsh your app. BTW we are currently working on a solution with regards to updating the emulator and allowing more features. But, in the meantime head Evan's suggestions. Second, I think you realize that their are complex apps that touch the outer bounds for App Inventor and therefore often suits the space of Teaching Tool, with Ghica and Taifun suggestions and best practices most of our community has been having a lot of success. To finish we are continuing to refine, update and enhance App Inventor and our communities experiences. 

Best,

Andrew McKinney
Director of Software Development 
MIT App Inventor Project


 --
 I would like to know if there are alternative approaches that could be tried before launching myself in a major reprogramming effort that I do not know would be successfu

If you want another straw to grasp, look into sending some of your application complexity into a Web Viewer via Javascript files in the Media drawer.

Here are two examples from puravidaapps.com


There might be a structural cost in working around a delay in getting results back from the Web Viewer 

Good luck with your app!
ABG

-- 
Intriguing... That could be a clever solution. On my side, the downside is that this is Javascript, which is not a language I master. I would have to consider the time to get familiar with the specifics of that language.

That said, if the number crunching activity is passed on to a web viewer component, does this imply that said web viewer will then have a memory foot-print that has to be taken into consideration?



CBVG


-- 
1- This was not confusing to ME, it was confusing to YOU, that is why YOU brought up this irrelevant point
3- I know what I am doing, I am what you would call a "seasoned" programmer. I am new only to App Inventor. If I say there is virtually no redundancy, take it as a given. And given the complexity of the app, passing "screenshots" of the all the blocks from the problematic screen page would need at least 15 screen captures (after reorganizing to maximize coverage), at maximum zoom-out, where everything is microprint. Trust me, you don't want to go there.
4- Seems to me the consensus is that there is; some processing has to go somewhere else to lighten the load on that screen
5- If it is not relevant (which is precisely why I mentioned it) why did YOU bring up that topic?

-- I feel that the key issue is "how many bocks is too much", not "when you have too much, you have too much", which I already pretty much had figured out. What is needed is some metric that would say something like 3000 blocks total on a screen is usually OK, while 3200 probably not (or whatever values it should be). That is the kind of info that would be practical, reliable, and useful.


-- 
Intriguing... That could be a clever solution. On my side, the downside is that this is Javascript, which is not a language I master. I would have to consider the time to get familiar with the specifics of that language.


Another AI2 user recently posted a new AI2-Javascript sample here
It computes the hypotenuse of a right triangle, given the two non-diagonals sides lengths.

The sample should you an idea of the amount of boiler plate needed to get into Javascript's math capabilities,
how to pass multiple inputs across the AI2/WebViewer interface,
how to force a pause for the Web Viewer to do is work,
anf how to retrieve the calculation output.

Though I've been scared away from diving into my phone-book sized Javascript book,
I find that AI2 sample clear, even in a foreign language.


That said, if the number crunching activity is passed on to a web viewer component, does this imply that said web viewer will then have a memory foot-print that has to be taken into consideration?

I have no data on that.  I assume you won't need more than one Web Viewer component, since you can feed it different html pages from your Media drawer and different dynamic input.  The Blocks Editor and Designer can't possibly be affected by the contents of what appear to them as extra files in the Media Drawer.  Only the Web Viewer sees them, at run time, as your blocks feed them into the Web Viewer.

Again, this just a straw to grab, under the general category of "Turn Blocks into Data"

ABG
--  
(Throwing more stuff at the wall in hope something sticks...)
Under the category of "Turn Blocks into Data", here's another idea for how to reduce the component and blocks count in an app with a lot of input fields.
(I haven't seen your app, so I'm guessing here.)

Think of how your data would be represented in JSON.
JSON lets you encode all your app's data in a structured text string.
The attribute names, bracket nesting and element grouping can be summarized in a JSON schema,
that summarizes the structure of the data and that can be used to drive the capture of such data from a user,
a field at a time, into a nested AI2 list-of-pairs structure.

You probably don't need to package your data into JSON strings for interchange over the Web,
but having the schema on hand can help a small number of input components (a single label and text box) be re-used 
(probably under a ListView showing the current data level's elements and values)
to fill in your data structure.

For an example of such a structure, see this sample doc, based on XML:
(The doc only shows how to parse and navigate the data, not how to build it up.)
You could trade off navigating nested lists for looking up TinyDB data using concatenated tags/subtags.

This refactoring of your input would save you on components,
at the expense of having to code a little schema-driven input presenter and gatherer.

Unfortunately, I don't have a sample for you.

If you're unfamiliar with multi-level data navigation, see this sample:

ABG



--  
Splitting the screen helped one (although it will still need to be augmented with an inter page switching code), but the other one is still beyond being loadable. Is there a rule of thumb as to the memory footprint of various components? For instance, how much memory is required to support an additional label? An extra horizontal arrangement? One more button? And how much memory does each extra block in the "block" side take?

I presume that I could let the layout be less sophisticated, but all the effort to reduce the nested arrangements, would that be worth it?

I have already given up on a feature that was "neat" but not absolutely necessary. Now, it looks like I may have to cut in the functionality, which will hurt the application.
And of course, I resist the idea of moving up in terms of minimum system requirement; that would pretty much be the last option I want.

Any additional insight?

Thanks


CBVG


-- 
The device-dependent font size problem continues to be an aggravation in AI2.
Here's a link to a thread where AI2 user Boban shows off his Web Viewer trick to find the missing fudge factor ...

ABG


-- 
I see.

Well, if that is a problem, I will implement a font size selector function in the maintenance screen. Once established, a scaling factor would be passed on between screens using TinyDB. Of course, the flip side is that every label, every caption, every text box would need a object.FontSize set-up assignment. I juts hope that I can scavenge enough memory by regrouping labels into multi-lines ones.


CBVG


-- 
작성자: 시간:

댓글 1개:

피드 구독하기: 댓글 (Atom)